Bug#861791: ITP: node-create-ecdh -- create browserifiable ECDH

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

* Package name: node-create-ecdh
  Version : 4.0.0
  Upstream Author : Calvin Metcalf
* URL : https://github.com/crypto-browserify/createECDH
* License : Expat
  Programming Lang: JavaScript
  Description : create browserifiable ECDH

 In io.js or node >= 0.11 this module is just a shortcut to
crypto.createECDH.
 In node <= 0.11 or the browser this is a pure JavaScript
implimentation, more
 specifically a wrapper around elliptic to give it the same API as node.
 .
 Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature


Bug#861788: unblock: libosmium/2.11.3-1

2017-05-03 Thread Bas Couwenberg
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libosmium

Upstream has only fixed bugs for this release in line with the freeze
policy.

(include/attach the debdiff against the package in testing)

unblock libosmium/2.11.3-1

Kind Regards,

Bas
diff -Nru libosmium-2.11.1/CHANGELOG.md libosmium-2.11.3/CHANGELOG.md
--- libosmium-2.11.1/CHANGELOG.md   2017-03-07 13:54:48.0 +0100
+++ libosmium-2.11.3/CHANGELOG.md   2017-05-03 14:01:48.0 +0200
@@ -8,6 +8,24 @@
 
 ### Fixed
 
+## [2.11.3] - 2017-05-03
+
+### Fixed
+
+- Two bugs in area assembler affecting very complex multipolygons and
+  multipolygons with overlapping or nearly overlapping lines.
+- Invalid use of iterators leading to undefined behaviour in area assembler
+  code.
+- Read OPL file correctly even if trailing newline in file is missing.
+
+
+## [2.11.2] - 2017-04-10
+
+### Fixed
+
+- Use minimum size of 64 bytes for buffers. This fixes an infinite loop
+  when buffer size is zero.
+
 
 ## [2.11.1] - 2017-03-07
 
@@ -531,7 +549,9 @@
   Doxygen (up to version 1.8.8). This version contains a workaround to fix
   this.
 
-[unreleased]: https://github.com/osmcode/libosmium/compare/v2.11.1...HEAD
+[unreleased]: https://github.com/osmcode/libosmium/compare/v2.11.3...HEAD
+[2.11.3]: https://github.com/osmcode/libosmium/compare/v2.11.2...v2.11.3
+[2.11.2]: https://github.com/osmcode/libosmium/compare/v2.11.1...v2.11.2
 [2.11.1]: https://github.com/osmcode/libosmium/compare/v2.11.0...v2.11.1
 [2.11.0]: https://github.com/osmcode/libosmium/compare/v2.10.3...v2.11.0
 [2.10.3]: https://github.com/osmcode/libosmium/compare/v2.10.2...v2.10.3
diff -Nru libosmium-2.11.1/CMakeLists.txt libosmium-2.11.3/CMakeLists.txt
--- libosmium-2.11.1/CMakeLists.txt 2017-03-07 13:54:48.0 +0100
+++ libosmium-2.11.3/CMakeLists.txt 2017-05-03 14:01:48.0 +0200
@@ -25,7 +25,7 @@
 
 set(LIBOSMIUM_VERSION_MAJOR 2)
 set(LIBOSMIUM_VERSION_MINOR 11)
-set(LIBOSMIUM_VERSION_PATCH 1)
+set(LIBOSMIUM_VERSION_PATCH 3)
 
 set(LIBOSMIUM_VERSION
 
"${LIBOSMIUM_VERSION_MAJOR}.${LIBOSMIUM_VERSION_MINOR}.${LIBOSMIUM_VERSION_PATCH}")
diff -Nru libosmium-2.11.1/debian/changelog libosmium-2.11.3/debian/changelog
--- libosmium-2.11.1/debian/changelog   2017-03-07 18:31:00.0 +0100
+++ libosmium-2.11.3/debian/changelog   2017-05-03 18:44:44.0 +0200
@@ -1,3 +1,17 @@
+libosmium (2.11.3-1) unstable; urgency=medium
+
+  * New upstream bugfix release.
+- Use minimum size of 64 bytes for buffers. This fixes an infinite
+  loop when buffer size is zero.
+- Two bugs in area assembler affecting very complex multipolygons and
+  multipolygons with overlapping or nearly overlapping lines.
+- Invalid use of iterators leading to undefined behaviour in area
+  assembler code.
+- Read OPL file correctly even if trailing newline in file is missing.
+  * Update watch file to limit results to 2.11.x releases.
+
+ -- Bas Couwenberg   Wed, 03 May 2017 18:44:44 +0200
+
 libosmium (2.11.1-1) unstable; urgency=medium
 
   * New upstream bugfix release.
diff -Nru libosmium-2.11.1/debian/watch libosmium-2.11.3/debian/watch
--- libosmium-2.11.1/debian/watch   2017-03-07 18:23:24.0 +0100
+++ libosmium-2.11.3/debian/watch   2017-05-03 18:38:25.0 +0200
@@ -4,4 +4,4 @@
 
uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/;s/RC/rc/,\
 
filenamemangle=s/(?:.*\/)?(?:rel|v|libosmium)[\-\_]?(\d[\d\-\.]+)\.(tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))/libosmium-$1.$2/
 \
 https://github.com/osmcode/libosmium/releases \
