ian_bruce | 30 Sep 03:29 2014

Bug#763412: libjpeg-dev reinstalls over itself

Package: libjpeg-dev
Version: 1:1.3.1-3

Surely there is something wrong with this.

This can be repeated indefinitely; there's something wrong with the
version checking.

It would be nice if somebody would fix reportbug, so we could use that


# apt-get install libjpeg-dev
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
1 upgraded, 0 newly installed, 0 to remove and 876 not upgraded.
Need to get 0 B/48.3 kB of archives.
After this operation, 0 B of additional disk space will be used.
Reading changelogs... Done
(Reading database ... 233968 files and directories currently installed.)
Preparing to unpack .../libjpeg-dev_1%3a1.3.1-3_all.deb ...
Unpacking libjpeg-dev (1:1.3.1-3) over (1:1.3.1-3) ...

Matt Taggart | 30 Sep 03:06 2014

Bug#756275: testing pxe d-i in different cases


I did some testing with the daily build from 2014-09-29 which includes the 
changes KiBi committed for this bug.

1) unpacked daily case
wheezy server
unpacked daily tarball in foo/
ldlinux.c32 symlinux present
boot foo/pxelinux.0
everything works as expected

2) di-netboot-assistant daily case
wheezy server
di-netboot-install installed daily, which does
* moves debian-installer/amd64 to debian-installer/daily/amd64
* copies debian-installer/amd64/pxelinux.0 to debian-installer/pxelinux.0
* no ldlinux.c32 symlinux
boot debian-installer/pxelinux.0
gets 'Failed to load ldlinux.c32' (as expected)

3) chain wheezy to d-n-a daily case
wheezy server, syslinux-common 2:4.05+dfsg-6+deb7u1 installed
cp /usr/lib/syslinux/pxelinux.0 tftpboot/
have a pxelinux.cfg/default that also contains:
  INCLUDE debian-installer/pxelinux.cfg/default
boot pxelinux.0, select daily-amd64
gets "::/debian-installer/daily/amd64/boot/screens/vesamenu.c32: not a 
COM32R image" (this is a known failure mixing 4.x with 6.x, see #759424)

(Continue reading)

Christoph Anton Mitterer | 30 Sep 02:50 2014

Bug#707186: network-manager: wireless reconnection doesn't work without stoping NM an killing nm-applet

retitle 707186 network-manager: wireless reconnection doesn't work without restarting NM


Sorry for not having provided further information (debug logs), bug I
somehow got distracted back then and forgot about this.
Even though it seems that there is no goal to properly integrate NM into
Debian, the requested information shall be found here (at the very end)

On Wed, 08 May 2013 04:16:41 +0200 Michael Biebl <biebl <at> debian.org>
>As a first advice, if you want to manage your wireless interface with
>NM, I would recommed *against* using /e/n/i and managed=true.
>ifupdown will still manage your wlan0-foo interface and having two
>network management systems handling the same interface is not going to
>work out well.

Well I still stick to the point that Debian's native (and working)
network management tool is ifupdown, which also means that it's
configuration is the native configuration which other packages/systems
shall integrate into.

Even when not using managed-mode, NM has far too many issues and bugs
which makes it unusable as a general replacement for ifupdown - and no
I'm not saying ifupdown is perfect (the syntax of (/e/n/interfaces is
actually ugly), and no, nothing of this criticism is agains you
(Continue reading)

jhcha54008 | 30 Sep 04:34 2014

Bug#763391: chfn and fakechroot


May this be related to #745082 ? (the patch of #742070 would be needed to)

JH Chatenet

ferseiti | 30 Sep 02:19 2014

Bug#730885: Debian BTS Bug #730885

Hello John,

I just stumbled onto the same error on ppc64el, and giving it a little search, I could find this:

Basically it says the problem is not in globus-common, since it is has been 'multiarched'.

It would certainly be easier if we could use pkg-config as suggested in the aforementioned bug report, but since we can't, I sent a patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763409.

