Bug#792854: [pkg-dhcp-devel] Bug#792854: Also appears in 64-bit: fixed by removing empty /etc/hostname

[Nicolas Kovacs]

Le 13/09/2015 00:35, Michael Gilbert a écrit :
> I don't use dnsmasq so haven't tried to reproduce, but if true It is a bug.
> 
> There really isn't enough information to go on here.  Please do some
> troubleshooting (avoid network manager, networkd, resolvconf, etc.,
> and other possible culprits).  Also, try reporting upstream to ISC.

I'm basically a Slackware user, and I gave Debian a spin out of
curiosity. Reporting a bug with Slackware is as easy as posting a
message in the LinuxQuestions forum, and a couple days later, the distro
maintainer fixes it, with a curt Thank You note in the ChangeLog.

I'll let you guys fix this, but as far as I'm concerned, there is
clearly a malfunction, so my bug report stops here.

Cheers from the sunny South of France,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32

Bug#798808: packagesearch: FTBFS with libept 1.0.14

[Chris Lamb]

Source: packagesearch
Version: 2.7.4
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

packagesearch fails to build from source in unstable/amd64. I'm pretty
sure this is due to:

  libept (1.0.14) unstable; urgency=medium

* New version that includes Matthias' changes
* Removed compatibility symlink, not needed anymore

  [..]

  Project MESSAGE: generating debug
  version/usr/share/qt4/mkspecs/features/qt_functions.prf(117): Function
  'system' is not implementedProject ERROR: Package libept not
  foundUpdating
  
'/tmp/buildd/packagesearch-2.7.4/src/plugins/filenameplugin/../../../translations/filenameplugin_de.qm'...
  Generated 41 translation(s) (41 finished and 0 unfinished)
  Updating
  
'/tmp/buildd/packagesearch-2.7.4/src/plugins/filenameplugin/../../../translations/filenameplugin_es.qm'...
  Generated 44 translation(s) (44 finished and 0 unfinished)
  /usr/bin/lrelease-qt4 src/plugins/orphanplugin/orphanplugin.pro
  Project MESSAGE: generating debug
  version/usr/share/qt4/mkspecs/features/qt_functions.prf(117): Function
  'system' is not implementedProject ERROR: Package libept not
  foundUpdating
  
'/tmp/buildd/packagesearch-2.7.4/src/plugins/orphanplugin/../../../translations/orphanplugin_de.qm'...
  Generated 34 translation(s) (34 finished and 0 unfinished)
  Updating
  
'/tmp/buildd/packagesearch-2.7.4/src/plugins/orphanplugin/../../../translations/orphanplugin_es.qm'...
  Generated 34 translation(s) (34 finished and 0 unfinished)
  /usr/bin/lrelease-qt4
  src/plugins/screenshotplugin/screenshotplugin.pro

  [..]

The full build log is attached or can be viewed here:


https://reproducible.debian.net/logs/unstable/amd64/packagesearch_2.7.4.build1.log.gz


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Sat Sep 12 02:43:54 GMT+12 2015
I: pbuilder-time-stamp: 1442069034
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/unstable-reproducible-base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /dev/shm
I: Mounting /sys
I: policy-rc.d already exists
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 8.9.7), libept-dev (>= 1.0.9), libqt4-dev, 
qt4-dev-tools, docbook-to-man, pkg-config, libwibble-dev (>= 1.0), 
libtagcoll2-dev (>= 2.0), libxapian-dev, libapt-pkg-dev
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 20260 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on libept-dev (>= 1.0.9); however:
  Package libept-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libqt4-dev; however:
  Package libqt4-dev is not installed.
 pbuilder-satisfydepends-dummy depends on qt4-dev-tools; however:
  Package qt4-dev-tools is not installed.
 pbuilder-satisfydepends-dummy depends on docbook-to-man; however:
  Package docbook-to-man is not installed.
 pbuilder-satisfydepends-dummy depends on pkg-config; however:
  Package pkg-config is not installed.
 pbuilder-satisfydepends-dummy depends on libwibble-dev (>= 1.0); however:
  Package libwibble-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libtagcoll2-dev (>= 2.0); however:
  Package libtagcoll2-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libxapian-dev; however:
  Package libxapian-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libapt-
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
Building tag database...
pbuilder-satisfydepends-dummy is already installed at the requested version 
(0.invalid.0)
pbuilder-satisfydepends-dummy is already installed at the requested version 
(0.invalid.0)
The follow

Bug#798807: plasma-workspace: 100% CPU usage when starting (may be because of activities)

[Zhang Jingqiang]

> Package: plasma-workspace
> Version: 4:5.4.1-1
> Severity: important
> 
> Dear Maintainer,
> 
> plasmashell crashed when I'm using the non-default activity,
> then start plasmashell at yakuake didn't work as it use 100% CPU
> and don't respond.
> reboot does not help either.
>
/usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/main.qml:231:5:
 
QML TaskList: Binding loop detected for property "rows" 

Bug#795077: kicad: FTBFS: error: 'itr' was not declared in this scope

[Nick Østergaard]

A stable release candidate has been called, please use this instead.

https://launchpad.net/kicad/4.0/4.0.0-rc1/+download/kicad-4.0.0-rc1.tar.xz

Announcement, https://lists.launchpad.net/kicad-developers/msg20326.html

2015-09-09 20:58 GMT+02:00 Nick Østergaard :
> Just forget tryting to build the old stable version (bzr rev around
> 4022 to 4029). Go and spend your time one making sure you can build
> the latest in product and be happy. You are on debian testing afterall
> (I think).
>
> We should soon see a release candidate for the next stable,
> https://lists.launchpad.net/kicad-developers/msg20227.html
>
> And yes, that version that fedora is using is basically the
> development version, which I also advise debian to use untill we get
> the next release out.
>
> Also the official PPA is now skipping the boost build and the first
> builds that pass on ubuntu 15.10 is passing on
> https://code.launchpad.net/~js-reynaud/+archive/ubuntu/ppa-kicad/+build/7890601
>
> 2015-09-09 18:02 GMT+02:00 Graham Inggs :
>> Hi
>>
>>> Nick Østergaard [2015-08-13 16:24 +0200]:
>>> > You can use the cmake option -DKICAD_SKIP_BOOST=ON  to fix this issue.
>>> > Make sure this only happens for systems with boost version above 1.54.
>>
>> The -DKICAD_SKIP_BOOST=ON option doesn't work in the kicad stable branch
>> (bzr4029) currently in Debian and Ubuntu.
>>
>> CMake Warning:
>>   Manually-specified variables were not used by the project:
>>
>> KICAD_SKIP_BOOST
>>
>> I made the following change to CMakeLists.txt and also removed
>> include/boost/ :
>>
>> --- a/CMakeLists.txt
>> +++ b/CMakeLists.txt
>> @@ -285,8 +285,8 @@
>>  # kicad now includes needed boost files.
>>  # the two next lines can be uncommented to use the native boost lib.
>>  # but this is not a good idea
>> -#find_package(Boost 1.36 QUIET)
>> -#check_find_package_result(Boost_FOUND "Boost")
>> +find_package(Boost 1.36 QUIET)
>> +check_find_package_result(Boost_FOUND "Boost")
>>
>>  ##
>>  # Find wxWidgets library #
>>
>> ...and still I am getting tons of errors like the following:
>>
>> In file included from /usr/include/c++/5/list:63:0,
>>  from /usr/include/boost/polygon/isotropy.hpp:20,
>>  from /usr/include/boost/polygon/polygon.hpp:12,
>>  from
>> /«BUILDDIR»/kicad-0.20141025+bzr4029/common/../polygon/polygons_defs.h:9,
>>  from
>> /«BUILDDIR»/kicad-0.20141025+bzr4029/common/../polygon/PolyLine.h:23,
>>  from
>> /«BUILDDIR»/kicad-0.20141025+bzr4029/common/../pcbnew/class_pad.h:37,
>>  from
>> /«BUILDDIR»/kicad-0.20141025+bzr4029/common/footprint_info.cpp:22:
>> /usr/include/c++/5/bits/stl_list.h:1807:22: error: reference to 'list' is
>> ambiguous
>>  operator==(const list<_Tp, _Alloc>& __x, const list<_Tp, _Alloc>& __y)
>>
>>> This worked well, thank you! Fedora does the same. I uploaded this a
>>> few days ago to Ubuntu.
>>
>> Your upload failed to build [1].  Fedora are using a newer revision
>> (bzr6041).
>>
>> Any ideas?
>>
>> Regards
>> Graham
>>
>>
>> [1] https://launchpad.net/ubuntu/+source/kicad/0.20141025+bzr4029-2ubuntu1
>>

Bug#798807: plasma-workspace: 100% CPU usage when starting (may be because of activities)

[Zhang Jingqiang]

Package: plasma-workspace
Version: 4:5.4.1-1
Severity: important

Dear Maintainer,

plasmashell crashed when I'm using the non-default activity,
then start plasmashell at yakuake didn't work as it use 100% CPU
and don't respond.
reboot does not help either.

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

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

Versions of packages plasma-workspace depends on:
ii  dbus-x111.10.0-2
ii  frameworkintegration5.13.0-1
ii  gdb 7.10-1
ii  kactivities 5.13.0-1
ii  kde-cli-tools   4:5.4.1-1
ii  kded5   5.13.0-1
ii  kinit   5.13.0-1
ii  kio 5.13.0-1
ii  libc6   2.19-19
ii  libcln6 1.3.4-1
ii  libdbusmenu-qt5-2   0.9.3+15.10.20150604-1
ii  libgcc1 1:5.2.1-17
ii  libgps213.11-3
ii  libice6 2:1.0.9-1+b1
ii  libkf5activities5   5.13.0-1
ii  libkf5auth5 5.13.0-1
ii  libkf5baloo55.13.0-2
ii  libkf5bookmarks55.13.0-1
ii  libkf5completion5   5.13.0-1
ii  libkf5configcore5   5.13.0-1
ii  libkf5configgui55.13.0-1
ii  libkf5configwidgets55.13.0-2
ii  libkf5coreaddons5   5.13.0-1
ii  libkf5crash55.13.0-1
ii  libkf5dbusaddons5   5.13.0-1
ii  libkf5declarative5  5.13.0-1
ii  libkf5globalaccel-bin   5.13.0-2
ii  libkf5globalaccel5  5.13.0-2
ii  libkf5guiaddons55.13.0-1
ii  libkf5i18n5 5.13.0-1
ii  libkf5iconthemes5   5.13.0-1
ii  libkf5idletime5 5.13.0-1
ii  libkf5itemviews55.13.0-1
ii  libkf5jobwidgets5   5.13.0-1
ii  libkf5js5   5.13.0-2
ii  libkf5jsembed5  5.13.0-3
ii  libkf5kdelibs4support5  5.13.0-3
ii  libkf5kiocore5  5.13.0-1
ii  libkf5kiofilewidgets5   5.13.0-1
ii  libkf5kiowidgets5   5.13.0-1
ii  libkf5networkmanagerqt6 5.13.0-1
ii  libkf5newstuff5 5.13.0-1
ii  libkf5notifications55.13.0-1
ii  libkf5notifyconfig5 5.13.0-1
ii  libkf5package5  5.13.0-2
ii  libkf5plasma5   5.13.0-2
ii  libkf5plasmaquick5  5.13.0-2
ii  libkf5quickaddons5  5.13.0-1
ii  libkf5runner5   5.13.0-1
ii  libkf5screen6   4:5.4.1-1
ii  libkf5service-bin   5.13.0-2
ii  libkf5service5  5.13.0-2
ii  libkf5solid55.13.0-1
ii  libkf5su5   5.13.0-1
ii  libkf5texteditor5   5.13.0-1
ii  libkf5textwidgets5  5.13.0-1
ii  libkf5wallet5   5.13.0-1
ii  libkf5waylandclient54:5.4.1-1
ii  libkf5waylandserver54:5.4.1-1
ii  libkf5webkit5   5.13.0-1
ii  libkf5widgetsaddons55.13.0-1
ii  libkf5windowsystem5 5.13.0-3
ii  libkf5xmlgui5   5.13.0-1
ii  libkf5xmlrpcclient5 5.13.0-1
ii  libksgrd7   4:5.4.1-1
ii  libkworkspace5-54:5.4.1-1
ii  libpam0g1.1.8-3.1
ii  libphonon4qt5-4 4:4.8.3-2
ii  libplasma-geolocation-interface54:5.4.1-1
ii  libprocesscore7 4:5.4.1-1
ii  libprocessui7   4:5.4.1-1
ii  libqalculate5v5 0.9.7-9.1
ii  libqt5core5a5.4.2+dfsg-9
ii  libqt5dbus5 5.4.2+dfsg-9
ii  libqt5gui5  5.4.2+dfsg-9
ii  libqt5network5  5.4.2+dfsg-9
ii  libqt5qml5  5.4.2-6
ii  libqt5quick55.4.2-6
ii  libqt5script5   5.4.2+dfsg-4
ii  libqt5sql5  5.4.2+dfsg-9
ii  libqt5webkit5   5.4.2+dfsg-3
ii  libqt5widgets5  5.4.2+dfsg-9
ii  libqt5x11extras55.4.2-2+b1
ii  libqt5xml5  5.4.2+dfsg-9
ii  libsm6  2:1.2.2-1+b1
ii  libstdc++6 

Bug#798806: plowshare4: FTBFS: Incompatible with bash-completion 1:2.1-4.2

[Chris Lamb]

Source: plowshare4
Version: 1.0.5-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

plowshare4 fails to build from source in unstable/amd64 as the paths
have changed in bash-completion 1:2.1-4.2:

  [..]

 debian/rules override_dh_bash-completion
  make[1]: Entering directory '/tmp/buildd/plowshare4-1.0.5'
  dh_bash-completion
  sed -i -e '/cut/ s,/usr/local,/usr,' \
debian/plowshare4/etc/bash_completion.d/plowshare
  sed: can't read debian/plowshare4/etc/bash_completion.d/plowshare: No
  such file or directory
  debian/rules:14: recipe for target 'override_dh_bash-completion'
  failed
  make[1]: *** [override_dh_bash-completion] Error 2
  make[1]: Leaving directory '/tmp/buildd/plowshare4-1.0.5'
  debian/rules:7: recipe for target 'binary' failed
  make: *** [binary] Error 2
  dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
  status 2

  [..]

The full build log is attached or can be viewed here:


https://reproducible.debian.net/logs/unstable/amd64/plowshare4_1.0.5-2.build1.log.gz


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Sat Sep 12 07:38:10 GMT+12 2015
I: pbuilder-time-stamp: 1442086690
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/unstable-reproducible-base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /dev/shm
I: Mounting /sys
I: policy-rc.d already exists
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 9), bash-completion
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 20260 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on bash-completion; however:
  Package bash-completion is not installed.

Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
Building tag database...
pbuilder-satisfydepends-dummy is already installed at the requested version 
(0.invalid.0)
pbuilder-satisfydepends-dummy is already installed at the requested version 
(0.invalid.0)
The following NEW packages will be installed:
  bash-completion{a} 
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 179 kB of archives. After unpacking 1252 kB will be used.
Writing extended state information...
Get: 1 http://ftp.de.debian.org/debian/ unstable/main bash-completion all 
1:2.1-4.2 [179 kB]
Fetched 179 kB in 0s (9892 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package bash-completion.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 20260 files and directories currently installed.)
Preparing to unpack .../bash-completion_1%3a2.1-4.2_all.deb ...
Unpacking bash-completion (1:2.1-4.2) ...
Processing triggers for man-db (2.7.3-1) ...
Setting up bash-completion (1:2.1-4.2) ...
Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
Writing extended state information...
Building tag database...
 -> Finished parsing the build-deps
Reading package lists...
Building dependency tree...
Reading state information...
fakeroot is alre

Bug#798805: libfreetype6 2.6-1 makes Cantarell blurry (CFF?)

[Josh Triplett]

Would help if I actually attached the screenshots.

- Josh Triplett

Bug#798805: libfreetype6 2.6-1 makes Cantarell blurry (CFF?)

[Josh Triplett]

Package: libfreetype6
Version: 2.6-1
Severity: important