-(?:.*/)?(?:rel|v|libosmium)[\-\_]?(\d[\d\-\.]+)\.(?:tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
+(?:.*/)?(?:rel|v|libosmium)[\-\_]?(2\.11\.\d[\d\-\.]*)\.(?:tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
diff -Nru libosmium-2.11.1/include/osmium/area/assembler.hpp 
libosmium-2.11.3/include/osmium/area/assembler.hpp
--- libosmium-2.11.1/include/osmium/area/assembler.hpp  2017-03-07 
13:54:48.0 +0100
+++ libosmium-2.11.3/include/osmium/area/assembler.hpp  2017-05-03 
14:01:48.0 +0200
@@ -474,17 +474,17 @@
 
 class rings_stack_element {
 
-int32_t m_y;
+double m_y;
 detail::ProtoRing* m_ring_ptr;
 
 public:
 
-rings_stack_element(int32_t y, detail::ProtoRing* ring_ptr) :
+rings_stack_element(double y, detail::ProtoRing* ring_ptr) :
 m_y(y),
 m_ring_ptr(ring_ptr) {
 }
 
-int32_t y() const noexcept {
+double y() const noexcept {
 return m_y;
 }
 
@@ -504,7 +504,7 @@
 return m_y < rhs.m_y;
 }
 
-}; // class ring_stack_element
+}; // class rings_stack_element
 
 using rings_stack = std::vector;
 
@@ -592,7 

Bug#847613: TAG: nextcloud-client -- desktop client for nextcloud

2017-05-03 Thread Lev Lazinskiy
Owner: l...@levlaz.org
Control: retitle -1 ITP: nextcloud-client -- desktop client for nextcloud



Bug#861787: ITP: node-is-binary-path -- check if a filepath is a binary file

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

* Package name: node-is-binary-path
  Version : 2.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/is-binary-path#readme
* License : Expat
  Programming Lang: JavaScript
  Description : check if a filepath is a binary file

 This library checks if a filepath is a binary file by checking known binary
 file extentions list.
 .
 Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature


Bug#861786: activemq: adjust CVE identifier retrospectively in debian/changelog for 5.14.3-3 upload

2017-05-03 Thread Salvatore Bonaccorso
Source: activemq
Version: 5.14.3-3
Severity: minor

Hi activemq maintainers,

The CVE id was typoed in the 5.14.3-3 upload. To avoid confusion can
you consider adjusting the reference on any next upload of activemq?

The correct CVE id was CVE-2015-7559.

If you have in your team policy to not ammend older changelog entries,
then please close this request.

Regards,
Salvatore



Bug#861783: dpkg: trying to local divert a file diverted by a package does not work

2017-05-03 Thread Joshua Hudson
(If the suggestions below end up not being accepted, then you could
simply use your local firefox, and create a dummy package to fulfill
dependencies with something like equivs.)

Ah yes I suppose I was not clear. The firefox-esr package causes all
its depends to be installed, which is what allows the local firefox to
run; otherwise the local firefox would have a host of missing depends.



Bug#860660: golang-github-cznic-fileutil: FTBFS on i386: dh_auto_test

2017-05-03 Thread Roger Shimizu
control: forwarded -1 https://github.com/cznic/fileutil/issues/16
control: tag -1 +patch

Backport the patch from upstream, FTBFS issue seems fixed.
So I pushed commit to master (w/o the releasing commit), and mentors branch
with the releasing commit.

Package is uploaded to mentors for RFS.
Thank you!

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


pgpuBZXqjU0Vs.pgp
Description: PGP signature


Bug#860660: Pending fixes for bugs in the golang-github-cznic-fileutil package

2017-05-03 Thread pkg-go-maintainers
tag 860660 + pending
thanks

Some bugs in the golang-github-cznic-fileutil package are closed in
revision a8dbbc2c3e52e0d5dae95878a9725b48487b6baf in branch 'master'
by Roger Shimizu

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-cznic-fileutil.git/commit/?id=a8dbbc2

Commit message:

debian/patches: Add a patch from upstream

Patch to fix FTBFS on 32-bit system

Closes: #860660



Bug#861785: libreoffice-calc: has high CPU usage and consumes all available memory when closed

2017-05-03 Thread Andrew Enderson
Package: libreoffice-calc
Version: 1:5.2.6-2
Severity: important

Dear Maintainer,

* What led up to the situation?
Closing LibreOffice-Calc after attempting to swap two columns of text data.

* What exactly did you do (or not do) that was effective?
1. Entered 20 text entries in each of the first 3 columns.
2. Highlight the entire 3rd column by selecting the ‘C’ column heading
3. Right clicked and selected Cut to cut the column 3 data.
4. Highlighted the entire 2nd column by selecting the ‘B’ column heading.
5. Right clicked the ‘B’ column heading again and selected Past Special, then
selected ‘Right’ under ‘Shift Cells’ and clicked OK.
6. Next, clicked ‘X’ on the Window frame to close the application, and selected
discard when prompted to save the spreadsheet.

* What was the outcome of this action?
The LibreOffice-Calc application window disappeared, and the computer quickly
became very sluggish and difficult to use. I opened System-Monitor and found
that all available memory was in use (7 GiB), and swap memory was being
consumed. I then changed to the Process view, and found there was still an
entry for soffice.bin, so I selected that Process entry and clicked 'End
Process'. Switching back to the Resoures view, I saw the memory usage
immediately drop back down to about 1 GiB, and the computer became responsive
again.

* What outcome did you expect instead?
The LibreOffice-Calc applicatioin would close, and it would release the memory
it was using - not start consuming all available memory.

* Some additional information.
I’ve been able to consistently reproduce this issue on Gnome 3. I can open
System-Monitor to the Resources view, open LibreOffice-Calc, perform the steps
above, and then watch all memory be consumed in System-Monitor after closing
Calc. I can then end the soffice.bin process using System-Monitor, and see the
memory usage drop back down. I also attempted to reproduce this issue on Ubuntu
Mate 17.04 and on the Solus Budgie desktops, but I could not reproduce it on
those desktop environments, but I was able to reproduce it on the Solus Gnome 3
desktop, and Solus currently has a newer version of LibreOffice than is in
Debian, so it looks like this may be related to the Gnome 3 desktop environment
somehow.

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

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

Versions of packages libreoffice-calc depends on:
ii  coinor-libcbc3   2.8.12-1+b2
ii  coinor-libcoinmp1v5  1.7.6+dfsg1-2
ii  coinor-libcoinutils3v5   2.9.15-4
ii  dpkg 1.18.23
ii  libblas3 [libblas.so.3]  3.7.0-1
ii  libboost-filesystem1.62.01.62.0+dfsg-4
ii  libboost-iostreams1.62.0 1.62.0+dfsg-4
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-10
ii  libetonyek-0.1-1 0.1.6-5
ii  libgcc1  1:6.3.0-14
ii  libicu57 57.1-6
ii  liblapack3 [liblapack.so.3]  3.7.0-1
ii  liblcms2-2   2.8-4
ii  libmwaw-0.3-30.3.9-1
ii  libodfgen-0.1-1  0.1.6-2
ii  liborcus-0.11-0  0.11.2-3+b1
ii  libreoffice-base-core1:5.2.6-2
ii  libreoffice-core 1:5.2.6-2
ii  librevenge-0.0-0 0.0.4-6
ii  libstdc++6   6.3.0-14
ii  libwps-0.4-4 0.4.5-1
ii  libxml2  2.9.4+dfsg1-2.2
ii  lp-solve 5.5.0.15-4+b1
ii  uno-libs35.2.6-2
ii  ure  5.2.6-2
ii  zlib1g   1:1.2.8.dfsg-5

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
pn  ocl-icd-libopencl1  

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.7+b1
ii  fonts-opensymbol  2:102.7+LibO5.2.6-2
ii  libboost-date-time1.62.0  1.62.0+dfsg-4
ii  libc6 2.24-10
ii  libcairo2 1.14.8-1
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.1-8
ii  libcurl3-gnutls   7.52.1-5
ii  libdbus-1-3   1.10.18-1
ii  libdbus-glib-1-2  0.108-2
ii  libdconf1 0.26.0-2+b1
ii  libeot0   0.01-4+b1
ii  libexpat1 2.2.0-2
ii  libexttextcat-2.0-0   3.4.4-2+b1
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-14
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglew2.02.0.0-3+b1
ii  libglib2.0-0  2.50.3-2
ii  libgltf-0.0-0v5   0.0.2-5
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgraphite2-31.3.9-4
ii  

Bug#861713: netdata: `service netdata restart` fails due to missing pidfile

2017-05-03 Thread Daniel Ring
I use sysvinit (upgraded from wheezy, when it was the default).
The init script that `service` calls is "debian/netdata.init" from the source 
package. Running it directly from init.d has the same effect.

May 3, 2017 6:02 AM, "Lennart Weller"  wrote:

> What init do you use on your system?
> The creation of the pid file should have been done by the init.
> 
> May 3, 2017 5:09 AM, "Daniel Ring"  wrote:
> 
>> Package: netdata
>> Version: 1.5.0+dfsg-4
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> The init scripts provided with this package do not seem to work properly.
>> I reported this bug upstream at 
>> https://github.com/firehol/netdata/issues/2135, but the init
>> scripts provided with this package have been modified for Debian so I'm not 
>> sure where the issue
>> first arose.
>> The directory "/var/run/netdata" is not created by default on my system. 
>> Creating it and chowning
>> to netdata:netdata had no effect.
>> 
>> Running `service netdata restart` results in the following output:
>> [ ok ] Stopping the netdata daemon...done (not running - there is no 
>> /var/run/netdata/netdata.pid).
>> [] Starting the netdata daemon...2017-05-02 19:55:59: netdata: ERROR: 
>> IPv4 bind() on ip
>> '127.0.0.1' port 1 failed. (errno 98, Address already in use)
>> 2017-05-02 19:55:59: netdata: ERROR: Cannot bind to ip '127.0.0.1', port 
>> 1
>> 2017-05-02 19:55:59: netdata: FATAL: Cannot listen on any socket. Exiting... 
>> # : Success
>> 
>> 2017-05-02 19:55:59: netdata: INFO: Saving database...
>> 2017-05-02 19:55:59: netdata: INFO: netdata exiting. Bye bye...
>> failed.
>> 
>> Running `service netdata stop` results in the following output:
>> [ ok ] Stopping the netdata daemon...done (not running - there is no 
>> /var/run/netdata/netdata.pid).
>> 
>> A netdata instance is running normally in the background in both cases.
>> Running `service netdata start` works as expected.
>> 
>> -- System Information:
>> Debian Release: 8.7
>> APT prefers stable-updates
>> APT policy: (500, 'stable-updates'), (500, 'stable')
>> Architecture: i386 (i686)
>> 
>> Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: sysvinit (via /sbin/init)
>> 
>> Versions of packages netdata depends on:
>> ii adduser 3.113+nmu3
>> ii init-system-helpers 1.22
>> ii libc6 2.19-18+deb8u7
>> ii libcap2-bin 1:2.24-8
>> ii libuuid1 2.25.2-6
>> ii lsb-base 4.1+Debian13+nmu1
>> ii netdata-data 1.5.0+dfsg-4
>> ii python 2.7.9-1
>> ii python-yaml 3.11-2
>> ii zlib1g 1:1.2.8.dfsg-2+b1
>> 
>> Versions of packages netdata recommends:
>> pn nodejs 
>> 
>> netdata suggests no packages.
>> 
>> -- Configuration Files:
>> /etc/netdata/netdata.conf changed [not included]
>> 
>> -- no debconf information



Bug#861782: mariadb-server-10.1: Upgrade fails because mariadb-server-10.1.prerm fails to stop mysqld.

2017-05-03 Thread inkbottle
On Thursday, May 4, 2017 4:53:52 AM CEST Ondřej Surý wrote:
> And output of:
> 
> pgrep mysqld
> 
> does it return the same pid as pidof command?
> 
> Cheers,

It think you are right, there are 2 processes:
# ps uax | egrep $(pidof /usr/sbin/mysqld|tr ' ' '|')  # as root
chris 6177  0.5  1.7 606652 141384 ?   Sl   03:20   0:40 
/usr/sbin/mysqld --defaults-file=/home/chris/.local/share/akonadi/mysql.conf 
--datadir=/home/chris/.local/share/akonadi/db_data/ 
--socket=/tmp/akonadi-chris.UBoT4r/mysql.socket
mysql11527  0.3  0.9 669628 74320 ?Ssl  05:17   0:00 
/usr/sbin/mysqld

When I do, as in the "prerm" script:
invoke-rc.d mysql stop

it stops only the mysqld of user mysql
(no matter how many times)
and
pidof -c /usr/sbin/mysqld
continues to give a positive answer.

However, initially,
pidof -c /usr/sbin/mysqld # (with -c, on two lines, w/o one the same line)
was giving two pid.
But when done after the
invoke-rc.d mysql stop
it gives only one pid.
So it might be, that at that point, installation could keep going, instead of 
stopping.


Also the two processes are own by different users, so they are easy to 
differentiate
in a test.

Best,
Chris



Bug#861576: new dpkg colourized output doesn't respect /etc/terminal-colors.d/disable

2017-05-03 Thread Guillem Jover
Control: severity -1 wishlist

On Mon, 2017-05-01 at 08:57:10 +0200, Sven Joachim wrote:
> On 2017-04-30 18:47 -0400, Brad Barnett wrote:
> > Package: dpkg
> > Version: 1.18.23
> >
> > Newer versions of dpkg have colourized output.
> >
> > I can see the usage case for this, and I can see the value for some.
> >
> > However, for others, it is a major detractor.
> >
> > One of the issues with the recent colourization of the userland, is that
> > each has its own way to disable it.
> >
> > Which is why /etc/terminal-colors.d/disable exists, as far as I can see.
> >
> > Yet, dpkg does not respect /etc/terminal-colors.d/disable.  dmesg does.
> > Lots of other packages do.
> 
> AFAICS, those "lots of other packages" are all built from the same
> source package, namely util-linux[1].  So this is far from standardized.

Indeed, went through the same process of searching on codesearch and
then checking the man page, and reaching some blog posts from
util-linux upstream briefly describing this stuff.

Will need to check if there's other alternative prior art and similar.
I'm a bit undecided about this though, in a way it sounds nice, but
dunno.

Thanks,
Guillem



Bug#861783: dpkg: trying to local divert a file diverted by a package does not work

2017-05-03 Thread Guillem Jover
Control: reassign -1 firefox,firefox-esr
Control: retitle -1 firefox: Usage of diversions disallows more than two 
installed implementations
Control: severity -1 wishlist

Hi!

On Wed, 2017-05-03 at 18:48:34 -0700, Joshua wrote:
> Package: dpkg
> Version: 1.18.23
> Severity: normal

>* What led up to the situation?
> 
> firefox-esr has a diversion of /usr/bin/firefox; and package firefox-esr
> must be installed for dependency resolution; however I actually need
> to use a package of firefox that doesn't have a .dpkg
> 
> So I try dpkg-divert /usr/bin/firefox
> 
> Nope!

(If the suggestions below end up not being accepted, then you could
simply use your local firefox, and create a dummy package to fulfill
dependencies with something like equivs.)

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> All variants of dpkg-divert that remotely made sense to try.
> 
> I tried reading the source code to determine if I could safely knock
> the check out. This was inconclusive as I don't understand it well enough
> to tell what would happen.

The problem is that diversion are not stackable, so only a couple of
packages providing the same pathname can be installed at the same
time, if there's need for more then those should be using alternatives
for example.

>* What was the outcome of this action?
> 
> Frustration.
> 
>* What outcome did you expect instead?
> 
> let go of /usr/bin/firefox so I could add symlink
> /usr/bin/firefox -> /usr/local/lib/firefox/firefox

That's something for the firefox maintainers to decide.

Thanks,
Guillem



Bug#861782: mariadb-server-10.1: Upgrade fails because mariadb-server-10.1.prerm fails to stop mysqld.

2017-05-03 Thread Ondřej Surý
And output of:

pgrep mysqld

does it return the same pid as pidof command?

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Thu, May 4, 2017, at 04:40, Ondřej Surý wrote:
> Chris,
> 
> I don't use KDE, so I will need a little of your help.
> 
> Could you do on a running system:
> 
> ps uax | grep $(pidof -c /usr/sbin/mysqld)
> 
> and
> 
> is there a difference between:
> 
> pidof /usr/sbin/mysqld
> 
> and
> 
> pidof -c /usr/sbin/mysqld
> 
> ?
> 
> Cheers,
> -- 
> Ondřej Surý 
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
> Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
> fast DNS(SEC) resolver
> Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
> pečení chleba všeho druhu
> 
> On Thu, May 4, 2017, at 03:17, chris wrote:
> > Package: mariadb-server-10.1
> > Version: 10.1.22-4
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > Upgrade from 1 month old version failed.
> > 
> > Installation says:
> > 
> > There is a MySQL server running, but we failed in our attempts to stop
> > it.
> > Stop it yourself and try again!
> > 
> > and fails.
> > 
> > When looking at:
> > /var/lib/dpkg/info/mariadb-server-10.1.prerm
> > one can see:
> > invoke-rc.d mysql stop
> > pidof -c /usr/sbin/mysqld
> > 
> > Executing those lines myself, I get:
> > # invoke-rc.d mysql stop; pidof -c /usr/sbin/mysqld
> > 3174
> > 
> > Similarly:
> > # systemctl stop mariadb.service; pidof -c /usr/sbin/mysqld
> > 3174
> > 
> > However I could stop the sever as a plain user:
> > $ akonadictl stop
> > 
> > Verify it is stopped:
> > # pidof -c /usr/sbin/mysqld
> > 
> > Then the upgrade worked flawlessly:
> > # apt-get upgrade
> > 
> > A very verbose description can be found there:
> > https://lists.debian.org/debian-kde/2017/05/msg0.html
> > 
> > 
> > Best,
> > Chris
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: 9.0
> >   APT prefers unstable
> >   APT policy: (500, 'unstable'), (500, 'testing')
> > Architecture: amd64
> >  (x86_64)
> > 
> > Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
> > LC_ALL set to en_US.UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > Versions of packages mariadb-server-10.1 depends on:
> > ii  adduser   3.115
> > ii  debconf [debconf-2.0] 1.5.60
> > ii  galera-3  25.3.20-1
> > ii  gawk  1:4.1.4+dfsg-1
> > ii  init-system-helpers   1.48
> > ii  iproute2  4.9.0-1
> > ii  libaio1   0.3.110-3
> > ii  libc6 2.24-10
> > ii  libdbi-perl   1.636-1+b1
> > ii  libpam0g  1.1.8-3.5
> > ii  libstdc++66.3.0-16
> > ii  lsb-base  9.20161125
> > ii  lsof  4.89+dfsg-0.1
> > ii  mariadb-client-10.1   10.1.22-4
> > ii  mariadb-common10.1.22-4
> > ii  mariadb-server-core-10.1  10.1.22-4
> > ii  passwd1:4.4-4
> > ii  perl  5.24.1-2
> > ii  psmisc22.21-2.1+b2
> > ii  rsync 3.1.2-2
> > ii  socat 1.7.3.1-2+b1
> > ii  zlib1g1:1.2.8.dfsg-5
> > 
> > Versions of packages mariadb-server-10.1 recommends:
> > ii  libhtml-template-perl  2.95-2
> > 
> > Versions of packages mariadb-server-10.1 suggests:
> > ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-4
> > pn  mariadb-test   
> > pn  netcat-openbsd 
> > pn  tinyca 
> > 
> > -- debconf information:
> >   mariadb-server-10.1/postrm_remove_databases: false
> >   mariadb-server-10.1/nis_warning:
> >   mariadb-server-10.1/old_data_directory_saved:
> > 
> 



Bug#851877: fails every time

2017-05-03 Thread Adam Borowski
Control: severity -1 serious

Looks like for some reason it switched to failing 100% of the time now -- or
at least it does so on all of my setups.  I have yet to see the build
succeed, despite tens of attempts on amd64, armhf and i386.

The fail reason is same as in your report:

cat: /tmp/sslh_test.pid: No such file or directory
killing 
Can't kill a non-numeric process ID at ./t line 221.

(then it hangs until sbuild kills it)


> The bug should be reproducible with sbuild on a single CPU virtual
> machine, provided you try enough times (as the failure happens randomly).

All of my sbuilds are on real metal, at least four cores;
DEB_BUILD_OPTIONS=parallel=XXX is set appropriately.


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.



Bug#861782: mariadb-server-10.1: Upgrade fails because mariadb-server-10.1.prerm fails to stop mysqld.

2017-05-03 Thread Ondřej Surý
Chris,

I don't use KDE, so I will need a little of your help.

Could you do on a running system:

ps uax | grep $(pidof -c /usr/sbin/mysqld)

and

is there a difference between:

pidof /usr/sbin/mysqld

and

pidof -c /usr/sbin/mysqld

?

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu

On Thu, May 4, 2017, at 03:17, chris wrote:
> Package: mariadb-server-10.1
> Version: 10.1.22-4
> Severity: important
> 
> Dear Maintainer,
> 
> Upgrade from 1 month old version failed.
> 
> Installation says:
> 
> There is a MySQL server running, but we failed in our attempts to stop
> it.
> Stop it yourself and try again!
> 
> and fails.
> 
> When looking at:
> /var/lib/dpkg/info/mariadb-server-10.1.prerm
> one can see:
> invoke-rc.d mysql stop
> pidof -c /usr/sbin/mysqld
> 
> Executing those lines myself, I get:
> # invoke-rc.d mysql stop; pidof -c /usr/sbin/mysqld
> 3174
> 
> Similarly:
> # systemctl stop mariadb.service; pidof -c /usr/sbin/mysqld
> 3174
> 
> However I could stop the sever as a plain user:
> $ akonadictl stop
> 
> Verify it is stopped:
> # pidof -c /usr/sbin/mysqld
> 
> Then the upgrade worked flawlessly:
> # apt-get upgrade
> 
> A very verbose description can be found there:
> https://lists.debian.org/debian-kde/2017/05/msg0.html
> 
> 
> Best,
> Chris
> 
> 
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64
>  (x86_64)
> 
> Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages mariadb-server-10.1 depends on:
> ii  adduser   3.115
> ii  debconf [debconf-2.0] 1.5.60
> ii  galera-3  25.3.20-1
> ii  gawk  1:4.1.4+dfsg-1
> ii  init-system-helpers   1.48
> ii  iproute2  4.9.0-1
> ii  libaio1   0.3.110-3
> ii  libc6 2.24-10
> ii  libdbi-perl   1.636-1+b1
> ii  libpam0g  1.1.8-3.5
> ii  libstdc++66.3.0-16
> ii  lsb-base  9.20161125
> ii  lsof  4.89+dfsg-0.1
> ii  mariadb-client-10.1   10.1.22-4
> ii  mariadb-common10.1.22-4
> ii  mariadb-server-core-10.1  10.1.22-4
> ii  passwd1:4.4-4
> ii  perl  5.24.1-2
> ii  psmisc22.21-2.1+b2
> ii  rsync 3.1.2-2
> ii  socat 1.7.3.1-2+b1
> ii  zlib1g1:1.2.8.dfsg-5
> 
> Versions of packages mariadb-server-10.1 recommends:
> ii  libhtml-template-perl  2.95-2
> 
> Versions of packages mariadb-server-10.1 suggests:
> ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-4
> pn  mariadb-test   
> pn  netcat-openbsd 
> pn  tinyca 
> 
> -- debconf information:
>   mariadb-server-10.1/postrm_remove_databases: false
>   mariadb-server-10.1/nis_warning:
>   mariadb-server-10.1/old_data_directory_saved:
> 



Bug#861784: bluez: bluetooth headphones change from A2DP to hsp after about 30 minutes of playing music

2017-05-03 Thread Prashant L Rao
Package: bluez
Version: 5.43-2
Severity: important

Dear Maintainer,

   * What led up to the situation?
I connected to the A2DP sink on my BoatRockerz 600 headphones using blueman and 
began playing music using Audacious. After about half an hour the sound output 
suddenly became distorted. 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I re-paired the device and reconnected to the A2DP sink. 

   * What was the outcome of this action?
It worked and the distortion was gone.

   * What outcome did you expect instead?
The audio playback should have continued smoothly.



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

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

Versions of packages bluez depends on:
ii  dbus 1.10.18-1
ii  init-system-helpers  1.47
ii  kmod 23-2
ii  libc62.24-10
ii  libdbus-1-3  1.10.18-1
ii  libglib2.0-0 2.50.3-2
ii  libreadline7 7.0-2
ii  libudev1 232-22
ii  lsb-base 9.20161125
ii  udev 232-22

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  10.0-1

-- no debconf information



Bug#174331: macro support

2017-05-03 Thread Raphaël Droz
patch against git master

I had to changed my rsyslog format recently and logcheck is near to
unusable if I need to change/duplicate/transform all the rules
From 9fa05bd1202418da3a279c9f3bfe2a7c192e43c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Droz?= 
Date: Wed, 3 May 2017 22:45:02 -0300
Subject: [PATCH] added a MACRO expand system. Just add bash-style variable
 definition inside $RULEDIR/macros. logcheck-test -r support using a -m flag

---
 src/logcheck  | 12 
 src/logcheck-test | 30 ++
 2 files changed, 42 insertions(+)

diff --git a/src/logcheck b/src/logcheck
index a8c58ea..4a70773 100755
--- a/src/logcheck
+++ b/src/logcheck
@@ -223,6 +223,11 @@ cleanrules() {
 			error "Couldn't read $x"
 		fi
 	done
+
+	if [[ -n $RULEDIR/macros ]]; then
+	{ cat "$RULEDIR/macros" && echo "read -r -d '' str <<__EOF__"; } > "$cleaned/$rulefile"
+	fi
+
 	for rulefile in $(run-parts --list "$dir"); do
 	rulefile="$(basename "$rulefile")"
 	if [ -f "${dir}/${rulefile}" ]; then
@@ -233,6 +238,13 @@ cleanrules() {
 		|| error "Couldn't append to $cleaned/$rulefile."
 	fi
 	done
+
+	if [[ -n $RULEDIR/macros ]]; then
+	echo -e '__EOF__\necho "$str";' >> "$cleaned/$rulefile";
+	/usr/bin/env bash "$cleaned/$rulefile" > "$cleaned/$rulefile.tmp"
+	mv -f "$cleaned/$rulefile.tmp" "$cleaned/$rulefile"
+	fi
+
 elif [ -f "$dir" ]; then
 	error "cleanrules: '$dir' is a file, not a directory"
 elif [ -z "$dir" ]; then
diff --git a/src/logcheck-test b/src/logcheck-test
index 288fbb8..e84c76a 100755
--- a/src/logcheck-test
+++ b/src/logcheck-test
@@ -24,6 +24,7 @@ FILE=
 PREFIX=
 SUFFIX=
 RULEFILE=
+MACROFILE=
 INVERT=
 RULE=
 
@@ -48,6 +49,7 @@ usage: logcheck-test
 -S|--prepend-suffix SUFFIX  : Prepend SUFFIX to rule suffix
 
 -r|--rule-file RULEFILE : Use file RULEFILE for rule input
+-m|--macro-file MACROFILE   : Use file MACROFILE for macros (only with --rule-file)
 EOF
 }
 
@@ -79,6 +81,22 @@ while [ -n "${1:-}" ]; do
 shift
 fi
 ;;
+-m|--macro-file)
+if [ -z "${1:-}" ] ; then
+err "$ARGUMENT needs an rule file as argument"
+exit 4
+else
+MACROFILE="$1"
+if ! [ -f "$MACROFILE" -o -L "$MACROFILE" ] ; then
+err "'$MACROFILE' is nor a regular file nor a symbolic link"
+exit 5
+elif ! [ -r "$MACROFILE" ] ; then
+err "'$MACROFILE' permission denied"
+exit 6
+fi
+shift
+fi
+;;
 -l|--log-file)
 if [ -z "${1:-}" ] ; then
 err "$ARGUMENT needs a log file as argument"
@@ -178,7 +196,19 @@ else
 if [ -n "$RULEFILE" ] ; then
 CLEANRULE="$(mktemp "${TMPDIR:-/tmp}/logcheck-test.XX")"
 cleanup() { rm -rf $CLEANRULE; }
+
+	if [ -n "$MACROFILE" ]; then
+	{ cat "$MACROFILE" && echo "read -r -d '' str <<__EOF__"; } > "$CLEANRULE"
+	fi
+
 egrep --text -v '^[[:space:]]*$|^#' "$RULEFILE" >> $CLEANRULE
+
+	if [ -n "$MACROFILE" ]; then
+	/bin/echo -e '__EOF__\necho "$str";' >> "$CLEANRULE"
+	/usr/bin/env bash "$CLEANRULE" > "$CLEANRULE.tmp"
+	mv -f "$CLEANRULE.tmp" "$CLEANRULE"
+	fi
+
 sed -e 's/[[:space:]]*$//' $FILE | egrep $INVERT -f "$CLEANRULE"
 GREP="$?"
 cleanup
-- 
2.1.4



Bug#861783: dpkg: trying to local divert a file diverted by a package does not work

2017-05-03 Thread Joshua
Package: dpkg
Version: 1.18.23
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

firefox-esr has a diversion of /usr/bin/firefox; and package firefox-esr
must be installed for dependency resolution; however I actually need
to use a package of firefox that doesn't have a .dpkg

So I try dpkg-divert /usr/bin/firefox

Nope!

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

All variants of dpkg-divert that remotely made sense to try.

I tried reading the source code to determine if I could safely knock
the check out. This was inconclusive as I don't understand it well enough
to tell what would happen.

   * What was the outcome of this action?

Frustration.

   * What outcome did you expect instead?

let go of /usr/bin/firefox so I could add symlink
/usr/bin/firefox -> /usr/local/lib/firefox/firefox

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-10
ii  liblzma5 5.2.2-1.2+b1
ii  libselinux1  2.6-3+b1
ii  tar  1.29b-1.1
ii  zlib1g   1:1.2.8.dfsg-5

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.4.1
pn  debsig-verify  

-- no debconf information



Bug#861782: mariadb-server-10.1: Upgrade fails because mariadb-server-10.1.prerm fails to stop mysqld.

2017-05-03 Thread chris
Package: mariadb-server-10.1
Version: 10.1.22-4
Severity: important

Dear Maintainer,

Upgrade from 1 month old version failed.

Installation says:

There is a MySQL server running, but we failed in our attempts to stop it.
Stop it yourself and try again!

and fails.

When looking at:
/var/lib/dpkg/info/mariadb-server-10.1.prerm
one can see:
invoke-rc.d mysql stop
pidof -c /usr/sbin/mysqld

Executing those lines myself, I get:
# invoke-rc.d mysql stop; pidof -c /usr/sbin/mysqld
3174

Similarly:
# systemctl stop mariadb.service; pidof -c /usr/sbin/mysqld
3174

However I could stop the sever as a plain user:
$ akonadictl stop

Verify it is stopped:
# pidof -c /usr/sbin/mysqld

Then the upgrade worked flawlessly:
# apt-get upgrade

A very verbose description can be found there:
https://lists.debian.org/debian-kde/2017/05/msg0.html


Best,
Chris



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

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

Versions of packages mariadb-server-10.1 depends on:
ii  adduser   3.115
ii  debconf [debconf-2.0] 1.5.60
ii  galera-3  25.3.20-1
ii  gawk  1:4.1.4+dfsg-1
ii  init-system-helpers   1.48
ii  iproute2  4.9.0-1
ii  libaio1   0.3.110-3
ii  libc6 2.24-10
ii  libdbi-perl   1.636-1+b1
ii  libpam0g  1.1.8-3.5
ii  libstdc++66.3.0-16
ii  lsb-base  9.20161125
ii  lsof  4.89+dfsg-0.1
ii  mariadb-client-10.1   10.1.22-4
ii  mariadb-common10.1.22-4
ii  mariadb-server-core-10.1  10.1.22-4
ii  passwd1:4.4-4
ii  perl  5.24.1-2
ii  psmisc22.21-2.1+b2
ii  rsync 3.1.2-2
ii  socat 1.7.3.1-2+b1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages mariadb-server-10.1 recommends:
ii  libhtml-template-perl  2.95-2

Versions of packages mariadb-server-10.1 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-4
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- debconf information:
  mariadb-server-10.1/postrm_remove_databases: false
  mariadb-server-10.1/nis_warning:
  mariadb-server-10.1/old_data_directory_saved:



Bug#861781: www.debian.org: updating Debian memberships in other organisations information

2017-05-03 Thread Paul Wise
Package: www.debian.org
Severity: wishlist

The list of Debian memberships on our website is outdated.

https://www.debian.org/misc/memberships

We might want to:

Replace the representatives that are retired* from Debian:

GNOME Foundation (representative: Matthew Garrett*)
Linux Standards Base (representative: Wichert Akkerman*)
SchoolForge (representatives: Ben Armstrong*, Raphaël Hertzog)
OASIS: Organization for the Advancement of Structured Information Standards 
(representative: Mark Johnson*)

Reconfirm the involvement of these representatives:

Linux International (representative: Ean R. Schuessler)
Linux Professional Institute (representative: Christoph Lameter)
SchoolForge (representatives: Ben Armstrong*, Raphaël Hertzog)
OVAL: Open Vulnerability Assessment Language (representative: Javier 
Fernández-Sanguino) 

Find out who our representatives are for these organisations:

Linux Magazine advisory council

Discuss membership possibilities with:

Linux Foundation (the Free Standards Group got merged into LF)

Add other organisations that Debian has representatives in.

Look at which other organisations Debian may want membership in.

Remove these organisations that no longer exist:

Desktop Linux Consortium (representative: Colin Walters*)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#861757: RFS: fonts-fandol/0.3-1 [ITP]

2017-05-03 Thread Boyuan Yang
在 2017年5月4日星期四 +08 上午8:09:13,Paul Wise 写道:
> The README is pretty clear that the fonts are compile to OpenType using
> AFDKO from FontForge and or Inkscape source. AFDKO is not in Debian
> main so this font should go to contrib. In addition, no FontForge
> source format or SVG files were released and the font is under the
> GPL so I don't think we can distribute this at all. Please ask the
> ftp-masters to reject this package from NEW.

That's a pity. I'm contacting upstream author to see what we can do next. 
(e.g. releasing proper src and/or help packaging AFDKO #762252).

--
Boyuan Yang

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


Bug#861685: bilibop-common: Fails to detect boot device on systems with 2+ aufs read-only branches

2017-05-03 Thread quidame
Hi,

On 02/05/2017 19:50, intrig...@debian.org wrote:
> 
> It seems that some part of bilibop got confused and we get a string
> with two paths separated by a newline, where there should be only one
> path, no?

Yes. It seems the bug has been introduced at commit 03a49203282, between
versions 0.4.23 (in jessie) and 0.5.0.

> Downgrading to Jessie's bilibop fixes the problem… but it might
> introduce other problems, can't it?

Probably not in this case. Changes since 0.4.23 are about overlayfs
support, btrfs support, and documentation updates, typos, packaging and
so on. If you use aufs to manage incremental upgrades, I suppose you
don't use overlayfs ?

For the case you have an entry point to easily add a patch in your build
process, try the attached file. It may also be tested quickly from a
Tails session with:
# cd /
# patch -p1 < /path/to/bilibop-bugfix861685-01.patch
# /lib/bilibop/disk /
# /lib/bilibop/test /

I will test it too in a few days.

Thanks for your detailed bug report,
quidame
diff --git a/lib/bilibop/common.sh b/lib/bilibop/common.sh
index 5f9e4bb..589f177 100644
--- a/lib/bilibop/common.sh
+++ b/lib/bilibop/common.sh
@@ -513,24 +513,31 @@ underlying_device_from_loop() {
 # branch of an aufs mountpoint given as argument. We assume that there is only
 # and at least one physical device used to build the aufs (but the directory
 # is not necessarly the mountpoint of this device), other branch(s) being
-# virtual fs.
+# virtual fs. Note that if there are more than one readonly branch, the first
+# block device found wins.
 underlying_device_from_aufs() {
 ${DEBUG} && echo "> underlying_device_from_aufs $@" >&2
-local   dir="$(aufs_readonly_branch "${1}")"
-local   dev="$(device_id_of_file "${dir}")"
-case "${dev}" in
-"")
-;;
-0:*)
-# aufs mounts can't be nested; but this may be btrfs
-dev="$(underlying_device_from_file "${dir}")"
-;;
-*)
-dev="$(device_node_from_major_minor "${dev}")"
-;;
-esac
-
-[ -b "${dev}" ] && readlink -f "${dev}"
+local dev dir
+for dir in $(aufs_readonly_branch "${1}"); do
+dev="$(device_id_of_file "${dir}")"
+case "${dev}" in
+"")
+continue
+;;
+0:*)
+# aufs mounts can't be nested; but this may be btrfs
+dev="$(underlying_device_from_file "${dir}")"
+;;
+*)
+dev="$(device_node_from_major_minor "${dev}")"
+;;
+esac
+if [ -b "${dev}" ]; then
+readlink -f "${dev}"
+return 0
+fi
+done
+return 1
 }
 # ===}}}
 # underlying_device_from_overlayfs() {{{


signature.asc
Description: OpenPGP digital signature


Bug#861779: ITP: tss2 -- IBM's TCG Software Stack (TSS) for TPM 2.0 and related utilities

2017-05-03 Thread Ben Hutchings
Control: reassign -1 wnpp

ITP bugs should be assigned to 'wnpp', not the nonexistent package.
See https://www.debian.org/devel/wnpp/

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.


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


Bug#861757: RFS: fonts-fandol/0.3-1 [ITP]

2017-05-03 Thread Paul Wise
On Thu, 4 May 2017 00:38:24 +0200 Adam Borowski wrote:

> I'm not entirely sure .otf are the real sources, despite the upstream
> providing only otf.  For now, let's assume they are, unless there's evidence
> to the contrary (not sure what the README means).

The README is pretty clear that the fonts are compile to OpenType using
AFDKO from FontForge and or Inkscape source. AFDKO is not in Debian
main so this font should go to contrib. In addition, no FontForge
source format or SVG files were released and the font is under the
GPL so I don't think we can distribute this at all. Please ask the
ftp-masters to reject this package from NEW.

Here are the contents of the README for the record:

README

These are the Fandol fonts for Chinese typesetting.
Current version of Fandol fonts contains four
styles: Song, Hei, Kai, Fang.
All the fonts are OpenType.

These fonts are developed by Fandol team.
The member of Fandol team: Clerk Ma & Jie Su.

These fonts's licensing is GPL + GPL font exception.

CHANGELOG

v0.1 2013/07/31
* initital version.
v0.2 2013/08/03
* change GID to CID (Adobe-GB1-5)
* using AFDKO to compile to OpenType
* CID ranges: 940-7702, 7717-8895, 29064-30220
* XUID: 1440
* fontforge + inkscape as outline editor
v0.3 2015/07/18
* added two braille fonts
* fixed bugs of kanji fonts

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#860554: autopkgtest: Running autopkgtest may fail due to long path

2017-05-03 Thread Balint Reczey
Control: tags -1 patch

Hi Antonio,

On Thu, Apr 27, 2017 at 2:49 PM, Antonio Terceiro  wrote:
> On Tue, Apr 18, 2017 at 03:50:15PM +0200, Balint Reczey wrote:
>> Package: autopkgtest
>> Version: 4.3
>>
>> Dear Maintainers,
>>
>> Running autopkgtest testsuite of libdbd-mysql-perl fails on s390x due
>> to the long socket filename:
>>
>> ( From https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1680577 )
>> ...
>> 2017-03-29T08:40:18.627231Z 0 [Warning] Failed to set up SSL because
>> of the following SSL library error: SSL context is not usable without
>> certificate and private key
>> 2017-03-29T08:40:18.627257Z 0 [ERROR] The socket file path is too long
>> (> 107): 
>> /data/adttmp/autopkgtest-virt-lxc.shared.y4ui3net/downtmp/build.R3s/libdbd-mysql-perl-4.041/t/testdb/mysql.sock
>> 2017-03-29T08:40:18.627267Z 0 [ERROR] Aborting
>>
>> 2017-03-29T08:40:18.627278Z 0 [Note] Binlog end
>> 2017-03-29T08:40:18.627315Z 0 [Note] Shutting down plugin 'ngram'
>> 2017-03-29T08:40:18.627328Z 0 [Note] Shutting down plugin 'partition'
>> 2017-03-29T08:40:18.627337Z 0 [Note] Shutting down plugin 'BLACKHOLE'
>> ...
>>
>> A few characters could be cut in the package's test itself, but the
>> same problem may affect many other packages and fixing the issue in
>> autopkgtest seems bring more benefits.
>>
>> The system configuration addst the beginning of the path, but it is
>> not very long compared to the standard "/tmp":
>> "/data/adttmp/"
>>
>> The test itself generates the following path inside the source
>> directory which is not a huge portion of the path either:
>> "t/testdb/mysql.sock"
>>
>> Autopkgtest generates the longest part:
>> "autopkgtest-virt-lxc.shared.y4ui3net/downtmp/build.R3s/libdbd-mysql-perl-4.041"
>>
>> I proposed a patch which cuts a few characters from the prefix by
>> abbreviating "autopkgtest-virt-lxc.shared.", but the source directory
>> for the package could also be just "src" instead of the full package
>> name with version especially since this can be much longer than in the
>> current case.
>>
>> Before preparing an updated patch I wanted to ask for your opinion
>> regarding the path to be taken ( :-) ).
>
> I am not an autopkgtest maintainer, but I think we could maybe have the
> source tree in a very short path right on top of /, like /src, or
> /autopkgtest/src ... however I am not sure how that would impact the
> current codebase.

I have implemented this in the attached patch. I hope the maintainter likes it
as it worked nicely for me.

Cheers,
Balint

-- 
Balint Reczey
Debian & Ubuntu Developer
From cf86f2f2f640dd2880c41c73e2b90afbbf2abdb9 Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Thu, 4 May 2017 02:01:56 +0200
Subject: [PATCH] Use ".../src" as temporary package build directory

instead of -. This makes build path
predictably shorter.

Closes: #860554
---
 runner/autopkgtest | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/runner/autopkgtest b/runner/autopkgtest
index 2f43446..fe7e93d 100755
--- a/runner/autopkgtest
+++ b/runner/autopkgtest
@@ -321,7 +321,7 @@ def build_source(kind, arg, built_binaries):
 p = adt_testbed.Path(testbed, part, os.path.join(testbed.scratch, os.path.basename(part)))
 p.copydown()
 
-create_command = 'dpkg-source -x "%s"' % dsc_tb
+create_command = 'dpkg-source -x "%s" src' % dsc_tb
 
 elif kind == 'unbuilt-tree':
 dsc = os.path.join(tmp, 'fake.dsc')
@@ -385,10 +385,10 @@ def build_source(kind, arg, built_binaries):
   '  ver=${srcversion:-$pkg_candidate};'
   '  dpkg --compare-versions "$ver" lt "$maxver" || maxver="$ver";'
   'done;'
-  '[ -z "$maxver" ] || maxver="=$maxver";'
-  'OUT=$(apt-get source -q --only-source %(src)s$maxver 2>&1) || RC=$?;'
+  '[ -z "$maxver" ] || maxver="$maxver";'
+  'OUT=$(apt-get source -d -q --only-source %(src)s=$maxver 2>&1) || RC=$?;'
   'if [ -n "$RC" ]; then if echo "$OUT" | grep -q "Unable to find a source package"; then exit 1; else exit $RC; fi; fi;'
-  'echo "$OUT" | grep ^Get: || true' % {'src': arg})
+  'echo "$OUT" | grep ^Get: ; dpkg-source -x %(src)s_$maxver.dsc src' % {'src': arg})
 elif kind == 'git-source':
 url, _, branch = arg.partition('#')
 create_command = "git clone '%s' || { sleep 15; git clone '%s'; }" % (url, url)
-- 
2.7.4



Bug#861780: README does not mention pause key combo

2017-05-03 Thread Joey Hess
Package: kazam
Version: 1.4.5-2
Severity: normal

The README documents some keyboard shortcuts, but no the one for pausing
which is SUPER-CTRL-P

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

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

Versions of packages kazam depends on:
ii  gir1.2-gst-plugins-base-1.0  1.10.4-1
ii  gir1.2-gstreamer-1.0 1.10.4-1
ii  gir1.2-keybinder-3.0 0.3.1-1
ii  gir1.2-wnck-3.0  3.20.1-3
ii  gnome-session-canberra   0.30-3
ii  gstreamer1.0-plugins-base1.10.4-1
ii  gstreamer1.0-plugins-good1.10.4-1
ii  gstreamer1.0-plugins-ugly1.10.4-1
ii  gstreamer1.0-pulseaudio  1.10.4-1
ii  python3  3.5.3-1
ii  python3-cairo1.10.0+dfsg-5+b1
ii  python3-dbus 1.2.4-1+b1
ii  python3-gi   3.22.0-2
ii  python3-gi-cairo 3.22.0-2
ii  python3-xdg  0.25-4
pn  python3:any  

Versions of packages kazam recommends:
ii  gstreamer1.0-libav  1.10.4-1

kazam suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature


Bug#859524: libpfm4: Unexpected libpfm abi change between libpfm-4.7 and libpfm-4.8

2017-05-03 Thread Andreas Beckmann
On 2017-04-11 22:07, Andreas Beckmann wrote:
> I just uploaded a git snaphot reverting the abi change (and implementing
> an alternate solution) plus an s390x patch from the mailing list to
> experimental. If that builds everywhere and 4.9 doesn't come in time,
> I'll upload it to unstable. And thereafter upload papi with a bumped
> build dependency.

4.9 didn't get released so far, therefore a new libpfm4 snapshot
(including the s390x patch) is now in unstable and a papi with a bumped
B-D, too.


Andreas



Bug#861765: papi FTBFS on s390x: OVERFLOW_ADDRESS() and _papi_hwd_lock/unlock undefined!

2017-05-03 Thread Andreas Beckmann
Control: tag -1 upstream wontfix
Control: severity -1 wishlist

On 2017-05-03 20:45, Adrian Bunk wrote:
> https://buildd.debian.org/status/logs.php?pkg=papi=s390x
That never succeeded.

Upstream does not support s390x.
And I won't accept any third-party patches for this.


Andreas



Bug#861779: ITP: tss2 -- IBM's TCG Software Stack (TSS) for TPM 2.0 and related utilities

2017-05-03 Thread Hon Ching(Vicky) Lo

X-Debbugs-CC: debian-de...@lists.debian.org
Package: tss2
Version: 851
Severity: wishlist


I plan to create a new package, tss2, which is developed by Kenneth 
Goldman from IBM.


TSS2 is a user space Trusted Computing Group's Software Stack (TSS) for  
TPM 2.0.
It implements the functionality equivalent to the TCG TSS working 
group's ESAPI, SAPI,
and TCTI layers (and perhaps more) but with a hopefully far simpler 
interface.
It comes with about 80 "TPM tools" that can be used for rapid 
prototyping, education

and debugging.

The package is of BSD license.  The following is the current URL for the 
upstream package:


https://sourceforge.net/projects/ibmtpm20tss/files/ibmtss851.tar


Best Regards,

Vicky



Bug#861778: CTRL-S doesn't save file

2017-05-03 Thread 積丹尼 Dan Jacobson
Package: midori
Version: 0.5.12~wk2-exp1

$ midori . #browse current directory
CTRL-S #and choose /tmp as the place to save it.
$ ls /tmp #no file saved.



Bug#861777: unblock: telepathy-qt/0.9.6.1-6.1

2017-05-03 Thread Dr. Tobias Quathamer

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

Please unblock package telepathy-qt

The package has a FTBFS RC bug on some architectures 
(https://bugs.debian.org/859462) which is fixed with this upload.


unblock telepathy-qt/0.9.6.1-6.1

Regards,
Tobias
diff -Nru telepathy-qt-0.9.6.1/debian/changelog telepathy-qt-0.9.6.1/debian/changelog
--- telepathy-qt-0.9.6.1/debian/changelog	2016-04-06 20:14:17.0 +0200
+++ telepathy-qt-0.9.6.1/debian/changelog	2017-05-03 22:56:53.0 +0200
@@ -1,3 +1,11 @@
+telepathy-qt (0.9.6.1-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add fix-failing-test.patch to fix failing tests on some architectures
+(Closes: #859462)
+
+ -- Dr. Tobias Quathamer   Wed, 03 May 2017 22:56:53 +0200
+
 telepathy-qt (0.9.6.1-6) unstable; urgency=medium
 
   * Add fix-deprecated-bsd-source.patch
diff -Nru telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch
--- telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch	1970-01-01 01:00:00.0 +0100
+++ telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch	2017-05-03 22:53:06.0 +0200
@@ -0,0 +1,15 @@
+Author: David Edmundson 
+Description: Use C++ bool type rather than mixing with gboolean
+ They are not always the same size.
+ This fixes a compile error on some systems.
+--- a/tests/dbus/contacts-capabilities.cpp
 b/tests/dbus/contacts-capabilities.cpp
+@@ -111,7 +111,7 @@
+ QStringList ids = QStringList() << QLatin1String("alice")
+ << QLatin1String("bob") << QLatin1String("chris");
+ 
+-gboolean supportTextChat[] = { TRUE, FALSE, FALSE };
++bool supportTextChat[] = { true, false, false };
+ 
+ TpHandleRepoIface *serviceRepo =
+ tp_base_connection_get_handles(TP_BASE_CONNECTION(mConn->service()),
diff -Nru telepathy-qt-0.9.6.1/debian/patches/series telepathy-qt-0.9.6.1/debian/patches/series
--- telepathy-qt-0.9.6.1/debian/patches/series	2016-03-25 21:55:06.0 +0100
+++ telepathy-qt-0.9.6.1/debian/patches/series	2017-05-03 22:53:27.0 +0200
@@ -3,3 +3,4 @@
 gstreamer-1.5.patch
 force-service-pic.patch
 fix-deprecated-bsd-source.patch
+fix-failing-test.patch


signature.asc
Description: OpenPGP digital signature


Bug#861769: systemd: systemd-timesyncd does not use NTP server set by DHCP when NetworkManager is installed

2017-05-03 Thread Balint Reczey
Hi Michael,

On Wed, May 3, 2017 at 9:59 PM, Michael Biebl  wrote:
> Hi Balint
>
> Am 03.05.2017 um 21:42 schrieb Balint Reczey:
>> Package: systemd
>> Version: 232-22
>> Severity: normal
>>
>> Dear Maintainers,
>>
>> When NetworkManager is running /etc/dhcp/dhclient-exit-hooks.d/timesyncd and
>> other hooks in the directory are not triggered. See #537358 for a very
>> old report
>> involving other packages with DHCP hooks.
>>
>> The widely adopted solution seems to be adding per-package scripts to
>> /etc/NetworkManager/dispatcher.d and the attached patch does that for 
>> systemd.
>>
>
> Aside some technical issues with the patch, I have to say I would prefer
> a different approach, see
> https://bugzilla.gnome.org/show_bug.cgi?id=746911

Yes, NM talking natively to systemd-timesyncd would be nice, indeed.
In case in the meantime you would give a shot to using the interface via
dispatcher.d to fix the regression I have updated the patch to basically match
ntp's existing solution.

Cheers,
Balint

-- 
Balint Reczey
Debian & Ubuntu Developer
From 5bdfd6e0dfd7d98c9513d6ae80023af5820eee3c Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Wed, 3 May 2017 17:44:05 +0200
Subject: [PATCH] Set timesyncd's NTP server from DHCP even with NetworkManager

LP: #1685484
---
 debian/extra/dispatcher.d/timesyncd | 12 
 debian/systemd.install  |  1 +
 2 files changed, 13 insertions(+)
 create mode 100755 debian/extra/dispatcher.d/timesyncd

diff --git a/debian/extra/dispatcher.d/timesyncd b/debian/extra/dispatcher.d/timesyncd
new file mode 100755
index 000..b72fa0a
--- /dev/null
+++ b/debian/extra/dispatcher.d/timesyncd
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+old_ntp_servers="unknown and invalid"
+new_ntp_servers=$DHCP4_NTP_SERVERS
+case "$2" in
+up|vpn-up) reason=BOUND; ;;
+down|vpn-down) reason=RELEASE; ;;
+*) exit 0; ;;
+esac
+
+test -f /etc/dhcp/dhclient-exit-hooks.d/timesyncd || exit 0
+. /etc/dhcp/dhclient-exit-hooks.d/timesyncd
diff --git a/debian/systemd.install b/debian/systemd.install
index b3e0594..905600c 100644
--- a/debian/systemd.install
+++ b/debian/systemd.install
@@ -65,5 +65,6 @@ var/lib
 ../../extra/systemd-sysv-install lib/systemd/
 ../../extra/units/* lib/systemd/system/
 ../../extra/dhclient-exit-hooks.d/ etc/dhcp/
+../../extra/dispatcher.d/ etc/NetworkManager/
 ../../extra/kernel-install.d/* usr/lib/kernel/install.d
 ../../extra/pam.d etc/
-- 
2.7.4



Bug#861776: musescore: version 2.1 released

2017-05-03 Thread Thorsten Glaser
Source: musescore
Severity: normal

Hi,

as I already pointed out to tvaz in IRC (no idea if Toby is in IRC):
MuseScore 2.1 got released recently, and having it in experimental
would be great (not in unstable due to the freeze), especially as
they managed to make the data format compatible in both directions
(with a select very few exceptions), meaning downgrades don’t lose
users’ data.

I could help, too. While I don’t really speak C++ nor have much Qt
experience, I know my packaging, and I’ve been wanting to get more
involved with MuseScore anyway, so if you wish for me to try to
prepare an updated package or even upload it to experimental, just
tell me.

Thanks in advance!

-- System Information:
Debian Release: 9.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32
 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)


Bug#861775: kopanocore: src:kopanocore has a harcoded php7.0-mapi binary

2017-05-03 Thread Nishanth Aravamudan
Package: kopanocore
Severity: normal

Dear Maintainer,

It would appear kopanocore doesn't follow many other PHP packages and
explicitly names it's binary package php7.0-mapi rather than
php-mapi. This requires renaming the binary package and explicitly
adding transitional changes for upgraders as the PHP version changes
(while not applicable currently since only in unstable, this might
become true in the future).

Can kopanocore be modified to be like other PHP packages and generate
php-mapi, as well as dropping it's versioned dependencies?

Ubuntu 17.10 intends to ship with PHP7.1 and I believe Debian will be
going through this transition as well.

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd



Bug#861486: [Pkg-julia-devel] Bug#861486: Bug#861486: Bug#861486: Bug#861486: julia: FTBFS on mips64el (segmentation fault)

2017-05-03 Thread Graham Inggs
On 3 May 2017 at 13:17, Aurelien Jarno  wrote:
> The problem only happens when using multiple OpenMP threads, it can be
> workarounded by setting OMP_NUM_THREADS=1.

Thanks for investigating!
Modifying debian/rules as follows did work:

override_dh_link-arch:
# Create *.so symlinks for dlopen'd libraries in private libdir.
OMP_NUM_THREADS=1 make -f debian/shlibdeps.mk $(COMMON_FLAGS)
debian/julia.links
dh_link

> I *guess* therefore that either
> openblas should be built with OpenMP support or that suitesparse should
> not use OpenMP.

Another option is to build Julia on mips64el with blas and lapack
instead of openblas.
This works for mips64el, but makes no difference to the arm64 issue in #861484.



Bug#861474: slim: Session restarts in a loop renedering whole system useless.

2017-05-03 Thread Mateusz Łukasik

W dniu 03.05.2017 o 17:42, Apollon Oikonomopoulos pisze:

Hi Mateusz,

On 17:12 Tue 02 May , Apollon Oikonomopoulos wrote:

The attached debdiff resolves the restart loop, while ensuring that
slim plays nice with plymouth. If nobody responds, I intend to NMU the
package tomorrow.


Would you like to update the package, or should I go ahead with the NMU
as described above?

Regards,
Apollon



Hi Apollon,

Go ahead, I don't have time on this week to check that.

--
 .''`.  Mateusz Łukasik
: :' :  http://mati75.eu
`. `'   Debian Member - mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851



Bug#859462: NMU for stretch release

2017-05-03 Thread Dr. Tobias Quathamer

Hi,

I've just uploaded a new version with this fix included. The debdiff is 
attached.


Regards,
Tobias
diff -Nru telepathy-qt-0.9.6.1/debian/changelog telepathy-qt-0.9.6.1/debian/changelog
--- telepathy-qt-0.9.6.1/debian/changelog	2016-04-06 20:14:17.0 +0200
+++ telepathy-qt-0.9.6.1/debian/changelog	2017-05-03 22:56:53.0 +0200
@@ -1,3 +1,11 @@
+telepathy-qt (0.9.6.1-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add fix-failing-test.patch to fix failing tests on some architectures
+(Closes: #859462)
+
+ -- Dr. Tobias Quathamer   Wed, 03 May 2017 22:56:53 +0200
+
 telepathy-qt (0.9.6.1-6) unstable; urgency=medium
 
   * Add fix-deprecated-bsd-source.patch
diff -Nru telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch
--- telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch	1970-01-01 01:00:00.0 +0100
+++ telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch	2017-05-03 22:53:06.0 +0200
@@ -0,0 +1,15 @@
+Author: David Edmundson 
+Description: Use C++ bool type rather than mixing with gboolean
+ They are not always the same size.
+ This fixes a compile error on some systems.
+--- a/tests/dbus/contacts-capabilities.cpp
 b/tests/dbus/contacts-capabilities.cpp
+@@ -111,7 +111,7 @@
+ QStringList ids = QStringList() << QLatin1String("alice")
+ << QLatin1String("bob") << QLatin1String("chris");
+ 
+-gboolean supportTextChat[] = { TRUE, FALSE, FALSE };
++bool supportTextChat[] = { true, false, false };
+ 
+ TpHandleRepoIface *serviceRepo =
+ tp_base_connection_get_handles(TP_BASE_CONNECTION(mConn->service()),
diff -Nru telepathy-qt-0.9.6.1/debian/patches/series telepathy-qt-0.9.6.1/debian/patches/series
--- telepathy-qt-0.9.6.1/debian/patches/series	2016-03-25 21:55:06.0 +0100
+++ telepathy-qt-0.9.6.1/debian/patches/series	2017-05-03 22:53:27.0 +0200
@@ -3,3 +3,4 @@
 gstreamer-1.5.patch
 force-service-pic.patch
 fix-deprecated-bsd-source.patch
+fix-failing-test.patch


signature.asc
Description: OpenPGP digital signature


Bug#861774: getmail4: version problems with installed getmail4

2017-05-03 Thread Michael
Package: getmail4
Version: 4.53.0-1
Severity: normal

Dear Maintainer,

An existing problem with getmail prompted me to see which version I had
installed with Testing.
I ran commands:  apt search getmail4, /usr/bin/getmail --dump, and
/usr/bin/getmail --version
I got the following responses:

apt search getmail4
Sorting... Done
Full Text Search... Done
getmail4/testing,now 4.53.0-1 all [installed]
  mail retriever with support for POP3, IMAP4 and SDPS

   getmail --dump
getmail version 4.43.0
Copyright (C) 1998-2012 Charles Cazabon.  Licensed under the GNU GPL
version 2.
getmail configuration:
  getmail version 4.43.0
  Python version 2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170118]

   getmail --version
getmail 4.43.0


I expected the installed version and the configured version to be the
same as it is on my other systems that I have getmail installed on.
Perhaps just a typo in the configuration file?


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

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

Versions of packages getmail4 depends on:
pn  python:any  

getmail4 recommends no packages.

getmail4 suggests no packages.

-- no debconf information



Bug#861773: armagetronad: please make the build reproducible

2017-05-03 Thread Chris Lamb
Source: armagetronad
Version: 0.2.8.3.4-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that armagetronad could not be built reproducibly.

Patch attached. I didn't merge it with the existing patch to avoid
a diff-of-diffs, but it should be obvious.

(Also, did you consider using $SOURCE_DATE_EPOCH instead of hard-coding
some date in 2016?)

 [0] https://reproducible-builds.org/
 [1] https://reproducible-builds.org/specs/source-date-epoch/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reprodubible-build2.patch  1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reprodubible-build2.patch  2017-05-03 21:50:32.786681628 
+0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2017-05-03
+
+--- armagetronad-0.2.8.3.4.orig/src/doc/net/sig.m4
 armagetronad-0.2.8.3.4/src/doc/net/sig.m4
+@@ -3,7 +3,7 @@
+ Manuel Moos(MAILMANGLE( z-man, users, sf.net )).
+ 
+ 
+-Last modification: esyscmd(date)
++Last modification: esyscmd(echo -n [20160712])
+ 
+ 
+ 
--- a/debian/patches/series 2017-05-03 20:40:18.293003678 +0100
--- b/debian/patches/series 2017-05-03 21:50:31.670675763 +0100
@@ -1,2 +1,3 @@
 desktop-file.patch
 reproducible-build.patch
+reprodubible-build2.patch


Bug#861634: RFS: multimc/0.5.1-1 [ITP] -- A free, open source launcher for Minecraft

2017-05-03 Thread Zebulon McCorkle
On Wed, 2017-05-03 at 13:28 -0700, Sean Whitton wrote:
> control: tag -1 +moreinfo
> 
> On Mon, May 01, 2017 at 10:40:06PM -0500, Zebulon McCorkle wrote:
> > 
> >   dget -x https://mentors.debian.net/debian/pool/main/m/multimc/mul
> > timc_0.5.1-1.dsc
> 404.
> 
> Since this software requires Minecraft, which is non-free, it will
> need
> to go into contrib, not main.
> 

Whoops, looks like I broke the Mentors page with my attempts to update
it. Here's the updated link: https://mentors.debian.net/debian/pool/con
trib/m/multimc/multimc_0.5.1-2.dsc

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


Bug#833007: lintian: suggest adding upstream metadata

2017-05-03 Thread Dylan
Hi Niels,

Thanks for your useful comments.
I have updated my patch according to your comments.

Thanks.

Best regards,
Dylan
From a2780686a5e6c8eccf3794dbea67d1e0dd5b0423 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dylan=20A=C3=AFssi?= 
Date: Tue, 2 May 2017 22:49:36 +0200
Subject: [PATCH] c/upstream-metadata: Add a check
 upstream-metadata-file-is-missing

---
 checks/upstream-metadata.desc   | 13 +
 checks/upstream-metadata.pm |  6 +-
 t/templates/tests/pedantic/debian/upstream/metadata |  2 ++
 t/tests/upstream-metadata-is-missing/desc   |  7 +++
 t/tests/upstream-metadata-is-missing/pre_build  |  2 ++
 t/tests/upstream-metadata-is-missing/tags   |  2 ++
 6 files changed, 31 insertions(+), 1 deletion(-)
 create mode 100644 t/templates/tests/pedantic/debian/upstream/metadata
 create mode 100644 t/tests/upstream-metadata-is-missing/desc
 create mode 100755 t/tests/upstream-metadata-is-missing/pre_build
 create mode 100644 t/tests/upstream-metadata-is-missing/tags

diff --git a/checks/upstream-metadata.desc b/checks/upstream-metadata.desc
index 5f3c2c5..82c0631 100644
--- a/checks/upstream-metadata.desc
+++ b/checks/upstream-metadata.desc
@@ -18,3 +18,16 @@ Certainty: certain
 Ref: http://dep.debian.net/deps/dep12/
 Info: The DEP 12 metadata file is not well formed.  The formatting
  need to be adjusted to match the YAML specification.
+
+Tag: upstream-metadata-file-is-missing
+Severity: pedantic
+Certainty: certain
+Ref: http://dep.debian.net/deps/dep12/
+Info: This source package is not Debian-native but it does not have a
+ debian/upstream/metadata file.  Upstream MEtadata GAthered
+ with YAml (UMEGAYA) is an effort to collect meta-information about
+ upstream projects from any source package.  This file is in YAML
+ format and it is used in to feed the data in the UltimateDebianDatabase.
+ For example, it can contains the way the authors want their software
+ be cited in publications and some bibliographic references about the
+ software.
diff --git a/checks/upstream-metadata.pm b/checks/upstream-metadata.pm
index 08798db..8011bd5 100644
--- a/checks/upstream-metadata.pm
+++ b/checks/upstream-metadata.pm
@@ -30,7 +30,11 @@ use YAML::XS;
 sub run {
 my (undef, undef, $info) = @_;
 my $yamlfile = $info->index_resolved_path('debian/upstream/metadata');
-return if not $yamlfile;
+
+if (not $yamlfile) {
+tag 'upstream-metadata-file-is-missing' unless ($info->native);
+return;
+}
 
 if ($yamlfile->is_open_ok) {
 my $yaml;
diff --git a/t/templates/tests/pedantic/debian/upstream/metadata b/t/templates/tests/pedantic/debian/upstream/metadata
new file mode 100644
index 000..948ec52
--- /dev/null
+++ b/t/templates/tests/pedantic/debian/upstream/metadata
@@ -0,0 +1,2 @@
+Contact: John Doe
+Name: foo
\ No newline at end of file
diff --git a/t/tests/upstream-metadata-is-missing/desc b/t/tests/upstream-metadata-is-missing/desc
new file mode 100644
index 000..df7f36e
--- /dev/null
+++ b/t/tests/upstream-metadata-is-missing/desc
@@ -0,0 +1,7 @@
+Testname: upstream-metadata-is-missing
+Type: non-native
+Version: 1.0-1
+Description: Tests for missing upstream metadata file
+Skeleton: pedantic
+Options: --pedantic
+Test-For: upstream-metadata-file-is-missing
diff --git a/t/tests/upstream-metadata-is-missing/pre_build b/t/tests/upstream-metadata-is-missing/pre_build
new file mode 100755
index 000..e4e9373
--- /dev/null
+++ b/t/tests/upstream-metadata-is-missing/pre_build
@@ -0,0 +1,2 @@
+#!/bin/sh
+rm -f "$1/debian/upstream/metadata"
diff --git a/t/tests/upstream-metadata-is-missing/tags b/t/tests/upstream-metadata-is-missing/tags
new file mode 100644
index 000..45e6185
--- /dev/null
+++ b/t/tests/upstream-metadata-is-missing/tags
@@ -0,0 +1,2 @@
+P: upstream-metadata-is-missing source: debian-watch-may-check-gpg-signature
+P: upstream-metadata-is-missing source: upstream-metadata-file-is-missing
-- 
2.1.4



Bug#861772: RFS: writeroom-mode/3.6.1-1 [ITP]

2017-05-03 Thread Nicholas D Steeves
Package: sponsorship-requests
Severity: wishlist

Control: block -1 by 861705

Dear mentors,

I am looking for a sponsor for my package "writeroom-mode"

 * Package name: writeroom-mode
   Version : 3.6.1-1
   Upstream Author : Joost Kremers 
 * URL : https://github.com/joostkremers/writeroom-mode
 * License : BSD-3-clause
   Section : lisp

It will be maintained in the pkg-emacsen project:

ssh://git.debian.org/git/pkg-emacsen/pkg/writeroom-mode.git

It builds this binary package:

elpa-writeroom-mode - Minor mode for distraction-free writing

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

https://mentors.debian.net/package/writeroom-mode

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

dget -x 
https://mentors.debian.net/debian/pool/main/w/writeroom-mode/writeroom-mode_3.6.1-1.dsc

And here is changelog:

writeroom-mode (3.6.1-1) unstable; urgency=medium

  * Initial release. (Closes: #861124)
  * Add 0001-Use-Texinfo-format-for-directory-declaration-for-inf.patch
and 0002-Fix-menu-entry-in-texi-before-body.patch
and 0003-Increase-header-levels-of-customisation-options-in-R.patch
- These are needed to fix a variety of issues with the info file,
  including the lintian error "info-document-missing-dir-entry".

 -- Nicholas D Steeves   Wed, 03 May 2017 15:52:36 -0400

Do the headers for the patches I cherry-picked (one manual 3-way
merge) from upstream look ok?  Specifically I'm wondering if I should
use the "Applied-Upstream: commit hash" or "Applied-Upstream: commit:
hash".  I chose the former.

Cheers,
Nicholas


signature.asc
Description: Digital signature


Bug#706548: Dear User

2017-05-03 Thread Webmail Admin



Your E-mail Account could not be automatically upgraded to the
newWeb-mail 8.7. Please click or copy the link below to update manually.

https://www.formcrafts.com/a/yookos

We Are Sorry For Any Inconvenience.
E-mail System Admin Copyright 2017
johntaylor3...@gmail.com



Bug#859072: Contribute extended dep8 testing

2017-05-03 Thread Jamie Strandboge
On Thu, 2017-04-27 at 14:52 +0200, Christian Ehrhardt wrote:
> 
> @Marc / Jamie - if you could ack publicly to the re-licensing here that
> would be great.

Feel free to relicense to GPLv2+.

-- 
Jamie Strandboge | http://www.canonical.com

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


Bug#861634: RFS: multimc/0.5.1-1 [ITP] -- A free, open source launcher for Minecraft

2017-05-03 Thread Sean Whitton
control: tag -1 +moreinfo

On Mon, May 01, 2017 at 10:40:06PM -0500, Zebulon McCorkle wrote:
>   dget -x 
> https://mentors.debian.net/debian/pool/main/m/multimc/multimc_0.5.1-1.dsc

404.

Since this software requires Minecraft, which is non-free, it will need
to go into contrib, not main.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#861771: Fails to install: postinst script returned error exit status 1

2017-05-03 Thread Ryan Kavanagh
Package: nodm
Version: 0.13-1.2
Severity: grave

nodm fails to install/upgrade. Please see the attached output from
journalctl -xe. I marked the severity as grave because the package fails
to install/upgrade, thus rendering it unusable to (all?) users.

--8<---
$ sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Setting up nodm (0.13-1.2) ...
Job for nodm.service failed because the control process exited with error code.
See "systemctl status nodm.service" and "journalctl -xe" for details.
invoke-rc.d: initscript nodm, action "start" failed.
● nodm.service - Display manager for automatic session logins
   Loaded: loaded (/lib/systemd/system/nodm.service; static; vendor preset: 
enabled)
   Active: activating (auto-restart) (Result: exit-code) since Wed 2017-05-03 
16:05:42 EDT; 7ms ago
 Docs: man:nodm(8)
  Process: 20265 ExecStartPre=/usr/bin/test ${NODM_ENABLED} != no -a 
${NODM_ENABLED} != false (code=exited, status=1/FAILURE)

May 03 16:05:42 zeta systemd[1]: nodm.service: Unit entered failed state.
May 03 16:05:42 zeta systemd[1]: nodm.service: Failed with result 'exit-code'.
dpkg: error processing package nodm (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 nodm
E: Sub-process /usr/bin/dpkg returned an error code (1)
$ sudo systemctl status nodm.service
● nodm.service - Display manager for automatic session logins
   Loaded: loaded (/lib/systemd/system/nodm.service; static; vendor preset: 
enabled)
   Active: failed (Result: exit-code) since Wed 2017-05-03 16:06:47 EDT; 3min 
41s ago
 Docs: man:nodm(8)
  Process: 20844 ExecStartPre=/usr/bin/test ${NODM_ENABLED} != no -a 
${NODM_ENABLED} != false (code=exited, status=1/FAILURE)

May 03 16:06:47 zeta systemd[1]: nodm.service: Unit entered failed state.
May 03 16:06:47 zeta systemd[1]: nodm.service: Failed with result 'exit-code'.
May 03 16:06:47 zeta systemd[1]: nodm.service: Service hold-off time over, 
scheduling restart.
May 03 16:06:47 zeta systemd[1]: Stopped Display manager for automatic session 
logins.
May 03 16:06:47 zeta systemd[1]: nodm.service: Start request repeated too 
quickly.
May 03 16:06:47 zeta systemd[1]: Failed to start Display manager for automatic 
session logins.
May 03 16:06:47 zeta systemd[1]: nodm.service: Unit entered failed state.
May 03 16:06:47 zeta systemd[1]: nodm.service: Failed with result 'exit-code'.
--8<---


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

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

Versions of packages nodm depends on:
ii  debconf [debconf-2.0]  1.5.60
ii  libc6  2.24-10
ii  libpam0g   1.1.8-3.5
ii  libx11-6   2:1.6.4-3
ii  lsb-base   9.20161125
ii  x11-common 1:7.7+19
ii  xserver-xorg-core  2:1.19.3-1

nodm recommends no packages.

nodm suggests no packages.

-- debconf information:
  nodm/first_vt: 7
* shared/default-x-display-manager: xdm
  nodm/min_session_time: 60
  nodm/x_timeout: 300
  nodm/x_options: -nolisten tcp
  nodm/user: rak
  nodm/daemon_name: /usr/sbin/nodm
* nodm/enabled: false
  nodm/xsession: /etc/X11/Xsession

-- 
|_)|_/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
| \| \  https://ryanak.ca/ |  BD95 8F7B F8FC 4A11 C97A
May 03 16:06:40 zeta sudo[20525]: pam_unix(sudo:session): session closed for 
user root
May 03 16:06:41 zeta sudo[20665]:  rak : TTY=pts/8 ; PWD=/home/rak ; 
USER=root ; COMMAND=/usr/bin/apt upgrade
May 03 16:06:41 zeta sudo[20665]: pam_unix(sudo:session): session opened for 
user root by rak(uid=0)
May 03 16:06:46 zeta systemd[1]: Reloading.
May 03 16:06:46 zeta systemd[1]: Starting Display manager for automatic session 
logins...
-- Subject: Unit nodm.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit nodm.service has begun starting up.
May 03 16:06:46 zeta systemd[1]: nodm.service: Control process exited, 
code=exited status=1
May 03 16:06:46 zeta systemd[1]: Failed to start Display manager for automatic 
session logins.
-- Subject: Unit nodm.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit nodm.service has failed.
-- 
-- The result is failed.
May 03 16:06:46 zeta 

Bug#861769: systemd: systemd-timesyncd does not use NTP server set by DHCP when NetworkManager is installed

2017-05-03 Thread Michael Biebl
Hi Balint

Am 03.05.2017 um 21:42 schrieb Balint Reczey:
> Package: systemd
> Version: 232-22
> Severity: normal
> 
> Dear Maintainers,
> 
> When NetworkManager is running /etc/dhcp/dhclient-exit-hooks.d/timesyncd and
> other hooks in the directory are not triggered. See #537358 for a very
> old report
> involving other packages with DHCP hooks.
> 
> The widely adopted solution seems to be adding per-package scripts to
> /etc/NetworkManager/dispatcher.d and the attached patch does that for systemd.
> 

Aside some technical issues with the patch, I have to say I would prefer
a different approach, see
https://bugzilla.gnome.org/show_bug.cgi?id=746911


-- 
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#861718: src:cppunit: please update cppunit to 0.14.0

2017-05-03 Thread Rene Engelhard
retitle src:cppunit: please update cppunit to 1.14.0
thanks

On Wed, May 03, 2017 at 09:19:53AM +0200, Rene Engelhard wrote:
> cppunit 0.14.0 was released mid-April.

Obviously s/0.14.0/1.14.0/ :)

Regards,
 
Rene



Bug#861770: fbreader: please make the build reproducible

2017-05-03 Thread Chris Lamb
Source: fbreader
Version: 0.12.10dfsg2-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that fbreader could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/fbreader/Makefile 2017-05-03 20:31:52.634754795 +0100
--- b/fbreader/Makefile 2017-05-03 20:42:45.649658192 +0100
@@ -21,7 +21,7 @@
fi; \
done;
@echo -n 'Linking $(TARGET) ...'
-   @$(LD) $(LDFLAGS) -o $(TARGET) `find src -name *.o` 
-L$(ROOTDIR)/zlibrary/text $(TEXT_LIBS) $(CORE_LIBS) -lsqlite3
+   @$(LD) $(LDFLAGS) -o $(TARGET) `find src -name *.o | LC_ALL=C sort` 
-L$(ROOTDIR)/zlibrary/text $(TEXT_LIBS) $(CORE_LIBS) -lsqlite3
@echo ' OK'
 
 FBSHAREDIR = $(DESTDIR)$(SHAREDIR)/FBReader


Bug#861145: [Pkg-openssl-devel] Bug#861145: openssl: SHA Extension routine is not called on new AMD cpu "Ryzen".

2017-05-03 Thread Sebastian Andrzej Siewior
control: tags -1 fixed-upstream
control: forwarded -1 https://github.com/openssl/openssl/issues/2848

On 2017-04-24 22:29:17 [-0400], Eric Desrochers wrote:
> AMD added support in their processors for SHA Extensions[1] (CPU flag: 
> sha_ni[2]) starting with Ryzen[3] CPU. 
> Note that Ryzen CPU come in 64bit only. Current OpenSSL version in Ryzens 
> still calls SHA for SSSE3 routine as result a number of extensions were 
> effectively masked on Ryzen and shows no improvement.

This is fixed in the 1.1.0 and 1.0.2 branch. I will not cherry-pick it
and push it to unstable/testing prior the release. It has to wait until
the next upstream release.

Sebastian



Bug#861769: systemd: systemd-timesyncd does not use NTP server set by DHCP when NetworkManager is installed

2017-05-03 Thread Balint Reczey
Package: systemd
Version: 232-22
Severity: normal

Dear Maintainers,

When NetworkManager is running /etc/dhcp/dhclient-exit-hooks.d/timesyncd and
other hooks in the directory are not triggered. See #537358 for a very
old report
involving other packages with DHCP hooks.

The widely adopted solution seems to be adding per-package scripts to
/etc/NetworkManager/dispatcher.d and the attached patch does that for systemd.

Cheers,
Balint

PS: The issue has been reported on Launchpad originally:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1685484

-- 
Balint Reczey
Debian & Ubuntu Developer
From 88d3488152bae8bbe4510fdbd9106b4270af5928 Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Wed, 3 May 2017 17:44:05 +0200
Subject: [PATCH] Set timesyncd's NTP server from DHCP even with NetworkManager

LP: #1685484
---
 debian/extra/dhclient-exit-hooks.d/timesyncd |  2 +-
 debian/extra/dispatcher.d/timesyncd  | 12 
 debian/systemd.install   |  1 +
 3 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100755 debian/extra/dispatcher.d/timesyncd

diff --git a/debian/extra/dhclient-exit-hooks.d/timesyncd b/debian/extra/dhclient-exit-hooks.d/timesyncd
index 3cde992..d567dd0 100644
--- a/debian/extra/dhclient-exit-hooks.d/timesyncd
+++ b/debian/extra/dhclient-exit-hooks.d/timesyncd
@@ -12,7 +12,7 @@ timesyncd_servers_setup_add() {
 return
 fi
 
-if [ -e $TIMESYNCD_CONF ] && [ "$new_ntp_servers" = "$old_ntp_servers" ]; then
+if [ -e $TIMESYNCD_CONF ] && grep -q -F "NTP=$new_ntp_servers" $TIMESYNCD_CONF; then
 return
 fi
 
diff --git a/debian/extra/dispatcher.d/timesyncd b/debian/extra/dispatcher.d/timesyncd
new file mode 100755
index 000..cc1f3bc
--- /dev/null
+++ b/debian/extra/dispatcher.d/timesyncd
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+# Call timesyncd DHCP hook on NetworkManager interface events
+
+if [ "$2" = "up" -a -n "${DHCP4_NTP_SERVERS:-}" ]; then
+env reason="BOUND" \
+new_ntp_servers="${DHCP4_NTP_SERVERS}" \
+sh /etc/dhcp/dhclient-exit-hooks.d/timesyncd
+elif [ "$2" = "down" ]; then
+env reason="STOP" \
+sh /etc/dhcp/dhclient-exit-hooks.d/timesyncd
+fi
diff --git a/debian/systemd.install b/debian/systemd.install
index b3e0594..905600c 100644
--- a/debian/systemd.install
+++ b/debian/systemd.install
@@ -65,5 +65,6 @@ var/lib
 ../../extra/systemd-sysv-install lib/systemd/
 ../../extra/units/* lib/systemd/system/
 ../../extra/dhclient-exit-hooks.d/ etc/dhcp/
+../../extra/dispatcher.d/ etc/NetworkManager/
 ../../extra/kernel-install.d/* usr/lib/kernel/install.d
 ../../extra/pam.d etc/
-- 
2.7.4



Bug#861725: unblock: nagstamon/2.0.1-5

2017-05-03 Thread Moritz Schlarb
Control: retitle -1 unblock: nagstamon/2.0.1-5

Hi everyone,

I changed the patch to kind of the reverse: It now explicitly does not
call disable_warnings.

Regards,
Moritz

Attached nagstamon_2.0.1-5.debdiff

unblock nagstamon/2.0.1-5

On 03.05.2017 10:13, Moritz Schlarb wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package nagstamon
> 
> Hi there,
> 
> nagstamon/2.0.1-4, which just got uploaded to unstable fixes #861152, which is
> release critical and #774002, which just adds a Recommends for convenience - I
> hope this doesn't prevent the unblock.
> 
> Thank you.
> 
> Attached nagstamon_2.0.1-4.debdiff
> 
> unblock nagstamon/2.0.1-4
> 
> -- System Information:
> Debian Release: 8.7
>   APT prefers stable-updates
>   APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> 
diff -Nru nagstamon-2.0.1/debian/README.debian 
nagstamon-2.0.1/debian/README.debian
--- nagstamon-2.0.1/debian/README.debian1970-01-01 01:00:00.0 
+0100
+++ nagstamon-2.0.1/debian/README.debian2017-04-28 21:23:58.0 
+0200
@@ -0,0 +1,17 @@
+Nagstamon for Debian
+
+
+Please note that not to verify server certificates is a deliberate decision
+made by upstream (although there is an open issue to make it configurable
+per server) that is shared by the current package maintainers.
+The rationale for this is that monitoring servers are typically not
+intended for broad public access but for a limited group of technically
+trained users. (#861152)
+
+If you see "ImportError: No module named secretstorage" while starting:
+This non-critical message will occur when the recommended package
+python3-secretstorage is not installed. Nagstamon will work regardless,
+but please be aware that your server credentials will be stored
+in plaintext in the config files. (#774002)
+
+ -- Moritz Schlarb   Fri, 28 Apr 2017 21:06:17 +0200
diff -Nru nagstamon-2.0.1/debian/changelog nagstamon-2.0.1/debian/changelog
--- nagstamon-2.0.1/debian/changelog2017-01-12 11:27:30.0 +0100
+++ nagstamon-2.0.1/debian/changelog2017-05-03 14:48:11.0 +0200
@@ -1,3 +1,25 @@
+nagstamon (2.0.1-5) unstable; urgency=medium
+
+  * Don't disable InsecureRequestWarning warnings from urllib3 
+Closes: #861152
+
+ -- Moritz Schlarb   Wed, 03 May 2017 14:47:04 +0200
+
+nagstamon (2.0.1-4) unstable; urgency=medium
+
+  * Add Recommends for python3-secretstorage to debian/control
+Closes: #774002
+  * Fix code for disabling InsecureRequestWarning warnings
+Closes: #861152
+
+ -- Moritz Schlarb   Fri, 28 Apr 2017 21:16:17 +0200
+
+nagstamon (2.0.1-1~bpo8+1) jessie-backports; urgency=medium
+
+  * jessie-backports rebuild
+
+ -- Christoph Martin   Tue, 24 Jan 2017 12:31:59 +0100
+
 nagstamon (2.0.1-1) unstable; urgency=medium
 
   [ Moritz Schlarb ]
diff -Nru nagstamon-2.0.1/debian/control nagstamon-2.0.1/debian/control
--- nagstamon-2.0.1/debian/control  2017-01-12 11:27:30.0 +0100
+++ nagstamon-2.0.1/debian/control  2017-04-28 11:09:23.0 +0200
@@ -16,6 +16,7 @@
 Depends: ${python3:Depends}, ${misc:Depends}, python3-pkg-resources, 
python3-bs4,
  python3-pyqt5, python3-pyqt5.qtsvg, python3-pyqt5.qtmultimedia, 
libqt5multimedia5-plugins,
  python3-requests, python3-psutil, python3-dbus.mainloop.pyqt5
+Recommends: python3-secretstorage
 Description: Nagios status monitor which takes place in systray or on desktop
  Nagstamon is a Nagios status monitor which takes place in systray or 
  on desktop (GNOME, KDE) as floating statusbar to inform you in
diff -Nru nagstamon-2.0.1/debian/patches/not-disable-warnings.patch 
nagstamon-2.0.1/debian/patches/not-disable-warnings.patch
--- nagstamon-2.0.1/debian/patches/not-disable-warnings.patch   1970-01-01 
01:00:00.0 +0100
+++ nagstamon-2.0.1/debian/patches/not-disable-warnings.patch   2017-05-03 
14:46:11.0 +0200
@@ -0,0 +1,23 @@
+Description: Don't disable InsecureRequestWarning warnings
+Author: Moritz Schlarb 
+Bug-Debian: https://bugs.debian.org/861152
+Bug-Debian: https://bugs.debian.org/861725
+
+diff --git a/Nagstamon/Servers/Generic.py b/Nagstamon/Servers/Generic.py
+index dd9dcb1..17ebf17 100644
+--- a/Nagstamon/Servers/Generic.py
 b/Nagstamon/Servers/Generic.py
+@@ -18,13 +18,6 @@
+ # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, 
USA
+ 
+ import requests
+-# disable annoying InsecureRequestWarning warnings
+-try:
+-requests.packages.urllib3.disable_warnings()
+-except:
+-# older requests version might not have the packages submodule
+-# for example the one in Ubuntu 

Bug#796295: Reopen

2017-05-03 Thread u
Control: reopen 796295

Hi,

I'd like to reopen this bug, it's a call for help and it still applies
as long as the software is in the archive.

Cheers!
u.



Bug#861767: libgetdata: Incomplete debian/copyright?

2017-05-03 Thread Chris Lamb
Source: libgetdata
Version: 0.10.0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Alastair McKinstry 

Hi,

I just ACCEPTed libgetdata from NEW but noticed it was missing 
attribution in debian/copyright for at least m4/ax_compare_version.m4.

(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#861768: opendkim-tools: "opendkim-testmsg -t $(pwd) -K" does not leave temporary files in the current directory

2017-05-03 Thread Daniel Kahn Gillmor
Package: opendkim-tools
Version: 2.11.0~alpha-9
Severity: normal

It looks to me like the path argument to opendkim-testmsg isn't working:

0 $ ls
example.eml
0 $ ls /tmp
0 $ opendkim-testmsg -t $(pwd) -K < ./example.eml
opendkim-testmsg: dkim_eom(): Bad signature
70 $ ls
example.eml
0 $ ls /tmp
dkim.opendkim-testmsg.8Dtj3g
dkim.opendkim-testmsg.CsZJp3
0 $

Regards,

--dkg

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

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

Versions of packages opendkim-tools depends on:
ii  libbsd00.8.3-1
ii  libc6  2.24-10
ii  libdb5.3   5.3.28-12+b1
ii  libldap-2.4-2  2.4.44+dfsg-4+b1
ii  liblua5.1-05.1.5-8.1+b2
ii  libmemcached11 1.0.18-4.1
ii  libmemcachedutil2  1.0.18-4.1
ii  libopendbx11.4.6-11
ii  libopendkim11  2.11.0~alpha-9
ii  librbl12.11.0~alpha-9
ii  libssl1.1  1.1.0e-1
ii  libunbound21.6.0-3
ii  libvbr22.11.0~alpha-9

opendkim-tools recommends no packages.

opendkim-tools suggests no packages.

-- no debconf information



Bug#861764: [Calypso-maint] Bug#861764: calypso: Unicode error

2017-05-03 Thread Guido Günther
reassign 861764 python-vobject
forcemerge 841247 861764

On Wed, May 03, 2017 at 07:34:30PM +0100, Dev PICSL wrote:
[..snip..]
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/calypso/__init__.py", line 418, in
> do_PUT
> new_item = xmlutils.put(self.path, webdav_request, self._collection,
> context=context)
>   File "/usr/lib/python2.7/dist-packages/calypso/xmlutils.py", line 242, in 
> put
> return collection.append(name, webdav_request, context=context)
>   File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 463, in
> append
> self.create_file(new_item, context=context)
>   File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 389, in
> create_fiel

Upstream python-vobject is working on a fix:

https://github.com/eventable/vobject/issues/51

I've posted a workaround for calypso recently:

https://keithp.com/pipermail/calypso/2017-April/000345.html

which I'll push if upstream doesn't resolve the issue in the near
future.
Cheers,
 -- Guido



Bug#861705: RFS: visual-fill-column/1.11-1 [ITP]

2017-05-03 Thread Nicholas D Steeves
control: tags -1 - moreinfo

Ciao Gianfranco,

Thank you for sponsoring this upload of visual-fill-column! :-)

On Wed, May 03, 2017 at 12:01:55PM +, Gianfranco Costamagna wrote:
> control: reopen -1
> control: tags -1 moreinfo
> control: owner -1 !
> 
> 
> Remove moreinfo once you have something ready.
> 
> G.
> 
> Visual-fill-column is needed before the writeroom-mode RFP/ITP (Bug
> #861124) can be closed. I am maintaining both as part of the
> pkg-emacsen team.
> 
 ssh://git.debian.org/git/pkg-emacsen/pkg/visual-fill-column.git
> 
> To access further information about this package, please visit the following 
> URL:
> 
 https://mentors.debian.net/package/visual-fill-column
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/v/visual-fill-column/visual-fill-column_1.10-1.dsc

I just uploaded an update to mentors.  The updated URL is here:
https://mentors.debian.net/debian/pool/main/v/visual-fill-column/visual-fill-column_1.11-1.dsc

Changes since last upload: 

visual-fill-column (1.11-1) unstable; urgency=medium

  * Initial release. (Closes: #861687)
  * Add 0001-Update-claimed-version-important-for-integration-wit.patch
- Provides the correct version to GNU ELPA and MELPA to prevent
  potential dependency resolution issues.

 -- Nicholas D Steeves   Wed, 03 May 2017 14:43:38 -0400

Thank you!
Nicholas



signature.asc
Description: Digital signature


Bug#861766: wrong dependencies in liblog4cpp5

2017-05-03 Thread Cristiano Scardini

Package: liblog4cpp5
Version: 1.0-4


When I try to install two or more arch of packege, in a multiarch 
system, for cross compiling, i'm receiving a error:


Here is a transcript:

# apt-get install liblog4cpp5 liblog4cpp5:armhf

Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 liblog4cpp5 : Conflicts: liblog4cpp5:armhf but 1.0-4 is to be installed
 liblog4cpp5:armhf : Conflicts: liblog4cpp5 but 1.0-4 is to be installed
E: Unable to correct problems, you have held broken packages.

I suggest that the dependencies to be verified.

I am using Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 
(2017-03-07) x86_64 GNU/Linux.




Bug#861765: papi FTBFS on s390x: OVERFLOW_ADDRESS() and _papi_hwd_lock/unlock undefined!

2017-05-03 Thread Adrian Bunk
Source: papi
Version: 5.3.2-2
Severity: important

https://buildd.debian.org/status/logs.php?pkg=papi=s390x

...
In file included from papi_internal.h:120:0,
 from papi_preset.c:18:
linux-context.h:41:2: error: #error "OVERFLOW_ADDRESS() undefined!"
 #error "OVERFLOW_ADDRESS() undefined!"
  ^
In file included from papi_lock.h:20:0,
 from papi_internal.h:438,
 from papi_preset.c:18:
linux-lock.h:226:2: error: #error "_papi_hwd_lock/unlock undefined!"
 #error "_papi_hwd_lock/unlock undefined!"
  ^
...



Bug#861764: calypso: Unicode error

2017-05-03 Thread Dev PICSL
Package: calypso
Version: 1.5-3
Severity: important

Dear Maintainer,

* What led up to the situation?

When trying to create a calendar event in Thunderbird, where the title contains
non-ascii characters, calypso, in debug mode, displays a unicode error and the
event is not created.

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

It is the default installation. Nothing special has been done.

What was the outcome of this action?

You can not create events. Calypso creates a "Unicode Error" exception.

* What outcome did you expect instead?

Calypso fails to create events with the title with non-ascii characters. It
should not be like that.



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

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

Versions of packages calypso depends on:
ii  git  1:2.11.0-2
ii  python   2.7.13-2
ii  python-daemon2.1.2-1
ii  python-lockfile  1:0.12.2-2
ii  python-vobject   0.9.3-3

calypso recommends no packages.

calypso suggests no packages.

-- no debconf information

*** /tmp/Resumen-Calypso.txt
192.168.252.30 - - [03/May/2017 14:43:50] "PUT
/private/picsl/C783582E-E600-0001-6576-1FD1D56D4870.vcf HTTP/1.1" 400 -
First line 'PUT /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf
HTTP/1.1
'
keep-alive
reqlen 240
Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in
collection: /private/picsl
Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in
collection: /private/picsl
owner private user desarrollo
Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in name:
C783582E-E600-0001-F188-174014981B0F.vcf
Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in
collection: /private/picsl
Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in
collection: /private/picsl
Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in name:
C783582E-E600-0001-F188-174014981B0F.vcf
xmlutils put path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf name
C783582E-E600-0001-F188-174014981B0F.vcf
Scan /home/desarrollo/.config/calypso/calendars/private/picsl
New /home/desarrollo/.config/calypso/calendars/private/picsl/card-6Yf_0D.vcf
Parse error in None
/home/desarrollo/.config/calypso/calendars/private/picsl/card-6Yf_0D.vcf
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 75, in
__init__
self.object = vobject.readOne(text)
  File "/usr/lib/python2.7/dist-packages/vobject/base.py", line 1130, in
readOne
allowQP))
StopIteration
Insert /home/desarrollo/.config/calypso/calendars/private/picsl/card-6Yf_0D.vcf
failed
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 246, in
insert_file
item = self.read_file(path)
  File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 241, in
read_file
item = Item(text, None, path)
  File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 75, in
__init__
self.object = vobject.readOne(text)
  File "/usr/lib/python2.7/dist-packages/vobject/base.py", line 1130, in
readOne
allowQP))
StopIteration
Putting a new item, because name C783582E-E600-0001-F188-174014981B0F.vcf is
not known
append name C783582E-E600-0001-F188-174014981B0F.vcf
New item C783582E-E600-0001-F188-174014981B0F.vcf
Add C783582E-E600-0001-F188-174014981B0F.vcf
Failed PUT for /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/calypso/__init__.py", line 418, in
do_PUT
new_item = xmlutils.put(self.path, webdav_request, self._collection,
context=context)
  File "/usr/lib/python2.7/dist-packages/calypso/xmlutils.py", line 242, in put
return collection.append(name, webdav_request, context=context)
  File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 463, in
append
self.create_file(new_item, context=context)
  File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 389, in
create_file
context['action'] = u'Add %s'%item
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 12:
ordinal not in range(128)




192.168.252.30 - - [03/May/2017 14:43:51] "PUT
/private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf HTTP/1.1" 400 -
First line 'PUT /private/picsl/C783582E-E600-0001-5522-E2A08E3014BF.vcf
HTTP/1.1
'
keep-alive
reqlen 239
Path /private/picsl/C783582E-E600-0001-5522-E2A08E3014BF.vcf results in
collection: /private/picsl
Path /private/picsl/C783582E-E600-0001-5522-E2A08E3014BF.vcf results in
collection: /private/picsl
owner private user desarrollo
Path /private/picsl/C783582E-E600-0001-5522-E2A08E3014BF.vcf 

Bug#818942: ITP: python-bitcoinlib -- Easy interface to the Bitcoin data structures and protocol

2017-05-03 Thread Josue Ortega
retitle 818942 ITP: python-bitcoinlib -- Easy interface to the Bitcoin data 
structures and protocol
owner 818942 !

---
Josue Ortega
«Happy Hacking»
http://josueortega.org

signature.asc
Description: PGP signature


Bug#861763: inkscape: Launching in tiling WM (Awesome) causes corrupt UI

2017-05-03 Thread Steve Pomeroy
Package: inkscape
Version: 0.92.1-1
Severity: normal

Dear Maintainer,

Using AwesomeWM as my window manager in one of the tiling modes causes
Inkscape's UI to be corrupted. If I use the floating mode (where
Inkscape can set its own size / position on the screen), everything
works normally.

When launching Inkscape in one of Awesome's tiling modes, the UI is
somewhat responsive some of the time, but doesn't appear to redraw the
entire window. For example, zooming in/out will redraw the ruler, but
not the editing area. Eventually Inkscape stops responding to UI input
(I
haven't been able to trace what causes it to stop responding).

This seems to only happen when launching Inkscape: if I start Inkscape
from the floating mode and I switch to a tiling mode, everything works
fine even if I resize the window.

My suspicion is that Inkscape and Awesome are fighting over window
sizes when originally creating the window and Inkscape is holding on to
the assumption that it got the size it requested.

In addition to this (which could be related?): Inkscape has the bad
habit of putting itself on my 2nd monitor after loading a file for no
obvious reason. For example, I can load up Inkscape on my primary
monitor, open another file and the new window will appear on the 2nd
monitor.

This is AwesomeWM 4.0.0.0~git63-g6896a0aa

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

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

Versions of packages inkscape depends on:
ii  libaspell150.60.7~20110707-3+b2
ii  libatk1.0-02.22.0-1
ii  libatkmm-1.6-1v5   2.24.2-2
ii  libc6  2.24-10
ii  libcairo2  1.14.8-1
ii  libcairomm-1.0-1v5 1.12.0-1+b1
ii  libcdr-0.1-1   0.1.3-3+b1
ii  libdbus-1-31.10.18-1
ii  libdbus-glib-1-2   0.108-2
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.2
ii  libgc1c2   1:7.4.2-8
ii  libgcc11:6.3.0-14
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libglib2.0-0   2.50.3-2
ii  libglibmm-2.4-1v5  2.50.0-1
ii  libgomp1   6.3.0-14
ii  libgsl22.3+dfsg-1
ii  libgtk2.0-02.24.31-2
ii  libgtkmm-2.4-1v5   1:2.24.5-1
ii  libgtkspell0   2.0.16-1.1
ii  libjpeg62-turbo1:1.5.1-2
ii  liblcms2-2 2.8-4
ii  libmagick++-6.q16-78:6.9.7.4+dfsg-6
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-6
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-6
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpangoft2-1.0-0  1.40.5-1
ii  libpangomm-1.4-1v5 2.40.1-3
ii  libpng16-161.6.28-1
ii  libpoppler-glib8   0.48.0-2
ii  libpoppler64   0.48.0-2
ii  libpopt0   1.16-10+b2
ii  libpotrace01.13-3
ii  librevenge-0.0-0   0.0.4-6
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libstdc++6 6.3.0-14
ii  libvisio-0.1-1 0.1.5-4+b1
ii  libwpg-0.3-3   0.3.1-3
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-2.2
ii  libxslt1.1 1.1.29-2.1
pn  python:any 
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages inkscape recommends:
ii  aspell   0.60.7~20110707-3+b2
ii  fig2dev [transfig]   1:3.2.6a-2
ii  imagemagick  8:6.9.7.4+dfsg-6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-6
ii  libimage-magick-perl 8:6.9.7.4+dfsg-6
ii  libwmf-bin   0.2.8.4-10.6
ii  python-lxml  3.7.1-1
ii  python-numpy 1:1.12.1-2
ii  python-scour 0.32-2
ii  transfig 1:3.2.6a-2

Versions of packages inkscape suggests:
ii  dia  0.97.3+git20160930-5
pn  libsvg-perl  
pn  libxml-xql-perl  
pn  pstoedit 
pn  python-uniconvertor  
ii  ruby 1:2.3.3

-- no debconf information



Bug#861438: systemd is bad

2017-05-03 Thread Michael Biebl
Control: tags -1 + moreinfo

Hi Greg

Am 29.04.2017 um 07:32 schrieb Greg Alexander:
> Package: systemd
> Version: 232-22
> Severity: important
> 
> Dear Maintainer,
> 
> My specific problem is that systemd doesn't umount NFS before killing the
> network, which has previously been reported in Oct 2015 as Debian bug
> #800707, has not been fixed, and has been bumped several times by other
> users running into the same problem.

Sorry to hear that you had a bad experience with systemd.
As far as the autofs issue is concerned, the service file shipped by the
autofs package should have proper orderings in stretch afaics. So if you
network management tools properly hook into network.target and
network-online.target, there should be a correct ordering on shutdown.

If your issue is the same as  #800707, I would suggest you follow up
there or does your configuration differ from the above bug report so
this need to be tracked as a separate issue?

Speaking of configuration: Please provide more detailed information
about your setup. Log messages from the shutdown would be helpful as well.
/usr/share/doc/systemd/README.Debian.gz has some hints how to gather log
messages during shutdown.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature


Bug#861438: systemd is bad

2017-05-03 Thread Michael Biebl
Am 03.05.2017 um 20:12 schrieb Michael Biebl:
> Speaking of configuration: Please provide more detailed information
> about your setup. 

This includes: details about your network setup, tools you use to setup
your network, your autofs / fstab configuration.

-- 
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#861636: FTBFS when sources imported into git

2017-05-03 Thread Dirk Eddelbuettel

On 3 May 2017 at 19:33, Daniel Baumann wrote:
| On 05/03/17 16:19, Dirk Eddelbuettel wrote:
| > But there isn't a lot I can do
| 
| well, you could create the directory in the clean target.. and keep
| track of that by using find -type d -empty or so..

Patch?
 
| (yes, rather anyoing)
| 
| > -- besides using my upstream bugzilla account
| > and filing this as 
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17266
| 
| thanks ;)
| 
| also there's another funny one: if you name the directory of the source
| tree something containing a tilde (in my case, 3.4.0-1~dschinn1 for my
| local stretch backport), then it FTBFS too.

That is a known Debian or texlive or ... bug methinks as I had similar issues
when naming the actual build directory that way.

I think I should close this.  It is a pure upstream issue.

(And if follow the issue upstream, I didn't get to warm a reception.)

Dirk

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



Bug#861762: sbuild: apt clean should run after installing build dependencies

2017-05-03 Thread Vagrant Cascadian
Package: sbuild
Version: 0.73.0-4
Severity: normal

With "$apt_clean = 1;" in my ~/.sbuildrc, it appears that apt_clean runs
before the build-dependencies are installed, and so
/var/cache/apt/archive/*.deb files are not removed during the build.

It would be nice if it ran before the build started, but after any
packages have been installed, to save disk space during the build,
especially if running on a tmpfs where disk == ram.


live well,
  vagrant


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (120, 'unstable'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: armhf, arm64

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

Versions of packages sbuild depends on:
ii  adduser 3.115
ii  libsbuild-perl  0.73.0-4
pn  perl:any

Versions of packages sbuild recommends:
ii  autopkgtest  4.3
ii  debootstrap  1.0.89
ii  schroot  1.6.10-3+b1

Versions of packages sbuild suggests:
pn  deborphan  
ii  kmod   23-2
ii  wget   1.18-5

-- no debconf information


signature.asc
Description: PGP signature


Bug#861732: systemd: How to get suricata started at boot?

2017-05-03 Thread Michael Biebl
Am 03.05.2017 um 18:50 schrieb Arturo Borrero Gonzalez:

> No, suricata comes pre-configured to run out of the box. You can run
> suricata with the basic configuration we ship in the package. The
> software is ready to run.
> 
> But it requires rules (like a firewall) and the user setting some
> variables in order to let suricata know about the network environment,
> among other things.

If it doesn't open up any security hole, then I don't see a reason to
not enable suricata upon installation.
Keep in mind that we basically do the same for say apache2. I bet most
admins installing apache2 tweak it's configuration afterwards.

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



signature.asc
Description: OpenPGP digital signature


Bug#844676: Fwd: reorganization of www.debian.org/partners, and translations

2017-05-03 Thread Laura Arjona Reina
Hi

El 3 de mayo de 2017 8:09:03 CEST, Holger Wansing  
escribió:
>Hi,
>
>Laura Arjona Reina  wrote:
>> Hi everybody
>> I've sent the message below to the i18n mailing list.
>> 
>> I'll work in the following days on updating the
>> www.debian.org/partners section, but content wise only.
>> 
>> If I don't receive any report/issue/suggestion on the technical side,
>> I'll assume this reorganization is done and working, and close the
>bug
>> #844676 in mid-May.
>
>Well, the issues I reported in
>https://lists.debian.org/debian-www/2017/03/msg00065.html
>are still there, FYI.
>

I think those are fixed now.

Please let me know any other issue you find.

Thanks!


Laura Arjona Reina
https://wiki.debian.org/LauraArjona



Bug#859560: fixed in xen 4.8.1-1

2017-05-03 Thread Maximilian Engelhardt
On Dienstag, 25. April 2017 00:08:20 CEST Ivar Smolin wrote:
> On Tue, 18 Apr 2017 17:34:15 + Ian Jackson
> 
>  wrote:
> > Source: xen
> > Source-Version: 4.8.1-1
> > 
> > We believe that the bug you reported is fixed in the latest version of
> > xen, which is due to be installed in the Debian FTP archive.
> 
> Thanks for fixing!
> 
> This bug affects also Xen 4.4.x, Jessie is still vulnerable.


Hi, what's the status of this in Jessie?

According to https://security-tracker.debian.org/tracker/CVE-2017-7228 Jessie 
is still vulnerable.

Thanks,
Maxi

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


Bug#861761: unblock: (pre-approval) offlineimap/7.0.14+dfsg1-2

2017-05-03 Thread Ilias Tsitsimpis
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear Release Team,

One of the UIs for OfflineIMAP, namely Blinkenlights, is broken in the
current version of OfflineIMAP. More specifically, the output of
Blinkenlights becomes "garbled" and eventually results in a crash of the
Python process. For more information, see the upstream bug report:

https://github.com/OfflineIMAP/offlineimap/issues/160

This has been broken for more than a year, but only recently fixed.
Since the patch is fairly small, and users have already complained about
this in the past[1], I would like to update OfflineIMAP to fix this bug.
What do you think?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809676#31

unblock offlineimap/7.0.14+dfsg1-2

Kind Regards,

-- 
Ilias
diff -Nru offlineimap-7.0.12+dfsg1/debian/changelog offlineimap-7.0.12+dfsg1/debian/changelog
--- offlineimap-7.0.12+dfsg1/debian/changelog	2016-12-01 13:04:38.0 +0200
+++ offlineimap-7.0.12+dfsg1/debian/changelog	2017-05-03 18:40:38.0 +0300
@@ -1,3 +1,11 @@
+offlineimap (7.0.12+dfsg1-2) unstable; urgency=medium
+
+  * Backport upstream patch to fix Blinkenlights UI.
+Fix the Blinkenlights UI where the terminal is garbled and eventually
+OfflineIMAP crashes.
+
+ -- Ilias Tsitsimpis   Wed, 03 May 2017 18:40:38 +0300
+
 offlineimap (7.0.12+dfsg1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch
--- offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch	1970-01-01 02:00:00.0 +0200
+++ offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch	2017-05-03 18:29:54.0 +0300
@@ -0,0 +1,60 @@
+From: Ilias Tsitsimpis 
+Date: Wed, 12 Apr 2017 13:25:46 +0300
+Subject: Acquire lock before updating the CursesLogHandler window
+
+Make sure that we refresh the screen atomically, since the emit()
+function may be called by more that one threads at a time.
+
+Also, modify the draw_bannerwin() method which used to fail in case the
+window would become too small. Make sure that the provided offsets to
+the window.addstr() method are properly bounded.
+
+Closes #160: blinkenlights display is broken
+Tested-by: Cyril Brulebois
+Tested-by: Gaudenz Steinlin
+Signed-off-by: Ilias Tsitsimpis 
+Signed-off-by: Nicolas Sebrecht 
+
+Origin: upstream, https://github.com/OfflineIMAP/offlineimap/commit/7bc54d241cce
+Bug: https://github.com/OfflineIMAP/offlineimap/issues/160
+Bug-Debian: https://bugs.debian.org/809676
+---
+ offlineimap/ui/Curses.py | 15 ---
+ 1 file changed, 8 insertions(+), 7 deletions(-)
+
+diff --git a/offlineimap/ui/Curses.py b/offlineimap/ui/Curses.py
+index 152c5d6..e97bed0 100644
+--- a/offlineimap/ui/Curses.py
 b/offlineimap/ui/Curses.py
+@@ -315,11 +315,11 @@ class CursesLogHandler(logging.StreamHandler):
+ y,x = self.ui.logwin.getyx()
+ if y or x: self.ui.logwin.addch(10) # no \n before 1st item
+ self.ui.logwin.addstr(log_str, color)
++self.ui.logwin.noutrefresh()
++self.ui.stdscr.refresh()
+ finally:
+ self.ui.unlock()
+ self.ui.tframe_lock.release()
+-self.ui.logwin.noutrefresh()
+-self.ui.stdscr.refresh()
+ 
+ class Blinkenlights(UIBase, CursesUtil):
+ """Curses-cased fancy UI.
+@@ -611,11 +611,12 @@ class Blinkenlights(UIBase, CursesUtil):
+ color = curses.A_REVERSE
+ self.bannerwin.clear() # Delete old content (eg before resizes)
+ self.bannerwin.bkgd(' ', color) # Fill background with that color
+-string = "%s %s"% (offlineimap.__productname__,
+-offlineimap.__version__)
+-self.bannerwin.addstr(0, 0, string, color)
+-self.bannerwin.addstr(0, self.width -len(offlineimap.__copyright__) -1,
+-  offlineimap.__copyright__, color)
++string = "%s %s" % (offlineimap.__productname__,
++offlineimap.__version__)
++spaces = " " * max(1, (self.width - len(offlineimap.__copyright__)
++   - len(string) - 1))
++string = "%s%s%s" % (string, spaces, offlineimap.__copyright__)
++self.bannerwin.addnstr(0, 0, string, self.width - 1, color)
+ self.bannerwin.noutrefresh()
+ 
+ def draw_logwin(self):
diff -Nru offlineimap-7.0.12+dfsg1/debian/patches/series offlineimap-7.0.12+dfsg1/debian/patches/series
--- offlineimap-7.0.12+dfsg1/debian/patches/series	2016-12-01 13:04:11.0 +0200
+++ offlineimap-7.0.12+dfsg1/debian/patches/series	2017-05-03 

Bug#861636: FTBFS when sources imported into git

2017-05-03 Thread Daniel Baumann
On 05/03/17 16:19, Dirk Eddelbuettel wrote:
> But there isn't a lot I can do

well, you could create the directory in the clean target.. and keep
track of that by using find -type d -empty or so..

(yes, rather anyoing)

> -- besides using my upstream bugzilla account
> and filing this as https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17266

thanks ;)

also there's another funny one: if you name the directory of the source
tree something containing a tilde (in my case, 3.4.0-1~dschinn1 for my
local stretch backport), then it FTBFS too.

Regards,
Daniel



Bug#859016: Processed: Re: Bug#859016: yadifa should drop ppc64el -O2 workaround

2017-05-03 Thread Gianfranco Costamagna
control: reopen 859016
thanks


the patch has been upstreamed :(

G.


Il Mercoledì 3 Maggio 2017 18:45, Debian Bug Tracking System 
 ha scritto:



Processing control commands:

> fixed -1 2.2.3-1
Bug #859016 [src:yadifa] yadifa should drop ppc64el -O2 workaround
Marked as fixed in versions yadifa/2.2.3-1.
> close -1
Bug #859016 [src:yadifa] yadifa should drop ppc64el -O2 workaround
Marked Bug as done

-- 
859016: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859016
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problemsProcessing control commands:

> fixed -1 2.2.3-1
Bug #859016 [src:yadifa] yadifa should drop ppc64el -O2 workaround
Marked as fixed in versions yadifa/2.2.3-1.
> close -1
Bug #859016 [src:yadifa] yadifa should drop ppc64el -O2 workaround
Marked Bug as done

-- 
859016: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859016
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#861480: ImportError: No module named QtWebKit

2017-05-03 Thread Dejan Muhamedagic
On Sat, Apr 29, 2017 at 11:25:41PM +0200, Michal Čihař wrote:
> Gammu/Wammu should work as well [1], though the GUI is probably not
> that nice.
> 
> [1]:https://wammu.eu/docs/manual/protocol/s60.html

Unfortunately the gnapplet thing won't run on my S60 phone (Nokia
C05 I think), so I cannot test wammu. Anyway, apparently the
porting shouldn't be so difficult.



Bug#861575: tilix: Does not start on Stretch (symbol lookup error: undefined symbol)

2017-05-03 Thread Mathieu Basille
Hey Jason,

Thanks for looking it up! As a matter of fact, it looks like both
libgtkd-3-0 and libvted-3-0 needs to be >= 3.5.1-1. Installing both
libraries from unstable (both v.3.5.1-1) fixes the problem, and Tilix is
able to run with it.

Cheers,
Mathieu.


On 05/03/2017 01:42 AM, Jason Crain wrote:
> On Sun, Apr 30, 2017 at 06:43:18PM -0400, Mathieu Basille wrote:
>> Following the name change from terminix to tilix, I updated 
>> my Stretch system (which uses apt pining to install Sid 
>> packages whenever possible) to use the new developments of 
>> tilix.
>>
>> Install of v1.5.4-1 works without any problem, but I'm unable
>> to run tilix:
>>
>> tilix: symbol lookup error: tilix: undefined symbol:
>>  
>> _D7gobject7ObjectG7ObjectG11addOnNotifyMFDFC7gobject9ParamSpec9ParamSpecC7gobject7ObjectG7ObjectGZvAyaE4gtkc12gobjecttypes13GConnectFlagsZm
> ...
>>
>> Versions of packages tilix depends on:
>> ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
>> ii  libc62.24-10
>> ii  libgtkd-3-0  3.3.1-2
>> ii  libphobos2-ldc71 1:1.1.1-1
>> ii  libvted-3-0  3.3.1-2
>> ii  libx11-6 2:1.6.4-3
>> ii  tilix-common 1.5.4-1
> 
> tilix seems to require libgtkd-3-0 >= 3.5.1-1 and should have its
> Depends increased.
> 

-- 

Ce message est signé pour en assurer l'authenticité.
Pour une correspondance avec moi réellement privée,
utilisez ma clé publique pour chiffrer vos messages :

  http://mathieu.basille.net/pub.asc

Plus d'infos : http://mzl.la/1BsOGiZ



signature.asc
Description: OpenPGP digital signature


Bug#778917: texlive-latex-extra: missing dependency - textgreek.sty requires lgrenc.def (texlive-lang-greek)

2017-05-03 Thread Carnë Draug
Package: texlive-latex-extra
Version: 2016.20170123-5
Followup-For: Bug #778917

On 21 Feb 2015 21:01:04 +0100, Hilmar Preuße wrote:
> On 21.02.2015 20:18, carandraug wrote:
>
> Hi,
>
>> The Tex textgreek package is part of the texlive-latex-extra debian package.
>> This Tex package depends on lgrenc.def which in Debian, is part of the Debian
>> texlive-lang-greek package.  This package should then be listed as a
>> dependency for texlive-latex-extra but it is not.
>
> Hmm. texlive-latex-extra has size of 33MB. texlive-lang-greek has a size 
> of 88MB. Forcing users to download and install 88MB just for a def file 
> having a size of 37KB won't make us friends.
> Norbert, could you discuss this w/ upstream. Maybe moving the 
> "greek-fontenc" TeX package to an extra TeX Live package?
>
> Hilmar

This issue is still present on Debian Stretch.  It was not a problem
on Wheezy because lgrenc.def was part of texlive-latex-base.

I understand trying to avoid the 88MB dependency but at the moment
that means that the textgreek package in texlive-latex-extra is
broken which I would arguee is worse.

Carnë

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

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

Versions of packages texlive-latex-extra depends on:
ii  preview-latex-style11.90-1
ii  tex-common 6.06
ii  texlive-base   2016.20170123-5
ii  texlive-binaries   2016.20160513.41080.dfsg-2
ii  texlive-latex-recommended  2016.20170123-5
ii  texlive-pictures   2016.20170123-5

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2016.20170123-5
ii  texlive-generic-extra  2016.20170123-5
ii  texlive-latex-extra-doc2016.20170123-5

Versions of packages texlive-latex-extra suggests:
ii  libfile-which-perl  1.21-1
ii  libspreadsheet-parseexcel-perl  0.6500-1
ii  python-pygments 2.2.0+dfsg-1

Versions of packages tex-common depends on:
ii  dpkg  1.18.23
ii  ucf   3.0036

Versions of packages tex-common suggests:
ii  debhelper  10.2.5

Versions of packages texlive-latex-extra is related to:
ii  tex-common6.06
ii  texlive-binaries  2016.20160513.41080.dfsg-2

-- no debconf information


Bug#861759: libsane: Xsane fails to find Epson Perfection V600 Photo USB Scanner

2017-05-03 Thread Jonathan Hutchins
Package: libsane
Version: 1.0.24-8+deb8u1
Severity: important

Dear Maintainer,

Xsane fails to find the scanner.  sane-find-scanner finds it at
/dev/bus/usb/008/003  scanimage -l or scanimage -L fails to find it.
I have installed the iscan package from Epson, as several reports
indicates this includes a driver/wrapper that may help, but iscan is
"unable to send comannd".
/dev/bus/usb/008/003 is crw-rw-r--+ 1 root root - this could be a problem
for regular users, but root is also unable to find the scanner with the
same results as above.
The scanner was working with current Jessie 32b upgraded through several
versions of Debian, and I believe I may have solved a similar problem in
the past, but I can not find my notes on that.

(Sorry for the delay in re-reporting this, I had to re-install reportbug.)

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

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

Versions of packages libsane depends on:
ii  acl2.2.52-2
ii  adduser3.113+nmu3
ii  libavahi-client3   0.6.31-5
ii  libavahi-common3   0.6.31-5
ii  libc6  2.19-18+deb8u7
ii  libexif12  0.6.21-2
ii  libgphoto2-6   2.5.4-1.1+b2
ii  libgphoto2-port10  2.5.4-1.1+b2
ii  libieee1284-3  0.2.11-12
ii  libjpeg62-turbo1:1.3.1-12
ii  libsane-common 1.0.24-8+deb8u1
ii  libtiff5   4.0.3-12.3+deb8u2
ii  libusb-1.0-0   2:1.0.19-1
ii  libv4l-0   1.6.0-2
ii  multiarch-support  2.19-18+deb8u7
ii  udev   215-17+deb8u6

Versions of packages libsane recommends:
ii  libsane-extras  1.0.22.3
ii  sane-utils  1.0.24-8+deb8u1

Versions of packages libsane suggests:
ii  avahi-daemon  0.6.31-5
ii  hplip 3.14.6-1+deb8u1
pn  hpoj  

-- no debconf information



Bug#861732: systemd: How to get suricata started at boot?

2017-05-03 Thread Arturo Borrero Gonzalez
On 3 May 2017 at 18:33, Michael Biebl  wrote:
> [dropping debian-user from CC]
>
> Am 03.05.2017 um 17:39 schrieb Arturo Borrero Gonzalez:
>> On 3 May 2017 at 12:36, Michael Biebl  wrote:
>>> Am 03.05.2017 um 11:11 schrieb Hans:
 Hello all,
>
>>> systemctl enable suricata.service
>>>
>>> will do the trick. That should be done by the package though.
>>
>> This conflicts with what was reported in #850889 [0].
>>
>> I think both arguments are valid:
>>
>> 1) any suricata deployment is likely to require manual configuration
>> before proper service. Auto-start makes no sense.
>> 2) yes, we are debian, we like things running out of the box
>>
>> So, I'm unsure what path to follow.
>>
>> In any case, a fix is not landing in stretch at this point. We should
>> wait for the stretch stable release.
>>
>> Comments/discussion welcome.
>>
>> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861732
>
> So, if I understand you correctly, suricata comes unconfigured
> out-of-the-box? What does suricata do, it it is started anyway?
>

No, suricata comes pre-configured to run out of the box. You can run
suricata with the basic configuration we ship in the package. The
software is ready to run.

But it requires rules (like a firewall) and the user setting some
variables in order to let suricata know about the network environment,
among other things.

This is documented in our wiki [0].

Take into account that the user here is likely a system/network
administrator. Someone who is supposed to know what is doing by
installing suricata.

[0] https://wiki.debian.org/suricata#Suricata_running_configuration



Bug#859016: yadifa should drop ppc64el -O2 workaround

2017-05-03 Thread Gianfranco Costamagna
control: fixed -1 2.2.3-1
control: close -1
On Wed, 29 Mar 2017 18:35:27 +0300 Adrian Bunk  wrote:
> On Wed, Mar 29, 2017 at 06:14:31PM +0300, Adrian Bunk wrote:
> > Source: yadifa
> > Version: 2.2.3-1
> > Severity: minor
> > 
> > yadifa should drop fix-ppc64el_ftbfs.patch,
> > the relevant gcc bugs are now fixed.
> > 
> > There is no need to hurry and change this in stretch,
> > but for stretch this workaround should be removed.
> 

this is already fixed in Stretch, just it hasn't been mentioned in changelog.
The patch has been commented in series file between 2.2.2-2 and 2.2.3-1

G.



signature.asc
Description: OpenPGP digital signature


Bug#861732: systemd: How to get suricata started at boot?

2017-05-03 Thread Michael Biebl
[dropping debian-user from CC]

Am 03.05.2017 um 17:39 schrieb Arturo Borrero Gonzalez:
> On 3 May 2017 at 12:36, Michael Biebl  wrote:
>> Am 03.05.2017 um 11:11 schrieb Hans:
>>> Hello all,

>> systemctl enable suricata.service
>>
>> will do the trick. That should be done by the package though.
> 
> This conflicts with what was reported in #850889 [0].
> 
> I think both arguments are valid:
> 
> 1) any suricata deployment is likely to require manual configuration
> before proper service. Auto-start makes no sense.
> 2) yes, we are debian, we like things running out of the box
> 
> So, I'm unsure what path to follow.
> 
> In any case, a fix is not landing in stretch at this point. We should
> wait for the stretch stable release.
> 
> Comments/discussion welcome.
> 
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861732

So, if I understand you correctly, suricata comes unconfigured
out-of-the-box? What does suricata do, it it is started anyway?

Is there a config file which needs to be created and you could test for
in the systemd service file, with
ConditionPathExists=/etc/my.config


-- 
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#798601: limereg: FTBFS on mips/mipsel

2017-05-03 Thread Mattia Rizzolo
On Wed, May 03, 2017 at 05:19:37PM +0100, James Cowgill wrote:
> It looks like this was just an uninitialized variable in
> test_searchSubimage.c. Applying the attached patch fixes this issue for
> me on mipsel.


Thank you for the patch!
Uploading :)

-- 
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#861169: Triaging and downgrading severity (includes rationale and suggestions)

2017-05-03 Thread Henrique de Moraes Holschuh
severity 861169 important
retitle 861169 systemd service overrides opendkim.conf socket at start
thanks


The previous report mentioned by the bug submitter is #853769.
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853769)

>From that bug report, message #38
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853769#38)
says:

Using the existing service file I confirmed that changes in
/etc/opendkim.conf do affect the configuration of the running
service after it is restarted.  There's no change needed.

Apparently, this not correct when the service is started, or at least in
the specific way the submitter used to configure opendkim.


Still, the behavior described in this new bug report is exactly how the
sysvinit script behaves (according to #853769), which means the local
admin is supposed to *override* this in the initscript.  While this is
NOT nearly as userfriendly as one might like, the *same* logic may be
applied to systemd support if no better fix is possible at this time.

IMHO, if a better choice is not available (e.g. due to security concerns
or complexity of the required fix to avoid regressing any
already-installed systems that depended on the initscript/systemd unit
forced unix socket path), this could be properly documented in
NEWS.debian/README.debian and also in the default /etc/ config file (and
maybe as comments in the systemd unit and also the sysvinit initscript
-- being through in these things pays off).


I am downgrading this bug to important (which does *NOT* mean it should
not be fixed, and if the fix is actually going to be just documentation,
IMO that fix should be uploaded ASAP since it has zero regression risk
and should be present in the next Debian stable if possible).

Reasons for the severity downgrade:

1.  It does *NOT* render the package unusable to the majority of its
users, and it only affects more complex setups that would never
work out-of-the-box without local configuration being done.

2.  AFAIK, it matches previous behavior of Debian stable, and also when
using initscripts instead of systemd.

3.  It is not a regression in itself, and it doesn't cause regressions
when the package is updated, as far as I can tell.

4.  The issue it causes is going to be detected when the local admin is
first configuring opendkim, and it is easy to work around (by
editing the sysvinit script -- which is a conffile -- or by dropping an
override for the systemd unit in the appropriate place under /etc).

Bugs #853769 and #861169 are available as temporary documentation
for the issue and provide hints to the required configuration change
for the workaround.

5.  The "grave" severity is very troublesome for every package depending
on opendkim, and risks kicking all those packages out of the next
Debian stable.

-- 
  Henrique Holschuh



Bug#861757: RFS: fonts-fandol/0.3-1 [ITP]

2017-05-03 Thread Boyuan Yang
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fonts-fandol"

 * Package name: fonts-fandol
   Version : 0.3-1
   Upstream Author : Clerk Ma 
 * URL : https://www.ctan.org/pkg/fandol
 * License : GPL-3 with fonts exception
   Section : fonts


  It builds those binary packages:

fonts-fandol - Fandol fonts designed for Chinese typesetting

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

  https://mentors.debian.net/package/fonts-fandol

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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-fandol/fonts-fandol_0.3-1.dsc

 Packaging Git repository:
https://anonscm.debian.org/git/collab-maint/fonts-fandol.git

 Changes since the last upload:

fonts-fandol (0.3-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #861720)

--
Sincerely,
Boyuan Yang

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


Bug#798601: limereg: FTBFS on mips/mipsel

2017-05-03 Thread James Cowgill
Control: tags -1 patch

Hi,

I investigated this a bit by comparing in gdb a good version of limereg
compiled without -Ofast and -fstack-protector and the original version.

It looks like this was just an uninitialized variable in
test_searchSubimage.c. Applying the attached patch fixes this issue for
me on mipsel.

Thanks,
James
--- a/tests/test_searchSubimage.c
+++ b/tests/test_searchSubimage.c
@@ -86,6 +86,7 @@ bool test_searchSubimage()
 	const unsigned int skipLvl=2;
 	struct Limereg_AdvancedRegControl advancedRegControl;
 	advancedRegControl.maxIterations = 50;
+	advancedRegControl.stopSensitivity = 0;
 	advancedRegControl.pyramidLevelCount = pyramidLvl;
 	advancedRegControl.skipFineLevelCount = skipLvl;
 	advancedRegControl.startParameters = 


signature.asc
Description: OpenPGP digital signature


Bug#861497: gcc-6-cross: FTBFS in stretch

2017-05-03 Thread Santiago Vila
On Wed, May 03, 2017 at 01:40:12AM +0200, Matthias Klose wrote:

> > I tried to build this package in stretch with "dpkg-buildpackage -A"
> > but it failed:
> 
> fine, but you should make sure that this occurs in a distro environment as 
> well.

I always do these test builds using sbuild in a chroot, as official 
autobuilders do.

I also do "dpkg-buildpackage -A" or "dpkg-buildpackage -B" as official
autobuilders do.

So if by "distro environment" you meant I should use a chroot, I already do 
that.

> > I've put the full build log here:
> > 
> > https://people.debian.org/~sanvila/build-logs/gcc-6-cross/
> 
> for future reports, please could you keep a list of packages to check manually
> for the errors?  I tried to rebuild the package, and I couldn't even reproduce
> this one.

I already try to check before reporting.

In this case, because the package takes a long time to build, I
decided to do my "second" build not in my own autobuilders but in
the reproducible builds autobuilders.

So I tried twice in two different and unrelated autobuilders and I got
two failures. Seemed good enough to me to report it as a bug.

If the failures happened because of different reasons, as you say,
then I'm very sorry for not having noticed, but in such case the
problem is even worse, as it would mean that the package does not
build reliably, or it fails to build randomly.

When a the package fails to build randomly, you can't be sure that it
does not fail randomly just by building it once, it could be just a
matter of luck that it built ok that time.

I have found more than 50 packages in stretch which FTBFS randomly so
I can tell you for sure that such packages do exist.

> PS: gcc-6-cross_22 was successfully built on the buildds.

Glad to know, but such fact does not exclude that the package may fail
randomly, so I would not consider this fixed just because of that.

Thanks.



Bug#861364: dgit: empty directories are not representable

2017-05-03 Thread Ian Jackson
Nish Aravamudan writes ("Bug#861364: dgit: empty directories are not 
representable"):
> On Wed, May 3, 2017 at 8:47 AM, Ian Jackson
> > Call it a bug in git ? :-)  I know that doesn't really help.
> 
> Yeah -- Robie is working on fixing git.

Coo!

> > My initial plan was to simply ignore empty directories and hope that
> > it didn't matter.  If they do matter then we probably don't have a
> > good answer.
> 
> Agreed -- I think it is generically not possible to know if a given
> empty directory matters or not. But it does mean if a goal is to
> represent the exact contents of a given source package in the
> corresponding git commit -- that's not achievable in the presence of
> empty directories, at least by default.

Yes.

> I wanted to file this mostly so our importer and dgit did the same
> thing for cases like this :)

Stuff like this is one reason I haven't done a big historical import.
After reifying such an import, it will be difficult to retrospectively
fix this kind of problem.

If you have an actual plan for fixing this then I would certainly like
to hear it.  If you have any non-awful workaround ideas, too.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

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



Bug#861756: pd-pdstring: please make the build reproducible

2017-05-03 Thread Chris Lamb
Source: pd-pdstring
Version: 0.10.2-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that pd-pdstring could not be built reproducibly as it embeds
the current username.

Patch attached that modifies that patch I previously sent in
#833445.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/common/m4/ax_pd_external.m4   2017-05-03 17:06:26.820444508 +0100
--- b/common/m4/ax_pd_external.m4   2017-05-03 17:10:13.613304235 +0100
@@ -244,10 +244,11 @@
  ## compiled
  if test -n "$SOURCE_DATE_EPOCH"; then
AC_DEFINE_UNQUOTED(PACKAGE_BUILD_DATE,  "`LC_ALL=C date --utc 
--date="@$SOURCE_DATE_EPOCH"`",   [Date this package was configured])
+   AC_DEFINE_UNQUOTED(PACKAGE_BUILD_USER,  "unknown",[User who configured 
this package])
  else
AC_DEFINE_UNQUOTED(PACKAGE_BUILD_DATE,  "`date`",   [Date this package was 
configured])
+   AC_DEFINE_UNQUOTED(PACKAGE_BUILD_USER,  "$USER",[User who configured 
this package])
  fi
- AC_DEFINE_UNQUOTED(PACKAGE_BUILD_USER,  "$USER",[User who configured this 
package])
  ## /compiled
  ##^^
 


Bug#861755: libpll: FTBFS on x86: AVX target specific option mismatch

2017-05-03 Thread Aaron M. Ucko
Source: libpll
Version: 0.0+20160909+ds1-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

Builds of libpll on x86 architectures (even kfreebsd-amd64) fail too:

  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -msse3 -g 
-c core_partials_avx.c  -fPIC -DPIC -o .libs/libpll_la-core_partials_avx.o
  core_partials_avx.c: In function 'pll_core_create_lookup_4x4_avx':
  core_partials_avx.c:155:11: warning: AVX vector return without AVX enabled 
changes the ABI [-Wpsabi]
  [...]
  /usr/lib/gcc/x86_64-kfreebsd-gnu/6/include/avxintrin.h:1270:1: error: 
inlining failed in call to always_inline '_mm256_set_epi64x': target specific 
option mismatch

It appears to be performing CPU type detection at build time rather
than runtime.  As such, please specify --disable-avx everywhere and
--disable-sse on i386 and ensure that the resulting configurations
build.

Thanks!

FTR, I'm reporting this bug as a regression because I suspect it would
affect binNMUs on amd64.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#861364: dgit: empty directories are not representable

2017-05-03 Thread Nish Aravamudan
On Wed, May 3, 2017 at 8:47 AM, Ian Jackson
 wrote:
> Nishanth Aravamudan writes ("Bug#861364: dgit: empty directories are not 
> representable"):
>> At least src:software-properties has at one time had empty directories
>> in the source package, e.g. in 0.96.20.5 in xenial on Ubuntu, and git
>> (and thus dgit (via import-dsc) and the Ubuntu git importer) fail to
>> properly represent the srcpkg's contents in the import.
>>
>> Specifically, tests/aptroot/etc/apt/apt.conf.d/ is missing from either
>> import.
>
> Presumably the package breaks without this ?

Yeah, in this case, a developer built a new srcpkg using our imported
tree and it failed to pass the autopkgtests, which depended on this
directory existing.

>> Given that git does not represent empty directories, I'm not sure what
>> we should do here?
>
> Call it a bug in git ? :-)  I know that doesn't really help.

Yeah -- Robie is working on fixing git.

> My initial plan was to simply ignore empty directories and hope that
> it didn't matter.  If they do matter then we probably don't have a
> good answer.

Agreed -- I think it is generically not possible to know if a given
empty directory matters or not. But it does mean if a goal is to
represent the exact contents of a given source package in the
corresponding git commit -- that's not achievable in the presence of
empty directories, at least by default.

I wanted to file this mostly so our importer and dgit did the same
thing for cases like this :)



Bug#861754: libpll: FTBFS on non-x86: x86intrin.h: No such file or directory

2017-05-03 Thread Aaron M. Ucko
Source: libpll
Version: 0.0+20160909+ds1-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of libpll for non-x86 architectures have been failing:

  pll.h:28:23: fatal error: x86intrin.h: No such file or directory

It looks like the build system already checks for this header, just
doesn't (fully?) honor the check results; please conditionalize this
#include directive on HAVE_X86INTRIN_H.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#861748: r-cran-rmpi: Loading library fails

2017-05-03 Thread Ralf Stubner
On Wed, May 3, 2017 at 5:42 PM, Dirk Eddelbuettel  wrote:
>
> I think I found it.  Do an 'apt-get install libopenmpi-dev' and it will work.

I was about to write that 'pkg-config --libs ompi' produces an error
and that there is no libmpi.so on my system. After installing
libopenmpi-dev, both symptoms go away and I am able to load the Rmpi
library. thanks a lot!

> Looks like we are missing an ldconfig run there.

Is it really an ldconfig runthat is missing? To me it looks like the
necessary link for libmpi.so is set-up by libopenmpi-dev and not
libopenmpi2. So either r-cran-rmpi should (also) depend on
libopenmpi-dev, or creating this link should be moved to libopenmpi2.

Greetings
Ralf



Bug#861364: dgit: empty directories are not representable

2017-05-03 Thread Ian Jackson
Nishanth Aravamudan writes ("Bug#861364: dgit: empty directories are not 
representable"):
> At least src:software-properties has at one time had empty directories
> in the source package, e.g. in 0.96.20.5 in xenial on Ubuntu, and git
> (and thus dgit (via import-dsc) and the Ubuntu git importer) fail to
> properly represent the srcpkg's contents in the import.
>
> Specifically, tests/aptroot/etc/apt/apt.conf.d/ is missing from either
> import.

Presumably the package breaks without this ?

> Given that git does not represent empty directories, I'm not sure what
> we should do here?

Call it a bug in git ? :-)  I know that doesn't really help.

My initial plan was to simply ignore empty directories and hope that
it didn't matter.  If they do matter then we probably don't have a
good answer.

Ian.

-- 
Ian Jackson    These opinions are my own.

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



Bug#861474: slim: Session restarts in a loop renedering whole system useless.

2017-05-03 Thread Apollon Oikonomopoulos
Hi Mateusz,

On 17:12 Tue 02 May , Apollon Oikonomopoulos wrote:
> The attached debdiff resolves the restart loop, while ensuring that 
> slim plays nice with plymouth. If nobody responds, I intend to NMU the 
> package tomorrow.

Would you like to update the package, or should I go ahead with the NMU 
as described above?

Regards,
Apollon



Bug#861748: r-cran-rmpi: Loading library fails

2017-05-03 Thread Dirk Eddelbuettel

On 3 May 2017 at 09:36, Dirk Eddelbuettel wrote:
| 
| This may have something to do with it:
| 
|   root@ef11adb9da1c:/# pkg-config --libs ompi
|   -L/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr//lib -lmpi
|   root@ef11adb9da1c:/#
| 
| This is what we use at build-time.  Yet:
| 
|   root@ef11adb9da1c:/# ls -l /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.*
|   lrwxrwxrwx 1 root root 16 Feb 10 05:43 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so -> libmpi.so.20.0.2
|   -rw-r--r-- 1 root root 919704 Feb 10 05:43 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so.20.0.2
|   root@ef11adb9da1c:/#
|   root@ef11adb9da1c:/# ldconfig -p|grep libmpi.so
|   libmpi.so.20 (libc6,x86-64) => /lib/x86_64-linux-gnu/libmpi.so.20
|   root@ef11adb9da1c:/# 
| 
| Looks like ldconfig is unaware of libmpi.so.  But why? Maybe this?
| 
|   root@ef11adb9da1c:/# ls -l /etc/alternatives/libmpi*
|   lrwxrwxrwx 1 root root 47 May  3 14:26 /etc/alternatives/libmpi.so -> 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
|   lrwxrwxrwx 1 root root 51 May  3 14:26 /etc/alternatives/libmpi++.so -> 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so
|   root@ef11adb9da1c:/#
| 
| Weirder still, now that I ran `ldconfig` a few times it loads (but dies over
| an OpenMPI config wart in the Docker container I am in right now).

I think I found it.  Do an 'apt-get install libopenmpi-dev' and it will work.

Looks like we are missing an ldconfig run there.

Dirk

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



Bug#861742: apt-cache showsrc reports errors for additional successful source package results

2017-05-03 Thread Michael

On 2017-05-03 15:08, schrieb David Kalnischkies wrote:


I guess (= haven't looked too hard yet) that this is okay even through
moving found_this should be enough already.


I think so too.

A patch should really come with a testcase through as this is just 
going

to break one way or the other in the future otherwise. Especially as
showsrc hasn't that many tests at all at the moment.


Good point. Maybe it has broken because of this in the past. ;-)


The README has some information on running and writing
a test/integration script and looking at existing ones should be
helpful, too, but feel free to ask here or on IRC (#debian-apt) if
something isn't clear!


I'm a little short of time atm, I don't know if I'm able to dig further 
into this.



Nobody said that we like it, but reformatting means a lot of additional
work nobody likes [...]


agreed - delicate subject. I won't raise this topic again.

Regards
Michael



Bug#861732: systemd: How to get suricata started at boot?

2017-05-03 Thread Arturo Borrero Gonzalez
On 3 May 2017 at 12:36, Michael Biebl  wrote:
> Am 03.05.2017 um 11:11 schrieb Hans:
>> Hello all,
>>
>> I have installed suricata on my system, but it will not start at boot.
>>
>> When I manually start it, it is working well.
>>
>> As the document advises, I copied  /lib/systemd/system/suricata.service to
>> /etc/systemd/system/suricata.service and tested with
>
> You only need to copy suricata.service to /etc if you want to change its
> contents. Even then, often drop-in snippets are preferrable, which only
> override/extend the parts you need
>
>> systemctl start suricata.service
>>
>> "ps -aux | grep suricata" showed me the running process. But after reboot, 
>> the
>> process is not started automatically. As init is no more supported by
>> suricata, but systemd,
>
> The suricata package still ships a SysV init script, but if a systemd
> service file exists, it takes precedence.
>
>  how can I add this service into systemd, so that it is
>> started automatically at boot? I am still not quite experienced with systemd.
>
> systemctl enable suricata.service
>
> will do the trick. That should be done by the package though.

This conflicts with what was reported in #850889 [0].

I think both arguments are valid:

1) any suricata deployment is likely to require manual configuration
before proper service. Auto-start makes no sense.
2) yes, we are debian, we like things running out of the box

So, I'm unsure what path to follow.

In any case, a fix is not landing in stretch at this point. We should
wait for the stretch stable release.

Comments/discussion welcome.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861732



Bug#861364: Acknowledgement (dgit: empty directories are not representable)

2017-05-03 Thread Nish Aravamudan
Note we are tracking the affected source packages which are hitting
this at: https://bugs.launchpad.net/usd-importer/+bug/1687057.



Bug#858307: shotwell: https://picasaweb.google.com/data/feed/api/user/default returns HTTP 400

2017-05-03 Thread Jörg Frings-Fürst
Hello Jérémy,

google has shutdown picasa. 

So I close this bug.

CU
Jörg

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

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

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

Threema: SYR8SJXB
Wire: @joergfringsfuerst

IRC: j_...@freenode.net
 j_...@oftc.net

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


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


Bug#819664: Suggestions to update the https://www.debian.org/CD/ page

2017-05-03 Thread Stéphane Blondon


> -- Original message --
> 
> To: debian-mirr...@lists.debian.org
> Subject: Suggestions to update the https://www.debian.org/CD/ page
> From: Matt Weeks 
> The https://www.debian.org/CD/ page seems a bit outdated. Is there someone 
> here who can update it?
> 
> 
> I'd suggest changing
> 
> "Due to space and bandwidth constraints, only very few mirrors are able to 
> supply direct HTTP/FTP download links. These sites may use bandwidth 
> throttling, downloads can be quite slow. Please use jigdo or bittorrent 
> instead. DVD images are only available for some architectures and not on all 
> mirrors."
> 
> 
> To:
> 
> "Many mirrors supply direct HTTP download links you can download with your 
> browser."


Does someone disagrees about this change?
If no one objects, I plan to commit the change this week-end.



> 
> Broadband penetration has also dramatically increased, statistics in nearly 
> all the countries as I can find show that most users with internet access 
> (that can view this page) will also have broadband. E.g. Pew says 84% of U.S. 
> households own a computer, and 73% of households have broadband. China Daily 
> says Chinese speeds average 9.46 Mb/s. So I do not believe it is appropriate 
> any more to put the best option for dial-up at the top of the page. And while 
> there’s nothing wrong with jigdo or bittorrent, it will probably take the 
> average user more time to download, install, and open jigdo than to simply 
> download the iso from their closest mirror in their browser using the auto 
> mirror selector.
> 
>  
> 
> Speaking of that, the automatic mirror selector has been working for over a 
> year now, so perhaps we should drop the “experimental” label and make it the 
> default as well. I do not think it is used for the iso links on 
> https://www.debian.org/distrib/ ? Do we plan to use it there?

I have no idea about this point.




signature.asc
Description: OpenPGP digital signature


Bug#860747: dh_ruby: please inject versioned dependency on ruby metapackage

2017-05-03 Thread Julien Cristau
Control: severity 860747 serious
Control: tag 860747 stretch-ignore jessie-ignore

On 05/03/2017 04:27 PM, Antonio Terceiro wrote:
> On Mon, May 01, 2017 at 01:12:19PM +0200, Julien Cristau wrote:
>> On Wed, Apr 19, 2017 at 13:42:39 -0400, Aaron M. Ucko wrote:
>>
>>> Package: gem2deb
>>> Version: 0.33.1
>>> Severity: normal
>>>
>>> Please have compiled Ruby extensions depend on compatible versions of
>>> the ruby metapackage; for instance, an extension built only for 2.3
>>> would depend on ruby (>= 2.3), ruby (<< 2.4), and an extension built
>>> for both 2.3 and 2.4 would depend on ruby (>= 2.3), ruby (<< 2.5).
>>> (Python packaging settled on an analogous approach some time ago.)
>>> Ideally, this dependency would go to a dedicated ${ruby:Depends}
>>> substvar, but adding it to ${misc:Depends} would allow for much faster
>>> adoption.
>>>
>>> As it stands, we can get situations like #860512, in which the m68k
>>> build of telegram-desktop failed because ruby 2.3 wound up paired with
>>> a ruby-fast-xs installation that only covered 2.2.  (The 0.8.0-3+b2
>>> m68k binNMU was intended to add 2.3 support, but accidentally picked
>>> up old metapackages.)  With an explicit versioned dependency in place,
>>> generic automated tools would have caught this problem.
>>>
>> As this allows broken package combinations, it seems to me the severity
>> should be serious, not normal.
> 
> fair enough. Can it algo be ignored for stretch? I reallt don't think we
> should change that this late.
> 
Sounds fair.

Thanks,
Julien



  1   2   3   >