Just thought it might be useful to you as well.

Michael Biebl | 30 Sep 02:18 2014

Bug#763411: systemctl reload openvpn.service fails under systemd

Package: openvpn
Version: 2.3.4-1
Severity: normal


/lib/systemd/system/openvpn.service contains

When I try to reload openvpn.service, I get:

# systemctl reload openvpn.service 
Failed to reload openvpn.service: Job type reload is not applicable for
unit openvpn.service.

The problem here is, that ExecReload= needs to be set explicitly for
services which support that.

I noticed, that openvpn.service is only a "helper" service to
restart/reload the openvpn <at> .service instances, which do support Reload.

Also, the ExecStop= line is not actually necessary, as this will be
defined by defined and only needs to be overwritten if the stop action
needs to do something special (which is not the case here).
So maybe what you want instead is something like this:


With that change, I can run systemctl reload openvpn.service and my
instanced services are reloaded.

But here I've stumbled into another issue: A systemctl reload
openvpn <at> <foo>.service kills the service:

# systemctl status openvpn <at> mypi.service
● openvpn <at> mypi.service - OpenVPN connection to mypi
   Loaded: loaded (/lib/systemd/system/openvpn <at> .service; disabled)
   Active: active (running) since Di 2014-09-30 02:16:53 CEST; 5s ago
  Process: 31269 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
  Process: 31544 ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10
--cd /etc/openvpn --config /etc/openvpn/%i.conf (code=exited, status=0/SUCCESS)
 Main PID: 31545 (openvpn)
   CGroup: /system.slice/system-openvpn.slice/openvpn <at> mypi.service
           └─31545 /usr/sbin/openvpn --daemon ovpn-mypi --status /run/openvpn/mypi.status 10 --cd
/etc/openvpn --config /etc/openvpn/mypi.conf

# systemctl reload openvpn <at> mypi.service
# systemctl status openvpn <at> mypi.service
● openvpn <at> mypi.service - OpenVPN connection to mypi
   Loaded: loaded (/lib/systemd/system/openvpn <at> .service; disabled)
   Active: failed (Result: exit-code) since Di 2014-09-30 02:17:30 CEST; 2s ago
  Process: 31652 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
  Process: 31544 ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10
--cd /etc/openvpn --config /etc/openvpn/%i.conf (code=exited, status=0/SUCCESS)
 Main PID: 31545 (code=exited, status=1/FAILURE)

Sep 30 02:17:30 pluto systemd[1]: openvpn <at> mypi.service: main process exited, code=exited, status=1/FAILURE
Sep 30 02:17:30 pluto systemd[1]: Unit openvpn <at> mypi.service entered failed state.

So maybe openvpn <at> .service doesn't actually support reload and should be
removed there? If not, this failure on reload should probably be tracked
as a separate issue.


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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.53
ii  initscripts            2.88dsf-53.4
ii  iproute2               3.16.0-2
ii  libc6                  2.19-11
ii  liblzo2-2              2.08-1
ii  libpam0g               1.1.8-3.1
ii  libpkcs11-helper1      1.11-2
ii  libssl1.0.0            1.0.1i-2

Versions of packages openvpn recommends:
pn  easy-rsa  <none>

Versions of packages openvpn suggests:
ii  openssl     1.0.1i-2
pn  resolvconf  <none>

-- Configuration Files:
/etc/default/openvpn changed [not included]

-- debconf information excluded


To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org

Filipus Klutiero | 30 Sep 02:18 2014

Bug#763410: [installation-guide] 4.3.1: "written directly a USB stick"

Package: installation-guide
Version: 20140916
Severity: minor
X-Debbugs-Cc: joeyh <at> debian.org

Section 4.3.1. Preparing a USB stick using a hybrid CD or DVD image starts with:
> Debian CD and DVD images can now be written directly a USB stick, which is a very easy way to make a bootable
USB stick.

A preposition such as "on" or "to" is missing between "directly" and "a".