[Severity important because this breaks GNOME's primary interface font.]

After upgrading to libfreetype 2.6-1, the Cantarell font shows up as
blurry; lines get smeared across pixels.  This doesn't happen with every
font; for instance, DejaVu Sans seems fine.

I've attached a pair of screenshots to demonstrate.
cantarell-blurry.png shows the blurry rendering of Cantarell; zoom in on
a vertical line such as in the 'n', 't', 'r', or 'f' of "Interface", and
notice that the vertical line gets smeared out across multiple pixels.
sans.png shows the rendering of DejaVu Sans; notice that the same
vertical lines snap to pixel boundaries.

Given that 2.6-1 re-enabled CFF, that seems like a likely culprit,
unless other significant changes occurred in the same version.

Also, given that this has happened multiple times in the past, I wonder
if a "font unit test" would help?  Take a couple of key fonts, such as
the aforementioned DejaVu Sans and Cantarell, render specific letters
with the default parameters, and scan across the resulting image at a
given y to make sure the rendering doesn't smear across pixels.  Such a
test would make sure future changes to libfreetype6 don't re-introduce
critical font rendering errors.

- Josh Triplett

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

Kernel: Linux 4.1.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 libfreetype6 depends on:
ii  libc6   2.19-19
ii  libpng12-0  1.2.50-2+b2
ii  zlib1g  1:1.2.8.dfsg-2+b1

libfreetype6 recommends no packages.

libfreetype6 suggests no packages.

-- no debconf information

Bug#705980: easychem application hangs on File -> Export

[prathibhab]

This issue exists in easychem 0.6-8(debian jessie) with ghostscript
9.06~dfsg-2+deb8u1.

After upgrading ghostscript to 9.16-dfsg-2 all the export option works except
'EPS, optimized for size(.eps)'. It creates an eps file. On opening the
exporting it gets closed immediately.



Regards,
Prathibha
Senior Engineer
C-DAC Chennai
---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

Bug#798724: kde-runtime: kwalletd in kde-runtime is missing org.kde.kwalletd5.service

[Scott Kitterman]

On Saturday, September 12, 2015 07:13:00 PM Scott Kitterman wrote:
> On Saturday, September 12, 2015 11:01:15 PM Gregor Riepl wrote:
...
> > May I suggest making kde-runtime depend on libkf5wallet-bin?
> > That would be the most appropriate place, I think...
> 
> No.  kde-runtime is KDE4 and will eventually go away.  It's not surprising
> not everything works when recommends are disabled, but I'll have a look and
> see if there should be a dependency relationship somewhere.

OK.  I took a look and I believe I understand the situation.  Out of the 
binary packages built from the kwallet-kf5 source package, three are relevant 
to this issue: libkf5wallet-bin, libkf5wallet5, and  libkwalletbackend5-5.

Package: libkf5wallet-bin
Depends: libkf5wallet5 (>= 4.96.0), libkwalletbackend5-5 (>= 4.96.0)

Package: libkf5wallet5
Depends: libkwalletbackend5-5 (= 5.13.0-1)
Recommends: libkf5wallet-bin (= 5.13.0-1)

Package: libkwalletbackend5-5
Depends: 
Recommends: libkf5wallet-bin (= 5.13.0-1)

That's done that way to prevent a dependency loop (and an example of why 
turning off Recommends is a bad idea.

Looking externally, neither libkwalletbackend5-5 nor libkf5wallet-bin have 
external rdepends, but libkf5wallet5 does:

$reverse-depends libkf5wallet5
Reverse-Depends
===
* kate
* kio
* konversation
* ksshaskpass
* kwalletmanager
* libkf5khtml5
* libkf5wallet-bin
* libkf5wallet-dev
* libkf5wallet5-dbg
* libkf5webkit5
* plasma-desktop
* plasma-nm
* plasma-workspace

kwalletmanager is a depends of kde-standard.

Based on this, it's quite easy to see how if a user doesn't install recommends 
they end up with a broken kwallet.  While I generally think that if you 
disable recommends and something breaks, it's not a bug, in this case, because 
recommends are only being used to avoid a dependemcy loop, I think it is a 
bug.

Proposed fix (for comment):

Since libkf5wallet5 is what is pulled in by other packages, it's the one that 
should have a hard depends on libkf5wallet-bin and libkwalletbackend5-5 to 
ensure users get a working system.  Those two packages can then Recommend 
libkf5wallet5 so there's still no loop.  Here's what I propose:

Package: libkf5wallet-bin
Depends: libkwalletbackend5-5 (>= 4.96.0)
Recommends: libkf5wallet5 (>= 4.96.0)

Package: libkf5wallet5
Depends: libkwalletbackend5-5 (= 5.13.0-1),  libkf5wallet-bin (= 5.13.0-1)

Package: libkwalletbackend5-5
Depends: 
Recommends: libkf5wallet5 (= 5.13.0-1)

Comments?  If no one objects, I'll stage this for upload soon.

Scott K

Bug#795844: tagging 795844

[Cyril Brulebois]

Steve McIntyre  (2015-09-13):
> On Sun, Sep 13, 2015 at 04:30:21AM +0200, Cyril Brulebois wrote:
> >Steve McIntyre  (2015-08-27):
> >> tags 795844 + pending
> >> thanks
> >
> >Is it OK for me to assume this is fixed for Stretch Alpha 3? That
> >doesn't seem obvious while looking at /home/debian-cd/build.stretch on
> >pettersson though.
> 
> Yes, it is.
> 
> Looking in the build dir for the armhf netinst:
> 
> debian-cd@pettersson:~/build$ ls -al 
> /org/cdbuilder.debian.org/src/deb-cd/tmp/2armhf/stretch/CD1/install/
> total 44
> drwxr-xr-x  7 debian-cd debian-cd   131 Sep 11 23:22 .
> drwxr-xr-x 10 debian-cd debian-cd  4096 Sep 11 23:23 ..
> -rw-r--r--  1 debian-cd debian-cd 22942 Sep 11 23:21 MANIFEST
> drwxr-xr-x  2 debian-cd debian-cd  8192 Sep 11 23:22 device-tree
> drwxr-xr-x  2 debian-cd debian-cd67 Sep 11 23:22 hd-media
> drwxr-xr-x  3 debian-cd debian-cd   104 Sep 11 23:22 netboot
> drwxr-xr-x  2 debian-cd debian-cd48 Sep 11 23:22 network-console
> drwxr-xr-x 17 debian-cd debian-cd  4096 Sep 11 23:22 u-boot

Perfect, thanks.

> The change is in 
> /home/debian-cd/build.stretch/debian-cd/tools/boot/stretch/boot-arm

Right, I forgot we have a git checkout inside another git checkout…

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#795844: tagging 795844

[Steve McIntyre]

On Sun, Sep 13, 2015 at 04:30:21AM +0200, Cyril Brulebois wrote:
>Steve McIntyre  (2015-08-27):
>> tags 795844 + pending
>> thanks
>
>Is it OK for me to assume this is fixed for Stretch Alpha 3? That
>doesn't seem obvious while looking at /home/debian-cd/build.stretch on
>pettersson though.

Yes, it is.

Looking in the build dir for the armhf netinst:

debian-cd@pettersson:~/build$ ls -al 
/org/cdbuilder.debian.org/src/deb-cd/tmp/2armhf/stretch/CD1/install/
total 44
drwxr-xr-x  7 debian-cd debian-cd   131 Sep 11 23:22 .
drwxr-xr-x 10 debian-cd debian-cd  4096 Sep 11 23:23 ..
-rw-r--r--  1 debian-cd debian-cd 22942 Sep 11 23:21 MANIFEST
drwxr-xr-x  2 debian-cd debian-cd  8192 Sep 11 23:22 device-tree
drwxr-xr-x  2 debian-cd debian-cd67 Sep 11 23:22 hd-media
drwxr-xr-x  3 debian-cd debian-cd   104 Sep 11 23:22 netboot
drwxr-xr-x  2 debian-cd debian-cd48 Sep 11 23:22 network-console
drwxr-xr-x 17 debian-cd debian-cd  4096 Sep 11 23:22 u-boot

The change is in 
/home/debian-cd/build.stretch/debian-cd/tools/boot/stretch/boot-arm

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

Bug#798804: make: Please add U flag in the default ARFLAGS

[Celelibi]

Package: make
Version: 4.0-8.2
Severity: minor

Dear maintainer,

It looks like the ar program in the binutils package in debian is now
configured with --enable-deterministic-archives, which is fine (I
guess). However, when dealing with archive members, make needs the
timestamp of the file in order to decide to update it or not. With the
current deterministic behavior of ar, the timestamp is always 0.

The following implicit rule will thus always re-add the member to the
archive as it is considered outdated.

(%): %
#  recipe to execute (built-in):
$(AR) $(ARFLAGS) $@ $<

An undue update of a file in an archive may have a cascading effect in
both directions. The targets that depend on the archive will have to be
updated; and the archive members (if determined to be intermediate
files) will have to be rebuilt. Thus making a major part of the project
to be rebuilt for no reason.


Steps to reproduce:
1) Create a file foo.c.
int main(void) {
return 0;
}

2) Create a Makefile.
target: archive.a(foo.o)
echo doing something

3) Run make twice.
$ make
cc-c -o foo.o foo.c
ar rv archive.a foo.o
ar: creating archive.a
a - foo.o
echo doing something
doing something
rm foo.o

$ make
cc-c -o foo.o foo.c
ar rv archive.a foo.o
r - foo.o
echo doing something
doing something
rm foo.o

4) Check that the timestamp of foo.o in archive.a is 0.
$ ar tv archive.a
rw-r--r-- 0/0848 Jan  1 01:00 1970 foo.o



I think the answer "fix your Makefile" is not appropriate for at least
two reasons:
- Make always rely on the timestamps of the file members, so taking the
  risk of not having them devoid completely the point of having implicit
  rules. And not having valid timestamps can only produce buggy cases
  like the one shown above.
- You cannot always fix the Makefiles because it's not always yours, and
  your Makefiles rely on an archive produced by a Makefile you don't
  have control over.

A workaround may be to add ARFLAGS=rvU as argument or environment
variable to make. This may work in some cases, but it's still a bit
hackish to fix from the outside a broken Makefile when a sensful default
value would fix it once for all.


Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages make depends on:
ii  libc6  2.19-19

make recommends no packages.

Versions of packages make suggests:
pn  make-doc  

-- no debconf information

Bug#796857: closed by Ben Pfaff (Re: Bug#796857: pspp: halts when reading sintax file)

[alvaro rincon]

next time it halts i will keep the syntax file, but i was so concentrated
in my math job that i forgot the bug reporting

2015-09-12 21:36 GMT-04:30 Debian Bug Tracking System :

> This is an automatic notification regarding your Bug report
> which was filed against the pspp package:
>
> #796857: pspp: halts when reading sintax file
>
> It has been closed by Ben Pfaff .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ben Pfaff <
> b...@cs.stanford.edu> by
> replying to this email.
>
>
> --
> 796857: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796857
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Mensaje reenviado --
> From: Ben Pfaff 
> To: alvaro rincon 
> Cc: 796857-d...@bugs.debian.org
> Date: Sat, 12 Sep 2015 19:02:47 -0700
> Subject: Re: Bug#796857: pspp: halts when reading sintax file
> OK.  I don't know how to address a bug that comes with so little
> information, so I'm closing it (with this message).
>
> Thanks,
>
> Ben.
>
> On Sat, Sep 12, 2015 at 09:25:15PM -0430, alvaro rincon wrote:
> > i am sorry but i erased it
> >
> > 2015-09-12 21:23 GMT-04:30 Ben Pfaff :
> >
> > > On Mon, Aug 24, 2015 at 09:36:14PM -0430, alvaro rincon wrote:
> > > > Package: pspp
> > > > Version: 0.7.9+git20120620-1.1
> > > > Severity: important
> > > >
> > > > Dear Maintainer,
> > > > *** Please consider answering these questions, where appropriate ***
> > > >
> > > >* What led up to the situation?
> > > >
> > > > when you run  the sintax file
> > > >
> > > >* What exactly did you do (or not do) that was effective (or
> > > >  ineffective)?
> > > >
> > > > changing the sintax stops the problem
> > >
> > > What syntax file causes the problem?
> > >
>
> -- Mensaje reenviado --
> From: alvaro rincon 
> To: Debian Bug Tracking System 
> Cc:
> Date: Mon, 24 Aug 2015 21:36:14 -0430
> Subject: pspp: halts when reading sintax file
> Package: pspp
> Version: 0.7.9+git20120620-1.1
> Severity: important
>
> Dear Maintainer,
> *** Please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
> when you run  the sintax file
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> changing the sintax stops the problem
>
>
>
>
> -- System Information:
> Debian Release: 7.8
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
> Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages pspp depends on:
> ii  dpkg   1.16.16
> ii  install-info   4.13a.dfsg.1-10
> ii  libatk1.0-02.4.0-2
> ii  libc6  2.13-38+deb7u8
> ii  libcairo2  1.12.2-3
> ii  libfontconfig1 2.9.0-7.1
> ii  libfreetype6   2.4.9-1.1+deb7u1
> ii  libgdk-pixbuf2.0-0 2.26.1-1
> ii  libglib2.0-0   2.33.12+really2.32.4-5
> ii  libgsl0ldbl1.15+dfsg.2-2
> ii  libgtk2.0-02.24.10-2
> ii  libgtksourceview2.0-0  2.10.4-1
> ii  libncurses55.9-10
> ii  libpango1.0-0  1.30.0-1
> ii  libpq5 9.1.16-0+deb7u2
> ii  libreadline6   6.2+dfsg-0.1
> ii  libtinfo5  5.9-10
> ii  libxml22.8.0+dfsg1-7+wheezy4
> ii  zlib1g 1:1.2.7.dfsg-13
>
> pspp recommends no packages.
>
> pspp suggests no packages.
>
> -- no debconf information
>
>

Bug#795844: tagging 795844

[Cyril Brulebois]

Steve McIntyre  (2015-08-27):
> tags 795844 + pending
> thanks

Is it OK for me to assume this is fixed for Stretch Alpha 3? That
doesn't seem obvious while looking at /home/debian-cd/build.stretch on
pettersson though.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#796857: pspp: halts when reading sintax file

[Ben Pfaff]

On Mon, Aug 24, 2015 at 09:36:14PM -0430, alvaro rincon wrote:
> Package: pspp
> Version: 0.7.9+git20120620-1.1
> Severity: important
> 
> Dear Maintainer,
> *** Please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> when you run  the sintax file
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> changing the sintax stops the problem

What syntax file causes the problem?

Bug#497206: Aptitude wishlist bug with a package - how to get it merged?

[Thadeu Lima de Souza Cascardo]

On Sat, Sep 12, 2015 at 02:02:48AM +0100, Manuel A. Fernandez Montecelo wrote:
> 
> Hello,
> 
> (replying to both messages at bottom...)
> 
> 
> 2010-07-08 23:29 Thadeu Lima de Souza Cascardo:
> >Hello, Daniel.
> >
> >I've submitted bug 497206 for aptitude with a patch attached almost two
> >years ago.  It's a new feature, to allow packages to be grouped by
> >source. It's usually easier to upgrade all packages from the same
> >source, without having to look for (and sometimes guess) what are the
> >other packages from that given source package.
> >
> >At that time, I've got some feedback (my first implementation required a
> >change to apt), and have responded with another patch. I've been missing
> >some aptitude upgrades or rebuilding it ever since.
> >
> >This is a simple patch, since it looks like very much other code already
> >in aptitude to group packages by other criteria. I know aptitude has
> >lots of reported bugs and maintaining it must really take a lot of time.
> >
> >I would like to know what I can do to help get this merged.
> >Unfortunately, I cannot commit to co-maintain aptitude. But I could help
> >fixing any bugs that arise from my patch and those come to my knowledge
> >(perhaps, I should subscribe for the aptitude bug list for a while).
> >
> >At last, I would like to thank you for developing and maintaining this
> >great software.
> >
> >Cheers,
> >Cascardo.
> 
> 
> 2010-07-18 13:23 Henrique de Moraes Holschuh:
> >On Thu, 08 Jul 2010, Thadeu Lima de Souza Cascardo wrote:
> >>I've submitted bug 497206 for aptitude with a patch attached almost two
> >>years ago.  It's a new feature, to allow packages to be grouped by
> >>source. It's usually easier to upgrade all packages from the same
> >>source, without having to look for (and sometimes guess) what are the
> >>other packages from that given source package.
> >
> >Hmm, wishlist seconded, FWLIW.
> >
> >Grouping by source package is a feature that would help me when I know
> >for sure something is broken in unstable and the entire set of binary
> >packages from the same source needs to be put in hold...
> 
> Thanks for working and providing this patch, refreshing it and insisting
> for a long time :-)
> 
> For some reason, Daniel Burrows at the time decided not to merge the
> part creating the Source View:
> 
>  
> https://anonscm.debian.org/cgit/aptitude/aptitude.git/commit/?id=66adb6c872f7b49279da43601e7d3ff16c1a
> 
>  Add a new "source" grouping policy, which groups packages according to
>  their source package.
> 
>  Closes: #497206; thanks to Thadeu Lima de Sourza Cascardo for the
>  patch.
> 
>  Didn't merge the part of the patch that adds an entry to the Views
>  menu, as I don't personally believe that this grouping needs its own
>  entry there.
> 
> 
> With the new grouping policy merged, probably you were already making
> use of this feature in some way to browse the packages.
> 
> But for a long time I thought that some sort of package view would be
> useful for other purposes, e.g. to see all binary packages provided by a
> library and install also the documentation if it was available, rather
> than hop around the package list in other ways.  (search and filtering
> works sometimes, but if the package names do not match expectations,
> it's a hassle).
> 
> Another use is to selectively upgrade all packages coming from the same
> source (e.g. util-linux, many binaries and difficult to find because
> they have very disparate names), while keeping the rest of the system in
> the same state.
> 
> Anyway, the point is that I do find it an useful addition, so I decided
> to also create a source view, it will be included in the next release.
> 
> Since I found the view that you had submitted a bit flat / unappealing
> (maybe that's also why Daniel Burrows didn't like it much), I expanded
> the grouping "firstchar" to also be able to use source names rather than
> binary names, and to also add the top section (e.g. "main").  So the
> resulting view looks a bit like browsing the FTP, some feature that I
> missed sometimes when working on ports (porters think much more in terms
> of source packages than most of the rest of Debian users and devels, I
> think).
> 
> Anyway, this is an example, limiting the view to the packages matching
> "dpkg" and expanding some subtrees, I hope that you like it.
> 
> 
>  --\ main - The main Debian archive (21)
>--\ a (1)
>  --- apt-dpkg-ref (1)
>--\ d (12)
>  --\ dpkg (6)
>  i dpkg  1.18.2 1.18.2
>  p dpkg:i386  1.18.2
>  i dpkg-dev  1.18.2 1.18.2
>  p libdpkg-dev1.18.2
>  p libdpkg-dev:i386   1.18.2
>  i A   libdpkg-perl  1.18.2 1.18.2
>  --- dpkg-awk (1)
>  --- dpkg-cross (2)
>  --- dpkg-repack (1)
>  --- dpkg-sig (1)
>  --- dpkg-www (1)
>--\ e (1)
>  --- emacs-goodies-el (1)
>--\ h (5)
>  --- haskell-dpkg (5)
>

Bug#798803: fetchmail: Slowness when .fetchids file grows large

[Mark Triggs]

Package: fetchmail
Version: 6.3.26-1+b1
Severity: normal
Tags: patch upstream

Dear Maintainer,

Recently I've noticed that running 'fetchmail' to awake my background
fetchmail daemon is quite slow.  It takes around 5 seconds to return,
where previously it was pretty much instantaneous.

I ran fetchmail under callgrind and found that it was spending all of
its time loading my (large) .fetchids file into a linked list.  I've
got a POP3 server with all messages kept on it, and my .fetchids file
contains around 50,000 entries (I should probably switch to IMAP ;)

>From what I can see, the issue is that each ID from .fetchids is
appended to a linked list (by initialize_saved_lists() in uid.c), but
the append operation (save_str) has to scan the entire linked list
from head to tail on every append operation.  As a result, the process
of reading the file is O(N^2) instead of O(N).

There's a struct member on 'struct query' called 'oldsavedend' that
was unused and seemed like it might have been intended to track the
end of the linked list, so I've modified uid.c to use that
variable--keeping track of the last node in the linked list and
avoiding the full scan.  I've attached a patch for that, and
performance is back to instantaneous in my testing.

It's a pretty minor thing, but easy enough to fix so I thought I'd
report it.

Cheers,

Mark

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

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

Versions of packages fetchmail depends on:
ii  adduser   3.113+nmu3
ii  debianutils   4.4+b1
ii  libc6 2.19-18
ii  libcomerr21.42.12-1.1
ii  libgssapi-krb5-2  1.12.1+dfsg-19
ii  libkrb5-3 1.12.1+dfsg-19
ii  libssl1.0.0   1.0.1k-3+deb8u1
ii  lsb-base  4.1+Debian13+nmu1

Versions of packages fetchmail recommends:
ii  ca-certificates  20141019

Versions of packages fetchmail suggests:
pn  fetchmailconf 
pn  resolvconf
ii  ssmtp [mail-transport-agent]  2.64-8

-- no debconf information
commit 4efda943a32a17b43b80fbb5e2c27ddf785dd53d
Author: Mark Triggs 
Date:   Sat Sep 12 20:53:12 2015 +1000

Performance fix for linked list: O(N^2) to (N)

diff --git a/fetchmail.h b/fetchmail.h
index d759d39..083a204 100644
--- a/fetchmail.h
+++ b/fetchmail.h
@@ -390,7 +390,7 @@ struct query
 unsigned int uid;		/* UID of user to deliver to */
 struct idlist *skipped;	/* messages skipped on the mail server */
 struct idlist *oldsaved, *newsaved;
-struct idlist **oldsavedend;
+struct idlist *oldsavedend;
 char lastdigest[DIGESTLEN];	/* last MD5 hash seen on this connection */
 char *folder;		/* folder currently being polled */
 
diff --git a/uid.c b/uid.c
index 8a775b9..504301b 100644
--- a/uid.c
+++ b/uid.c
@@ -119,7 +119,7 @@ void initialize_saved_lists(struct query *hostlist, const char *idfile)
 	ctl->skipped = (struct idlist *)NULL;
 	ctl->oldsaved = (struct idlist *)NULL;
 	ctl->newsaved = (struct idlist *)NULL;
-	ctl->oldsavedend = &ctl->oldsaved;
+	ctl->oldsavedend = (struct idlist *)NULL;
 }
 
 errno = 0;