By the way, my English is not native, but 4.3's introduction looks like it contains a Frenchism to me:
> You should be able to see to which device the USB stick was mapped by running the command dmesg after
inserting it.

Shouldn't "to which device the USB stick was mapped" read "which device the USB stick was mapped to"?


Filipus Klutiero

Fernando Seiti Furusato | 30 Sep 02:11 2014

Bug#763409: cctools: FTBFS on ppc64el -- globus_config.h: No such file or directory

Source: cctools
Severity: normal
Tags: patch
User: debian-powerpc <at> lists.debian.org
Usertags: ppc64el

Dear Maintainer,

The package cctools fails to build from source due to problems with detection of globus paths on ppc64el.
With the following error:

	In file included from /usr/include/globus/globus_common.h:55:0,
	                 from auth_globus.c:20:
	/usr/include/globus/globus_common_include.h:24:27: fatal error: globus_config.h: No such file or directory
	 #include "globus_config.h"
	compilation terminated.
	make[3]: *** [auth_globus.o] Error 1
	../../Makefile.rules:6: recipe for target 'auth_globus.o' failed

Full build log at:

As can be seen on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743059, according to
globus-common maintainer, this is not
an error in globus-common.
Since this pkg does not use pkg-config, the patch attached inserts a condition to configure so it will
include the necessary paths,
specifically for ppc64el, not affecting other architectures. I am not sure if this is the ideal, but it
works for our case.

Thanks and regards.


-- System Information:
Debian Release: jessie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 3.16-trunk-powerpc64le (SMP w/32 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Attachment (ppc64el.debdiff): text/x-diff, 2474 bytes
brian m. carlson | 30 Sep 02:07 2014

Bug#763408: chromium: does not display ECC certificate algorithms

Package: chromium
Version: 37.0.2062.120-2
Severity: minor

Chromium ships with ECC certificates[0], but when viewing the
Certificate Signature Algorithm or Subject Public Key Algorithm fields,
they are displayed as OIDs.  Presumably Chromium knows how to handle
these algorithms to perform cryptographic operations, so it should be
also able to display the algorithms in an appropriate human-readable
form.  The user would probably be interested to know that the more
secure SHA-384 hash algorithm is used here instead of, say, SHA-1.

Please consider adding this type of human-readable output.

[0] For example, the COMODO ECC Certificate Authority
-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.17-rc5-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

Versions of packages chromium depends on:
ii  chromium-inspector   37.0.2062.120-2
ii  gconf-service        3.2.6-3
ii  libasound2           1.0.28-1
ii  libc6                2.19-11
ii  libcairo2            1.12.16-5
ii  libcap2              1:2.24-6
ii  libcups2             1.7.5-2
ii  libdbus-1-3          1.8.8-1
ii  libexpat1            2.1.0-6
ii  libfontconfig1       2.11.0-6.1
ii  libfreetype6         2.5.2-2
ii  libgcc1              1:4.9.1-15
ii  libgconf-2-4         3.2.6-3
ii  libgdk-pixbuf2.0-0   2.30.8-1
ii  libglib2.0-0         2.42.0-1
ii  libgnome-keyring0    3.12.0-1
ii  libgtk2.0-0          2.24.24-1
ii  libharfbuzz0b        0.9.35-1
ii  libjpeg8             8d1-1
ii  libnspr4             2:4.10.7-1
ii  libnss3              2:3.17.1-1
ii  libpango-1.0-0       1.36.7-1
ii  libpangocairo-1.0-0  1.36.7-1
ii  libspeechd2          0.8-6
ii  libspeex1            1.2~rc1.2-1
ii  libstdc++6           4.9.1-15
ii  libudev1             215-5
ii  libx11-6             2:1.6.2-3
ii  libxcomposite1       1:0.4.4-1
ii  libxcursor1          1:1.1.14-1
ii  libxdamage1          1:1.1.4-2
ii  libxext6             2:1.3.2-1
ii  libxfixes3           1:5.0.1-2
ii  libxi6               2:1.7.4-1
ii  libxml2              2.9.1+dfsg1-4
ii  libxrandr2           2:1.4.2-1
ii  libxrender1          1:0.9.8-1
ii  libxslt1.1           1.1.28-2
ii  libxss1              1:1.2.2-1
ii  libxtst6             2:1.2.2-1
ii  xdg-utils            1.1.0~rc1+git20111210-7.1

chromium recommends no packages.

Versions of packages chromium suggests:
pn  chromium-l10n  <none>
pn  mozplugger     <none>

-- Configuration Files:
/etc/chromium/default changed [not included]

-- no debconf information


brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
herbert | 30 Sep 01:10 2014

Bug#763407: dash: dash should start using fnmatch(3) again

Package: dash
Version: 0.5.7-3
Severity: wishlist

AFAICS the current glibc has a working fnmatch(3) so we should
build dash with fnmatch enabled.

FWIW glob(3) is still broken:

-- System Information
Debian Release: 7.1
Kernel Version: Linux gondolin #5 SMP PREEMPT Tue Jan 18 12:20:04 EST 2011 i686 GNU/Linux

Versions of the packages dash depends on:
ii  debianutils                           4.3.2                              i386         Miscellaneous utilities specific to Debian
ii  dpkg                                  1.16.10                            i386         Debian package management system
libc6	Not installed or no info

GSR | 30 Sep 01:08 2014

Bug#763406: geeqie: Float window uses image window dimensions

Package: geeqie
Version: 1:1.2-2
Severity: important

Dear Maintainer,

After updating, it seems the saved state for the ile list window is
the same of the image window. Move or resize any of them, and in next
use they both will appear as the image one was when closing. This
worked fine in 1.1, each window was remembered correctly, all the
state X, Y, width and height. The worst is that the file list get all
the contents rearranged (if not hidden for lack of space) when the
size is too small.

Verified by looking at the config file, the values match perfectly
every time, whatever main_window has, appears for float_window:
        main_window.x = "267"
        main_window.y = "191"
        main_window.w = "200"
        main_window.h = "70"

        float_window.x = "267"
        float_window.y = "191"
        float_window.w = "200"
        float_window.h = "70"

Please check what went wrong with the 1.1 to 1.2 changes, thanks.

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

Kernel: Linux 3.11-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages geeqie depends on:
ii  geeqie-common        1:1.2-2
ii  libatk1.0-0          2.8.0-2
ii  libc6                2.19-9
ii  libcairo2            1.12.14-4
ii  libexiv2-13          0.24-4
ii  libfontconfig1       2.11.0-1
ii  libfreetype6         2.4.9-1.1
ii  libgcc1              1:4.8.1-8
ii  libgdk-pixbuf2.0-0   2.28.2-1
ii  libglib2.0-0         2.40.0-2
ii  libgtk2.0-0          2.24.18-1
ii  libjpeg62            1:1.3.1-3
ii  liblcms2-2           2.2+git20110628-2.2
ii  liblircclient0       0.9.0~pre1-1
ii  liblua5.1-0          5.1.5-7
ii  libpango-1.0-0       1.36.3-1
ii  libpangocairo-1.0-0  1.36.3-1
ii  libpangoft2-1.0-0    1.36.3-1
ii  libstdc++6           4.9.1-12
ii  libtiff5             4.0.3-5

Versions of packages geeqie recommends:
pn  exiftran         <none>
pn  exiv2            <none>
ii  imagemagick      8:
ii  librsvg2-common  2.36.4-2
pn  lpr              <none>
pn  ufraw-batch      <none>
pn  zenity           <none>

Versions of packages geeqie suggests:
pn  geeqie-dbg     <none>
ii  gimp           2.6.12-1+b2
ii  libjpeg-progs  8d-1
pn  ufraw          <none>
pn  xpaint         <none>

-- no debconf information