@@ -216,7 +216,13 @@ void initialize_saved_lists(struct query *hostlist, const char *idfile)
 		for (ctl = hostlist; ctl; ctl = ctl->next) {
 		if (strcasecmp(host, ctl->server.queryname) == 0
 			&& strcasecmp(user, ctl->remotename) == 0) {
-			save_str(&ctl->oldsaved, id, UID_SEEN);
+			save_str(&ctl->oldsavedend, id, UID_SEEN);
+
+			if (ctl->oldsaved == NULL) {
+			/* When we add the first element to the list, set our head to point to it. */
+			ctl->oldsaved = ctl->oldsavedend;
+			}
+
 			break;
 		}
 		}

Bug#798783: [kwalletmanager] Support for GPG encrypted wallets

[Scott Kitterman]

On September 12, 2015 4:09:29 PM EDT, Maximiliano Curia 
 wrote:
>On 12/09/15 17:47, Frederic Tronel wrote:
>> The KF5 version of kwalletmanager does not allow to create a GPG
>encrypted 
>> wallet. This feature was present in the KDE4 version of
>kwalletmanager.
>> This is may be due to an missing flag during the compilation of
>kwalletmanager 
>> ?
>
>That requires kwallet5 to be built against gpgmepp which is currently
>in NEW.
>https://ftp-master.debian.org/new/gpgmepp_15.08.0-1.html
>
>This feature will be enabled after the package is approved.

It's accepted now.

Scott K

Bug#785989: cwiid: diff for NMU version 0.6.00+svn201-3.2

[Romain Beauxis]

Hi,

Please go ahead. Also, feel free to take over the package if you wish so.

Romain

2015-09-12 11:59 GMT-05:00 Luca Falavigna :

> Control: tags 785989 + patch
> Control: tags 785989 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for cwiid (versioned as 0.6.00+svn201-3.2) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
>

Bug#784041: exceptions.OSError: [Errno 2] No such file or directory

[Cyril Brulebois]

Hi,

Antoine Beaupré  (2015-07-28):
> Package: torbrowser-launcher
> Version: 0.1.9-1+deb8u1
> Followup-For: Bug #784041
> 
> Confirmed. The bug is still present in Debian 8.1.

It would be nice to have a fix in Jessie at some point.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#798802: xorp: systemd integration using sd_notify

[Dhionel Díaz]

Package: xorp
Version: 1.8.5-4.1
Severity: normal
Tags: patch
Usertags: systemd-units
X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org

Dear Maintainer,

The attached patch incorporates systemd integration and notifications
via sd_notify to xorp_rtrmgr. It has been tested in a production router,
the tests were limited to the start, stop, restart and logging behaviour.

The patch also routes the log to the journal via stderr, therefore
eliminating the weekly restart performed by logrotate. That restart was
failing in a somewhat loaded router until the proposed changes where
applied. It was also found that the default output log setup was failing
to work with systemd and it was changed to a simple one which, as far as
I know, should be very portable.

The unit file was sent to the systemd maintainers for review and their
helpful directions have been followed.

I hope this patch can be useful.

Regards,


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

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

Versions of packages xorp depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  libc62.19-18+deb8u1
ii  libgcc1  1:4.9.2-10
ii  libncurses5  5.9+20140913-1+b1
ii  libpcap0.8   1.6.2-2
ii  libssl1.0.0  1.0.1k-3+deb8u1
ii  libstdc++6   4.9.2-10
ii  libsystemd0  215-17+deb8u2
ii  libtinfo55.9+20140913-1+b1

Versions of packages xorp recommends:
ii  iputils-ping   3:20121221-5+b2
ii  iputils-tracepath  3:20121221-5+b2
ii  traceroute 1:2.0.20-2+b1

xorp suggests no packages.

-- Configuration Files:
/etc/default/xorp changed [not included]
/etc/xorp/config.boot changed [not included]

-- no debconf information



-- 
Dhionel Díaz
Centro Nacional de Desarrollo e Investigación en Tecnologías Libres
Ministerio del Poder Popular para
Educación Universitaria, Ciencia y Tecnología
diff -u xorp-1.8.5/debian/control xorp-1.8.5/debian/control
--- xorp-1.8.5/debian/control
+++ xorp-1.8.5/debian/control
@@ -7,6 +7,7 @@
  scons, libboost-dev,
  autotools-dev, quilt, libssl-dev, 
  libncurses5-dev | ncurses-dev, docbook-to-man, libpcap0.8-dev,
+ dh-systemd, libsystemd-dev, pkg-config,
 Build-Conflicts: iptables-dev
 Standards-Version: 3.9.5
 Homepage: http://www.xorp.org
diff -u xorp-1.8.5/debian/patches/series xorp-1.8.5/debian/patches/series
--- xorp-1.8.5/debian/patches/series
+++ xorp-1.8.5/debian/patches/series
@@ -13,0 +14,2 @@
+default_log_output.patch
+sd_notify_rtrmgr.patch
diff -u xorp-1.8.5/debian/rules xorp-1.8.5/debian/rules
--- xorp-1.8.5/debian/rules
+++ xorp-1.8.5/debian/rules
@@ -22,11 +22,11 @@
 DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
-# Personall Variables
+# Personal Variables
 PACKNAME=$(shell dh_listpackages)
 PACKAGE=$(shell dh_listpackages)
 
-# Variabels used by the Debian Maintainer exclusively for package
+# Variables used by the Debian Maintainer exclusively for package
 # development.
 SOURCENAME=$(shell dpkg-parsechangelog | grep "Source:" | cut -d ' ' -f 2)
 DEBVER=$(shell dpkg-parsechangelog | grep "Version:" | cut -d ' ' -f 2)
@@ -57,6 +57,7 @@
 		sysconfdir=/etc \
 		with-olsr=true \
 		disable_fw=true \
+		enable_systemd=true \
 		CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" LDFLAGS='-Wl,-z,defs'
 
 #SCONSFLAGS += CC=gcc-4.6 CXX=g++-4.6
@@ -165,7 +166,9 @@
 	dh_installdocs
 	dh_installexamples -pxorp rtrmgr/config/*.boot debian/config.boot.mcast  rtrmgr/config/README
 	dh_installlogrotate
+	dh_systemd_enable
 	dh_installinit
+	dh_systemd_start
 	dh_installman 
 	dh_link
 	dh_strip
diff -u xorp-1.8.5/debian/xorp.postinst xorp-1.8.5/debian/xorp.postinst
--- xorp-1.8.5/debian/xorp.postinst
+++ xorp-1.8.5/debian/xorp.postinst
@@ -41,6 +41,7 @@
 	--system \
 		--ingroup $XORPGROUP \
 		--no-create-home \
+		--home $LOGDIR \
 		--disabled-password \
 		$XORPUSER 2>/dev/null || true
 	fi
only in patch2:
unchanged:
--- xorp-1.8.5.orig/debian/patches/default_log_output.patch
+++ xorp-1.8.5/debian/patches/default_log_output.patch
@@ -0,0 +1,34 @@
+Description: Simplify and fix default log output setup.
+Author: Dhionel Díaz 
+Last-Update: 2015-09-09
+
+---
+--- a/libxorp/xlog.c
 b/libxorp/xlog.c
+@@ -798,24 +798,8 @@
+ 	return (xlog_add_output(fp));
+ 
+ #else /* !HOST_OS_WINDOWS */
+-
+-const char* defaults[] = {	/* The default outputs (in preference order) */
+-	"/dev/stderr",		/* XXX: temporary this is the default */
+-	"/dev/console",
+-	"/dev/stdout"
+-};
+-size_t ndefaults = sizeof(defaults) / sizeof(defaults[0]);
+-size_t i;
+-
+-/*
+- * Attempt to open default output stream, console first i

Bug#789942: mapnik-vector-tile: FTBFS with mapnik 3.0(?): mapnik/graphics.hpp: No such file or directory

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Jérémy,

On 12-09-15 23:14, Sebastiaan Couwenberg wrote:
> On 12-09-15 23:04, Jérémy Lal wrote:
>> My position is that it is good to have node-mapnik in debian, because it's
>> not that easy to
>> install otherwise - and i'm quite motivated to update it, but i'll find
>> time to do it before the end of the year.
> 
> Alright. If we're going to keep node-mapnik around, we need to get
> mapnik-vector-tile (0.10.0+dfsg-1) ready for upload.
> 
> Do you prefer a separate mapnik-clipper package, or just bundling
> clipper.{c,h}pp in mapnik-vector-tile?

I've opted to bundle clipper.{c,h}pp in mapnik-vector-tile for the time
being, we can still decide to switch to the mapnik-clipper package after
all.

mapnik-vector-tile (0.10.0+dfsg-1) has been uploaded to unstable to fix
this RC issue, and to remove this blocker for the node-mapnik update as
part of the upcoming nodejs 4.0 migrations.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#343896: iLO workarounds

[Matt Taggart]

This bug is coming up on it's TEN YEAR anniversary!

HP has had 10 years to fix the broken ssh implementations in these devices. 
They no longer care about these older products, and even the slightly newer 
devices fail to support modern crypto and have other bugs.

I think this bug can continue to document work-arounds but should be tagged 
wontfix and no priority placed on compatibility with these old broken 
products. (still possible currently, but sha1, 3des, md5, cbc, etc. will 
eventually be disabled and will stop)

Hopefully this will also serve as an example to HP and other vendors that 
choosing to use proprietary firmware on these devices is both inferior and 
not as cost effective. If they had used something like dropbear for the ssh 
implemention there would be no compatibility problems and they'd also have 
support for all the latest crypto.

Here's an idea for HP: they are working on new IoT software stacks that 
will use FOSS technologies and prioritize security. As a demonstratation of 
these new software stacks, why not port them to older iLO devices first. 
iLO devices could be considered some of the first IoT devices :)

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

Bug#798724: kde-runtime: kwalletd in kde-runtime is missing org.kde.kwalletd5.service

[Scott Kitterman]

On Saturday, September 12, 2015 11:01:15 PM Gregor Riepl wrote:
> >> I had kde-full installed, however.
> >> Shouldn't libkf5wallet-bin be a dependency of that?
> >> 
> >> In any case, thanks. kwallet is working now, except that I'm struggling
> >> with
> >> the wallet migration wizard. But that's a different story.
> > 
> > That answers if it's packaging or upstream.
> > 
> > Do you have Recommends installation turned off?  I'm pretty sure with
> > kde-full it should be at least recommended.
> No, I usually turn Recommends off because it may pull in tons of unwanted
> packages sometimes.
> 
> libkf5wallet5 has libkf5wallet-bin in its Recommends list.
> 
> That's a start, but I don't think it makes a lot of sense.
> Anything that uses kwallet should have a hard dependency on
> libkf5wallet-bin, since it will simply not work without it.
> 
> May I suggest making kde-runtime depend on libkf5wallet-bin?
> That would be the most appropriate place, I think...

No.  kde-runtime is KDE4 and will eventually go away.  It's not surprising not 
everything works when recommends are disabled, but I'll have a look and see if 
there should be a dependency relationship somewhere.

Scott K

Bug#798801: libkf5wallet-bin: Configuration file "//.config/kwalletd5rc" not writable

[Ben Hay]

Package: libkf5wallet-bin
Version: 5.13.0-1
Severity: normal

Dear Maintainer,

Logging into the desktop produces a dialog 

Configuration file "//.config/kwalletd5rc" not writable".  Please
contact your system administrator.

After login I can start and use both KDE Wallet and KWalletManager
without seeing any errors.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.1.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libkf5wallet-bin depends on:
ii  libc6 2.19-19
ii  libgcc1   1:5.2.1-17
ii  libkf5configcore5 5.13.0-1
ii  libkf5coreaddons5 5.13.0-1
ii  libkf5dbusaddons5 5.13.0-1
ii  libkf5i18n5   5.13.0-1
ii  libkf5iconthemes5 5.13.0-1
ii  libkf5notifications5  5.13.0-1
ii  libkf5service55.13.0-2
ii  libkf5wallet5 5.13.0-1
ii  libkf5widgetsaddons5  5.13.0-1
ii  libkf5windowsystem5   5.13.0-3
ii  libkwalletbackend5-5  5.13.0-1
ii  libqt5core5a  5.4.2+dfsg-9
ii  libqt5dbus5   5.4.2+dfsg-9
ii  libqt5gui55.4.2+dfsg-9
ii  libqt5widgets55.4.2+dfsg-9
ii  libstdc++65.2.1-17

libkf5wallet-bin recommends no packages.

libkf5wallet-bin suggests no packages.

-- no debconf information

Bug#745425: aptitude: dependency handling jammed on chromium upgrade

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Edward,

Sorry that this was not handled earlier, maybe now you don't even
remember the details, but I'll have a shot at it...


2014-04-21 14:20 Edward Welbourne:

Package: aptitude
Version: 0.6.10-1
Severity: normal

Dear Maintainer,

I'm on testing.  I have chromium installed.  I use the browser.  I do
not use the inspector.  None the less, chromium declares that it depends
on chromium-inspector, which is thus installed.  Recently (around the
time of heartbleed) there has come a security upgrade for
chromium-inspector.  This upgrade conflicts (in some way, I couldn't see
how) with the existing version of chromium.  Aptitude reported a
conflict and offered to resolve it by uninstalling chromium (which I
want) or keeping chromium-inspector (which I don't consciously use; and
wouldn't have any use for at all without chromium) at its old version
(which, apparently, means retaining a known security bug on my system).
If chromium actually does use inspector, without my being aware of it,
this is a security problem, that I can't fix other than by uninstalling
chromium (at which point I may as well uninstall its inspector).

[Aside (for the chromium maintainer): I do not think it makes sense for
chromium (the browser) to depend on (i.e. force installation of)
chromium-inspector if, in fact, it is possible to browse without this
tool for web developers.  It would make sense for chromium-inspector to
depend on chromium, and for chromium to Suggest or Recommend its
inspector, but the present Depends seems misguided (regardless of the
situation, above, that has brought it to my attention).]


Note: this bug was reported to aptitude, without copy to the chromium
maintainers, so unless you submitted a bug report for them at the time,
they are very unlikely to have read what you wrote above.



dpkg -l 'chromium*' says (once I set COLUMNS to 120 to see full version
information): 

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version   Architecture  Description
+++--=-=-=
ii  chromium 33.0.1750.152-1   amd64 Chromium web 
browser
un  chromium-codecs-ffmpeg   (no 
description available)
un  chromium-codecs-ffmpeg-e (no 
description available)
ii  chromium-inspector   33.0.1750.152-1   all   page inspector 
for the Chromium browser
un  chromium-l10n(no 
description available)
un  chromium-testsuite   (no 
description available)



In aptitude, I did see a version 34.0.1847.116-1~deb7u1 listed for
chromium; but attempting to mark the installed version for deletion and
this new version for installation does not work: it merely marks the
33.0... version to be kept installed, with the attendant conflict with
its own inspector.

I kept inspector at its old version and assumed a compatible version of
chromium would show up sooner or later.  After about a week, I tried
again; nothing had changed.  Same conflict, same offered resolutions.

Eventually, I uninstalled both packages, then installed chromium afresh.
The above dpkg command now reports 

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version   Architecture  Description
+++--=-=-=
ii  chromium 33.0.1750.152-1   amd64 Chromium web 
browser
un  chromium-codecs-ffmpeg   (no 
description available)
un  chromium-codecs-ffmpeg-e (no 
description available)
ii  chromium-inspector   33.0.1750.152-1   all   page inspector 
for the Chromium browser
un  chromium-l10n(no 
description available)
un  chromium-testsuite   (no 
description available)

 unchanged !  I am unable to make sense of what aptitude was
complaining about or why purging and reinstalling has (apparently) fixed
the alleged problem.



From what you paste above (I don't know if it's correct), I don't see

any obvious problem.  If chromium cannot be upgraded from 33 to 34
because it depends on another version of chromium-inspector, but the
current versions (33) of both are compatible, and you remove and install
again the same 33 old versions (which are compatible), aptitude does not
complain about it and you end up with the same state as before.
Behaviour expected.

I thought that you wanted to install version 34 of both 

Bug#798387: [pkg-wine-party] Bug#798387: [wine] Evernote 5.9 do not update notes on video

[Michael Gilbert]

control: severity -1 minor
control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=38880

On Tue, Sep 8, 2015 at 12:16 PM, Marco Righi  wrote:
> Sometimes Evernote hang up when launched:

Seems similar to the winehq bug above.  Please work with upstream on this one.

Best wishes,
Mike

Bug#796561: insighttoolkit: ABI transition needed for libstdc++ v5

[Steve M. Robbins]

On September 2, 2015 02:48:01 PM you wrote:

> > I haven't checked, but I will be conservative and assume it needs
> > transition. I have already staged v4.8 in experimental for that purpose;
> > see also #793250 and #796561.
> 
> Thanks, I've noted those on the Titanpad. I will not open a separate bug
> here, since #796561 can act as the tracking bug.

I see that there are build failures now for insighttoolkit4.  I'm going to 
have a look at these in the coming days.  Should I need an upload to fix: would 
I be able to target unstable or should it still stay in experimental?

Thanks,
-Steve


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

Bug#791722: check-all-the-things: look for #! lines

[Paul Wise]

On Sat, 2015-09-12 at 21:25 +0200, Jakub Wilk wrote:

> Filed as #798796.

Also discussed in #698569 and upstream:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698569#44
http://mx.gw.com/pipermail/file/2015/001778.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#798591: libreoffice: Long click closes Libre Office 5

[John-Paul Durrieu]

Hi Chris,

uninstalling libreoffice-gtk, and/or starting LO with "OOO_FORCE_DESKTOP=none 
loffice" does not
work around the bug for me. Still crashes on long click ("long click" being 
about 1 second
without moving the mouse, by the way. Can click as long as I want while moving 
the mouse).

Bug#792854: [pkg-dhcp-devel] Bug#792854: Also appears in 64-bit: fixed by removing empty /etc/hostname

[Michael Gilbert]

control: tag -1 moreinfo, upstream

On Thu, Sep 10, 2015 at 9:10 AM, Nicolas Kovacs wrote:
> Dhclient showing inconsistent behavior on 32-bit and 64-bit systems
> looks like a bug to me.

I don't use dnsmasq so haven't tried to reproduce, but if true It is a bug.

There really isn't enough information to go on here.  Please do some
troubleshooting (avoid network manager, networkd, resolvconf, etc.,
and other possible culprits).  Also, try reporting upstream to ISC.

Best wishes,
Mike

Bug#796114: CVE-2015-2156

[Emmanuel Bourg]

On Wed, 19 Aug 2015 16:59:58 +0200 Moritz Muehlenhoff 
wrote:

> This was assigned CVE-2015-2156:
> http://netty.io/news/2015/05/08/3-9-8-Final-and-3.html

I got a look at this issue, the packages depending on libnetty-java in
squeeze/wheezy/jessie do not use the CookieDecoder and aren't affected
by this vulnerability.

The only package using the CookieDecoder class is elasticsearch, but it
depends on libnetty-3.9-java. So this package will have to be updated in
Jessie.


> Please phase out src:netty towards the updated src:netty-3.9 so that
> there's only one version around.

libnetty-java is going to be updated to the version 4.x. We have to keep
two versions of this library because the APIs aren't compatible. The 3.x
line is still maintained upstream, so that should be fine for now.

Emmanuel Bourg

Bug#798800: RM: libmodglue1-dev [all] -- RoQA; NBS; obsolete arch:all package

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please remove the obsolete arch:all package libmodglue1-dev from
unstable:

  libmodglue1-dev |   1.17-2.2 | all

This was turned into an arch:any package in 1.17-2.3, but somehow
automatic cruft removal did not catch this.


Andreas

Bug#798710: jit-playback changes brake package pygccjit build

[Jurica Stanojkovic]

Please do note that this error is caused by changes that occurred in 
gcc-5_5.2.1-13.

Building pygccjit with gcc-5_5.2.1-12 or gcc-5_5.1.1-14 or gcc-5_5.1.1-13 
version of gcc-5 
binary packages do not cause this issue.
I just have to install some of previously listed version of gcc-5-base and 
libgccjit0 binary packages to not have this issue.

pygccjit is newer built on mips/mipsel because -fPIC flag is missing on 
following line:
gcc-5 -shared /tmp/libgccjit-z1jPnd/fake.s -o /tmp/libgccjit-z1jPnd/fake.so 
-fno-use-linker-plugin

Which is configured in libgccjit and I wasnt able to change this on pygccjit 
level.
This is done in gcc-5 source in jit-playback.c file.

I will have to file this bug during next week to gcc-5 again, because this 
again is likely a libgccjit error for mips/mipsel.
Issue that I was able to solve on gcc-5_5.1.1-14 version, and I wanted to send 
a patch when new issue is introduced to pygccjit by a gcc-5 moving to a 
5.2-1-15 version.
So I had to try to figure out first this new regression.

I you try to build pygccjit_0.4-4 now (give-back) you will notice this new 
issue.

Thank you!

Regards,
Jurica

Bug#796864: libmodglue1v5 and libmodglue1: error when trying to install together

[Andreas Beckmann]

Followup-For: Bug #796864
Control: tag -1 patch pending

Attached is a patch adding the missing Breaks+Replaces. I'm going to
upload this to DELAYED/2.


Andreas
diff -Nru modglue-1.17/debian/changelog modglue-1.17/debian/changelog
--- modglue-1.17/debian/changelog	2015-08-14 19:35:15.0 +0200
+++ modglue-1.17/debian/changelog	2015-09-12 23:27:37.0 +0200
@@ -1,3 +1,11 @@
+modglue (1.17-2.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * libmodglue1v5: Add Breaks+Replaces: libmodglue1.  (Closes: #796864)
+  * Drop obsolete DMUA flag.
+
+ -- Andreas Beckmann   Sat, 12 Sep 2015 23:27:37 +0200
+
 modglue (1.17-2.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru modglue-1.17/debian/control modglue-1.17/debian/control
--- modglue-1.17/debian/control	2015-08-14 19:31:42.0 +0200
+++ modglue-1.17/debian/control	2015-09-12 23:25:06.0 +0200
@@ -3,7 +3,6 @@
 Priority: optional
 Maintainer: Iulian Udrea 
 Uploaders: Kasper Peeters 
-DM-Upload-Allowed: yes
 Homepage: http://www.aei.mpg.de/~peekas/modglue/
 Build-Depends: debhelper (>= 7.0.50), pkg-config, libsigc++-2.0-dev, libtool, libtool-bin, chrpath
 Standards-Version: 3.8.4
@@ -25,6 +24,8 @@
 Package: libmodglue1v5
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Breaks: libmodglue1
+Replaces: libmodglue1
 Description: C++ library for handling of multiple co-processes
  Modglue is a C++ library with classes for forking external
  processes and asynchronous reading from streams. It takes

Bug#773275: dh-make: fails to create native package with --defaultless

[Craig Small]

On Tue, Dec 16, 2014 at 11:55:25AM +0100, Benjamin Drung wrote:
> native packages cannot be created with --defaultless option.
> Steps to reproduce:
> 
> mkdir /tmp/example-package-1.0
> cd /tmp/example-package-1.0
> dh_make -c mit -s -n -p example-package_1.0 -y -d
The defaultless option was added with bug #81120 [1] in 2001 and
basically doesn't apply any default debian and package files into the
directory. If you read the bug report you'll see how it is used for
their specific case.

So dh_make is doing what its told. It seems we have more of a
documentation issue; what were you expecting defaultless to do?
Generally defaultless doesn't make sense without and overlay or custom
directory. Perhaps that information is missing in the man page.

 - Craig
-- 
Craig Small (@smallsees)   http://enc.com.au/   csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#798598: NMU version

[Tomasz Buchert]

I'll only add that I've made a mistake of not resetting the NMU suffix
to 0.1 with the new upstream version. It would be nice to have lintian
report this.

Tomasz


signature.asc
Description: Digital signature

Bug#718273: #718273 ITP: go-fuse -- FUSE bindings for Go

[Julian Gilbey]

On Sat, Sep 12, 2015 at 07:11:50AM +1000, Dmitry Smirnov wrote:
> Hi Julian,
> 
> How is the progress with "go-fuse"?
> 
> Packaging seems to be trivial and license is clear. Do you need any help?

Yes, I would love some help!

I have a package at
Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hanwen-go-fuse.git
Vcs-Git: 
git://anonscm.debian.org/pkg-go/packages/golang-github-hanwen-go-mtpfs.git

It built fine a couple of weeks ago, when I submitted the ITP.  I
decided to wait a week in case there were any objections before
uploading it to sid.

But in that week, I upgraded my testing machine and also tried
building on sid, and now both fail on two of the unionfs tests:

--- FAIL: TestExplicitScan (0.03s)
autounion_test.go:218: Should have workspace backing1: lstat 
/tmp/764464878/mnt/backing1: no such file or directory

--- FAIL: TestUnionFsDropDeletionCache (0.09s)
unionfs_test.go:1039: Lstat() should have succeeded lstat 
/tmp/unionfs541255389/mnt/file: no such file or directory

I haven't managed to get to the bottom of this.  I could disable the
tests (as I needed to do for the go-mtpfs package), but that seems to
be avoiding the problem.

If you have any idea of the cause of this, it would be great!

   Julian

Bug#792110: shunit2: switch Build-Depends from pdksh to mksh

[Andreas Beckmann]

Followup-For: Bug #792110
Control: tag -1 patch pending

Hi,

I just uploaded a NMU fixing this to DELAYED/10. Full diff is attached.
Please let me know if I should delay it longer.


Andreas
diff -Nru shunit2-2.1.6/debian/changelog shunit2-2.1.6/debian/changelog
--- shunit2-2.1.6/debian/changelog	2012-03-25 13:08:32.0 +0200
+++ shunit2-2.1.6/debian/changelog	2015-09-12 23:03:56.0 +0200
@@ -1,3 +1,11 @@
+shunit2 (2.1.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch Build-Depends from pdksh to mksh.  (Closes: #792110)
+  * Drop obsolete DMUA flag.
+
+ -- Andreas Beckmann   Sat, 12 Sep 2015 23:03:56 +0200
+
 shunit2 (2.1.6-1) unstable; urgency=low
 
   * New upstream version.
diff -Nru shunit2-2.1.6/debian/control shunit2-2.1.6/debian/control
--- shunit2-2.1.6/debian/control	2012-03-25 17:26:58.0 +0200
+++ shunit2-2.1.6/debian/control	2015-09-12 22:58:36.0 +0200
@@ -3,10 +3,9 @@
 Priority: optional
 Maintainer: Ulrich Dangel 
 Build-Depends: debhelper (>= 9)
-Build-Depends-Indep: asciidoc, docbook-xsl, pdksh, xsltproc, zsh
+Build-Depends-Indep: asciidoc, docbook-xsl, mksh, xsltproc, zsh
 Standards-Version: 3.9.3
 Homepage: http://code.google.com/p/shunit2/
-DM-Upload-Allowed: yes
 
 Package: shunit2
 Architecture: all

Bug#789942: mapnik-vector-tile: FTBFS with mapnik 3.0(?): mapnik/graphics.hpp: No such file or directory

[Sebastiaan Couwenberg]

On 12-09-15 23:04, Jérémy Lal wrote:
> 2015-09-12 21:56 GMT+02:00 Sebastiaan Couwenberg :
>> Please share your thoughts about the future of the mapnik-vector-tile,
>> and its reverse dependencies (node-mapnik &
>> node-tilelive-{bridge,mapnik,vector}).
>>
>> [...]
> 
> My position is that it is good to have node-mapnik in debian, because it's
> not that easy to
> install otherwise - and i'm quite motivated to update it, but i'll find
> time to do it before the end of the year.

Alright. If we're going to keep node-mapnik around, we need to get
mapnik-vector-tile (0.10.0+dfsg-1) ready for upload.

Do you prefer a separate mapnik-clipper package, or just bundling
clipper.{c,h}pp in mapnik-vector-tile?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#798408: [arm] libgles2-mesa-dev and libglew-dev disagree over GLsizeiptr

[Yann Dirson]

On Tue, Sep 08, 2015 at 11:44:21PM +0200, Julien Cristau wrote:
> On Tue, Sep  8, 2015 at 23:11:53 +0200, Yann Dirson wrote:
> 
> > Package: libgles2-mesa-dev, libglew-dev
> > Version: 10.5.7-1, 1.10.0-3
> > Severity: important
> > 
> > The 2 buildd attempts of tulip 4.7.0 on armel and armhf both failed,
> > starting with the following type conflicts, and openscad hits a
> > similar problem.
> > 
> > https://bugs.debian.org/793137
> > https://bugs.debian.org/797816
> > 
> > libglew-dev and libgles2-mesa-dev were the same in both builds (I'm
> > puzzled that arnold does not use an uptodate mesa versions, BTW)
> > 
> I'm not sure that's our bug.  You probably shouldn't be mixing GLES and
> desktop GL that way...

What seems to have happenned is that while libqt4-opengl links to
libgl1 on all archs, for Qt5 things changed for armel and armhf.

So it does look like this is a Qt5 issue after all: looking that the
package's build-dep, there do not seem to be any arm-specific
discrepancy - but all archs pull both libgl-dev and libgles2-dev.

OTOH, looking at the logs, the armel build does check for varions
versions of "GL ES" (look for that specific string), while the amd64
build does not.

Using GLES on ARM looks like an upstream behaviour, and it may make
sense as ARM is essentially an embedded platform.  But then do we want
to restrict ARM to GLES, as we ship libgl1 for ARM as well, and other
archs are also used in embedded space.

Don't we need separate GL and GLES builds of Qt5, for all platforms ?

Or is it simply a bug that Qt5 headers propagate the selected
implementation to the includer source file ?

Bug#733227: [Xcb] Bug#733227: libxcb-xinput required for KF5+wacomtablet/kde-config-tablet

[Gregor Riepl]

> The protocol definitions for Xinput are incomplete and buggy in 1.11.
> That's why it is disabled by default.

I see. I thought that XCB-Xinput has matured well enough and was made
available to the general public (tm) by now. Guess I was wrong.

> In the next major release (1.12), the Xinput protocol definitions will be
(almost) complete. So, maybe we'll activate it by default then.

That's good to hear.
It will take a while until that reaches Debian though, libxcb still on 1.10
now - even in sid.

> If libxcb-xinput is already used with release 1.11, we need to take care of
ABI compatibility when releasing the fixes in 1.12.
> We have to solve that for XKB, too, so there is no way around this anyways.
>
> One possible solution is to do symbol-versioning for this and provide
compatibility wrappers for old symbols, with appropriate symbol-versions.
> (like the glibc does it, for example)
>
> I hope we can come up with some automatic or semi-automatic way to do this.
>
> Symbol-versioning will provide ABI compatibility but not API compatibility.
> Maybe that's acceptable: If the interface of an API function is buggy, the
client-source-code will need be fixed anyways.
> ABI-compatibility is important, of course, so that existing binaries
continue to work after upgrading libxcb-xinput.

It looks like Fedora ships the Xinput extension, and some people are already
starting to use it (as evidenced by the KF5 wacomtablet port). But since it is
still an experimental API, the additional work on compatibility may not be
worth the effort. Developers that use the the extension now should likely
expect to make changes to their code later.

Thanks for the heads up though!

Bug#709305: aptitude: Incorrect Italian translation of -aptitude update- output

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo
Control: retitle -1 aptitude: [l10n] Incorrect Italian translation of -aptitude 
update-


Hi Riccardo,

2013-05-22 14:12 Riccardo Boninsegna:

Package: aptitude
Version: 0.6.8.2-1
Severity: minor
Tags: l10n

Sample output of `aptitude update` with it_IT.UTF-8 locale:
[...]
Get: 28 http://debian.dynamica.it sid/main 2013-05-21-2016.39.pdiff [7665 B]
Scaricato 384 kB in 1min 51s (3434 B/s)

Stato attuale: 27 aggiornati [+27], 16 nuovi [+16].



The "Scaricato" ("downloaded"), being a plural quantity, should actually read
"Scaricati".

Additionally, as in the deselected vs. unselected controversy in dpkg,
"aggiornati" (updated/upgraded, those words are equivalent in Italian) implies
that what is called "upgrading packages" has already taken place: as the
message indicates a certain amount of upgradeable packages which may or may not
be actually upgraded, that word should be chaged into "aggiornabili"
(upgradeable).


Sorry that it took ages to handle this bug report, but there are loads of them.

The italian translation has been updated since your report, I think, can
you confirm if this still happens now?

Additionally, it would be great if you could contact the translators of
the .po file, or to provide a patch direcly about this, because I am not
sure about all of the instances where this should be changed.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#789942: mapnik-vector-tile: FTBFS with mapnik 3.0(?): mapnik/graphics.hpp: No such file or directory

[Jérémy Lal]

2015-09-12 21:56 GMT+02:00 Sebastiaan Couwenberg :

> Hi Jérémy & David,
>
> Please share your thoughts about the future of the mapnik-vector-tile,
> and its reverse dependencies (node-mapnik &
> node-tilelive-{bridge,mapnik,vector}).
>
> On 12-09-15 13:10, Sebastiaan Couwenberg wrote:
> > The mapbox/pbf.hpp dependency is no longer required, mapnik-vector-tile
> > has switched to the protozero [0] library also required for recent
> > libosmium releases.
> >
> > mapnik/clipper is still required, this is a mapnik specific fork of
> > polyclipping [1] (packaged in Debian as libpolyclipping [2]).
> >
> > I've updated the mapnik-vector-tile package to the recent 0.10.0
> > upstream release and patched it to use the protozero Debian package
> > instead of a clone of the protozero git repository. I'll do the same for
> > mapnik-clipper once that's packaged (I'm working on that too).
>
> I've create initial Debian packaging for mapnik/clipper [0], and updated
> mapnik-vector-tile [1] to use that package.
>
> mapnik-vector-tile (0.10.0+dfsg-1) now builds successfully, but a test
> does fail.
>
> Updating the mapnik-vector-tile package to work with mapnik 3.0.x, and
> packaging the mapnik/clipper dependency is being discussed in the
> upstream issue tracker [2].
>
> One of the upstream developers remarked that packaging
> mapnik-vector-tile shouldn't be required, because developers are
> expected to bundle mapnik-vector-tile in their projects.
>
> As noted in the issue, mapnik-vector-tile is packaged because
> node-mapnik requires it. And node-mapnik is in turn required for
> node-tilelive-{bridge,mapnik,vector}.
>
> Maybe we should consider removing mapnik-vector-tile and its reverse
> dependencies from the archive.
>
> What are your thoughts about this as the maintainers of these packages?
>

My position is that it is good to have node-mapnik in debian, because it's
not that easy to
install otherwise - and i'm quite motivated to update it, but i'll find
time to do it before the
end of the year.

Jérémy

Bug#798629: procps: w and who do not view any logged in users

[Craig Small]

On Sat, Sep 12, 2015 at 11:14:32AM +0200, Martin Steigerwald wrote:
> Craig, it seems the utmp file is basically empty except the reboot and the
> logged out already tty1 session.
Which means w is reporting "correctly" from the utmp file point of
view.

> I suspected systemd-logind already, but I was not sure about it. Feel free
> to reassign as you see fit.
I have done so and noted that this bug affects (but it is not caused by)
procps. It might help the systemd people if you tell them what version
of systemd you are running but I'm sure they have other questions too.

 - Craig

-- 
Craig Small (@smallsees)   http://enc.com.au/   csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#798724: kde-runtime: kwalletd in kde-runtime is missing org.kde.kwalletd5.service

[Gregor Riepl]

>> I had kde-full installed, however.
>> Shouldn't libkf5wallet-bin be a dependency of that?
>>
>> In any case, thanks. kwallet is working now, except that I'm struggling
>> with
>> the wallet migration wizard. But that's a different story.
> 
> That answers if it's packaging or upstream.
> 
> Do you have Recommends installation turned off?  I'm pretty sure with 
> kde-full it should be at least recommended.

No, I usually turn Recommends off because it may pull in tons of unwanted
packages sometimes.

libkf5wallet5 has libkf5wallet-bin in its Recommends list.

That's a start, but I don't think it makes a lot of sense.
Anything that uses kwallet should have a hard dependency on libkf5wallet-bin,
since it will simply not work without it.

May I suggest making kde-runtime depend on libkf5wallet-bin?
That would be the most appropriate place, I think...

Bug#596007: Is this solved? kstars-data-extra-tycho2 exists

[Maximiliano Curia]

Control: reassign -1 kstars-data-extra-tycho2
Control: done -1 1.1r1-1

On 20/08/15 05:04, Trent W. Buck wrote:
> Package: kstars-data
> Followup-For: Bug #596007

> It looks like Noel created kstars-data-extra-tycho2 in non-free,
> but forgot to update this bug.

> Should this bug (#596007) status be changed to "done"?

I guess, I'm reassigning this bug to the kstars-data-extra-tycho2 package and
closing it. Thanks for noticing this.

Happy hacking,
-- 
"We must be very careful when we give advice to younger people: sometimes they
follow it!"
-- Edsger W. Dijkstra
Saludos /\/\ /\ >< `/



signature.asc
Description: OpenPGP digital signature

Bug#794940: jessie-pu: package sparse/0.4.5~rc1-2~deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Mon, 2015-08-17 at 16:31 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2015-08-08 at 13:46 +0200, Andreas Beckmann wrote:
> > sparse FTBFS in jessie and sid since the llvm default version was updated
> > to 3.5. Unfortunately nobody rebuilt contrib and non-free before the
> > release so this was not noticed in time :-(
> 
> +  * Temporarily build-depend on libedit-dev because llvm-config claims to 
> need
> +that.  (Closes: #793197)
> 
> "Temporarily"?
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#767975: wheezy-pu: package sendmail/8.14.4-4+deb7u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2015-08-29 at 16:09 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> Apologies for the delay in getting back to you on this.
> 
> On Mon, 2014-11-03 at 21:12 +0100, Andreas Beckmann wrote:
> > there is one security bug open against sendmail that should be solved
> > via stable-updates, no security update needed (#750562).
> > 
> > I'd like to use this opportunity to cherry-pick some more bugfixes from
> > jessie/sid that are useful on stable, too:
> > 
> > sendmail (8.14.4-4+deb7u1) wheezy; urgency=medium
> > [...]
> >   * Add support for OpenSSL options SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2
> > (backported from 8.14.8), thanks to David F. Skoll.  (Closes: #747910)
> 
> I debated that one, particularly in (now) oldstable, but the patch is
> simple and the benefit seems sufficient.
> 
> Please feel free to upload.

The upload happened and I've flagged it for acceptance.

Regards,

Adam

Bug#798334: opu: package maven2/2.2.1-12+deb7u1

[Adam D. Barratt]

Control: tags -1 + pending

On Tue, 2015-09-08 at 23:03 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2015-09-08 at 10:11 +0200, Emmanuel Bourg wrote:
> > Please accept maven2/2.2.1-12+deb7u1 in wheezy-proposed-updates, this update
> > combined with the maven2-core update (#779670) fixes a security concern with
> > Maven 2 (#779337).
> 
> Please go ahead.

Uploaded and flagged for acceptance, thanks.

Regards,

Adam

Bug#787900: wheezy-pu: package live-tools/3.0.20-1+deb7u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2015-08-29 at 16:12 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2015-06-06 at 08:49 +0200, Andreas Beckmann wrote:
> > live-tools diverts update-initramfs and installs its own implementation
> > (that calls the original update-initramfs). Due to a lack of Depends:
> > initramfs-tools this errors out if the original update-initramfs is not
> > found, breaking all packages that don't depend on update-initramfs, but
> > call update-initramfs only after checking for its existence.
> > 
> > So let's add the missing Depends as it was done for jessie+.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#798799: [checks/changes-file] warn against "Close: #123456"

[Jakub Wilk]

Package: lintian
Version: 2.5.37
Severity: wishlist

"Close: #123456" is a plausible misspelling of "Closes: #123456".
It would be nice if Lintian warned against it.

--
Jakub Wilk

Bug#793307: [Aptitude-devel] Bug#793307: Bug#793307: aptitude: Add a confirmation for changing 'automatic' flag

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix


2015-07-29 21:36 Артём Банщиков:

On Fri, 24 Jul 2015 19:54:09 +0100 "Manuel A. Fernandez Montecelo" <
manuel.montez...@gmail.com> wrote:

2015-07-22 20:01 artem_banschikov:
>On Wed, 22 Jul 2015 19:24:07 +0200 Axel Beckert  wrote:
>Hi,
>> If we do so, we should
>>
>> a) make it optional (on by default is fine for me),
>Completely agree.
>> b) only ask for confirmation if it would catch more than one package
>>(i.e. for whole branches)
>I thought about three options: ask for one package, ask for multiple
>packages, not ask at all. There is file deletion dialog in Ranger
>file-manager made in this way.
>> c) only for "m", not for "M" (as the subject may suggest)
>Confirmation for "M" may be added for consistency.
>
>Anyway I'll be glad if you make exactly as you said as it will entirely

solve

>my problem.
>
>Best regards, Artyom.


What about Undo (Control-U), as Axel suggested in the previous e-mail?

IMO it is a more general solution, and already implemented, so it should

be

favoured rather than adding these new options (unless it does not work).


1) It may be not obvious for unexperienced user.
2) It may be not noticed quickly enough.
But optional warning in status screen may be added for using "m" on
multiple packages.


I am still not convinced that this is a good idea to add, so I will mark
it as +wontfix for the time being.


Justification:

In principle it should be harmless to add another confirmation dialog
for those cases where users might not notice the action, but in practice
it needs a lot of work: to add additional config options, handle them in
code, add code and signals to show dialogs and react to confirmention
events, document all that, translate the documentation, fix bugs for the
implementation mistakes several years down the line...

And surely, if one has confirmation for that relatively harmless action,
there are others which are much more dangerous and also deserve
confirmations: removing/purging, or reinstalling (can break running
services in the machine).

So I don't want to start the argument of the slippery slope and blame
global warming on confirmation dialogs; but suddenly this is not just a
harmless new dialog -- implementing this leaves less time to work on
other pressing issues, and all of that added complexity makes aptitude
more difficult to maintain in the long term.

Even if we had infinite time to implement all that (e.g. it would not
detract to work on other things, etc.), I think that increasing the
number of dialogs and config options for aptitude is actively harmful
and makes the program less useful, so it should only be used with a good
justification.

As to the questions that it may be not obvious for the unexperienced
user or not noticed quickly enough... in my opinion, setting a package
as manually installed is generally harmless, compared to most things
that can be done on aptitude, and not a real problem in 99% of cases
other than added cruft.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#798783: [kwalletmanager] Support for GPG encrypted wallets

[Maximiliano Curia]

On 12/09/15 17:47, Frederic Tronel wrote:
> The KF5 version of kwalletmanager does not allow to create a GPG encrypted 
> wallet. This feature was present in the KDE4 version of kwalletmanager.
> This is may be due to an missing flag during the compilation of 
> kwalletmanager 
> ?

That requires kwallet5 to be built against gpgmepp which is currently in NEW.
https://ftp-master.debian.org/new/gpgmepp_15.08.0-1.html

This feature will be enabled after the package is approved.

Happy hacking,
-- 
"Fighting patents one by one will never eliminate the danger of software
patents, any more than swatting mosquitoes will eliminate malaria."
-- Richard M. Stallman
Saludos /\/\ /\ >< `/



signature.asc
Description: OpenPGP digital signature

Bug#787966: libtiff5: LZW compression doesn't work with GIMP.

[Jussi Hukkanen]

The reason why the bug didn't appear in 4.0.3-7ubuntu0.3 seems to be
that they disabled the patch that fixed CVE-2014-8128.
https://bugs.launchpad.net/ubuntu/+source/tiff/+bug/1439186

-- jussi.hukka...@gmail.com
What if this weren't a hypothetical question?

Bug#798786: [libpam-kwallet5] kwalletd5 started by libpam-kwallet5 is not used by kwalletmanager5

[Maximiliano Curia]

Control: severity -1 minor
Control: tag -1 + upstream

On 12/09/15 19:00, Rahul Amaram wrote:
> Severity: grave

> After installing the libpam-kwallet5 package, when I login via SDDM, a process
> such as below is started.

> Konsole outpu rahul12635 12634  0 22:08 ?00:00:00
> /usr/bin/kwalletd5 --pam-login 17 27

The way that libpam-kwallet5 works is that is listens in a socket and waits
for someone to connect to it. Currently the part that connects to it is in the
startkde script that is part of plasma-workspace from the version 5.4.0, sadly
plasma-workspace hasn't migrated to testing and so it shows the current 
behavior.

That said, it means that libpam-kwallet5 is only useful in a session that has
the code snippet from startkde:
if test -n "$PAM_KWALLET5_LOGIN" ; then
env | socat STDIN UNIX-CONNECT:$PAM_KWALLET5_LOGIN
fi
And the kwalletd5 processes will be `hanged' in a session without it.
(You can add the previous snippet to your startkde script to fix this issue
while we wait for plasma-workspace to enter into testing)

This problem was reported upstream as part of the code review done before
packaging it and acknowledged upstream:

http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2014-October/001971.html
and:
http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2015-January/002002.html

Àlex, please consider this a friendly ping about this issue.

Some ideas:
 - Avoid starting a new kwalled5 if there is one already for the same user.
 - Set the environment, if needed, on the first kwalletmanager instantiation.
 - Have a timeout for the environment read (1 minute should be enough).

Happy hacking,
-- 
"It is practically impossible to teach good programming to students that have
had a prior exposure to BASIC: as potential programmers they are mentally
mutilated beyond hope of regeneration."
-- Edsger W. Dijkstra
Saludos /\/\ /\ >< `/



signature.asc
Description: OpenPGP digital signature

Bug#789942: mapnik-vector-tile: FTBFS with mapnik 3.0(?): mapnik/graphics.hpp: No such file or directory

[Sebastiaan Couwenberg]

Hi Jérémy & David,

Please share your thoughts about the future of the mapnik-vector-tile,
and its reverse dependencies (node-mapnik &
node-tilelive-{bridge,mapnik,vector}).

On 12-09-15 13:10, Sebastiaan Couwenberg wrote:
> The mapbox/pbf.hpp dependency is no longer required, mapnik-vector-tile
> has switched to the protozero [0] library also required for recent
> libosmium releases.
> 
> mapnik/clipper is still required, this is a mapnik specific fork of
> polyclipping [1] (packaged in Debian as libpolyclipping [2]).
> 
> I've updated the mapnik-vector-tile package to the recent 0.10.0
> upstream release and patched it to use the protozero Debian package
> instead of a clone of the protozero git repository. I'll do the same for
> mapnik-clipper once that's packaged (I'm working on that too).

I've create initial Debian packaging for mapnik/clipper [0], and updated
mapnik-vector-tile [1] to use that package.

mapnik-vector-tile (0.10.0+dfsg-1) now builds successfully, but a test
does fail.

Updating the mapnik-vector-tile package to work with mapnik 3.0.x, and
packaging the mapnik/clipper dependency is being discussed in the
upstream issue tracker [2].

One of the upstream developers remarked that packaging
mapnik-vector-tile shouldn't be required, because developers are
expected to bundle mapnik-vector-tile in their projects.

As noted in the issue, mapnik-vector-tile is packaged because
node-mapnik requires it. And node-mapnik is in turn required for
node-tilelive-{bridge,mapnik,vector}.

Maybe we should consider removing mapnik-vector-tile and its reverse
dependencies from the archive.

What are your thoughts about this as the maintainers of these packages?

[0] https://anonscm.debian.org/cgit/pkg-grass/mapnik-clipper.git
[1] https://anonscm.debian.org/cgit/pkg-grass/mapnik-vector-tile.git
[2] https://github.com/mapnik/clipper/issues/1

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#798794: Exception in thread "main" java.awt.AWTError

[Martin Hanson]

Package: openjdk-8-jre-headless
Version: 8u66-b01-3

Having just upgraded with an apt-get dist-upgrade on "testing" the following 
error occurs running Minecraft with java:

LOADEDenfalse
SAVED: enfalse
LOADEDenfalse
SAVED: enfalse
LOADED LANGUAGES
Exception in thread "main" java.awt.AWTError: Assistive Technology not found: 
org.GNOME.Accessibility.AtkWrapper
at java.awt.Toolkit.loadAssistiveTechnologies(Toolkit.java:807)
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:886)
at java.awt.Window.getToolkit(Window.java:1362)
at java.awt.Window.init(Window.java:506)
at java.awt.Window.(Window.java:537)
at java.awt.Frame.(Frame.java:420)
at java.awt.Frame.(Frame.java:385)
at javax.swing.JFrame.(JFrame.java:189)
at net.mc.main.Main.startMC(Main.java:173)
at net.mc.main.Main.main(Main.java:212)

If I remove the package from testing and manually install the version from 
jessie-backports (8u66-b01-1~bpo8+1), the problem is gone.

I am running with testing on 4.1.0-2-amd64 #1 SMP Debian 4.1.6-1 (2015-08-23) 
x86_64 GNU/Linux.

Kind regards.

Bug#798797: aptitude: Version in sid does not play nice with apt from experimental

[Guillem Jover]

Package: aptitude
Version: 0.7.1-1
Severity: important

Hi!

I'm using apt from experimental (1.1~exp12), and aptitude from sid
(0.7.1-1), which is linked against libapt-pkg4.16, sid's apt library.

Just after upgrading apt from experimental, aptitude works fine.
Immediately after doing the first «apt update», then suddenly aptitude
loses track of any installed package, and considers all of them as
obsolete/local, except for ~c ones. In addition I cannot mark the ~c
ones as automatic. Here's the relevant “screenshot”:

,---
--\ Not Installed Packages (5)
  --- games - Games, toys, and fun programs (1)
  --- graphics - Utilities to create, view, and edit graphics files (1)
  --\ libs - Collections of software routines (3)
--\ main - The main Debian archive (3)
clibapt-inst1.7 
clibexiv2-13
clibsrtp0   
--- Obsolete and Locally Created Packages (2762)
--- Virtual Packages (1058)
`---

I'm also using a Deb822 formatted sources.list file. Please let me know
if you cannot reproduce, and I'll try to provide more information.

Thanks,
Guillem

Bug#798798: unused build dependency python-tox

[Matthias Klose]

Package: src:gunicorn
Version: 19.0-7

As long as the tests are disabled, please comment out the build dependency on
tox, or remove it.

Bug#798744: nmu: promoe esperanza

[Jonathan Wiltshire]

retitle -1 transition: xmms2
tag -1 confirmed
user release.debian@packages.debian.org
usertag -1 = transition
thanks

On Sat, Sep 12, 2015 at 10:27:22AM +0200, Rémi Vanicat wrote:
> xmms2 has been rebuild for the g++-v5 transition. Two package build
> depend on libxmmsclient++-dev and need to be rebuild.
> 
> see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797646
> 
> nmu promoe_0.1.1-3+b1 . ALL . unstable . -m "rebuild for libxmmsclient++4v5"
> nmu esperanza_0.4.0+git20091017-3 . ALL . unstable . -m "rebuild for 
> libxmmsclient++4v5"

binNMUs scheduled.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: Digital signature

Bug#798794: Exception in thread "main" java.awt.AWTError

[Jan Henke]

Am 12.09.2015 um 20:40 schrieb Martin Hanson:
> Package: openjdk-8-jre-headless
> Version: 8u66-b01-3
>
> Having just upgraded with an apt-get dist-upgrade on "testing" the following 
> error occurs running Minecraft with java:
>
> LOADEDenfalse
> SAVED: enfalse
> LOADEDenfalse
> SAVED: enfalse
> LOADED LANGUAGES
> Exception in thread "main" java.awt.AWTError: Assistive Technology not found: 
> org.GNOME.Accessibility.AtkWrapper
> at java.awt.Toolkit.loadAssistiveTechnologies(Toolkit.java:807)
> at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:886)
> at java.awt.Window.getToolkit(Window.java:1362)
> at java.awt.Window.init(Window.java:506)
> at java.awt.Window.(Window.java:537)
> at java.awt.Frame.(Frame.java:420)
> at java.awt.Frame.(Frame.java:385)
> at javax.swing.JFrame.(JFrame.java:189)
> at net.mc.main.Main.startMC(Main.java:173)
> at net.mc.main.Main.main(Main.java:212)
>
> If I remove the package from testing and manually install the version from 
> jessie-backports (8u66-b01-1~bpo8+1), the problem is gone.
>
> I am running with testing on 4.1.0-2-amd64 #1 SMP Debian 4.1.6-1 (2015-08-23) 
> x86_64 GNU/Linux.
>
> Kind regards.
>
>
Hi Martin,

this is not a bug. If you want to run any Java application with a GUI,
you need the non-headless openjdk package (i.e. openjdk-8-jre). The
headless package is intended for "headless" machines like servers.
Headless means here system usually running without local monitor,
keyboard, mouse, graphical user interface etc.

So the -headless package, by design, does not include the parts
necessary for running applications like Minecraft.

I hope that explanation helps.

Best Regards,
Jan Henke



signature.asc
Description: OpenPGP digital signature

Bug#791722: check-all-the-things: look for #! lines

[Jakub Wilk]

* Paul Wise , 2015-09-06, 23:08:

$ file --mime-type /usr/bin/check-all-the-things
/usr/bin/check-all-the-things: text/plain


This appears to be a regression between 1:5.22+15-2 and 1:5.24-1 but 
the changelog says the opposite so I'm confused:


 * New upstream version 5.24. Addresses:
   - '#!' should have a bigger strength, Closes: #698569


Filed as #798796.

--
Jakub Wilk

Bug#798796: "file --mime-type" recognizes Python scripts as text/plain

[Jakub Wilk]

Package: file
Version: 1:5.24-1

"file --mime-type" recognizes Python scripts as text/plain:

$ echo '#!/usr/bin/python' > pyscript
$ file --mime-type pyscript
pyscript: text/plain

... instead of text/x-python, as it used to in 1:5.22+15-2:

$ file --mime-type pyscript
pyscript: text/x-python


See bug #791722 for context.

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

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

Versions of packages file depends on:
ii  libc6  2.19-19
ii  libmagic1  1:5.24-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

--
Jakub Wilk

Bug#798731: dpkg: broken dependency calculation when removing packages

[Branislav Zahradník]

Hi Guillem,

honestly, I have no idea where this bug exactly came from, but from behavior it is issue in 
dependency resolution, which I guess is part of dpkg.


What I observed here is following scenario:

I had packages A (depends on B) and B installed.
removing B (probably via dependencies) results to: remove A B C (unwanted C)
removing A first, than B (two commands) -> C was not affected.

Best regards,
Brano

On 09/12/2015 07:17 PM, Guillem Jover wrote:

Hi!

On Sat, 2015-09-12 at 04:19:30 +0200, Branislav Zahradnik wrote:

Package: dpkg
Version: 1.18.2
Severity: normal



I had a problem with removing some KDE packages, leading to remove gnome.
After rejecting this bug from gnome package maintainer I tried to find more
(ie, remove packages one by one)



I had following issue (with apt-get output):

apt-get remove libkdeui5
The following extra packages will be installed:
   libkdecore5 libkdesu5 libkjsapi4 libkjsembed4 libkntlm4 libkpty4
The following packages will be REMOVED:
   libkdeui5 libkwineffects1abi5 libnepomuk4 libnepomukcore4 libnepomukquery4a
libnepomukutils4 liboktetagui4 libsendlater4
The following packages will be upgraded:
   libkdecore5 libkdesu5 libkjsapi4 libkjsembed4 libkntlm4 libkpty4

then I removed "be REMOVED" packages in reversed order manually without getting
extra packages installed or upgraded.

similar happen with:
apt-get remove libgpgme++2
The following extra packages will be installed:
   libreoffice-base-drivers
Suggested packages:
   libjtds-java libreoffice-mysql-connector libmyodbc libmysql-java
libsqliteodbc tdsodbc mdbtools
The following packages will be REMOVED:
   gnome libgpgme++2 libqgpgme1 libreoffice libreoffice-base libreoffice-
emailmerge libreoffice-evolution libreoffice-help-en-us libreoffice-java-common
libreoffice-officebean libreoffice-report-builder-bin libreoffice-sdbc-hsqldb
openoffice.org openoffice.org-evolution
   openoffice.org-help-en-us
The following packages will be upgraded:
   libreoffice-base-drivers

removing libqgpgme1 before solved problem again.


Sorry, but I don't think I understand what's the problem being
reported here. Also I don't quite see why this would be a problem in
dpkg (instead of say the package metadata, an ongoing transition or
apt) if there's one at all?

Thanks,
Guillem

Bug#798795: memtester FTCBFS: uses build architecture compiler

[Helmut Grohne]

Source: memtester
Version: 4.3.0-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

memtester FTCFBS, because it uses the build architecture compiler. The
build actually fails when dh_strip uses the host architecture strip on
the build architecture binary.

I am attaching a patch that forces the triplet-prefixed compiler upon
the wicked build system that hides the compiler invocations and fails to
use hardened build flags. I didn't find a simpler way to do that.

Helmut
diff --minimal -Nru memtester-4.3.0/debian/changelog 
memtester-4.3.0/debian/changelog
--- memtester-4.3.0/debian/changelog2013-04-01 12:06:33.0 +0200
+++ memtester-4.3.0/debian/changelog2015-09-12 20:03:05.0 +0200
@@ -1,3 +1,10 @@
+memtester (4.3.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Export CC to support cross compilation. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 12 Sep 2015 20:02:51 +0200
+
 memtester (4.3.0-3) unstable; urgency=low
 
   * New maintainer (closes: #704327).
diff --minimal -Nru memtester-4.3.0/debian/patches/02-cross.patch 
memtester-4.3.0/debian/patches/02-cross.patch
--- memtester-4.3.0/debian/patches/02-cross.patch   1970-01-01 
01:00:00.0 +0100
+++ memtester-4.3.0/debian/patches/02-cross.patch   2015-09-12 
20:52:44.0 +0200
@@ -0,0 +1,34 @@
+Author: Helmut Grohne 
+Description: make the build system honor $CC to facilitate cross builds
+
+Index: memtester-4.3.0/conf-cc
+===
+--- memtester-4.3.0.orig/conf-cc   2012-06-09 23:45:22.0 +0200
 memtester-4.3.0/conf-cc2015-09-12 20:36:27.0 +0200
+@@ -1,3 +1,3 @@
+-cc -O2 -DPOSIX -D_POSIX_C_SOURCE=200809L -D_FILE_OFFSET_BITS=64 
-DTEST_NARROW_WRITES -c
++$CC -O2 -DPOSIX -D_POSIX_C_SOURCE=200809L -D_FILE_OFFSET_BITS=64 
-DTEST_NARROW_WRITES -c
+ 
+ This will be used to compile .c files.
+Index: memtester-4.3.0/conf-ld
+===
+--- memtester-4.3.0.orig/conf-ld   2012-06-09 23:45:22.0 +0200
 memtester-4.3.0/conf-ld2015-09-12 20:36:33.0 +0200
+@@ -1,3 +1,3 @@
+-cc -s
++$CC -s
+ 
+ This will be used to link .o files into an executable.
+Index: memtester-4.3.0/Makefile
+===
+--- memtester-4.3.0.orig/Makefile  2015-09-12 20:01:06.0 +0200
 memtester-4.3.0/Makefile   2015-09-12 20:50:40.0 +0200
+@@ -10,8 +10,6 @@
+ # You don't need to edit these; change the contents of the conf-cc and conf-ld
+ # files if you need to change the compile/link commands.  See the README for
+ # more information.
+-CC= $(shell head -n 1 conf-cc)
+-LD= $(shell head -n 1 conf-ld)
+ 
+ SOURCES   = memtester.c tests.c
+ OBJECTS   = $(SOURCES:.c=.o)
diff --minimal -Nru memtester-4.3.0/debian/patches/series 
memtester-4.3.0/debian/patches/series
--- memtester-4.3.0/debian/patches/series   2013-04-01 12:06:46.0 
+0200
+++ memtester-4.3.0/debian/patches/series   2015-09-12 20:12:09.0 
+0200
@@ -1 +1,2 @@
 01-manpage.patch
+02-cross.patch
diff --minimal -Nru memtester-4.3.0/debian/rules memtester-4.3.0/debian/rules
--- memtester-4.3.0/debian/rules2012-11-23 10:29:43.0 +0100
+++ memtester-4.3.0/debian/rules2015-09-12 20:51:56.0 +0200
@@ -1,5 +1,12 @@
 #!/usr/bin/make -f
 
+DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
+
+ifeq ($(origin CC),default)
+CC = $(DEB_HOST_GNU_TYPE)-gcc
+endif
+export CC
+
 %:
dh ${@}
 

Bug#781322: python-jsmin new package

[gustavo panizzo (gfa)]

Hello
I've prepared a new version of this package, unfortunatelly it
is not possible to use it on wheezy, but works fine on jessie, would you
be willing to sponsor it?

you can check the package here

git://anonscm.debian.org/collab-maint/python-jsmin.git

thanks!

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: http://keybase.io/gfa

Bug#798793: gimp-gmic: All presets for film emulation produce 404's

[Tim Kelley]

Package: gimp-gmic
Version: 1.6.0.1-1
Severity: normal

Dear Maintainer,

Apparently all the presets for the film emulation section point to
locations on the web which no longer exist. They really should be
removed or fixed.

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

Kernel: Linux 3.16.0-4-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 gimp-gmic depends on:
ii  gimp 2.8.14-1+b1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u1
ii  libcairo21.14.0-2.1
ii  libfftw3-double3 3.3.4-2
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3
ii  libgcc1  1:4.9.2-10
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u2
ii  libgimp2.0   2.8.14-1+b1
ii  libglib2.0-0 2.42.1-1
ii  libgomp1 4.9.2-10
ii  libgtk2.0-0  2.24.25-3
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libpng12-0   1.2.50-2+b2
ii  libstdc++6   4.9.2-10
ii  libx11-6 2:1.6.2-3
ii  zlib1g   1:1.2.8.dfsg-2+b1

gimp-gmic recommends no packages.

Versions of packages gimp-gmic suggests:
pn  gmic  

-- no debconf information

Bug#798792: libhttp-proxy-perl: non-deterministic FTBFS: timing in 23connect.t

[Niko Tyni]

Package: libhttp-proxy-perl
Version: 0.304-1
Severity: important
Tags: upstream
Forwarded: https://github.com/book/HTTP-Proxy/issues/7

There's apparently a timing problem in t/23connect.t
that makes it fail non-determistically with

  t/23connect.t .. 
  1..4
  ok - The proxy accepts CONNECT requests
  not ok - Read some data from the socket
  not ok - CONNECTed to the TCP server and got the banner
  
  #   Failed test 'Read some data from the socket'
  #   at t/23connect.t line 78.
  
  #   Failed test 'CONNECTed to the TCP server and got the banner'
  #   at t/23connect.t line 79.
  #  got: undef
  # expected: 'President_of_Earth Barbarella Professor_Ping Stomoxys Dildano
  # '
  
I was able to reproduce it locally by running the test in a loop
and loading the build system with other tasks at the same time.

This is also discussed upstream in

-- 
Niko Tyni   nt...@debian.org

Bug#798710: jit-playback changes brake package pygccjit build

[Matthias Klose]

Control: severity -1 wishlist
Control: tags -1 + help

On 09/11/2015 10:11 PM, Jurica Stanojkovic wrote:
> Package: gcc-5
> Version: 5.2.1-15
> Severity: serious
> Tags: sid
> User: debian-m...@lists.debian.org
> 
> Package gcc-5_5.2.1-15 is causing following issue during package 
> pygccjit_0.4-4 build:

pygccjit never built on mips/mipsel. Please investigate and send a patch to
upstream.

> test_bf_jit (test.JitTests) ... /tmp/libgccjit-HxB6hJ/fake.s: Assembler 
> messages:
> /tmp/libgccjit-HxB6hJ/fake.s:14: Error: `fp=xx' used with a cpu lacking 
> ldc1/sdc1 instructions
> /tmp/libgccjit-HxB6hJ/fake.s:14: Error: `fp=xx' used with a cpu lacking 
> ldc1/sdc1 instructions
> /tmp/libgccjit-HxB6hJ/fake.s:15: Error: `fp=xx' used with a cpu lacking 
> ldc1/sdc1 instructions
> /tmp/libgccjit-HxB6hJ/fake.s:22: Error: `fp=xx' used with a cpu lacking 
> ldc1/sdc1 instructions
> /tmp/libgccjit-HxB6hJ/fake.s:24: Error: `fp=xx' used with a cpu lacking 
> ldc1/sdc1 instructions
> /tmp/libgccjit-HxB6hJ/fake.s:201: Error: `fp=xx' used with a cpu lacking 
> ldc1/sdc1 instructions
> /tmp/libgccjit-HxB6hJ/fake.s:202: Error: `fp=xx' used with a cpu lacking 
> ldc1/sdc1 instructions
> libgccjit.so: error: error invoking gcc driver: exit_status: 256 err: 0
> libgccjit.so: error: whilst attempting to run a driver named: 
> mipsel-linux-gnu-gcc-5
> libgccjit.so: error: PATH was: 
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> ERROR
> 
> For this issue to be seen on pygccjit build log, one could rebuild package 
> against new gcc-5 version.
> 
> This issue is not noticed with gcc-5 version gcc-5_5.1.1-13 that is in 
> pygccjit build log:
> https://buildd.debian.org/status/fetch.php?pkg=pygccjit&arch=mips&ver=0.4-4&stamp=1436417562
> Problem that is present with gcc-5_5.1.1-13 is still there on gcc-5_5.2.1-15 
> and I will open a separate bug report for this issue.
> 
> Here are lines that I get during package build with gcc-5_5.1.1-14:
>  gcc-5 -shared /tmp/libgccjit-z1jPnd/fake.s -o /tmp/libgccjit-z1jPnd/fake.so 
> -fno-use-linker-plugin
> 
> and gcc-5_5.2.1-15:
> gcc-5 -EL -mips1 -mabi=32 -shared /tmp/libgccjit-piCaTh/fake.s -o 
> /tmp/libgccjit-piCaTh/fake.so -fno-use-linker-plugin
> 
> Notice mips1 flag in build line.
> 
> I have traced back changes that caused this new issue and they are first 
> introduces with gcc-5_5.2.1-13 version:
> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/jit/jit-playback.h?r1=225207&r2=226126
> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/jit/jit-playback.c?r1=225726&r2=226126
> 
> After reverting these patches on MIPS this issue is not there any more.
> This is confirmed with gcc-5_5.2.1-15 built with those changes reverted.
> 
> This issue is found in versions:
> 5.2.1-13, 5.2.1-14, 5.2.1-15, 5.2.1-16.
> 
> Suggestions are welcomed.
> 
> Thank you!
> 
> Regards,
> Jurica
> 

Bug#624706: aptitude: Wrongly shows packages to be non-free in interactive mode

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Andrei,

2011-04-30 20:25 Andrei POPESCU:

Package: aptitude
Version: 0.6.3-4
Severity: normal

Hi,

I have lenny, squeeze, wheezy and sid in sources.list. For example
tango-icon-theme (but this is reproducible with other packages as well)
is non-free in lenny, but moved to main since squeeze:

$ apt-cache policy tango-icon-theme
tango-icon-theme:
 Installed: 0.8.90-3
 Candidate: 0.8.90-3
 Version table:
*** 0.8.90-3 0
   500 http://ftp.at.debian.org/debian/ sid/main amd64 Packages
   500 http://ftp.at.debian.org/debian/ squeeze/main amd64 Packages
   500 http://ftp.at.debian.org/debian/ wheezy/main amd64 Packages
   100 /var/lib/dpkg/status
0.8.1-4 0
   500 http://ftp.at.debian.org/debian/ lenny/non-free amd64 Packages

Aptitude know this in command-line mode:

$ aptitude show tango-icon-theme | grep Section
Section: x11

but not in interactive mode (copy pasted with 'screen')

---
Actions  Undo  Package  Resolver  Search  Options  Views  Help
C-T: Menu  ?: Help  q: Quit  u: Update  g: Download/Install/Remove Pkgs
   Packages tango-icon-theme info
aptitude 0.6.3
   icons follow a standard and consistent style guide to look coherent.
 Homepage: http://tango.freedesktop.org
 Priority: optional
 Section: non-free/x11
 Maintainer: Philipp Kern 
 Compressed size: 1789 k
 Uncompressed size: 10.9 M
 Source Package: tango-icon-theme
 --\ Depends (1)
   --- hicolor-icon-theme
 --\ Suggests (2)
   --- gnome-icon-theme
   --- kdelibs-data (UNSATISFIED)
 --\ Conflicts (1)
   --- tango-icon-theme-common (< 0.6)
 --- Packages which depend on tango-icon-theme (13)
 --\ Versions of tango-icon-theme (2)
p A  0.8.1-4
i A  0.8.90-3
Tango icon theme
---

(note: this is the default info for tango-icon-theme, not for the lenny
version 0.8.1-4)



I installed an old version from snapshots, 0.7.2-1 (maintainer "Utnubu
team"), which is in non-free/x11, and the current version 0.8.90-5 from
unstable section x11 (maintainer "P. Kern") is available.  They are not
the versions that you describe but they should be fine, I think.

When I enter package info screen the first time, the section is "x11"
(and the maintainer "P. Kern"), even if the version currently installed
is the other one.  If I go to the old or new version, and select (press
enter), I get the correct information in each case.  I repeat this a
number of times without problems.

Maybe the first time that one enters in that screen the information is
random (I don't think so, though: is probably either current or
candidate version consistently), but after that it shouldn't be, so I am
surprised about the behaviour that you describe.

I am also surprised specially because I think that the section of the
code has not been touched since ~2005 or so, so your tests a few years
ago and now should be the same.

Could you please see if you can reproduce it with this or other
packages?  (Preferably small and that don't require extra dependencies
installed, like this one, for ease of testing).


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#798622: openldap: CVE-2015-6908: ber_get_next denial of service vulnerability

[Ryan Tandy]

Control: tag -1 - fixed-upstream

The upstream fix has been reverted, for the moment.

Bug#798791: lgrind: FTBFS with dpkg-dev 1.18.2 due to invalid timestamp formatting

[Andreas Beckmann]

Package: lgrind
Version: 3.67-3
Severity: serious
Tags: sid stretch
Justification: fails to build from source

Hi,

The last debian/changelog entry has a date of:

  Sun, 11 April 2010 20:40:10 +0200

However, Policy section 4.4 tells us that "month is one of: Jan, Feb,
Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec".

This is important in a practical sense since dpkg-dev 1.18.2, date
parsing is stricter and thus dpkg-parsechangelog, dpkg-genchanges (etc.)
fail to process the file, ending in a FTBFS when genchanges is called to
parse the file.

s/April/Apr/ and that's it.


Andreas

Bug#798789: netperf: FTBFS with GCC 5: undefined reference to `demo_interval_tick'

[Andreas Beckmann]

Package: netperf
Version: 2.6.0-2
Severity: serious
Tags: sid stretch
Justification: fails to build from source (but built successfully in the past)

Hi,

netperf FTBFS in sid with GCC5:

[...]
gcc -DHAVE_CONFIG_H -I. -I..   -D_FORTIFY_SOURCE=2  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -c netlib.c
netlib.c: In function 'bind_to_specific_processor':
netlib.c:2292:9: warning: implicit declaration of function 'sched_setaffinity' 
[-Wimplicit-function-declaration]
 if (sched_setaffinity(getpid(), len, &netperf_cpu_set)) {
 ^
netlib.c: At top level:
netlib.c:4080:20: warning: 'temp_demo_ptr' is static but used in inline 
function 'demo_interval_tick' which is not static
 demo_two_ptr = temp_demo_ptr;
^
netlib.c:4080:5: warning: 'demo_two_ptr' is static but used in inline function 
'demo_interval_tick' which is not static
 demo_two_ptr = temp_demo_ptr;
 ^
netlib.c:4079:20: warning: 'demo_two_ptr' is static but used in inline function 
'demo_interval_tick' which is not static
 demo_one_ptr = demo_two_ptr;
^
[...]
gcc  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall  
-Wl,-z,relro -o netperf netperf.o netlib.o netsh.o nettest_bsd.o nettest_dlpi.o 
nettest_unix.o nettest_xti.o nettest_sctp.o nettest_sdp.o nettest_omni.o 
net_uuid.o dscp.o netcpu_procstat.o netrt_rtnetlink.o netdrv_ethtool.o 
netslot_linux.o netsys_linux.o netsec_linux.o  -ldl -lm 
nettest_omni.o: In function `send_omni_inner':
/tmp/buildd/netperf-2.6.0/src/nettest_omni.c:4366: undefined reference to 
`demo_interval_tick'
/tmp/buildd/netperf-2.6.0/src/nettest_omni.c:4359: undefined reference to 
`demo_interval_tick'
/tmp/buildd/netperf-2.6.0/src/nettest_omni.c:4363: undefined reference to 
`demo_interval_tick'
/tmp/buildd/netperf-2.6.0/src/nettest_omni.c:4356: undefined reference to 
`demo_interval_tick'
collect2: error: ld returned 1 exit status
[...]


Andreas

Bug#798788: libreoffice: display doesn't update properly (writer and calc)

[Stephen Kitt]

On Sat, 12 Sep 2015 20:17:42 +0200, Stephen Kitt  wrote:
> I've tried deleting ~/.libreoffice and switching off display
> acceleration (hardware acceleration, OpenGL, and the anti-aliasing
> options) without effect.

Deleting ~/.config/libreoffice fixes this.

I'll leave it up to you to decide what to do with this; there's something
missing in the upgrade code, but what...

Regards,

Stephen


pgprjr3T7QMET.pgp
Description: OpenPGP digital signature

Bug#798790: libmoosex-clone-perl: missing dependency on libnamespace-autoclean-perl

[Niko Tyni]

Package: libmoosex-clone-perl
Version: 0.06-1
Severity: serious
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Control: affects -1 libbread-board-perl

This package is missing a runtime dependency on
libnamespace-autoclean-perl.  This makes other packages, at least
libbread-board-perl, fail to build from source. See
  https://reproducible.debian.net/rb-pkg/unstable/amd64/libbread-board-perl.html

The autopkgtest checks also fail because of this, so running
them before the upload would have caught this.
-- 
Niko Tyni   nt...@debian.org

Bug#798787: linux-image-4.1.0-2-amd64: usb device recognised on i386 testing, but not on amd64: Alcor Micro Corp. Multi Flash Reader

[ael]

Package: src:linux
Version: 4.1.6-1
Severity: normal

I have a Multiflash (usb) reader which works under testing on i386
architecture. Here is the lsusb -v detail from that working system:

---
Bus 001 Device 004: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x058f Alcor Micro Corp.
  idProduct  0x6366 Multi Flash Reader
  bcdDevice1.00
  iManufacturer   1 Generic
  iProduct2 Mass Storage Device
  iSerial 3 058F63666471
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk-Only
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x
  (Bus Powered)
---

Here is the lsmod output on the working system:
---

Module  Size  Used by
uas20480  0
usb_storage53248  1 uas
snd_hrtimer16384  1
snd_seq_midi   16384  0
snd_seq_midi_event 16384  1 snd_seq_midi
snd_rawmidi24576  1 snd_seq_midi
snd_seq53248  3 snd_seq_midi_event,snd_seq_midi
snd_seq_device 16384  3 snd_seq,snd_rawmidi,snd_seq_midi
cpufreq_powersave  16384  0
cpufreq_userspace  16384  0
cpufreq_stats  16384  0
cpufreq_conservative16384  0
nfsd  249856  13
auth_rpcgss49152  1 nfsd
oid_registry   16384  1 auth_rpcgss
nfs_acl16384  1 nfsd
nfs   184320  0
lockd  73728  2 nfs,nfsd
grace  16384  2 nfsd,lockd
fscache45056  1 nfs
sunrpc225280  22 nfs,nfsd,auth_rpcgss,lockd,nfs_acl
arc4   16384  2
joydev 20480  0
iTCO_wdt   16384  0
iTCO_vendor_support16384  1 iTCO_wdt
sparse_keymap  16384  0
uvcvideo   73728  0
videobuf2_vmalloc  16384  1 uvcvideo
acerhdf16384  0
videobuf2_memops   16384  1 videobuf2_vmalloc
videobuf2_core 40960  1 uvcvideo
v4l2_common16384  1 videobuf2_core
videodev  118784  3 uvcvideo,v4l2_common,videobuf2_core
media  20480  2 uvcvideo,videodev
coretemp   16384  0
ath5k 139264  0
ath24576  1 ath5k
evdev  20480  21
pcspkr 16384  0
psmouse   102400  0
serio_raw  16384  0
snd_hda_codec_realtek65536  1
sg 32768  0
snd_hda_codec_generic65536  1 snd_hda_codec_realtek
mac80211  503808  1 ath5k
i2c_i801   20480  0
i915  937984  4
snd_hda_intel  28672  5
lpc_ich20480  0
mfd_core   16384  1 lpc_ich
snd_hda_controller 28672  1 snd_hda_intel
snd_hda_codec  86016  4 
snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller
rng_core   16384  0
drm_kms_helper 90112  1 i915
jmb38x_ms  20480  0
snd_hda_core   24576  4 
snd_hda_codec_realtek,snd_hda_codec_generi

Bug#787966: libtiff5: LZW compression doesn't work with GIMP.

[Jussi Hukkanen]

I tested this with GIMP 2.8.10 in Ubuntu 14.04, where the libtiff5
package is version 4.0.3-7ubuntu0.3. Both LZW and Deflate worked fine,
so it seems the bug has appeared between 4.0.3-7 and 4.0.3-12.3.
However, the inner workings of libtiff5 are beyond my understanding.

-- jussi.hukka...@gmail.com
What if this weren't a hypothetical question?


2015-09-07 13:36 GMT+03:00 Jussi Hukkanen :
> I have also encountered this bug.
>
> Debian 8; Linux 3.16.0-4-amd64
> libtiff5 4.0.3-12.3
> gimp 2.8.14-1+b1
>
> GIMP with libtiff5 exports uncompressed TIFF images correctly.
> However, if LZW or Deflate compression is selected, the resulting
> image gets corrupted. PackBits compression seems to work just fine.
>
> To reproduce, first open the file flower-uncompressed.tif in GIMP 2.8.14:
> http://bit.ly/1O8bZFv
>
> Export the image as a new TIFF file, using either LZW or Deflate
> compression method. Open the resulting image in GIMP. It will look
> like flower-lzw.tif here, when obviously it is supposed to be a
> pixel-perfect copy of the original, only a smaller file.
> http://bit.ly/1ISUx0G
>
> In another system running Debian 7 with gimp 2.8.2-2+deb7u1 and
> libtiff4 3.9.6-11, there was no problem with LZW export. I never tried
> Deflate there.
>
> -- jussi.hukka...@gmail.com
> What if this weren't a hypothetical question?

Bug#569150: Amavis never cleans its virusmail jail

[Alexander Wirt]

On Sat, 12 Sep 2015, Joey Hess wrote:

> I installed amavis to delete viruses. After a year, I noticed
> /var/lib/amavis/virusmails was where all my system's disk space had
> gone.
> 
> After grepping through all the documentation, I have yet to find
> anything that documents this package behaves this way. Is the admin
> supposed to learn about this when their server breaks?
> 
> Not sure why I'm even bothering to follow up since this bug
> has been open for 5 years(!), but I wanted to point out that
> this is also a documentation issue, and that this package, as it
> currently exists, is a landmine for the unwary admin.
I can add some documentation to README.Debian, but I will probably not
add some cronjob that possibly removes user mail. 

Alex



pgpVsRGgDbQgF.pgp
Description: PGP signature

Bug#794977: dselect: no access methods are available

[Guillem Jover]

Hi!

On Sun, 2015-09-06 at 22:10:18 +0200, Marcos Dione wrote:
> Package: dselect
> Version: 1.18.2
> Followup-For: Bug #794977

> I'm not sure if this helps, but the http method seems to have
> dissappeared:
[…]

There's never been a native http method in dselect (AFAIK).

> while we're at it, does the floppy method have any use? maybe
> usb drives?

Perhaps other tiny device, but this is unrelated to this bug report,
and it should be revisited once the download methods get a revamp.

Thanks,
Guillem

Bug#798731: dpkg: broken dependency calculation when removing packages

[Guillem Jover]

Hi!

On Sat, 2015-09-12 at 04:19:30 +0200, Branislav Zahradnik wrote:
> Package: dpkg
> Version: 1.18.2
> Severity: normal

> I had a problem with removing some KDE packages, leading to remove gnome.
> After rejecting this bug from gnome package maintainer I tried to find more
> (ie, remove packages one by one)

> I had following issue (with apt-get output):
> 
> apt-get remove libkdeui5
> The following extra packages will be installed:
>   libkdecore5 libkdesu5 libkjsapi4 libkjsembed4 libkntlm4 libkpty4
> The following packages will be REMOVED:
>   libkdeui5 libkwineffects1abi5 libnepomuk4 libnepomukcore4 libnepomukquery4a
> libnepomukutils4 liboktetagui4 libsendlater4
> The following packages will be upgraded:
>   libkdecore5 libkdesu5 libkjsapi4 libkjsembed4 libkntlm4 libkpty4
> 
> then I removed "be REMOVED" packages in reversed order manually without 
> getting
> extra packages installed or upgraded.
> 
> similar happen with:
> apt-get remove libgpgme++2
> The following extra packages will be installed:
>   libreoffice-base-drivers
> Suggested packages:
>   libjtds-java libreoffice-mysql-connector libmyodbc libmysql-java
> libsqliteodbc tdsodbc mdbtools
> The following packages will be REMOVED:
>   gnome libgpgme++2 libqgpgme1 libreoffice libreoffice-base libreoffice-
> emailmerge libreoffice-evolution libreoffice-help-en-us 
> libreoffice-java-common
> libreoffice-officebean libreoffice-report-builder-bin libreoffice-sdbc-hsqldb
> openoffice.org openoffice.org-evolution
>   openoffice.org-help-en-us
> The following packages will be upgraded:
>   libreoffice-base-drivers
> 
> removing libqgpgme1 before solved problem again.

Sorry, but I don't think I understand what's the problem being
reported here. Also I don't quite see why this would be a problem in
dpkg (instead of say the package metadata, an ongoing transition or
apt) if there's one at all?

Thanks,
Guillem

Bug#792779: nmu: android-platform-frameworks-base_21-2

[Andreas Beckmann]

On 2015-07-19 23:27, Jonathan Wiltshire wrote:
> It does indeed look like amd64 (a maintainer upload) was different to i386
> as built by wanna-build, and a rebuild is an appropriate fix. Scheduled in
> sid with +b2, I'll leave the Jessie rebuild until it's migrated.

The first binNMU attempt got stuck somehow and when it was retried 
later, it got entangled in some c++11 transition bits ... which is 
still reproducible:


g++ -fPIC -Wl,-rpath=/usr/lib/android -Wl,-z,relro -o aapt AaptAssets.o 
Command.o CrunchCache.o FileFinder.o Main.o Package.o StringPool.o XMLNode.o 
ResourceFilter.o ResourceTable.o Images.o Resource.o SourcePos.o ZipEntry.o 
ZipFile.o -lrt -ldl -lpthread -lz -lexpat -lpng -L/usr/lib/android  -lcutils 
-lhost -llog -lutils -L../../libs/androidfw  -landroidfw 
XMLNode.o: In function `parseStyledString(Bundle*, char const*, 
android::ResXMLTree*, android::String16 const&, android::String16*, 
android::Vector*, bool, bool)':
/tmp/buildd/android-platform-frameworks-base-21/tools/aapt/XMLNode.cpp:214: 
undefined reference to `pseudolocalize_string(std::__cxx11::basic_string, std::allocator > const&)'
collect2: error: ld returned 1 exit status


Andreas

Bug#776914: closed by Anton Gladky (Bug#776914: fixed in avogadro 1.1.1-1~exp1)

[Andreas Beckmann]

Control: found -1 1.1.0-4ubuntu1
Control: fixed -1 1.0.3-10.1

Hi Anton,

you mismerged the changelogs from sid and experimental, the version
numbers are not ordered correctly:

...
1.1.0-4ubuntu1
1.0.3-10.1
1.1.0-4
...

ordering must be by version, not by timestamp, otherwise this is going
to confuse the bts (as in: "WTH does this RC bug suddenly show up in
stable?" which I just tried to workaround)


Andreas

Bug#733227: [Xcb] Bug#733227: libxcb-xinput required for KF5+wacomtablet/kde-config-tablet

[Christian Linhart]

Hi Gregor,

I cannot speak for Debian, but just from the XCB side.

The protocol definitions for Xinput are incomplete and buggy in 1.11.
That's why it is disabled by default.

In the next major release (1.12), the Xinput protocol definitions will be 
(almost) complete. So, maybe we'll activate it by default then.

If libxcb-xinput is already used with release 1.11, we need to take care of ABI 
compatibility when releasing the fixes in 1.12.
We have to solve that for XKB, too, so there is no way around this anyways.

One possible solution is to do symbol-versioning for this and provide 
compatibility wrappers for old symbols, with appropriate symbol-versions.
(like the glibc does it, for example)

I hope we can come up with some automatic or semi-automatic way to do this.

Symbol-versioning will provide ABI compatibility but not API compatibility.
Maybe that's acceptable: If the interface of an API function is buggy, the 
client-source-code will need be fixed anyways.
ABI-compatibility is important, of course, so that existing binaries continue 
to work after upgrading libxcb-xinput.

Cheers,

Chris




On 09/11/15 18:26, Gregor Riepl wrote:
> stretch is currently lacking a package for kde-config-tablet, as wacomtablet
> is still being ported to KF5. I tried building the package from git, but was
> hit by a missing xcb-xinit.
>
> Please add --enable-xinput to the libxcb build settings and create
> libxcb-xinput and libxcb-xinput-dev packages.
>
> Thank you!
> ___
> Xcb mailing list
> x...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb

Bug#798786: [libpam-kwallet5] kwalletd5 started by libpam-kwallet5 is not used by kwalletmanager5

[Rahul Amaram]

Package: libpam-kwallet5
Version: 5.4.0-1
Severity: grave

--- Please enter the report below this line. ---

After installing the libpam-kwallet5 package, when I login via SDDM, a 
process such as below is started.


Konsole outpu rahul12635 12634  0 22:08 ?00:00:00 
/usr/bin/kwalletd5 --pam-login 17 27


Now when I start kwalletmanager, a new kwalletd5 process is created.

Konsole output rahul12806 1  0 22:08 ?00:00:04 
/usr/bin/kwalletd5


instead of it connecting to the already started kwalletd5 process.

Also, when I logout, the initial kwalletd5 process launched by pam is 
not terminated and becomes a zombie process. So, eventual logins ends up 
with multiple such processes.


Konsole output rahul 4346 1  0 21:17 ?00:00:00 
/usr/bin/kwalletd5 --pam-login 17 25
rahul 9801 1  0 21:52 ?00:00:00 /usr/bin/kwalletd5 
--pam-login 17 21
rahul11679 1  0 22:03 ?00:00:00 /usr/bin/kwalletd5 
--pam-login 17 25
rahul12180 1  0 22:05 ?00:00:00 /usr/bin/kwalletd5 
--pam-login 17 26



--- System information. ---
Architecture: amd64
Kernel: Linux 4.1.0-2-amd64

Debian Release: stretch/sid
500 trusty ppa.launchpad.net
500 stable dl.google.com
500 stable deb.opera.com
500 oldstable packages.x2go.org
500 all liveusb.info
1000 testing security.debian.org
1000 testing httpredir.debian.org

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

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#785989: cwiid: diff for NMU version 0.6.00+svn201-3.2

[Luca Falavigna]

Control: tags 785989 + patch
Control: tags 785989 + pending

Dear maintainer,

I've prepared an NMU for cwiid (versioned as 0.6.00+svn201-3.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru cwiid-0.6.00+svn201/debian/changelog cwiid-0.6.00+svn201/debian/changelog
--- cwiid-0.6.00+svn201/debian/changelog	2014-02-16 08:46:48.0 +0100
+++ cwiid-0.6.00+svn201/debian/changelog	2015-09-12 18:36:25.0 +0200
@@ -1,3 +1,10 @@
+cwiid (0.6.00+svn201-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to dh_python2 (Closes: #785989).
+
+ -- Luca Falavigna   Sat, 12 Sep 2015 18:35:59 +0200
+
 cwiid (0.6.00+svn201-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cwiid-0.6.00+svn201/debian/control cwiid-0.6.00+svn201/debian/control
--- cwiid-0.6.00+svn201/debian/control	2014-02-16 08:45:51.0 +0100
+++ cwiid-0.6.00+svn201/debian/control	2015-09-12 18:35:33.0 +0200
@@ -2,7 +2,6 @@
 Section: utils
 Priority: extra
 Maintainer: Romain Beauxis 
-XS-Python-Version: all
 Build-Depends: cdbs (>= 0.4.85~),
  debhelper (>= 7.0.1),
  dh-buildinfo,
@@ -11,7 +10,7 @@
  autoconf,
  quilt,
  patchutils (>= 0.2.25),
-   python-all-dev, python, python-support, 
+   python-all-dev, python, dh-python, 
libbluetooth-dev, libgtk2.0-dev, flex, bison
 Standards-Version: 3.9.2
 Homepage: http://abstrakraft.org/cwiid/
@@ -19,8 +18,6 @@
 Package: python-cwiid
 Architecture: any
 Depends: ${python:Depends}, ${shlibs:Depends}, libcwiid1 (>= ${binary:Version}), ${misc:Depends}
-XB-Python-Version: ${python:Versions}
-Provides: ${python:Provides}
 Section: python
 Description: library to interface with the wiimote
  CWiid is a working userspace driver along with various
diff -Nru cwiid-0.6.00+svn201/debian/control.in cwiid-0.6.00+svn201/debian/control.in
--- cwiid-0.6.00+svn201/debian/control.in	2011-04-24 00:27:34.0 +0200
+++ cwiid-0.6.00+svn201/debian/control.in	2015-09-12 18:34:54.0 +0200
@@ -2,9 +2,8 @@
 Section: utils
 Priority: extra
 Maintainer: Romain Beauxis 
-XS-Python-Version: all
 Build-Depends: @cdbs@, 
-   python-all-dev, python, python-support, 
+   python-all-dev, python, dh-support, 
libbluetooth-dev, libgtk2.0-dev, flex, bison
 Standards-Version: 3.9.2
 Homepage: http://abstrakraft.org/cwiid/
@@ -12,8 +11,6 @@
 Package: python-cwiid
 Architecture: any
 Depends: ${python:Depends}, ${shlibs:Depends}, libcwiid1 (>= ${binary:Version}), ${misc:Depends}
-XB-Python-Version: ${python:Versions}
-Provides: ${python:Provides}
 Section: python
 Description: library to interface with the wiimote
  CWiid is a working userspace driver along with various
diff -Nru cwiid-0.6.00+svn201/debian/rules cwiid-0.6.00+svn201/debian/rules
--- cwiid-0.6.00+svn201/debian/rules	2014-02-16 08:45:51.0 +0100
+++ cwiid-0.6.00+svn201/debian/rules	2015-09-12 18:35:22.0 +0200
@@ -25,7 +25,7 @@
 #LDFLAGS := -Wl,--as-needed -lbluetooth -lrt
 
 binary-install/python-cwiid::
-	dh_pysupport -ppython-cwiid
+	dh_python2 -ppython-cwiid
 
 configure/lswm::
 	mkdir -p $(CURDIR)/debian/tmp/usr/bin

Bug#785986: connectomeviewer: diff for NMU version 2.1.0-1.1

[Luca Falavigna]

Control: tags 785986 + patch
Control: tags 785986 + pending

Dear maintainer,

I've prepared an NMU for connectomeviewer (versioned as 2.1.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru connectomeviewer-2.1.0/debian/changelog connectomeviewer-2.1.0/debian/changelog
--- connectomeviewer-2.1.0/debian/changelog	2012-05-03 17:47:08.0 +0200
+++ connectomeviewer-2.1.0/debian/changelog	2015-09-12 18:29:55.0 +0200
@@ -1,3 +1,10 @@
+connectomeviewer (2.1.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to dh_python2 (Closes: #785986).
+
+ -- Luca Falavigna   Sat, 12 Sep 2015 18:29:30 +0200
+
 connectomeviewer (2.1.0-1) unstable; urgency=low
 
   * Namespace transition for Enthought Packages
diff -Nru connectomeviewer-2.1.0/debian/control connectomeviewer-2.1.0/debian/control
--- connectomeviewer-2.1.0/debian/control	2012-05-03 17:47:08.0 +0200
+++ connectomeviewer-2.1.0/debian/control	2015-09-12 18:28:30.0 +0200
@@ -2,12 +2,13 @@
 Section: python
 Priority: extra
 Maintainer: Stephan Gerhard 
-Build-Depends: debhelper (>= 7.2.18), python-all (>= 2.6), python-support,
+Build-Depends: debhelper (>= 7.2.18), python-all (>= 2.6), dh-python,
 			   python-numpy (>= 1.3.0), python-setuptools, python-traits (>= 4)
 Standards-Version: 3.9.2
 Homepage: http://www.connectomeviewer.org
 Vcs-Git: git://github.com/LTS5/connectomeviewer.git
 Vcs-Browser: http://github.com/LTS5/connectomeviewer
+X-Python-Version: >= 2.6
 
 Package: connectomeviewer
 Architecture: all
diff -Nru connectomeviewer-2.1.0/debian/pyversions connectomeviewer-2.1.0/debian/pyversions
--- connectomeviewer-2.1.0/debian/pyversions	2012-05-03 17:47:08.0 +0200
+++ connectomeviewer-2.1.0/debian/pyversions	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-2.6-
\ No newline at end of file
diff -Nru connectomeviewer-2.1.0/debian/rules connectomeviewer-2.1.0/debian/rules
--- connectomeviewer-2.1.0/debian/rules	2012-05-03 17:47:08.0 +0200
+++ connectomeviewer-2.1.0/debian/rules	2015-09-12 18:27:13.0 +0200
@@ -2,7 +2,7 @@
 # -*- makefile -*-
 
 %:
-	dh $@
+	dh $@ --with python2
 
 override_dh_auto_clean:
 	dh_auto_clean

Bug#785992: couchapp: diff for NMU version 1.0.1+git20140213+dfsg1-1.1

[Luca Falavigna]

Control: tags 785992 + patch

Dear maintainer,

I've prepared an NMU for couchapp (versioned as 1.0.1+git20140213+dfsg1-1.1). 
The diff
is attached to this message.

Regards.
diff -Nru couchapp-1.0.1+git20140213+dfsg1/debian/changelog couchapp-1.0.1+git20140213+dfsg1/debian/changelog
--- couchapp-1.0.1+git20140213+dfsg1/debian/changelog	2014-04-15 22:57:28.0 +0200
+++ couchapp-1.0.1+git20140213+dfsg1/debian/changelog	2015-09-12 18:41:00.0 +0200
@@ -1,3 +1,10 @@
+couchapp (1.0.1+git20140213+dfsg1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove useless python-support build-dependency (Closes: #785992).
+
+ -- Luca Falavigna   Sat, 12 Sep 2015 18:40:23 +0200
+
 couchapp (1.0.1+git20140213+dfsg1-1) unstable; urgency=medium
 
   * Initial release. (Closes: #735479).
diff -Nru couchapp-1.0.1+git20140213+dfsg1/debian/control couchapp-1.0.1+git20140213+dfsg1/debian/control
--- couchapp-1.0.1+git20140213+dfsg1/debian/control	2014-05-12 16:18:43.0 +0200
+++ couchapp-1.0.1+git20140213+dfsg1/debian/control	2015-09-12 18:39:55.0 +0200
@@ -10,7 +10,7 @@
python-nose-testconfig,
python-restkit,
python-setuptools,
-   python-support,
+   dh-python,
python-unittest2
 Standards-Version: 3.9.5
 Homepage: http://couchapp.org/

Bug#796798: perl: FTBFS on kfreebsd-*: t/op/stat.t failure

[Niko Tyni]

On Thu, Sep 03, 2015 at 10:52:20PM +0100, Dominic Hargreaves wrote:
> On Mon, Aug 24, 2015 at 07:15:19PM +0300, Niko Tyni wrote:
> > Package: perl
> > Version: 5.22.0-3
> > Severity: important
> > X-Debbugs-Cc: kfreebsd-i...@buildd.debian.org, 
> > kfreebsd-am...@buildd.debian.org
> > 
> > This package failed to build on kfreebsd-amd64 and kfreebsd-i386:
> > 
> >   # Failed test 9 - hard link ctime != mtime at op/stat.t line 147
> >   # it should not be "1440284403"
> >   # but it is.
> >   # Check if you are on a tmpfs of some sort.  Building in /tmp sometimes
> >   # has this problem.  Building on the ClearCase VOBS filesystem may also
> >   # cause this failure.
> >   #
> >   # Darwin's UFS doesn't have a ctime concept, and thus is expected to fail
> >   # this test.
> >   t/op/stat . FAILED at 
> > test 9

> > I see the buildds are now running kernel 10.1-0 while the earlier
> > builds were on 9.0-2.
> > 
> > @buildd admins: any ideas? Are there known issues with ctime in
> > /tmp on the buildds?
> 
> I tested on falla, and found that this is not specific to perl 5.22,
> so adjusting metadata accordingly. It's also not specific to the schroot
> environment, at least on the buildds; the same test fails outside the
> chroot.

The kfreebsd builds failed again with 5.22.0-4 because of this issue.

I'm taking the debian-bsd list into the loop. Could somebody please look
into this?
-- 
Niko Tyni   nt...@debian.org

Bug#798607: Patch to debian/clean

[Colin Watson]

Control: tag -1 pending

On Fri, Sep 11, 2015 at 11:56:44AM -0700, Linn Crosetto wrote:
> Here is a patch to debian/clean. I avoided wildcards for some files to be
> consistent with autogen.sh.

Lovely, thanks.  Applied.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#793161: tangerine-icon-theme: debian/clean-up.sh runs processes in background

[Andreas Beckmann]

Followup-For: Bug #793161
Control: tag -1 patch pending

Hi,

I just uploaded a NMU to delayed/10 that fixes this bug. Please let me
know if I should delay it longer.


Andreas
diff -u tangerine-icon-theme-0.26.debian/debian/changelog tangerine-icon-theme-0.26.debian/debian/changelog
--- tangerine-icon-theme-0.26.debian/debian/changelog
+++ tangerine-icon-theme-0.26.debian/debian/changelog
@@ -1,3 +1,10 @@
+tangerine-icon-theme (0.26.debian-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/cleanup.sh: Do not run processes in background.  (Closes: #793161)
+
+ -- Andreas Beckmann   Sat, 12 Sep 2015 18:26:08 +0200
+
 tangerine-icon-theme (0.26.debian-3) unstable; urgency=high
 
   * Use "libmagickcore-dev | libmagick9-dev" as the imagemagick build-dep,
diff -u tangerine-icon-theme-0.26.debian/debian/clean-up.sh tangerine-icon-theme-0.26.debian/debian/clean-up.sh
--- tangerine-icon-theme-0.26.debian/debian/clean-up.sh
+++ tangerine-icon-theme-0.26.debian/debian/clean-up.sh
@@ -3,13 +3,13 @@
 # Manually clean-up 
-find ./ -name Makefile.in* | xargs rm -f &>/dev/null
-rm -f ./po/Makefile.in.in &>/dev/null
-rm -f ./configure &>/dev/null
-rm -f ./intltool-update.in &>/dev/null
-rm -f ./intltool-merge.in &>/dev/null
-rm -r ./intltool-extract.in &>/dev/null
-rm -f ./config.guess &>/dev/null
-rm -f ./config.sub &>/dev/null
-rm -f ./install-sh &>/dev/null
-rm -f ./missing &>/dev/null
-rm -f ./aclocal.m4 &>/dev/null
+find ./ -name Makefile.in* | xargs rm -f >/dev/null
+rm -f ./po/Makefile.in.in >/dev/null
+rm -f ./configure >/dev/null
+rm -f ./intltool-update.in >/dev/null
+rm -f ./intltool-merge.in >/dev/null
+rm -r ./intltool-extract.in >/dev/null
+rm -f ./config.guess >/dev/null
+rm -f ./config.sub >/dev/null
+rm -f ./install-sh >/dev/null
+rm -f ./missing >/dev/null
+rm -f ./aclocal.m4 >/dev/null
 
diff -u tangerine-icon-theme-0.26.debian/debian/control tangerine-icon-theme-0.26.debian/debian/control
--- tangerine-icon-theme-0.26.debian/debian/control
+++ tangerine-icon-theme-0.26.debian/debian/control
@@ -1,3 +1,7 @@
+# This file is autogenerated. DO NOT EDIT!
+# 
+# Modifications should be made to debian/control.in instead.
+# This file is regenerated automatically in the clean target.
 Source: tangerine-icon-theme
 Section: non-free/x11
 Priority: optional

Bug#798785: ITP: ipython-genutils -- IPython vestigial utilities

[Julien Puydt]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Owner: Julien Puydt 

* Package name: ipython-genutils
  Version : 0.1.0
  Upstream Author : IPython Development Team
* URL : https://github.com/ipython/ipython_genutils
* License : BSD-3-clause
  Programming Lang: Python
  Description : IPython vestigial utilities
 Contains some utilities shared by the IPython and Jupyter projects.
 .
 No new code should be written against those utilities.

Although that code is (as made clear in the long description) not
supposed to be used in new code, there is still code using it, and
it's not going away soon, so it makes sense to package it (I asked
upstream!).

It is for example a dependency of 'traitlets', which is a dependency
of the whole IPython/Jupyter software stack.

Thanks,

Snark on #debian-python

Bug#792774: RFS: filters/2.54 [ITA]

[Marius Gavrilescu]

Jakub Wilk  writes:

> I'm sorry, but I can't dedicate any more time to this package. I hope
> you'll find another sponsor soon!

No problem. Thanks for your help!
-- 
Marius Gavrilescu


signature.asc
Description: PGP signature

Bug#793062: human-icon-theme: debian/clean-up.sh runs processes in background

[Andreas Beckmann]

Followup-For: Bug #793062
Control: tag -1 patch pending

Hi,

I just uploaded a NMU to delayed/10 that fixes this bug. Please let me
know if I should delay it longer.


Andreas
diff -Nru human-icon-theme-0.28.debian/debian/changelog human-icon-theme-0.28.debian/debian/changelog
--- human-icon-theme-0.28.debian/debian/changelog	2011-10-19 22:26:39.0 +0200
+++ human-icon-theme-0.28.debian/debian/changelog	2015-09-12 18:05:10.0 +0200
@@ -1,3 +1,10 @@
+human-icon-theme (0.28.debian-3.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/cleanup.sh: Do not run processes in background.  (Closes: #793062)
+
+ -- Andreas Beckmann   Sat, 12 Sep 2015 18:05:10 +0200
+
 human-icon-theme (0.28.debian-3.3) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru human-icon-theme-0.28.debian/debian/clean-up.sh human-icon-theme-0.28.debian/debian/clean-up.sh
--- human-icon-theme-0.28.debian/debian/clean-up.sh	2011-03-12 18:51:38.0 +0100
+++ human-icon-theme-0.28.debian/debian/clean-up.sh	2015-09-12 18:01:36.0 +0200
@@ -1,15 +1,15 @@
 #!/bin/sh
 
 # Manually clean-up 
-find ./ -name Makefile.in* | xargs rm -f &>/dev/null
-rm -f ./po/Makefile.in.in &>/dev/null
-rm -f ./configure &>/dev/null
-rm -f ./intltool-update.in &>/dev/null
-rm -f ./intltool-merge.in &>/dev/null
-rm -r ./intltool-extract.in &>/dev/null
-rm -f ./config.guess &>/dev/null
-rm -f ./config.sub &>/dev/null
-rm -f ./install-sh &>/dev/null
-rm -f ./missing &>/dev/null
-rm -f ./aclocal.m4 &>/dev/null
+find ./ -name Makefile.in* | xargs rm -f >/dev/null
+rm -f ./po/Makefile.in.in >/dev/null
+rm -f ./configure >/dev/null
+rm -f ./intltool-update.in >/dev/null
+rm -f ./intltool-merge.in >/dev/null
+rm -r ./intltool-extract.in >/dev/null
+rm -f ./config.guess >/dev/null
+rm -f ./config.sub >/dev/null
+rm -f ./install-sh >/dev/null
+rm -f ./missing >/dev/null
+rm -f ./aclocal.m4 >/dev/null
 
diff -Nru human-icon-theme-0.28.debian/debian/control human-icon-theme-0.28.debian/debian/control
--- human-icon-theme-0.28.debian/debian/control	2011-10-19 22:27:51.0 +0200
+++ human-icon-theme-0.28.debian/debian/control	2015-09-12 18:12:03.0 +0200
@@ -2,7 +2,6 @@
 # 
 # Modifications should be made to debian/control.in instead.
 # This file is regenerated automatically in the clean target.
-
 Source: human-icon-theme
 Section: non-free/x11
 Priority: optional

Bug#798784: Incompatible with systemd 226?

[Chris Lamb]

Package: docker.io
Version: 1.7.1~dfsg1-1
Severity: imporrr

Hi,

Looks like docker doesn't like systemd 226-1:

 Error response from daemon: Cannot start container
 b4ce284ca1208d54cf465d7f901cf5734b7fdabd25670fefb51a8da100877166: [8]
 System error: open
 
/sys/fs/cgroup/cpu,cpuacct/init.scope/system.slice/docker-b4ce284ca1208d54cf465d7f901cf5734b7fdabd25670fefb51a8da100877166.scope/cpu.shares:
 no such file or directory

Haven't looked in depth, but:

 https://github.com/docker/docker/issues/16256#issuecomment-139759855


Regards,

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

Bug#798783: [kwalletmanager] Support for GPG encrypted wallets

[Frederic Tronel]

Package: kwalletmanager
Version: 4:15.08.0-1
Severity: normal

--- Please enter the report below this line. ---

The KF5 version of kwalletmanager does not allow to create a GPG encrypted 
wallet. This feature was present in the KDE4 version of kwalletmanager.
This is may be due to an missing flag during the compilation of kwalletmanager 
?

Frederic

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.1.0-2-amd64

Debian Release: stretch/sid
  500 unstablewww.deb-multimedia.org 
  500 unstableftp.fr.debian.org 
  500 stable  dl.google.com 

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

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#798749: pu: package monit/1:5.9-1+jessie1

[Sergey B Kirpichev]

On Sat, Sep 12, 2015 at 04:56:19PM +0100, Adam D. Barratt wrote:
> Please don't use -quiet@ when replying to release.debian.org bugs.
> There's no good reason for the reply not to be sent to debian-release;
> in fact, not doing so is actively harmful.

Sorry.  Ok.

> I read that, and I know what "automatically updated with yacc" means,
> thank you. You appear to have ignored my pointing out that the package
> doesn't build-depend on anything providing yacc or bison, and that
> builds on the buildds _don't_ perform such updates due to the packages
> not being installed in the build environment.
> How are the updates managing to get performed in your uploads when a
> clean build won't have yacc available?

Usually there is no need to run yacc while building
the package: upstream maintainers provide tarball together
with yacc-generated stuff.  In this case, I did same.

I hope, this is clear.

Technically, it's possible to add a build-dependency on
yacc (instead of changing src/y.tab.c etc), not sure
if this is ok for stable upload.

Bug#792774: RFS: filters/2.54 [ITA]

[Jakub Wilk]

* Marius Gavrilescu , 2015-08-31, 17:02:

Er, so sobody did a QA(?) upload of filters_2.54:
https://packages.qa.debian.org/f/filters/news/20150830T230043Z.html

Marius, was this upload ACKed by you?


It wasn't. The uploader (Joey Hess) is the previous maintainer and the 
upstream.


Well, Joey is not a DD, so he couldn't upload it himself...


What do I do now?


The first step is to complain to the person who uploaded the package. 
who-uploads(1) says:


2.54 to unstable: Santiago Vila  on Sun, 30 Aug 2015 
23:00:43 +


I'm sorry, but I can't dedicate any more time to this package. I hope 
you'll find another sponsor soon!


--
Jakub Wilk

Bug#313034: aptitude: package version when logging installation

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi all,

I commited a change for this, to show version information for most
actions (install, remove, hold, reinstall, ...), not only upgrades and
downgrades.

It will be present in the next release, so marking this as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo