Bug#741573: Two menu systems

[Russ Allbery]

Keith Packard  writes:

> Thanks for pointing that out. desktop2menu is a perl script which uses
> the published perl bindings for .desktop files and has a start at a
> mapping from .desktop Categories to menu sections. It also doesn't
> correctly handle generating .xpm files for the icons.

> I think this does demonstrate that we could, with little effort, allow
> applications to ship only .desktop files and have the menu package take
> those and generate menu files for other systems.

Isn't this the tool that Sune wrote and mentioned earlier in this bug as
being incomplete and primarily useful for generating a template that
requires subsequent work?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#45

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752045: [RFR] templates://dictionaries-common/{dictionaries-common.templates}

[victory]

On Tue, 1 Jul 2014 07:40:45 +0200
Christian PERRIER wrote:

> Template: dictionaries-common/invalid_debconf_value
>  To fix this error, reinstall (or install) the package that provides
>  the missing value.

maybe it should be ${value}?

>  renaming (e.g., wenglish-> wamerican). In this case it is harmless and

wenglish -> wamerican?


-- 
victory


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753373: libreoffice: Please migrate away from gcc-4.7 in Jessie if possible

[Niels Thykier]

On 2014-07-01 07:32, Rene Engelhard wrote:
> reassign 753373 libreoffice
> forcemerge 748004 753373
> thanks
> 
> Hi,
> 
> On Tue, Jul 01, 2014 at 07:17:53AM +0200, Niels Thykier wrote:
>> Would it be feasible for libreoffice to migrate away from gcc-4.7 in
>> Jessie?
> 
> LibreOffice does NOT use gcc-4.7. (It does use cpp-4.7, though)
> 

I meant the gcc-4.7 as in the source package (cpp-4.7 is built from
gcc-4.7). Sorry for the confusing (and the duplicate bug as well).

>> Currently, only libreoffice and grub2 maintains a dependency against
>> it in testing.  We are hoping that we might be able to remove gcc-4.7
>> for Jessie.
> 
> See http://bugs.debian.org/748004.
> 
> I didn't receive a actual answer from doko on whether cpp-4.7 was also going
> to go away.
> 
> I can package ucpp but it needs to go through NEW. Or I use a internal ucpp 
> copy...
> 
> Regards,
> 
> Rene
> 

Reducing src:gcc-4.7 to just building cpp-4.7 sounds like a reasonable
alternative to removing src:gcc-4.7.

~Niels


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752283: [Pkg-acpi-devel] Bug#752283: downgrade to acpi-support* 0.141-2 fixed suspend

[Gijs Hillenius]

On 28 Jun 2014, Michael Meskes wrote:

>> I updated acpi-support and acpi-fakekey to 0.14-3, but "hold" (held)
>> acpi-support-base, and suspend @ lid continues to work. Another clue
>> that in my case the culprit is in acpi-support-base.
>
> Could you please update acpi-support-base to 0.141-3 but keep
> /usr/share/acpi-support/policy-funcs from 0.141-2? That'll help us
> figuring out if this file is the buggy one.
>

Hello Michael!

Thanks for the update of acpi-support and acpi-support-base to
0.141-4.

Unfortunately, this breaks suspend at lid once again. The previous fix
(using 0.141-3 but copying /usr/share/acpi-support/policy-funcs from
0.141-2 does now not work either -- that is, the suspend light on the
top of the laptop starts blinking, but suspend only happens "later" --
when the lid is open.


I'll investigate later, but for now will roll back to 0.141-3 with
/usr/share/acpi-support/policy-funcs from 0.141-2


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752045: [RFR] templates://dictionaries-common/{dictionaries-common.templates}

[Christian PERRIER]

Please find, for review, the debconf templates and packages descriptions for 
the dictionaries-common source package.

This review will last from Tuesday, July 01, 2014 to Friday, July 11, 2014.

Please send reviews as unified diffs (diff -u) against the original
files. Comments about your proposed changes will be appreciated.

Your review should be sent as an answer to this mail.

When appropriate, I will send intermediate requests for review, with
"[RFRn]" (n>=2) as a subject tag.

When we will reach a consensus, I send a "Last Chance For
Comments" mail with "[LCFC]" as a subject tag.

Finally, a summary will be sent to the review bug report,
and a mail will be sent to this list with "[BTS]" as a subject tag.


Template: dictionaries-common/debconf_database_corruption
Type: error
#flag:translate!:3
Description: Possible debconf database corruption
 The configuration question for "${question}" is empty but some
 elements are installed for the "${class}" class:
 .
  Choices_dictcom: "${installed_elements}"
  Choices_debconf: "${choices_value}"
  Owners/error: "${shared_owners}"
 .
 This can be related to a corruption of the "debconf" database.
 See "/usr/share/doc/dictionaries-common/README.problems", section
 "Debconf database corruption".
 .
 In this case, running "/usr/share/debconf/fix_db.pl" can help to put
 the debconf database in a consistent state.
 .
 Some questions are likely to be asked after this message in order to
 try leaving the dictionaries system in a (provisionally) working state.

Template: dictionaries-common/invalid_debconf_value
Type: error
_Description: Invalid configuration setting for ${value}
 An invalid value has been found for a configuration setting for
 dictionaries-common. It does not correspond to any installed package
 in the system.
 .
 That is usually caused by problems at some time during packages
 installation, where the package providing [${value}] was selected for
 installation but finally not installed because of errors in other
 packages.
 .
 To fix this error, reinstall (or install) the package that provides
 the missing value. Then, if you don't want this package on
 your system, remove it, which will also remove its configuration
 settings in the "debconf" database. A choices menu
 will be shown after this message in order to leave the system in a
 working state until you fix the problem.
 .
 This error message can also appear during ispell dictionary or wordlist
 renaming (e.g., wenglish-> wamerican). In this case it is harmless and
 everything will be fixed after you select your default in the menu(s)
 shown after this message.

Template: dictionaries-common/default-ispell
Type: select
Choices-C: ${choices}, Manual symlink setting
__Choices: ${echoices}, Manual symlink setting
_Description: System default ispell dictionary:
 Please indicate which dictionary ispell should use as system-wide
 default when no other spell-checking dictionary is specified.
 .
 This sets up the /usr/lib/ispell/default.aff and
 /usr/lib/ispell/default.hash symlinks, as well as ispell's global
 ispell-wrapper and Emacs defaults.
 .
 Use "Manual symlink setting" if you want to handle the symlinks
 yourself. In this case ispell will have no global ispell-wrapper or
 Emacs defaults.
 .
 The default ispell dictionary can be changed at any time by running
 "select-default-ispell".

Template: dictionaries-common/default-wordlist
Type: select
Choices-C: ${choices}, Manual symlink setting
#flag:translate!:1
__Choices: ${echoices}, Manual symlink setting
_Description: System default wordlist:
 Please indicate which wordlist the "/usr/share/dict/words" symlink
 should point to. This will provide a simple list of dictionary words
 for basic spell-checking and word searches. Use "Manual symlink
 setting" if you want to handle this symlink yourself.
 .
 The default wordlist can be changed at any time by running
 "select-default-wordlist".

Template: dictionaries-common/move_old_usr_dict
Type: boolean
Default: true
_Description: Move non-FHS stuff under /usr/dict to /usr/dict-pre-FHS?
 Some files (instead of symbolic links) have been found in
 /usr/dict. According to the FHS, such files should be placed in
 /usr/share/dict. Everything under /usr/dict can be moved to /usr/dict-pre-FHS
 and a symbolic link named /usr/dict can be created, pointing to
 /usr/share/dict.
 .
 Although no current package uses that obsolete /usr/dict location,
 not having that symlink may break some of your old applications that used
 it, so you are encouraged to let the files be moved and the link be set up.

Template: dictionaries-common/old_wordlist_link
Type: boolean
Default: true
_Description: Remove obsolete /etc/dictionary link?
 There is a /etc/dictionary link on the system. This is obsolete and no
 longer means anything. This link should be removed.
 .
 You will be asked to explicitly select the default wordlist during
 installation of wordlist packages. You can change your selection at any
 time by running "select

Bug#753375: src:e2fsprogs: FTCBFS for any arch: fails to pass includes to BUILD_CC

[Helmut Grohne]

Package: src:e2fsprogs
Version: 1.42.10-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Dear Maintainer,

e2fsprogs currently fails to cross-build for any architecture, because
includes are not passed to BUILD_CC.

Tail of the build log:
| dh_testdir
| /usr/bin/make -C /tmp/buildd/e2fsprogs/e2fsprogs-1.42.10/debian/BUILD-STD V=1 
all
| make[1]: Entering directory 
'/tmp/buildd/e2fsprogs/e2fsprogs-1.42.10/debian/BUILD-STD'
| cd ./util ; /usr/bin/make subst
| make[2]: Entering directory 
'/tmp/buildd/e2fsprogs/e2fsprogs-1.42.10/debian/BUILD-STD/util'
| echo "/* fake dirpaths.h for config.h */" > dirpaths.h
| gcc -c  /tmp/buildd/e2fsprogs/e2fsprogs-1.42.10/util/subst.c -o subst.o
| /tmp/buildd/e2fsprogs/e2fsprogs-1.42.10/util/subst.c:8:20: fatal error: 
config.h: No such file or directory
|  #include "config.h"
| ^
| compilation terminated.
| Makefile:306: recipe for target 'subst.o' failed
| make[2]: *** [subst.o] Error 1
| make[2]: Leaving directory 
'/tmp/buildd/e2fsprogs/e2fsprogs-1.42.10/debian/BUILD-STD/util'
| Makefile:163: recipe for target 'util/subst' failed
| make[1]: *** [util/subst] Error 2
| make[1]: Leaving directory 
'/tmp/buildd/e2fsprogs/e2fsprogs-1.42.10/debian/BUILD-STD'
| debian/rules:355: recipe for target 'debian/stampdir/build-std-stamp' failed
| make: *** [debian/stampdir/build-std-stamp] Error 2
| dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

You can see, that it first tries to compile subst.c with $BUILD_CC, but
does not pass any options beyond -c and -o. Since the config.h header
does not reside in the same directory as subst.c, compilation fails. It
appears that $BUILD_CFLAGS is empty for some reason. In fact, the reason
is revealed in configure where it is explicitly set to empty when
cross-compiling. Rather $INCLUDES should be preserved. When adding
$INCLUDES to $BUILD_CFLAGS, e2fsprogs succeeds to build. Please consider
using the attached patch.

Helmut
diff -Nru e2fsprogs-1.42.10/debian/changelog e2fsprogs-1.42.10/debian/changelog
--- e2fsprogs-1.42.10/debian/changelog  2014-06-21 12:58:14.0 +0200
+++ e2fsprogs-1.42.10/debian/changelog  2014-06-30 18:36:03.0 +0200
@@ -1,3 +1,10 @@
+e2fsprogs (1.42.10-1.2) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Pass $INCLUDES to BUILD_CFLAGS even when cross-compiling. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 30 Jun 2014 18:35:39 +0200
+
 e2fsprogs (1.42.10-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
e2fsprogs-1.42.10/debian/patches/0002-cross-compile-cflags-includes.patch 
e2fsprogs-1.42.10/debian/patches/0002-cross-compile-cflags-includes.patch
--- e2fsprogs-1.42.10/debian/patches/0002-cross-compile-cflags-includes.patch   
1970-01-01 01:00:00.0 +0100
+++ e2fsprogs-1.42.10/debian/patches/0002-cross-compile-cflags-includes.patch   
2014-06-30 18:40:02.0 +0200
@@ -0,0 +1,19 @@
+Subject: need to add includes to BUILD_CFLAGS for cross-building
+Author: Helmut Grohne 
+Last-Modified: 2014-06-30
+
+Otherwise compiling util/subst.c fails because config.h cannot be found.
+
+Index: e2fsprogs-1.42.10/configure
+===
+--- e2fsprogs-1.42.10.orig/configure   2014-05-15 19:04:08.0 +0200
 e2fsprogs-1.42.10/configure2014-06-30 18:36:53.451482000 +0200
+@@ -11479,7 +11479,7 @@
+BUILD_CFLAGS="$CFLAGS $CPPFLAGS $INCLUDES -DHAVE_CONFIG_H"
+BUILD_LDFLAGS="$LDFLAGS"
+ else
+-   BUILD_CFLAGS=
++   BUILD_CFLAGS="$INCLUDES"
+BUILD_LDFLAGS=
+ fi
+ 
diff -Nru e2fsprogs-1.42.10/debian/patches/series 
e2fsprogs-1.42.10/debian/patches/series
--- e2fsprogs-1.42.10/debian/patches/series 2014-06-21 12:45:57.0 
+0200
+++ e2fsprogs-1.42.10/debian/patches/series 2014-06-30 18:36:37.0 
+0200
@@ -1 +1,2 @@
 0001-mke2fs-use-ext2fs_open_file-in-check_plausibility.patch
+0002-cross-compile-cflags-includes.patch

Bug#753370: pu: package intel-microcode/1.20140624.1

[Adam D. Barratt]

On Mon, 2014-06-30 at 21:15 -0300, Henrique de Moraes Holschuh wrote:
> Please approve a fast-track upload of intel-microcode to non-free stable
> (Wheezy).

What do you mean by a "fast-track upload"? It can't get into stable any
more quickly than the point release.

> Intel has issued a high-priority microcode update, which better addresses
> the critical errata already fixed by the microcode update currently in
> wheezy-proposed-updates.

[...]
> I've attached the proposed diff, with the microcode data hunks removed for
> brevity.

Actually, you didn't. :-)

> Diffstat below:
> 
>  b/changelog  |9 
>  b/debian/changelog   |   21 
>  b/microcode-20140624.dat |38773 
> +++
>  microcode-20140430.dat   |38709 
> --
>  4 files changed, 38803 insertions(+), 38709 deletions(-)

Please go ahead; thanks.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#731254: (no subject)

[Federico Bruni]

I think that you can close this bug.
It appeared only in a machine that I'm not using anymore. Probably some 
local misconfiguration.. At any rate, I won't be able to check that 
machine anymore.

Bug#753373: libreoffice: Please migrate away from gcc-4.7 in Jessie if possible

[Rene Engelhard]

reassign 753373 libreoffice
forcemerge 748004 753373
thanks

Hi,

On Tue, Jul 01, 2014 at 07:17:53AM +0200, Niels Thykier wrote:
> Would it be feasible for libreoffice to migrate away from gcc-4.7 in
> Jessie?

LibreOffice does NOT use gcc-4.7. (It does use cpp-4.7, though)

> Currently, only libreoffice and grub2 maintains a dependency against
> it in testing.  We are hoping that we might be able to remove gcc-4.7
> for Jessie.

See http://bugs.debian.org/748004.

I didn't receive a actual answer from doko on whether cpp-4.7 was also going
to go away.

I can package ucpp but it needs to go through NEW. Or I use a internal ucpp 
copy...

Regards,

Rene


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#743439: lxsession: All work arounds fail

[James Blanford]

Package: lxsession
Version: 0.4.9.2-1
Followup-For: Bug #743439

Dear Maintainer,

I tried the listed work arounds, but none worked.  I tried Asho Yeh's patch.
I got a popup box asking for my password.  I entered it and it seemed to 
accept it, but nothing happened.  The errors in my run.log were reduced from:

(lxsession-logout:6999): GLib-GIO-CRITICAL **: g_dbus_proxy_call_sync_internal: 
assertion 'error == NULL || *error == NULL' failed

(lxsession-logout:6999): GLib-CRITICAL **: g_variant_unref: assertion 'value != 
NULL' failed

to:

(lxsession-logout:7651): GLib-CRITICAL **: g_variant_unref: assertion 'value != 
NULL' failed

I tried Tomek Kowalski's modified xserverrc and it changed:

Active=no

to:

Active=yes

Unfortunately, it left me with a system that does not repond to mouse clicks.

Is Tomek Kowalski implying that since systemd is the default that it has been 
implemented and will fix this problem without creating other problems in my 
system?

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

Kernel: Linux 3.14.8 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages lxsession depends on:
ii  libatk1.0-02.12.0-1
ii  libc6  2.19-4
ii  libcairo2  1.12.14-4
ii  libdbus-1-31.8.4-1
ii  libdbus-glib-1-2   0.102-1
ii  libfontconfig1 2.11.0-5
ii  libfreetype6   2.5.2-1
ii  libgdk-pixbuf2.0-0 2.30.7-1
ii  libgee20.6.8-1
ii  libglib2.0-0   2.40.0-3
ii  libgtk2.0-02.24.24-1
ii  libpango-1.0-0 1.36.3-1
ii  libpangocairo-1.0-01.36.3-1
ii  libpangoft2-1.0-0  1.36.3-1
ii  libpolkit-agent-1-00.105-6
ii  libpolkit-gobject-1-0  0.105-6
ii  libx11-6   2:1.6.2-2

Versions of packages lxsession recommends:
ii  consolekit   0.4.6-4
ii  lxde-common  0.5.5-6
ii  openbox [x-window-manager]   3.5.2-6
ii  openssh-client [ssh-client]  1:6.6p1-5
pn  upower   

Versions of packages lxsession suggests:
ii  gpicview  0.2.4-1
ii  lxpanel   0.5.12-3
ii  pcmanfm   1.2.0-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Two menu systems

[Keith Packard]

Nikolaus Rath  writes:

> Keith Packard  writes:
>>  1. Implement .desktop parsing support in the existing 'menu' package so
>> that packages providing only .desktop files would be incorporated
>> into menu programs without further change.
>
>
> FWIW, it seems there is at least partial support for that already. At
> least on my testing system, there is:
>
> NAME
>desktop2menu - create a menu file skeleton from a desktop file

Thanks for pointing that out. desktop2menu is a perl script which uses
the published perl bindings for .desktop files and has a start at a
mapping from .desktop Categories to menu sections. It also doesn't
correctly handle generating .xpm files for the icons.

I think this does demonstrate that we could, with little effort, allow
applications to ship only .desktop files and have the menu package take
those and generate menu files for other systems.

-- 
keith.pack...@intel.com


pgpARjJ53kHCi.pgp
Description: PGP signature

Bug#753374: grub2: Please migrate away from gcc-4.7 in Jessie if possible

[Niels Thykier]

Package: src:grub2
Version: 2.00-22
Severity: important

Hi,

Would it be feasible for grub2 to migrate away from gcc-4.7 in Jessie?

Note, that grub2 currently has several RC bugs affecting unstable,
which makes the current grub2 unable to migrate.  These may affect the
possibility of getting the change into Jessie, so please keep them in
mind estimating whether this is feasible.


Currently, only libreoffice and grub2 maintains a dependency against
it in testing.  We are hoping that we might be able to remove gcc-4.7
for Jessie.

~Niels


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753373: libreoffice: Please migrate away from gcc-4.7 in Jessie if possible

[Niels Thykier]

Source: libreoffice
Version: 1:4.2.5-1
Severity: important

Hi,

Would it be feasible for libreoffice to migrate away from gcc-4.7 in
Jessie?

Currently, only libreoffice and grub2 maintains a dependency against
it in testing.  We are hoping that we might be able to remove gcc-4.7
for Jessie.

~Niels


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753372: tomcat8: Can't run tomcat8-examples in Tomcat Web Application Manager

[Renato Rodrigues]

Package: tomcat8
Version: 8.0.9-1
Severity: normal

Dear Maintainer,

I'm trying to run tomcat8-examples application in Tomcat Web Application
Manager. Deploy works fine but 'start' button return me the message:

FAIL - Application at context path /examples could not be started
FAIL - Encountered exception org.apache.catalina.LifecycleException: Failed to
start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/examples]]

In addition to the installation, I only make the user/password in /etc/tomcat8
/tomcat-users.xml.

I have tried to run another web application. Deploy is ok, but 'start' return
me the message:

FAIL - Application at context path /ScadaBR could not be started

Maybe the problem is related.

Thanks for help.



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

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

Versions of packages tomcat8 depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.53
ii  tomcat8-common 8.0.9-1
ii  ucf3.0030

Versions of packages tomcat8 recommends:
ii  authbind  2.1.1

Versions of packages tomcat8 suggests:
pn  libtcnative-1 
ii  tomcat8-admin 8.0.9-1
ii  tomcat8-docs  8.0.9-1
ii  tomcat8-examples  8.0.9-1
pn  tomcat8-user  

-- Configuration Files:
/etc/tomcat8/tomcat-users.xml [Errno 13] Permissão negada: 
u'/etc/tomcat8/tomcat-users.xml'

-- debconf information:
  tomcat8/username: tomcat8
  tomcat8/groupname: tomcat8
  tomcat8/javaopts: -Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Two menu systems

[Nikolaus Rath]

Keith Packard  writes:
>  1. Implement .desktop parsing support in the existing 'menu' package so
> that packages providing only .desktop files would be incorporated
> into menu programs without further change.


FWIW, it seems there is at least partial support for that already. At
least on my testing system, there is:

NAME
   desktop2menu - create a menu file skeleton from a desktop file

SYNOPSIS
   desktop2menu --help|--version

   desktop2menu desktop file [package name]

DESCRIPTION
   desktop2menu generates a skeleton menu file from the supplied
   freedesktop.org desktop file.

   The package name to be used in the menu file may be passed as an
   additional argument. If it is not supplied then desktop2menu will
   attempt to derive the package name from the data in the desktop file.

LICENSE
   This program is Copyright (C) 2007 by Sune Vuorela
   . It was modified by Adam D. Barratt
for the devscripts package.  This program
   comes with ABSOLUTELY NO WARRANTY.  You are free to redistribute this
   code under the terms of the GNU General Public License, version 2 or
   later.

AUTHOR
   Sune Vuorela  with modifications by Adam D. Barratt
   

   
Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734633: Merge upstream 2.24

[Daniel Baumann]

severity 734633 important
thanks

as noted in #689035, this is needed for lxc to run unprivileged
containers which is an veryimportant security aspect of runnint containers.

are you still interested in maintaining libcap2? if so, please upgrade
to 2.24 anytime soon or let me know so i can help out.

Regards,
Daniel

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#746863: [Debian-med-packaging] Bug#746863: insighttoolkit4: ftbfs with GCC-4.9

[Steve M. Robbins]

On June 30, 2014 06:07:21 PM Gert Wollny wrote:
> The significant error is
> 
> /usr/share/gccxml-0.9/GCC/4.9/bits/stl_algo.h: In function
> '_OutputIterator std::__unique_copy(_InputIterator, _InputIterator,
> _OutputIterator, _BinaryPredicate, std::input_iterator_tag,
> std::output_iterator_tag)':
> /usr/share/gccxml-0.9/GCC/4.9/bits/stl_algo.h:1086: error: expected `;'
> before '__rebound_pred'
> 
> This is a problem with gccxml, and it seems to be already fixed in their
> upstream:
> 
> http://comments.gmane.org/gmane.science.robotics.rock.devel/4578

Mmm.  I think that's wishful thinking on the part of rock-dev.  We already 
have the latest git of gccxml (referenced in the above) packaged and it was 
used in the build that failed.

-Steve


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

Bug#753099: glibc FTBFS on alpha: test suite failures

[Michael Cree]

On Mon, Jun 30, 2014 at 11:02:24PM +0200, Aurelien Jarno wrote:
> On Sun, Jun 29, 2014 at 09:53:30PM +1200, Michael Cree wrote:
> > Source: glibc
> > Version: 2.19-4
> > Severity: important
> > User: debian-al...@lists.debian.org
> > Usertags: alpha
> > Justification: Fails to build from source but built in the past.
> > 
> > Finally the fixed gcc-4.8 arrived, however the rebuild of glibc on alpha
> > failed with unexpected test suite failures.  From the log:
> >
> > Encountered regressions that don't match expected failures 
> > (debian/testsuite-checking/expected-results-alpha-linux-gnu-libc):
> > badsalttest.out, Error 1
> 
> This one looks might be worrying, as it might affect the crypt()
> function, and thus safety of passwords. Do you have more details about
> the failure.

It's one of the string functions reading one byte passed the end
of the string.  The badsalttest very carefully places a short
checksum at the very end of a page and marks the next page of
memory as invalid and the string function used in the bad salt
test (I've forgotten which one it was now) reads one byte too far.
So the worst it can do is result in a spurious segmentation
violation.

> > test-double.out, Error 1
> > test-float.out, Error 1
> > test-snan.out, Error 1
> 
> I guess these three are actually due to the new FP tests that have been
> added in 2.19, so it should be relatively fine ignoring them, though it
> might be a good idea to confirm that. 

Interestingly these pass fine in the alphaev67 libc test suite.  The
difference between libc6.1 and libc6.1-alphaev67 is the use of extra
CPU instructions such as the byte-word extension and the extra floating
point instructions for efficient conversion of integer to float and back.
Oh, there might be a special square-root instruction introduced too IIRC.  

> > tst-backtrace2.out, Error 1
> > tst-backtrace3.out, Error 1
> > tst-backtrace4.out, Error 1
> > tst-backtrace5.out, Error 1
> > tst-backtrace6.out, Error 1
> 
> I don't think having the backtrace function working is something
> critical for a system, so yes they can be ignored. It might be
> interesting to see what caused them to stop working though.

Once again they pass in the build of libc6.1-alphaev67 but not in
libc6.1.  Maybe something about the byte-word extension?

Cheers
Michael.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752998: zfs dump magic

[Russell Coker]

https://wiki.freebsd.org/ZFS

I have attached a magic file for ZFS dumps downloaded from the above page.  I 
have never tested it but I expect that the FreeBSD people know what they are 
doing.


-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
#--
# zfs:  file(1) magic for ZFS dumps
#
# From 
# ZFS dump header has the following structure (as per zfs_ioctl.h
# in FreeBSD with drr_type is set to DRR_BEGIN)
#
#   enum {
#   DRR_BEGIN, DRR_OBJECT, DRR_FREEOBJECTS,
#   DRR_WRITE, DRR_FREE, DRR_END,
#   } drr_type;
#   uint32_t drr_pad;
#   uint64_t drr_magic;
#   uint64_t drr_version;
#   uint64_t drr_creation_time;
#   dmu_objset_type_t drr_type;
#   uint32_t drr_pad;
#   uint64_t drr_toguid;
#   uint64_t drr_fromguid;
#   char drr_toname[MAXNAMELEN];
#
# Backup magic is 0x0002f5bacbac (quad word)
# The drr_type is defined as
#   typedef enum dmu_objset_type {
# DMU_OST_NONE,
# DMU_OST_META,
# DMU_OST_ZFS,
# DMU_OST_ZVOL,
# DMU_OST_OTHER,  /* For testing only! */
# DMU_OST_ANY,/* Be careful! */
# DMU_OST_NUMTYPES
#  } dmu_objset_type_t;
#
# Almost all uint64_t fields are printed as the 32-bit ones (with high
# 32 bits zeroed), because there is no simple way to print them as the
# full 64-bit values.

# Big-endian values
8  string  \000\000\000\002\365\272\313\254 ZFS shapshot (big-endian 
machine),
>20belong  &0   version %lu,
>32belong  0type: NONE,
>32belong  1type: META,
>32belong  2type: ZFS,
>32belong  3type: ZVOL,
>32belong  4type: OTHER,
>32belong  5type: ANY,
>32belong  >5
>>32belong  &0  type: UNKNOWN (%lu),
>40byte&0   destination GUID: %02X
>41byte&0   %02X
>42byte&0   %02X
>43byte&0   %02X
>44byte&0   %02X
>45byte&0   %02X
>46byte&0   %02X
>47byte&0   %02X,
>48ulong   >0
>>52ulong   >0
>>>48byte&0 source GUID: %02X
>>>49byte&0 %02X
>>>50byte&0 %02X
>>>51byte&0 %02X
>>>52byte&0 %02X
>>>53byte&0 %02X
>>>54byte&0 %02X
>>>55byte&0 %02X,
>56string  >\0  name: '%s'

# Little-endian values
8  string  \254\313\272\365\002\000\000\000 ZFS shapshot (little-endian 
machine),
>16lelong  &0   version %lu,
>32lelong  0type: NONE,
>32lelong  1type: META,
>32lelong  2type: ZFS,
>32lelong  3type: ZVOL,
>32lelong  4type: OTHER,
>32lelong  5type: ANY,
>32lelong  >5
>>32lelong  &0  type: UNKNOWN (%lu),
>47byte&0   destination GUID: %02X
>46byte&0   %02X
>45byte&0   %02X
>44byte&0   %02X
>43byte&0   %02X
>42byte&0   %02X
>41byte&0   %02X
>40byte&0   %02X,
>48ulong   >0
>>52ulong   >0
>>>55byte&0 source GUID: %02X
>>>54byte&0 %02X
>>>53byte&0 %02X
>>>52byte&0 %02X
>>>51byte&0 %02X
>>>50byte&0 %02X
>>>49byte&0 %02X
>>>48byte&0 %02X,
>56string  >\0  name: '%s'

Bug#743292: amd64 vs 386

[Jason Raveling]

This problem also exists on the standard amd64 ISO. I attempted to
install the 386 version and had no issues. I'm waiting for a fix too.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753371: misconfigure pam rules

[Scott]

Package: anubis
Version: 4.1.1+dfsg1-3.1
Severity: important
Tags: security

pam rules defined for anubis
in /etc/pam.d/anubis are pointing to unavailable modules
(but the modules exists in /lib/x86_64-linux-gnu/security,
instead of /lib/security)

thanks


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

Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages anubis depends on:
ii  guile-1.8-libs  1.8.8+1-8
ii  libc6   2.17-97
ii  libgmp102:5.0.5+dfsg-2
ii  libgnutls26 2.12.20-8+deb7u2
ii  libgpg-error0   1.10-3.1
ii  libgpgme11  1.2.0-1.4
ii  libgsasl7   1.8.0-2
ii  libltdl72.4.2-1.1
ii  libpam0g1.1.3-7.1
ii  libpcre31:8.30-5
ii  libwrap07.6.q-24
ii  lsb-base4.1+Debian12

anubis recommends no packages.

Versions of packages anubis suggests:
pn  pidentd | ident-server  


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752214: maxima wants wxt as backend for gnuplot

[Kacper Gutowski]

In earlier versions of gnuplot packages in debian, the wxt terminal
would work regardless whether gnuplot-x11 or gnuplot-qt was installed.
But it was recently disabled in gnuplot 4.6.5-4 to fix bug #750045.


-k


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#718651: Built hostapd/wpasupplicant 2.1 (patch)

[Stefan Lippers-Hollmann]

Hi

On Monday 02 June 2014, Gerald Turner wrote:
> Stefan Lippers-Hollmann  writes:
> > On Saturday 31 May 2014, Stefan Lippers-Hollmann wrote:
> >> On Saturday 31 May 2014, Gerald Turner wrote:
> >> > Stefan Lippers-Hollmann  writes:
> >> > > On Saturday 31 May 2014, Gerald Turner wrote:
> > [...]
> >> > Would you like me to spend some time reconstructing a DEP-5
> >> > copyright file for 2.1, or would that also be wasted effort?
> >>
> >> It doesn't make sense to start collecting the copyright information
> >> from the 2.1 release, as meanwhile 28 files changed their copyright
> >> (new years, typically 2014, added), 24 new files were added + the
> >> whole new subdirectory hs20/ (which is fortunately licensed rather
> >> uniformly) and with 6 files being completely removed. If we already
> >> had this DEP-5 listing for 2.1, it would be reasonable to update it,
> >> but when starting from scratch, it only makes sense to start from
> >> current upstream HEAD (and then to use git diff ..hostap_2_2,
> >> to fill up the gaps until v2.1 gets tagged. I'm not asking you to
> >> spend time on this, as I know far too well how demotivating this is,
> >> but I certainly wouldn't say no to a patch either.
> >
> > Just as a hint, I have just[1] updated debian/get-orig-source to work
> > with wpa 2.2~. Using a version number like e.g.
> > 2.1+git20140531.1+147848e-1
> > then fetches the according upstream tarball.
> 
> Well, I've done it, and it sure was tedious!
> 
> Steps:
> 
>   git log --full-diff -p hostapd hs20 patches src wpa_supplicant | \
> egrep '(^diff|Copyright)' | \
> grep -B1 Copyright | \
> ./git-log-full-diff-parse-copyright
> 
> The Perl script (attached) took a few hours to write - there's a brick
> of about 60 lines to munge file moves.  Then about another hour to
> inspect all that output, plus poking at each file to make sure that the
> license change actually occured.

I've just finished cross-checking debian/copyright and ended up with 
the attached diff[1]. A few differences can be attributed to slightly
different collation methods, some add copyright information which is
hard to parse/ find automatically and some add information that your
parser appears to have missed.

By the way, I've disabled Hotspot 2.0 support for now, as it appears
to require a PHP- and webserver for the server part (hostapd), which
would require quite significant packaging changes that would need 
confirmation (and efforts) of someone who actually intends to use it.

Likewise I've disabled SQLITE support for hostapd, while hostapd isn't
as size sensitive (nor critical in regards to its FHS location) as 
wpa_supplicant would be, adding sqlite seems just to optimise managing
of the eap_user database, which is also available in a (duplicate) text
file format. IMHO this can be left disabled, until anyone actually 
needs it and presents a use case requiring this functionality.

If you did enable those symbols for a specific reason other than them
just being there in the new version, please give me a hint.

Regards
Stefan Lippers-Hollmann

[1] 
http://anonscm.debian.org/viewvc/pkg-wpa/wpa/trunk/debian/copyright?revision=1881&view=markup
--- /tmp/pkg/copyright	2014-07-01 03:08:02.301296645 +0200
+++ debian/copyright	2014-07-01 03:12:39.995009298 +0200
@@ -7,108 +7,75 @@ Files: *
 Copyright: 2002-2014, Jouni Malinen 
 License: BSD
 
+Files: hostapd/logwatch/*
+Copyright: 2005, Henrik Brix Andersen 
+License: BSD or GPL-2
+
 Files: hostapd/Android.mk
 Copyright: 2008, The Android Open Source Project
 License: BSD
 
-Files: hostapd/logwatch/*
-Copyright: 2005, Henrik Brix Andersen 
-License: BSD or GPL-2
+Files: hostapd/hostapd.8
+   hostapd/hostapd_cli.1
+Copyright: 2005, Faidon Liambotis 
+License: BSD
 
 Files: hs20/*
 Copyright: 2012-2014, Qualcomm Atheros, Inc.
 License: BSD
 
+Files: patches/*
+Copyright: 2005, Alexey Kobozev 
+   2005-2012, Jouni Malinen 
+License: BSD
+
 Files: src/ap/acs.*
 Copyright: 2011, Atheros Communications
2013, Qualcomm Atheros, Inc.
 License: BSD
 
-Files: src/ap/ap_config.*
-Copyright: 2003-2014, Jouni Malinen 
-   2007-2008, Intel Corporation
-License: BSD
-
 Files: src/ap/ap_list.*
+   src/ap/ap_mlme.*
+   src/ap/beacon.*
+   src/ap/hw_features.*
+   src/ap/vlan_init.*
+   src/ap/wmm.*
 Copyright: 2002-2009, Jouni Malinen 
-   2003-2004, Instant802 Networks, Inc.
-   2006, Devicescape Software, Inc.
-   2007-2008, Intel Corporation
-License: BSD
-
-Files: src/ap/ap_mlme.*
-Copyright: 2003-2008, Jouni Malinen 
-   2003-2004, Instant802 Networks, Inc.
+   2002-2004, Instant802 Networks, Inc.
2005-2006, Devicescape Software, Inc.
 License: BSD
 
-Files: src/ap/beacon.*
-Copyright: 2002-2004, Instant802 Networks, Inc.
-   2005-2006, Devicescape Software, Inc.
-   2007-2008, Intel Corporation
-   2008-2012, Jouni Malinen 
-License: BSD
-
 Files

Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs

[Hans Hagen]

On 7/1/2014 1:05 AM, Norbert Preining wrote:

On Mon, 30 Jun 2014, Hans Hagen wrote:

btw, If I grep my afm files for f_f and f_l I get lots of hits on
linotype fonts like palatino-nova, aldus-nova, palatinosans* so
there are type one fonts out there that use _ too.


Interestingly I cannot trigger the bug with xelatex and Palatino Sans,
for example.


If I understand right, the bug has to do with viewing (rendering) a 
glyph in a pdf file. In pdf the page stream has numbers pointing to a 
(normally) subset index which in turn maps onto the font slots (can be 
any order). Normally no glyph name is involved in that. Those names 
might kick in when copying is involved and no tounicode mapping is 
present in the pdf.


As you mention in a previous mail, it's a bug in poppler (or maybe some 
library it uses) that somehow used glyph names. I agree that there is no 
need to change the font (and I cannot predict what other issues might 
show up by duplicating glyph names; for instance turning f + i into an 
fi glyph .. it would still map onto the one associated with f_i). Using 
the unicode ligature sis a bad idea anyway as all these ligs in unicode 
make not much sense and is just there to suit bad old times.


Hans

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
 | www.pragma-pod.nl
-


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753370: pu: package intel-microcode/1.20140624.1

[Henrique de Moraes Holschuh]

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

Please approve a fast-track upload of intel-microcode to non-free stable
(Wheezy).

Intel has issued a high-priority microcode update, which better addresses
the critical errata already fixed by the microcode update currently in
wheezy-proposed-updates.

I have also reason to believe it extends the fixes on the previous microcode
update to the other Ivy Bridge processors, but unfortunately I cannot verify
this at this time because updated releases of the Processor Specification
Updates were not published yet.

I have also reason to believe this update enables RDRAND support on at least
some of the Xeon E5-v2, so it enhances system security (unfortunately I
don't have any at hand to verify this).  It also probably fixes a very nasty
erratum that can cause immediate system failure (emergency thermal poweroff
of the processor) too early, while the processor was still well within its
thermal envelope and there was no reason to cause data loss.  These errata
are listed for the Xeon E5v2, which has the most up-to-date specification
update.

For Haswell processors, it probably fixes a nasty erratum on features that
are not yet on any released kernel (Intel PT and Intel TMX used at the same
time will cause unpredictable system behaviour)... but it could also fix
other undisclosed errata that are active on current kernels.

The update is believed safe from regressions, as no microcodes were removed.

Canonical, which has access to better information from Intel than we do, has
fast tracked this update to all currently supported Ubuntu releases,
including their LTS releases.  In fact, it was Canonical that hinted that
this update enhanced the fixes present on the previous update.

I've attached the proposed diff, with the microcode data hunks removed for
brevity.  Diffstat below:

 b/changelog  |9 
 b/debian/changelog   |   21 
 b/microcode-20140624.dat |38773 +++
 microcode-20140430.dat   |38709 --
 4 files changed, 38803 insertions(+), 38709 deletions(-)

Thank you.

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

Kernel: Linux 3.10.45+ (SMP w/8 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742182: Not a debian issue

[Thomas Maerz]

This is also happening on red hat for me:

samba-tool -V
4.1.9-SerNet-RedHat-8.el6
[root@auth1 ad.brewerscience.com]# samba-tool gpo aclcheck
ldb_wrap open of secrets.ldb
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'sasl-DIGEST-MD5' registered
GENSEC backend 'schannel' registered
GENSEC backend 'spnego' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
ERROR(): uncaught exception - 'No such element'
  File "/usr/lib64/python2.6/site-packages/samba/netcmd/__init__.py", line 175, 
in _run
return self.run(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/samba/netcmd/gpo.py", line 1150, in 
run
ds_sd_ndr = m['nTSecurityDescriptor'][0]


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753331: [biber] wrong version ?

[Norbert Preining]

On Mon, 30 Jun 2014, Hugo Férée wrote:
> Since the last biblatex update (in texlive-bibtex-extra) biber does not seem 
> to work anymore.

Indeed, sorry that I missed that. Biber 1.9 will be uploaded
in a minute.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753315: RFS: ecj/3.10.0-1 - [UPLOADED]

[Emmanuel Bourg]

Thank you for the log Matthias. Could you also detail the steps to
reproduce this error please? I tried to build gcc with
--enable-java-maintainer-mode but I didn't see this error (but my
configure args were probably incomplete).

Emmanuel Bourg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Guo Yixuan]

On Mon, Jun 30, 2014 at 8:54 AM, Osamu Aoki 
wrote:
>
> Hi,
>
> On Sun, Jun 29, 2014 at 02:14:49PM -0400, Guo Yixuan wrote:
> > The only problem for using uversionmangle is:
> >
> > I: librime source:
> > debian-watch-file-should-dversionmangle-not-uversionmangle line 3
> > N:
> > N:The version of this package contains dfsg, ds, or debian, but a
> > N:misleading upstream version mangling occurs in the debian/watch
file.
> > N:Since the dfsg string is not part of the upstream version and its
> > N:addition is Debian-specific, the the debian/watch file should use
the
> > N:dversionmangle option to remove, instead of adding in
uversionmangle,
> > N:the dfsg before comparing version numbers.
> > N:
> > N:Refer to http://wiki.debian.org/DEHS for details.
> > N:
> > N:Severity: wishlist, Certainty: certain
> > N:
> > N:Check: watch-file, Type: source
> >
> > But if we use dversionmangle instead of uversionmangle,
> > then the renamed origin tarball has name "librime_1.1.orig.tar.gz",
> >  which needs to be manually renamed to "librime_1.1+dfsg.orig.tar.gz".
> >
> > A related bug is here. [1]
> >
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748465
>
> Did you try the solution at the bottom?

Do you mean message #42? I can't find any solutions there...
I think a lintian override is the best solution before the removal
of debian-watch-file-should-dversionmangle-not-uversionmangle.

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

> Also, adding yourself to uploader, go ahead.  This means you will stay
> with us and keep working on this :-)

Thank you!

Cheers,

Yixuan

Bug#744257: attica: FTBFS on arm64 (symbols issue)

[Wookey]

+++ Pino Toscano [2014-04-12 09:08 +0200]:

> The patch is indeed wrong, and should not be applied.
> 
> If you want more help on the issue, please do post a full build log.

So, as discussed, attica does in fact build fine on arm64 without any
changes. However, because of the way debian-ports works, the arm64
port now needs a version-bump of this package.

I originally uploaded a version 0.4.2-1+arm64 to the 'unreleased'
debian-ports repo to get builds depending on attica going. But that
turned out to be unnecessary. However, the kosher build of attica can
not now upload to plain debian-ports ('unstable') because it has a
lower version number (0.4.2-1) than the 0.4.2-1+arm64 in
unreleased. Only a new upload of attica with a version bump can fix
this.  I am happy to do this myself as an NMU as I
made the work, but if you'd prefer to just do a 0.4.2-2 upload that
would be great. Sorry for the faff.

As you can see from
http://buildd.debian-ports.org/status/package.php?p=attica&suite=sid a
correct version was uploaded 19 days ago, but it will not install due
to above versionitis.

cheers

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753369: dvbcut: play function misses sound

[Bernhard Übelacker]

Package: dvbcut
Version: 0.5.4+svn178-7
Severity: normal
Tags: patch

Dear Maintainer,

   * What led up to the situation?
- Load a TS record into dvbcut.
- Use the play function

   * What was the outcome of this action?
- Video plays, but audio is missing

   * What outcome did you expect instead?
- Audio should be playing


dvbcut uses mplayer for its play function:
mplayer -noconsolecontrols -wid 0x52000bc -sb 3751916 -geometry 1024x576+0+0
-aid 0x83f /mnt/file.ts

If using just the number of audio stream counted from 0 mplayer plays audio
just fine.


Patch:
--- dvbcut-0.5.4+svn178.orig/src/dvbcut.cpp
+++ dvbcut-0.5.4+svn178/src/dvbcut.cpp
@@ -1182,7 +1182,7 @@ void dvbcut::playPlay()
   arguments << "-geometry" <<
QString().sprintf("%dx%d+0+0",int(ui->imagedisplay->width()),int(ui->imagedisplay->height()));

   if (currentaudiotrack>=0 && currentaudiotrackgetaudiostreams()) {
-arguments << "-aid" <<
QString().sprintf("0x%x",int(mpg->mplayeraudioid(currentaudiotrack)));
+arguments << "-aid" << QString().sprintf("0x%x", currentaudiotrack);
 }

   // for now, pass all filenames from the current one up to the last one



-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (990, 'testing-updates'), (990, 'testing'), (500, 
'testing-proposed-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dvbcut depends on:
ii  liba52-0.7.4   0.7.4-17
ii  libao4 1.1.0-2
ii  libavcodec55   6:10.1-1
ii  libavformat55  6:10.1-1
ii  libavutil536:10.1-1
ii  libc6  2.19-3
ii  libgcc11:4.9.0-7
ii  libmad00.15.1b-8
ii  libqt4-network 4:4.8.6+dfsg-2
ii  libqt4-qt3support  4:4.8.6+dfsg-2
ii  libqt4-sql 4:4.8.6+dfsg-2
ii  libqt4-xml 4:4.8.6+dfsg-2
ii  libqtcore4 4:4.8.6+dfsg-2
ii  libqtgui4  4:4.8.6+dfsg-2
ii  libstdc++6 4.9.0-7
ii  libswscale26:10.1-1

Versions of packages dvbcut recommends:
ii  mplayer2 [mplayer]  2.0-728-g2c378c7-2

dvbcut suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#723718: suggest /etc/mailcap entry for xmore and xwud

[Kevin Ryde]

retitle 723718 suggest /etc/mailcap entry for xmore and xwud
thanks

xwud could also helpfully have a mailcap entry too.  New proposed
debian/mime file below.  xwud isn't the most sophisticated image viewer,
but xwd is its native format and on a minimal x11 install it could be
all that's available for xwd.

# priority=6 here is below "less" at priority=8.
# Believe "less" in an xterm is more featureful than xmore.
#
# Want to be above Emacs priority=5 entries made by update-mime from
# /usr/share/applications/emacs24.desktop.  Believe xmore is easier
# for standalone use.
#
text/plain; xmore '%s'; test=test -n "$DISPLAY"; description=Plain Text; 
priority=6

# priority=0 here to act as a fallback if some text/foo type has nothing
# specific.
text/*; xmore '%s'; test=test -n "$DISPLAY"; description=Plain Text; priority=0

# xwud with no arguments reads from standard input which can let
# run-mailcap or simlar feed it from a pipe rather than a temporary
# file.
# Lowish priority since xwud doesn't have many features.  It's about
# the same as imagemagick "display" so prioirty=2 the same as that.
image/x-xwindowdump; xwud; test=test -n "$DISPLAY"; priority=2

Bug#741573: Two menu systems

[Keith Packard]

Josselin Mouette  writes:

> One of the problems I have with your proposal, compared to Charles’
> original patch, is that it encourages maintainers of hundreds of (IMHO
> useless) menu files to port them to the desktop format.

Yeah, there are a lot of inappropriate entries in my /usr/share/menu
directory. Can we fix policy to weed these out? The current
wording in §9.6:

  All packages that provide applications that need not be passed any
  special command line arguments for normal operations should
  register a menu entry for those applications.

seems problematic to me -- it seems to require menu entries for things
as diverse as a web browser and a python interpreter. Coming up with
wording that encourages only programs which are conventionally used in
interactive mode to be included seems like a good fix here.

> We don’t need menu entries for bc or python, unless they are
> NoDisplay=true. This should be obvious, but currently we have trad menu
> entries for them. The proposed wording for the policy (which is the
> result of a compromise work between desktop maintainers and policy
> editors) handles this by stating maintainers must set appropriate
> NoDisplay/OnlyShowIn/NotShowIn fields, but experience shows maintainers
> are not cooperative in this matter (hence gross hacks such as
> gnome-menus-blacklist).

I think it's a lack of clarity in the spec which encourages
over-production of menu entries.

> Experience shows it doesn’t work. You can have ad-hoc selection after
> time (either automatic or manual), but you need something that works out
> of the box. Three-level nested menus with hundreds of entries are not
> something to present a new user, regardless of her proficiency.

I completely agree, but I don't think we can mandate good UI design in
Policy, all we can do is provide the tools necessary to construct a good
UI.

> There is a sensible way: not present the useless ones. Use
> NoDisplay=true everywhere appropriate.
>
> I don’t think presenting the whole contents of /usr/bin in a menu is
> helpful in any way to anyone.

As you say, we can't expect package developers to always make the
choices we'd like. I don't have any good solutions here, but I don't
think how the underlying menu information is transmitted in the package
is affected by that problem.

-- 
keith.pack...@intel.com


pgpNnT4au_b4H.pgp
Description: PGP signature

Bug#740801: zathura: Ligatures, like "fi", are not rendered. (fwd)

[Norbert Preining]

Dear Debian Poppler Maintainers, dear all,

> This bug report seems to be related:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=73291

This fix is not in fontconfig, nor in the TeX Gyre fonts, but
poppler needs to be fixed.

Adobe Glyph specification states clearly that new fonts should use
f_i
etc as glyph names for ligatures. See my last post in the above
freedesktop bug.

I suggest the Debian poppler maintainers to adopt the patch by 
Sebatisan to the poppler source to make ligatures in new style
fonts again available, given in this freedesktop bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80093

Poppler upstream maintainers seem to be ignorant about this, and
even worse, seem to be completely incooperative. I *STRONGLY*
suggest that this patch is included in the Debian poppler packages.

> that bug report, and linked to a commit:
> 
> http://cgit.freedesktop.org/fontconfig/commit/?id=c6aa4d4bfcbed14f39d070fe7ef90a4b74642ee7

Which is the wrong approach taken by fontconfig.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Two menu systems

[Keith Packard]

Russ Allbery  writes:

> The counterpoint here, which I had missed earlier in this discussion, is
> the file format for the menus themselves, not the *.desktop files.  I
> agree with you about the *.desktop file format, but the specification for
> the menus is much more complicated.  See:
>
> http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html

I didn't actually review that spec before putting together my
draft. I think it's slightly orthogonal to the question of how
applications publish information about themselves to a menu program
though.

> I'm not positive that the syntax of /etc/menu-methods is any less complex,
> but it's at least arguable, and it's certainly way different and already
> designed for generating menus for other applications that don't inherently
> support the XDG menu system.

It seems to me that the freedesktop .menu file format is that can be
mechanically constructed from the set of installed .desktop files, at
least by default. To some degree, that makes it something of an
implementation detail for a particular menu program. I think it is
documented so that external menu editing tools can be written to
rearrange things from the default configuration.

-- 
keith.pack...@intel.com


pgpvpQraRYveI.pgp
Description: PGP signature

Bug#753367: general: usb drives automatically mount but user permission is ro

[phasegen]

Package: general
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



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

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753368: texlive-base: suggest /etc/mailcap entry for dvi2tty

[Kevin Ryde]

Package: texlive-base
Version: 2014.20140528-3
Severity: wishlist
Tags: patch
File: /usr/lib/mime/packages/texlive-base

As a suggestion, it could be good for dvi2tty to offer itself in
/etc/mailcap for use as a dvi viewer.  This lets "see foo.dvi" or
similar display at least something on a tty where the graphical viewers
cannot run.  I suggest the lines below in
/usr/lib/mime/packages/texlive-base.  (I propose similar for catdvi in
bug#753366.)


# "-q" to not pipe through a pager.  run-mailcap or similar will do
# that, or not, as appropriate.
# priority=3 is the same as "catdvi".
application/x-dvi; /usr/bin/dvi2tty -q %s; copiousoutput; description=TeX DVI; 
priority=3


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

Kernel: Linux 3.14-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages texlive-base depends on:
ii  cdebconf [debconf-2.0]  0.191
ii  debconf [debconf-2.0]   1.5.53
ii  dpkg1.17.10
ii  libpaper-utils  1.1.24+nmu3
ii  tex-common  5.02
ii  texlive-binaries2014.20140528.34243-2
ii  ucf 3.0030
ii  xdg-utils   1.1.0~rc1+git20111210-7.1

Versions of packages texlive-base recommends:
pn  lmodern  

Versions of packages texlive-base suggests:
ii  evince [postscript-viewer]   3.12.1-1
ii  ghostscript [postscript-viewer]  9.05~dfsg-8.1
ii  gv [postscript-viewer]   1:3.7.4-1
ii  mupdf [pdf-viewer]   1.4-2
ii  perl-tk  1:804.032-2
ii  xpdf [pdf-viewer]3.03-17
ii  zathura [pdf-viewer] 0.2.7-1
ii  zathura-ps [postscript-viewer]   0.2.2-5

Versions of packages tex-common depends on:
ii  cdebconf [debconf-2.0]  0.191
ii  debconf [debconf-2.0]   1.5.53
ii  dpkg1.17.10
ii  ucf 3.0030

Versions of packages tex-common suggests:
ii  debhelper  9.20140228

Versions of packages texlive-base is related to:
ii  tex-common5.02
ii  texlive-binaries  2014.20140528.34243-2

-- debconf information:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
  tex-common/check_texmf_wrong:
  texlive-base/texconfig_ignorant:
  tex-common/check_texmf_missing:


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs

[Norbert Preining]

Dear Jacko,

thanks for your answer and time

> The fonts in the OTF format, however, we considered "new" ones
> (note, e.g., that they have Unicode tables and that they are equipped
> with the OTF typografic features, both absent from the original
> Adobe fonts) and, therefore, following Adobe's recommendations
> for the glyph naming in new fonts (see the mentioned by Karl

Agreed.

> 2. Does it make really sense to make a step
> backward and revert to the old-style names in the OTF

No. I disagree here. Poppler should be fixed.

> TeX Gyre fonts (including TeX Gyre Math)? It is feasible,
> but we are rather reluctant to introduce such a change,

Indeed, and I do *not* want you to make this step.

As Kalr pointed out, either we leave it like it is now, and
get poppler do be reasonable, or adding another fake glyph fi/f_i,
but not changing names, this is not a good idea.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs

[Norbert Preining]

On Mon, 30 Jun 2014, Karl Berry wrote:
> revert to the old-style names in the OTF
> 
> Seems like there should be no need to revert.  In principle, couldn't

Agreed, reverting is bad.

> the fi ligature glyph appear as both "f_i" and "fi"?  In other words,

That would be the safest option, indeed.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs

[Norbert Preining]

On Mon, 30 Jun 2014, Hans Hagen wrote:
> btw, If I grep my afm files for f_f and f_l I get lots of hits on
> linotype fonts like palatino-nova, aldus-nova, palatinosans* so
> there are type one fonts out there that use _ too.

Interestingly I cannot trigger the bug with xelatex and Palatino Sans,
for example.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#657405: update on mediagoblin?

[Matt Zagrabelny]

Hello!

Thanks for working on this ITP. Any update on it getting into the NEW queue?

Cheers!

-mz


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741573: Two menu systems

[Keith Packard]

Cameron Norman  writes:

> I believe the major aspect of .desktop files that makes them harder is the
> icon handling. Perhaps debian policy should instruct that a certain icon
> size must always be available in a particular format (e.g. 32x32 png) so
> that WMs do not have to handle so many corner cases in that area.

A window manager will need to handle resizing of icons in any case, and
it's pretty darn hard to pin down which sizes to require when so many
screen sizes and resolutions are in common use these days. Ideally, the
icon artwork is presumably coming from upstream and not constructed for
packaging purposes; that will naturally limit the icons to what is
provided, making mandating specific sizes somewhat impractical.

Of course, I would encourage application developers to provide .svg
icons instead of fixed sizes. That gives the window manager the
ability to present something good looking at any size.

-- 
keith.pack...@intel.com


pgpErTMf4QhWh.pgp
Description: PGP signature

Bug#753267: RM: guayadeque/0.3.7~ds0-2

[Emilio Pozuelo Monfort]

On 30/06/14 13:17, Alessio Treglia wrote:
> On Mon, Jun 30, 2014 at 11:56 AM, Emilio Pozuelo Monfort
>  wrote:
>> I've added a hint for this, guayadeque should be gone in tonight's britney 
>> run.
> 
> Thanks!

And it's gone now.

Cheers,
Emilio


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs

[Karl Berry]

revert to the old-style names in the OTF

Seems like there should be no need to revert.  In principle, couldn't
the fi ligature glyph appear as both "f_i" and "fi"?  In other words,
add a bunch more duplicate glyphs; nothing else need change, as I
understand it ... f + i would still lead to f_i, etc.  Ok, it's dumb and
ugly, but that's life with computers.

karl


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753366: catdvi: suggest /etc/mailcap entry

[Kevin Ryde]

Package: catdvi
Version: 0.14-12.1
Severity: wishlist
Tags: patch

catdvi could helpfully offer itself in /etc/mailcap as a text dvi
converter.  This can be used by "see foo.dvi" or similar when on a tty
so the graphical viewers cannot run.

I get some joy from the file debian/mime below.  It's installed by
dh_installmime of current debian/rules to /usr/lib/mime/packages/catdvi
in turn used by the mime-support package, when installed.

# catdvi with no command line filename reads from standard input.
# This is good for "run-mailcap" feeding it from a pipe rather than
# making a temporary file.
application/x-dvi; /usr/bin/catdvi; copiousoutput; description=TeX DVI; 
priority=3


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

Kernel: Linux 3.14-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages catdvi depends on:
ii  libc62.19-1
ii  libkpathsea6 2014.20140528.34243-2
ii  texlive-base 2014.20140528-3
ii  texlive-binaries [texlive-base-bin]  2014.20140528.34243-2

Versions of packages catdvi recommends:
ii  texlive-fonts-recommended  2014.20140528-3

catdvi suggests no packages.

-- no debconf information

Bug#752390: /usr/include/sys/_callout.h:56:2: error: unknown type name 'sbintime_t'

[Samuel Bronson]

Hector Oron  writes:
> https://buildd.debian.org/status/fetch.php?pkg=gdb&arch=kfreebsd-amd64&ver=7.7.1-2&stamp=1403257387

Here's the relevant portion of the buildlog:

x86_64-kfreebsd-gnu-gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 
-Wformat -Werror=format-security-I. -I/«PKGBUILDDIR»/gdb 
-I/«PKGBUILDDIR»/gdb/common -I/«PKGBUILDDIR»/gdb/config 
-DLOCALEDIR="\"/usr/share/locale\"" -DHAVE_CONFIG_H 
-I/«PKGBUILDDIR»/gdb/../include/opcode -I/«PKGBUILDDIR»/gdb/../opcodes/..  
-I../bfd -I/«PKGBUILDDIR»/gdb/../bfd -I/«PKGBUILDDIR»/gdb/../include 
-I../libdecnumber -I/«PKGBUILDDIR»/gdb/../libdecnumber  
-I/«PKGBUILDDIR»/gdb/gnulib/import -Ibuild-gnulib/import   -DTUI=1  
-D_FORTIFY_SOURCE=2  -I/usr/include/python2.7 
-I/usr/include/x86_64-kfreebsd-gnu/python2.7 -Wall 
-Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused 
-Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts 
-Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body 
-Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition 
-Wformat-nonliteral  -c -o i386-nat.o -MT i386-nat.o -MMD -MP -MF 
.deps/i386-nat.Tpo /«PKGBUILDDIR»/gdb/i386-nat.c
In file included from /usr/include/sys/callout.h:43:0,
 from /usr/include/sys/proc.h:41,
 from /«PKGBUILDDIR»/gdb/bsd-kvm.c:38:
/usr/include/sys/_callout.h:55:2: error: unknown type name 'sbintime_t'
  sbintime_t c_time;   /* ticks to the event */
  ^
/usr/include/sys/_callout.h:56:2: error: unknown type name 'sbintime_t'
  sbintime_t c_precision;   /* delta allowed wrt opt */
  ^
Makefile:1008: recipe for target 'bsd-kvm.o' failed
make[3]: *** [bsd-kvm.o] Error 1

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753365: apt-cacher: version regexp to tight

[gregor herrmann]

Package: apt-cacher
Version: 1.7.9
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The following just made me unhappy:

Tue Jul  1 00:17:00 2014|debug [30573]: Resolved request is 
http://ftp.ch.debian.org/debian/pool/main/d/dh-autoreconf/dh-autoreconf_9_all.deb
Tue Jul  1 00:17:00 2014|debug [30573]: Sorry, not allowed to fetch that type 
of file: dh-autoreconf_9_all.deb
Tue Jul  1 00:17:00 2014|debug [30573]: Response: 403 Sorry, not allowed to 
fetch that type of file: dh-autoreconf_9_all.deb

Afer digging around, I found %VALID_VERSION% and its definition in
/usr/share/apt-cacher/lib/apt-cacher.pl (line 267):

   version => '(?:\d+:)?[0-9][-+:.~a-zA-Z0-9]+',

Yes, this does not much the plain '9' of dh-autoreconf ...

Changing it to 
   version => '(?:\d+:)?[0-9][-+:.~a-zA-Z0-9]*',
allowed me to go on ...


Cheers,
gregor

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJrBAEBCgBVBQJTseQ+ThSAAB0AKGlzc3Vlci1mcHJAZ3BnLmNvbW9kby5w
cml2LmF0RDFFMTMxNkU5M0E3NjBBODEwNEQ4NUZBQkIzQTY4MDE4NjQ5QUEwNgAK
CRC7OmgBhkmqBunXD/wI7t0IuMUmEWWMH67gc0HUZsERgKfP4NILXBsWDCr/HYiy
FtSL5bH0Zkj4sNNRjEAPG5eMg3QP+xj5yNp2AWKpxFyG4kjNVyQeQONV6ApGKnvP
RfYszTOVg2WCH/36qF+QMjZKPJKGnfKNv7JxPjxxDT7aFubdETZh09+tiGvzvizQ
jExPcIFbBoGFQu68C+PymJr0Ivs5UDsdVY/v36ld1Giz81IXKBkxrsqAMLmNChBZ
JWO9H6UVM72hgoXI2I/m655WG37O8IPIn7WUxQQc9xa1/JUwKz3/VZdve5uDOi2n
VVAQ+8dKzidoZmjZ0SPz17b12jHdrfUP+8gH/Sif1FYKYQJDkW1dU89Xoncks11J
LY+/TFL326PWUCoUYnV7ciQWcDJEaO882G1DfS9iIyB/HO8X5PfY8ZMiUpiBryvG
4oKhTw3P6svPq2UL4D9UreeEXwvKvfiCstHzxbVNxecthbTrZK5gngL2q/+jJ73q
ti4c1k796TONa7mP9OxYzC2oLE8Jo8BK6xd64WvW+5PdR+4ro1VCHSBW0mzyt71F
h8D7ZTXp2yeOnNeTFZ/66foQrcVOj5QEdVVxv0nuV+2/k1/hsxjUzFkAzuwoK0q+
MJgGQG1Umi66ERWiXiYxgUFomHS//VdFlPQPJZxvoaei2Muy8NWUrZfn7kw6mw==
=CI4B
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753364: man page missing option

[Joey Hess]

Package: cpphs
Version: 1.18.4-1
Severity: normal

The man page is missing at least the --include option.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.13-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cpphs depends on:
ii  libc6 2.19-4
ii  libffi6   3.1-2
ii  libgmp10  2:6.0.0+dfsg-4

cpphs recommends no packages.

Versions of packages cpphs suggests:
ii  ghc  7.6.3-10

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#752345: [Debian-med-packaging] Bug#752345: gbrowse: hardcodes /usr/lib/perl5

[Charles Plessy]

Control: tag -1 + pending

Le Mon, Jun 30, 2014 at 11:11:40PM +0200, gregor herrmann a écrit :
> 
> On Sun, 22 Jun 2014 23:01:41 +0300, Niko Tyni wrote:
> 
> > > For this to work, packages containing binary perl modules need to migrate
> > > from using the hardcoded /usr/lib/perl5 directory to the value of the
> > > $Config{vendorarch} variable, as defined in the 'Config' module.
> 
> Attached is a patch that uses $Config{vendorarch} in d/rules and
> debian/gbrowse-calign.dirs.

Thanks Gregor, I applied it (after passing it through perl -pe 
's/\e\[?.*?[\@-~]//g').

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753363: advi: /etc/mailcap entry

[Kevin Ryde]

Package: advi
Version: 1.10.2-2
Severity: wishlist
Tags: patch

advi could offer itself as a dvi viewer in /etc/mailap.  I think a file
debian/advi.mime below can be installed by debhelper dh_installmime to
/usr/lib/mime/packages/advi, for use by mime-support.  (This is similar
to /usr/lib/mime/packages/texlive-base.)

application/x-dvi; /usr/bin/advi %s; description=TeX DVI; test=test -n 
"$DISPLAY"; priority=5


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

Kernel: Linux 3.14-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages advi depends on:
ii  dpkg 1.17.10
ii  ghostscript-x9.05~dfsg-8.1
ii  libc62.19-1
ii  libfreetype6 2.5.2-1
ii  libx11-6 2:1.6.2-2
ii  libxinerama1 2:1.1.3-1
ii  perl 5.18.2-4
ii  tex-common   5.02
ii  texlive-base 2014.20140528-3
ii  texlive-binaries [texlive-base-bin]  2014.20140528.34243-2
ii  zlib1g   1:1.2.8.dfsg-1

advi recommends no packages.

Versions of packages advi suggests:
ii  bzip2 1.0.6-5
pn  fonts-ipafont-gothic | fonts-japanese-gothic  
pn  fonts-ipafont-mincho | fonts-japanese-mincho  

-- no debconf information

Bug#741573: Two menu systems

[Josselin Mouette]

Hi,

Le lundi 30 juin 2014 à 13:59 -0700, Keith Packard a écrit : 
> One of the arguments that I had heard expressed against supporting
> applications shipping .desktop files is that it would reduce the number
> of applications offered in existing menu packages; I'm hoping that my
> draft addresses this question by demonstrating that the .desktop format
> offers a proper superset of the information found in menu files, and
> that package maintainers could mechanically convert their existing menu
> files into .desktop files without loss of information.

One of the problems I have with your proposal, compared to Charles’
original patch, is that it encourages maintainers of hundreds of (IMHO
useless) menu files to port them to the desktop format.

We don’t need menu entries for bc or python, unless they are
NoDisplay=true. This should be obvious, but currently we have trad menu
entries for them. The proposed wording for the policy (which is the
result of a compromise work between desktop maintainers and policy
editors) handles this by stating maintainers must set appropriate
NoDisplay/OnlyShowIn/NotShowIn fields, but experience shows maintainers
are not cooperative in this matter (hence gross hacks such as
gnome-menus-blacklist).

> I'm afraid that my notion of a transition plan was expressed implicitly
> in the proposal rather than explicitly. In any case, the transition plan
> I had in mind was pretty simple:
> 
>  1. Implement .desktop parsing support in the existing 'menu' package so
> that packages providing only .desktop files would be incorporated
> into menu programs without further change.

That part of the plan is obvious: replace the current “menu” package by
https://wiki.archlinux.org/index.php/Xdg-menu

>  2. Transition packages from providing menu files to providing .desktop
> files, deprecating support for the menu file format within the
> archive over time.
[snip] 
> I'd love to see so many programs in my menu that menu program developers
> are encouraged to figure out how to reasonably select entries in menus
> so that we can get to some kind of intentional preferential listing
> mechanism, rather than the ad-hoc selection that we have today.

Experience shows it doesn’t work. You can have ad-hoc selection after
time (either automatic or manual), but you need something that works out
of the box. Three-level nested menus with hundreds of entries are not
something to present a new user, regardless of her proficiency.

> However, I don't think that Policy is a sound place to make user
> interface design decisions, and that we should naturally defer how to
> present the provided application set to the menu program developers. I
> believe this part of Policy should focus on stating what application
> developers are expected to provide for the menu system, and then let the
> menu program do 'something sensible' with the provided data.

Agreed.

[snip] 
> I think this distinction is entirely an artifact of the current split
> between packages, some of which install only a menu file, and some of
> which install both menu and .desktop files. I would hope that by
> encouraging all packages to deliver only .desktop files, we'll see
> developers thinking about sensible ways to present hundreds of
> applications to their users.

There is a sensible way: not present the useless ones. Use
NoDisplay=true everywhere appropriate.

I don’t think presenting the whole contents of /usr/bin in a menu is
helpful in any way to anyone.

Cheers,
-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753004: Please compile git with PCRE support

[Jonathan Nieder]

unarchive 669376
forcemerge 669376 753004
quit

Hi,

Ian Jackson wrote:

> $ git-grep -P 'sendmsg ?='
> fatal: cannot use Perl-compatible regexes when not compiled with USE_LIBPCRE
> $
>
> IWBNI this worked.

It works in jessie and wheezy-backports.

Thanks and hope that helps,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752348: libhdate: hardcodes /usr/lib/perl5

[gregor herrmann]

Control: tag -1 + patch

On Sun, 22 Jun 2014 23:07:47 +0300, Niko Tyni wrote:

> For this to work, packages containing binary perl modules need to migrate
> from using the hardcoded /usr/lib/perl5 directory to the value of the
> $Config{vendorarch} variable, as defined in the 'Config' module.

I'm attaching a patch which uses $Config{vendorarch} in the relevant files.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Mark Knopfler: The Road
diff -Nru libhdate-1.6/debian/changelog libhdate-1.6/debian/changelog
--- libhdate-1.6/debian/changelog	2013-09-21 13:17:48.0 +0200
+++ libhdate-1.6/debian/changelog	2014-06-30 23:43:18.0 +0200
@@ -1,3 +1,13 @@
+libhdate (1.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "hardcodes /usr/lib/perl5"
+- use $Config{vendorarch} in debian/rules and debian/libhdate-perl.*
+- make the latter two executable
+(Closes: #752348)
+
+ -- gregor herrmann   Mon, 30 Jun 2014 23:31:58 +0200
+
 libhdate (1.6-2) unstable; urgency=low
 
   * Patch fix_3: fix an endless loop with hcal -3 (Closes: #692039).
diff -Nru libhdate-1.6/debian/libhdate-perl.dirs libhdate-1.6/debian/libhdate-perl.dirs
--- libhdate-1.6/debian/libhdate-perl.dirs	2013-08-16 15:23:02.0 +0200
+++ libhdate-1.6/debian/libhdate-perl.dirs	2014-06-30 23:41:20.0 +0200
@@ -1 +1,3 @@
-usr/lib/perl5
+#!/usr/bin/perl -w
+use Config;
+print substr($Config{vendorarch}, 1) . "\n";
diff -Nru libhdate-1.6/debian/libhdate-perl.install libhdate-1.6/debian/libhdate-perl.install
--- libhdate-1.6/debian/libhdate-perl.install	2013-08-16 15:23:02.0 +0200
+++ libhdate-1.6/debian/libhdate-perl.install	2014-06-30 23:41:20.0 +0200
@@ -1 +1,3 @@
-usr/lib/perl5/*
+#!/usr/bin/perl -w
+use Config;
+print substr($Config{vendorarch}, 1) . "\n";
diff -Nru libhdate-1.6/debian/rules libhdate-1.6/debian/rules
--- libhdate-1.6/debian/rules	2013-09-18 07:02:56.0 +0200
+++ libhdate-1.6/debian/rules	2014-06-30 23:38:47.0 +0200
@@ -1,10 +1,12 @@
 #!/usr/bin/make -f
 
+ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
+
 %:
 	dh $* --with python2,autotools_dev
 
 override_dh_auto_configure:
-	dh_auto_configure -- --with-perl-sitelib-dir=/usr/lib/perl5
+	dh_auto_configure -- --with-perl-sitelib-dir=$(ARCHLIB)
 
 override_dh_python2:
 	dh_python2 -s --no-guessing-versions


signature.asc
Description: Digital Signature

Bug#753352: Uncaught NameError when drag-and-dropping a picture into media object list to create new media object

[Ross Gammon]

forwarded 753352 https://gramps-project.org/bugs/view.php?id=7872
severity 753352 important
tags 753352 + upstream fixed-upstream
thanks

Hi Paul,

Thanks for reporting this. I have read the correspondence on the
upstream bug, and understand Paul's reasons for closing the bug.

I will have a look at this tomorrow, and see if we can get a fix sorted
out fairly soon.

Regards,

Ross

On 06/30/2014 09:15 PM, Paul Kilgo wrote:
> Package: gramps
> Version: 4.0.4+dfsg-1
> 
> This is a report of the same bug which I accidentally filed upstream:
> 
> https://gramps-project.org/bugs/view.php?id=7872
> 
> I'm receiving this traceback:
> 
> 38710: ERROR: grampsapp.py: line 114: Unhandled exception
> Traceback (most recent call last):
>   File
> "/usr/lib/python2.7/dist-packages/gramps/plugins/view/mediaview.py",
> line 189, in drag_data_received
> clean_string = conv_to_unicode(
> NameError: global name 'conv_to_unicode' is not defined
> 
> when doing the following:
> 
> 1. Open the media tab.
> 2. Drag-and-drop a photo (for me a JPG) from the system file browser
> into the media list
> 
> Expected behavior:
> 
> Dialog for adding a new media object invoked
> 
> Observed behavior:
> 
> Uncaught exception
> 
> As said in the ticket, it looks like it's just a missing import problem.
> The conv_to_unicode() function appears to live in gramps.gen.constfunc.
> 
> I'll caution I was using the 4.0.4 package in the backports for Ubuntu
> 14.04. I have checked out Debian's 4.0.4+dfsg-1 source package and it
> appears to be missing the same imports, and I didn't see a patch or
> issue for it.
> 
> Upstream said they have this fix in a later version.
> 
> Thanks, let me know if I can be of help. Sorry if this is not the proper
> place.




signature.asc
Description: OpenPGP digital signature

Bug#751424: closed by Bill Allombert (Bug#751424: fixed in libjpeg8 8d1-1)

[Mauricio Faria de Oliveira]

On 06/30/2014 12:00 PM, Bill Allombert wrote:

Could you check libjpeg6b ? It might need a similar patch.


Sure. Indeed; I submitted a patch in #753362.

Kind regards,

--
Mauricio Faria de Oliveira
IBM Linux Technology Center


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753362: libjpeg6b: build with dh-autoreconf

[Mauricio Faria de Oliveira]

Package: src:libjpeg6b
Version: 6b1-4
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el
User: debian-de...@lists.debian.org
Usertags: autoreconf

Hi Bill,

This patch runs dh-autoreconf when building libjpeg6b.

It is required for generating shared libraries on ppc64el and probably
other new ports as well.

It includes a patch to add -Wno-obsolete in AM_INIT_AUTOMAKE, due to
ansi2knr being deprecated in automake1.11.

(for the reader: reasoning for automake1.11 documented in #751424)


Before:
$ dpkg-deb -c libjpeg62_6b1-4_ppc64el.deb | fgrep .so
$

After:
$ dpkg-deb -c libjpeg62_6b1-4.1_ppc64el.deb | fgrep .so
	-rw-r--r-- root/root167528 2014-06-30 18:21 
./usr/lib/powerpc64le-linux-gnu/libjpeg.so.62.0.0
	lrwxrwxrwx root/root 0 2014-06-30 18:21 
./usr/lib/powerpc64le-linux-gnu/libjpeg.so.62 -> libjpeg.so.62.0.0



Thanks!

--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru libjpeg6b-6b1/debian/changelog libjpeg6b-6b1/debian/changelog
--- libjpeg6b-6b1/debian/changelog  2013-12-05 20:43:54.0 -0200
+++ libjpeg6b-6b1/debian/changelog  2014-06-30 18:20:38.0 -0300
@@ -1,3 +1,10 @@
+libjpeg6b (6b1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Run dh-autoreconf (requires automake1.11 -Wno-obsolete, see 
automake-Wno-obsolete.patch).
+
+ -- Mauricio Faria de Oliveira   Mon, 30 Jun 2014 
18:18:08 -0300
+
 libjpeg6b (6b1-4) unstable; urgency=high
 
   * Apply upstream patch to fix CVE-2013-6629 and CVE-2013-6630.
diff -Nru libjpeg6b-6b1/debian/control libjpeg6b-6b1/debian/control
--- libjpeg6b-6b1/debian/control2012-06-02 11:18:18.0 -0300
+++ libjpeg6b-6b1/debian/control2014-06-30 18:05:51.0 -0300
@@ -2,7 +2,7 @@
 Maintainer: Bill Allombert 
 Section: graphics
 Priority: optional
-Build-Depends: debhelper (>= 5), autotools-dev
+Build-Depends: debhelper (>= 5), autotools-dev, dh-autoreconf, automake1.11
 Standards-Version: 3.9.3
 
 Package: libjpeg62
diff -Nru libjpeg6b-6b1/debian/patches/automake-Wno-obsolete.patch 
libjpeg6b-6b1/debian/patches/automake-Wno-obsolete.patch
--- libjpeg6b-6b1/debian/patches/automake-Wno-obsolete.patch1969-12-31 
21:00:00.0 -0300
+++ libjpeg6b-6b1/debian/patches/automake-Wno-obsolete.patch2014-06-30 
18:17:36.0 -0300
@@ -0,0 +1,19 @@
+Description: automake 1.11 needs -Wno-obsolete due to ansi2knr (for autoreconf)
+ or fails with message 'automatic de-ANSI-fication support is deprecated'.
+Forwarded: not-needed
+Last-Update: 2014-06-30
+Author: Mauricio Faria de Oliveira 
+
+Index: libjpeg6b-6b1/configure.ac
+===
+--- libjpeg6b-6b1.orig/configure.ac2010-05-15 16:28:51.0 -0300
 libjpeg6b-6b1/configure.ac 2014-06-30 18:07:36.0 -0300
+@@ -21,7 +21,7 @@
+ 
+ # Initialize Automake
+ # Don't require all the GNU mandated files
+-AM_INIT_AUTOMAKE([-Wall -Werror ansi2knr no-dist foreign])
++AM_INIT_AUTOMAKE([-Wall -Werror -Wno-obsolete ansi2knr no-dist foreign])
+ 
+ # Make --enable-silent-rules the default.
+ # To get verbose build output you may configure
diff -Nru libjpeg6b-6b1/debian/patches/series 
libjpeg6b-6b1/debian/patches/series
--- libjpeg6b-6b1/debian/patches/series 2013-12-03 19:54:02.0 -0200
+++ libjpeg6b-6b1/debian/patches/series 2014-06-30 18:06:35.0 -0300
@@ -1,3 +1,4 @@
 extern_C-jpeglib.h
 use-autotools-dev
 fix-CVE-2013-6629_6630
+automake-Wno-obsolete.patch
diff -Nru libjpeg6b-6b1/debian/rules libjpeg6b-6b1/debian/rules
--- libjpeg6b-6b1/debian/rules  2013-12-05 08:24:59.0 -0200
+++ libjpeg6b-6b1/debian/rules  2014-06-30 18:05:51.0 -0300
@@ -15,10 +15,14 @@
 endif
 
 #export DH_VERBOSE=1
+export AUTOMAKE = automake-1.11
+export ACLOCAL = aclocal-1.11
+export AUTOHEADER = true
 
 build: build-stamp 
 build-stamp:
dh_testdir
+   dh_autoreconf
./configure --prefix=/usr --mandir=/usr/share/man \
  --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
 --enable-static --enable-shared --enable-maxmem=1024 \
@@ -36,6 +40,7 @@
-rm -f build-stamp stamp-h1
if [ -f Makefile ]; then $(MAKE) clean; fi
-rm -f Makefile jconfig.h config.log config.status  libtool
+   dh_autoreconf_clean
dh_clean
 
 binary-indep: 

Bug#742485: debian-installer: debian-test-amd64-gnome-CD1.iso installs XFCE

[Francewhoa]

Hope the following helps to narrow down the source of that issue

Until that issue is fixed here is a temporary workaround:
* When the graphical installer asks "Configure the package manager" > "Use
a network mirror?" select "No", this will install Gnome from the CD.
Otherwise if you select "Yes" that will install Xcfe from the network
mirror. This might be the source of the issue?

Downside of that workaround
* If you have a laptop the installer will by default install the "Desktop
environment.". The "Laptop" option is not available on the CD :(
* The packages are old. But you can always update them after the install.

Bug#741573: Two menu systems

[Keith Packard]

Colin Watson  writes:

>  * There's no reason that "has a .desktop file" should imply "shows up
>in modern desktop environments", and so I think that the question of
>coverage is to some extent a red herring; the systems have different
>coverage because they've always had different coverage, not because
>the .desktop format is inherently unable to meet the needs of trad
>menu consumers.

That's my view -- the two systems are split because they use a different
file format, and not through any carefully considered reason.

> On the other hand, Keith's draft seems highly aspirational to me.  While
> it seems to me to be broadly the right kind of long-term technical
> direction, there is an awful lot of work in there for people who want
> something like trad menus which is being glossed over.

I think the only piece of work necessary is to add support for .desktop
files to the 'menu' package. With that, other packages are free to
transition from menu files to .desktop files and any existing menu
programs will continue to work as before, while .desktop file consuming
menu programs will slowly see more and more applications to present.

> So, I prefer Ian's position in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#355 for the
> purposes of how the policy text should remain for the time being, and in
> terms of the philosophy of not ripping out work from under people's
> feet.

I guess I'm not sure what work we're ripping out from under people's
feet here. The only significant change proposed is to require support
for .desktop files in the 'menu' package. I would imagine that the
simplest way to add .desktop file support to the 'menu' package would be
to translate .desktop files into menu files and process those through
the existing code base.

> I prefer Keith's position as a long-term direction, but agree
> with Ian that it is lacking an awful lot of transitional thought, and
> feel that it has a lot of things-should-be-done without it being clear
> who will do them.

I feel like there's a mis-characterization of what it would mean to
switch to .desktop files, and whether the change would need to be
all-at-once or could be done incrementally. Here's the transition that I
imagine would occur:

 1) Support for .desktop files is added to the 'menu' package. This
ensures that applications providing only a .desktop file would
continue to appear in menu programs using the existing menu package
infrastructure.

 2) Packages would be encouraged to transition to shipping only .desktop
files. Over time, more and more would start to appear in menu
programs with native .desktop support.

 3) .desktop-based menu program users would start exploring the broader
range of applications shown to them and enjoy the benefits of this
broader selection of tools.

None of these steps places any specific burden on developers, although
skipping step 1) would regress menu programs using menu package support,
dropping any programs which choose to not ship a menu file. I would
expect that to be sufficient incentive for the 'menu' package to add
.desktop file support though.

-- 
keith.pack...@intel.com


pgpKTOr3jEr31.pgp
Description: PGP signature

Bug#752347: highlight: hardcodes /usr/lib/perl5

[gregor herrmann]

Control: tag -1 + patch

On Sun, 22 Jun 2014 23:05:43 +0300, Niko Tyni wrote:

> For this to work, packages containing binary perl modules need to migrate
> from using the hardcoded /usr/lib/perl5 directory to the value of the
> $Config{vendorarch} variable, as defined in the 'Config' module.

Attached is a patch that uses $Config{vendorarch} in an executable
.install file.

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Dave Brubeck: Trolley Song
diff -Nru highlight-3.9/debian/changelog highlight-3.9/debian/changelog
--- highlight-3.9/debian/changelog	2012-05-23 18:32:13.0 +0200
+++ highlight-3.9/debian/changelog	2014-06-30 23:25:44.0 +0200
@@ -1,3 +1,14 @@
+highlight (3.9-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "hardcodes /usr/lib/perl5":
+- make debian/libhighlight-perl.install executable and use
+  $Config{vendorarch} there
+- use debhelper (compat level) 9
+(Closes: #752347)
+
+ -- gregor herrmann   Mon, 30 Jun 2014 23:16:31 +0200
+
 highlight (3.9-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru highlight-3.9/debian/compat highlight-3.9/debian/compat
--- highlight-3.9/debian/compat	2012-05-23 18:32:13.0 +0200
+++ highlight-3.9/debian/compat	2014-06-30 23:22:13.0 +0200
@@ -1,2 +1,2 @@
-7
+9
 
diff -Nru highlight-3.9/debian/control highlight-3.9/debian/control
--- highlight-3.9/debian/control	2012-05-23 18:32:13.0 +0200
+++ highlight-3.9/debian/control	2014-06-30 23:22:27.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Ayman Negm 
 Uploaders: David Bremner 
-Build-Depends: debhelper (>= 7.0.50), swig, liblua5.1-0-dev, libboost-dev,
+Build-Depends: debhelper (>= 9), swig, liblua5.1-0-dev, libboost-dev,
 	   pkg-config
 Standards-Version: 3.9.3
 Homepage: http://www.andre-simon.de
diff -Nru highlight-3.9/debian/libhighlight-perl.install highlight-3.9/debian/libhighlight-perl.install
--- highlight-3.9/debian/libhighlight-perl.install	2012-05-23 18:32:13.0 +0200
+++ highlight-3.9/debian/libhighlight-perl.install	2014-06-30 23:23:15.0 +0200
@@ -1,2 +1,8 @@
-examples/swig/highlight.so usr/lib/perl5/auto/highlight
-examples/swig/highlight.pm usr/lib/perl5
+#!/usr/bin/perl -w
+
+use Config;
+
+my $vendorarch = substr($Config{vendorarch}, 1);
+
+print "examples/swig/highlight.so $vendorarch/auto/highlight\n";
+print "examples/swig/highlight.pm $vendorarch\n";


signature.asc
Description: Digital Signature

Bug#753361: gnome-shell: window manager: CurrentTime used to choose focus window; focus window may not be correct

[luskin]

Package: gnome-shell
Version: 3.4.2-7+deb7u1
Severity: important

Dear Maintainer,

sometimes the shell stops responding to mouse clicks (even cursor moving).
I found this on .xsession-errors

Avviso del window manager: CurrentTime used to choose focus window; focus 
window may not be correct.
Avviso del window manager: Got a request to focus 0x1a14041 (DOWNLOADS) with a 
timestamp of 0.  This shouldn't happen!
Avviso del window manager: CurrentTime used to choose focus window; focus 
window may not be correct.
Avviso del window manager: Got a request to focus 0x1a4 (Scrivania) with a 
timestamp of 0.  This shouldn't happen!
Avviso del window manager: CurrentTime used to choose focus window; focus 
window may not be correct.
Avviso del window manager: Got a request to focus 0x1a4 (Scrivania) with a 
timestamp of 0.  This shouldn't happen!



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backe  0.12.1-3
ii  gconf-service 3.2.5-1+build1
ii  gir1.2-accountsservice-1.00.6.21-8
ii  gir1.2-atk-1.02.4.0-2
ii  gir1.2-caribou-1.00.4.4-1
ii  gir1.2-clutter-1.01.10.8-2
ii  gir1.2-cogl-1.0   1.10.2-7
ii  gir1.2-coglpango-1.0  1.10.2-7
ii  gir1.2-folks-0.6  0.6.9-1+b1
ii  gir1.2-freedesktop1.32.1-1
ii  gir1.2-gconf-2.0  3.2.5-1+build1
ii  gir1.2-gcr-3  3.4.1-3
ii  gir1.2-gdesktopenums-3.0  3.4.2-3
ii  gir1.2-gdkpixbuf-2.0  2.26.1-1
ii  gir1.2-gee-1.00.6.4-2
ii  gir1.2-gkbd-3.0   3.4.0.2-1
ii  gir1.2-glib-2.0   1.32.1-1
ii  gir1.2-gmenu-3.0  3.4.2-5
ii  gir1.2-gnomebluetooth-1.0 3.4.2-1
ii  gir1.2-gtk-3.03.4.2-7
ii  gir1.2-json-1.0   0.14.2-1
ii  gir1.2-mutter-3.0 3.4.1-5
ii  gir1.2-networkmanager-1.0 0.9.4.0-10
ii  gir1.2-pango-1.0  1.30.0-1
ii  gir1.2-polkit-1.0 0.105-3
ii  gir1.2-soup-2.4   2.38.1-3
ii  gir1.2-telepathyglib-0.12 0.18.2-2
ii  gir1.2-telepathylogger-0.20.4.0-1
ii  gir1.2-upowerglib-1.0 0.9.17-1
ii  gjs   1.32.0-5
ii  gnome-bluetooth   3.4.2-1
ii  gnome-icon-theme-symbolic 3.4.0-2
ii  gnome-settings-daemon 3.4.2+git20121218.7c1322-3+deb7u3
ii  gnome-shell-common3.4.2-7+deb7u1
ii  gnome-themes-standard 3.4.2-2.1
ii  gsettings-desktop-schemas 3.4.2-3
ii  libatk1.0-0   2.4.0-2
ii  libc6 2.13-38+deb7u2
ii  libcairo-gobject2 1.12.2-3
ii  libcairo2 1.12.2-3
ii  libcanberra0  0.28-6
ii  libclutter-1.0-0  1.10.8-2
ii  libcogl-pango01.10.2-7
ii  libcogl9  1.10.2-7
ii  libcroco3 0.6.6-2
ii  libdbus-1-3   1.6.8-1+deb7u2
ii  libdbus-glib-1-2  0.100.2-1
ii  libebook-1.2-13   3.4.4-3
ii  libecal-1.2-113.4.4-3
ii  libedataserver-1.2-16 3.4.4-3
ii  libedataserverui-3.0-13.4.4-3
ii  libffi5   3.0.10-3
ii  libfolks250.6.9-1+b1
ii  libgck-1-03.4.1-3
ii  libgconf-2-4  3.2.5-1+build1
ii  libgcr-3-13.4.1-3
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libgee2   0.6.4-2
ii  libgirepository-1.0-1 1.32.1-1
ii  libgjs0b [libgjs0-libmozjs185-1.0]1.32.0-5
ii  libgl1-mesa-glx [libgl1]  8.0.5-4+deb7u2
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgnome-keyring0 3.4.1-1
ii  libgnome-menu-3-0 3.4.2-5
ii  libgstreamer0.10-00.10.36-1.2
ii  libgtk-3-03.4.2-7
ii  libical0  0.48-2
ii  libjson-gl

Bug#752345: gbrowse: hardcodes /usr/lib/perl5

[gregor herrmann]

Control: tag -1 + patch

On Sun, 22 Jun 2014 23:01:41 +0300, Niko Tyni wrote:

> > For this to work, packages containing binary perl modules need to migrate
> > from using the hardcoded /usr/lib/perl5 directory to the value of the
> > $Config{vendorarch} variable, as defined in the 'Config' module.

Attached is a patch that uses $Config{vendorarch} in d/rules and
debian/gbrowse-calign.dirs.

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Peter Ratzenbeck: Unterwegs / Bye Bye Melk
Index: debian/changelog
===
--- debian/changelog	(revision 17380)
+++ debian/changelog	(working copy)
@@ -1,3 +1,14 @@
+gbrowse (2.54+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't hardcode /usr/lib/perl5:
+- debian/rules: use $Config{vendorarch}
+- debian/gbrowse-calign.dirs: use $Config{vendorarch} and make executable
+- debian/compat: bump to 9
+  Closes: #752345
+
+ -- gregor herrmann   Mon, 30 Jun 2014 23:07:52 +0200
+
 gbrowse (2.54+dfsg-2) unstable; urgency=low
 
   * Transition to apache 2.4 (Closes: #669830).
Index: debian/compat
===
--- debian/compat	(revision 17380)
+++ debian/compat	(working copy)
@@ -1 +1 @@
-8
+9
Index: debian/gbrowse-calign.dirs
===
--- debian/gbrowse-calign.dirs	(revision 17380)
+++ debian/gbrowse-calign.dirs	(working copy)
@@ -1,2 +1,9 @@
-usr/lib/perl5/auto/Bio/Graphics/Browser2/CAlign
-usr/lib/perl5/Bio/Graphics/Browser2/
+#!/usr/bin/perl -w
+
+use Config;
+
+my $vendorarch = substr($Config{vendorarch}, 1);
+
+print "$vendorarch/auto/Bio/Graphics/Browser2/CAlign\n";
+print "$vendorarch/Bio/Graphics/Browser2/\n";
+
Index: debian/rules
===
--- debian/rules	(revision 17380)
+++ debian/rules	(working copy)
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 GBROWSE_BUILD_OPTIONS = --conf=/etc/gbrowse --htdocs=/usr/share/gbrowse/htdocs --tmp=/var/cache/gbrowse --databases=/var/lib/gbrowse/databases --cgibin=/usr/lib/cgi-bin/gbrowse --www-user=www-data --registration_done=1 --persistent=/var/lib/gbrowse
+ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
 
 %: 
 	dh $@ --with apache2
@@ -8,6 +9,11 @@
 override_dh_auto_configure:
 	dh_auto_configure -- $(GBROWSE_BUILD_OPTIONS)
 
+override_dh_installdirs:
+	# svn(-buildpackage) seems to ignore the x bit
+	chmod +x debian/gbrowse-calign.dirs
+	dh_installdirs
+
 override_dh_auto_install:
 	./Build  --install_base=debian/gbrowse debianinstall
 	#./Build   apache_conf > debian/gbrowse/etc/gbrowse/gbrowse_apache2.conf
@@ -15,8 +21,8 @@
 	./Build  --install_base=debian/gbrowse install_slave
 	mv debian/gbrowse/lib/perl5/* debian/gbrowse/usr/share/perl5
 	# Remove arch dependant data
-	mv debian/gbrowse/usr/share/perl5/auto/Bio/Graphics/Browser2/CAlign/* debian/gbrowse-calign/usr/lib/perl5/auto/Bio/Graphics/Browser2/CAlign/
-	mv debian/gbrowse/usr/share/perl5/Bio/Graphics/Browser2/CAlign.pm debian/gbrowse-calign/usr/lib/perl5/Bio/Graphics/Browser2/CAlign.pm
+	mv debian/gbrowse/usr/share/perl5/auto/Bio/Graphics/Browser2/CAlign/* debian/gbrowse-calign$(ARCHLIB)/auto/Bio/Graphics/Browser2/CAlign/
+	mv debian/gbrowse/usr/share/perl5/Bio/Graphics/Browser2/CAlign.pm debian/gbrowse-calign$(ARCHLIB)/Bio/Graphics/Browser2/CAlign.pm
 	rm -rf debian/gbrowse/lib
 	rm -f debian/gbrowse/usr/share/doc/gbrowse/INSTALL
 	rm -f debian/gbrowse/usr/share/perl5/auto/GBrowse/.packlist


signature.asc
Description: Digital Signature

Bug#741573: Two menu systems

[Keith Packard]

Ian Jackson  writes:

> Ian Jackson writes ("Re: Bug#741573: Two menu systems"):
>> But I'd like to make some specific comments too.  (I'm reading
>> 24f00b5:741573_menu_systems/keithp_draft.txt, of which I attach a
>> copy.)
> ...
>
> Oh, and:
>
> Fourthly: It makes no provision for the translation into the new
> regime of the carefully curated organisational structure of the
> existing Debian menus.  Without such a translation it amounts to
> throwing away a lot of work.

I tried to cover this here:

4. Discussion of the precise relationship between menu file
   section/hints values and .desktop file Categories values may be
   defined within the Debian Menu sub-policy and Debian Menu
   System.

I could include a strawman translation between these two sets as a part
of this proposal if you think that would help.

-- 
keith.pack...@intel.com


pgpFBke5jjcNX.pgp
Description: PGP signature

Bug#741573: Two menu systems

[Keith Packard]

Ian Jackson  writes:

> I see Keith has committed a draft to git.  As discussed, I disagree
> with this approach.  This amounts to nonconsensually abolishing
> someone's work when it is still being maintained, and the global cost
> is minimal.

Right, as I said in the May TC meeting, I would draft a proposal that
provided an option which was .desktop-focused. It's not complete yet;
several people have graciously pointed out some fairly obvious bugs.

One of the arguments that I had heard expressed against supporting
applications shipping .desktop files is that it would reduce the number
of applications offered in existing menu packages; I'm hoping that my
draft addresses this question by demonstrating that the .desktop format
offers a proper superset of the information found in menu files, and
that package maintainers could mechanically convert their existing menu
files into .desktop files without loss of information.

> Firstly, there is no talk of a transition plan.  There is AIUI
> currently a mixture of programs which provide both kinds of entry and
> programs which provide only one or only the other.  A resolution
> saying that these things should be unified needs to either contain the
> transition plan, or say that someone (who?) should write it.  If the
> transition plan is to be written later, the resolution should also say
> what should happen in the meantime.

I'm afraid that my notion of a transition plan was expressed implicitly
in the proposal rather than explicitly. In any case, the transition plan
I had in mind was pretty simple:

 1. Implement .desktop parsing support in the existing 'menu' package so
that packages providing only .desktop files would be incorporated
into menu programs without further change.

 2. Transition packages from providing menu files to providing .desktop
files, deprecating support for the menu file format within the
archive over time.

These goals were both expressed in terms of 'should' statements in the
proposal, all of which were to be read in standard terms indicating that
failing to follow these policies would be considered a bug.

It sounds like you'd like to see this transition written in a clearer
and more concrete fashion though.

> Secondly, it doesn't discuss how these menus will be organised or
> displayed.  In particular, it doesn't discuss how to manage the
> distinction between:
>   - Menu consumers who want to display a comprehensive menu along
> the lines of the traditional Debian menu;
>   - Menu consumers who want to display a curated or filtered menu
> along the lines of the desktop system menus.
> And, of course, the corresponding distinction between the different
> kinds of program.

Right now, the problem we have is that many common menu programs display
only applications which install .desktop files. I don't think that's a
result of careful curating by the menu programs, but rather that the
menu programs end up choosing between the two menu systems, and are often
selecting the one preferred by the upstream menu program developers.

I'd love to see so many programs in my menu that menu program developers
are encouraged to figure out how to reasonably select entries in menus
so that we can get to some kind of intentional preferential listing
mechanism, rather than the ad-hoc selection that we have today.

However, I don't think that Policy is a sound place to make user
interface design decisions, and that we should naturally defer how to
present the provided application set to the menu program developers. I
believe this part of Policy should focus on stating what application
developers are expected to provide for the menu system, and then let the
menu program do 'something sensible' with the provided data.

The freedesktop.org specifications offer some guidance in this area, but
the wide range of potential user interface implementations for
application selection leaves them without a lot of explicit detail.

> At the very least the resolution needs to acknowledge that these
> distinctions exist and say that they are not being abolished.  Or, if
> they are, say which of the two uses is being abolished.

I think this distinction is entirely an artifact of the current split
between packages, some of which install only a menu file, and some of
which install both menu and .desktop files. I would hope that by
encouraging all packages to deliver only .desktop files, we'll see
developers thinking about sensible ways to present hundreds of
applications to their users.

What I'm hearing you say is that you'd like to ensure that users
continue to have an option of seeing all of the programs they've
installed available in a menu system. I'm emphatically agreeing with you
here, to the point where I'm proposing that we make it normal for *all*
menu programs to present all of the installed programs in their menus,
and then encouraging them to figure out how to display them in a
sensible and efficient manner.

> Thirdly, IMO the resolu

Bug#753360: gsl: please use autoreconf to fix ftbfs on new archs

[Fernando Seiti Furusato]

Source: gsl
Version: 1.16+dfsg-1
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el
User: debian-de...@lists.debian.org
Usertags: autoreconf

Dear Maintainer,

Package gsl fails to build from source on ppc64el.
The usage of dh-autoreconf fixes that and the package builds successfully.

Could you please consider the patch attached? The patch includes dh-autoreconf 
to
debian/rules (including the prof target) properly and adds it as a build-dep.

Thanks.
Fernando


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

Kernel: Linux 3.13-1-powerpc64le (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u gsl-1.16+dfsg/debian/rules gsl-1.16+dfsg/debian/rules
--- gsl-1.16+dfsg/debian/rules
+++ gsl-1.16+dfsg/debian/rules
@@ -87,13 +87,12 @@
 	dh_testdir
 	dh_testdir
 
-	ln -sf /usr/share/misc/config.sub .
-	ln -sf /usr/share/misc/config.guess .
 	rm -f config.cache
 
 	[ -d doc ] || mkdir doc
 	cp -vax debian/Makefile.in.doc doc/Makefile.in
 
+	dh_autoreconf
 	./configure 	CFLAGS="$(CFLAGS)" 		\
 			--prefix=/usr 			\
 			--enable-shared 		\
@@ -113,13 +112,11 @@
 configure-prof-stamp:
 	dh_testdir
 
-	ln -sf /usr/share/misc/config.sub .
-	ln -sf /usr/share/misc/config.guess .
 	rm -f config.cache
 
 	[ -d doc ] || mkdir doc
 	cp -vax debian/Makefile.in.doc doc/Makefile.in
-
+	dh_autoreconf
 	./configure 	CFLAGS="$(CFLAGS)" 		\
 			--prefix=/usr 			\
 			--disable-shared 		\
@@ -172,6 +169,7 @@
 clean:
 	dh_testdir
 	dh_testroot
+	dh_autoreconf_clean
 	rm -f build-stamp install-stamp test-stamp build-doc-stamp \
 		configure-stamp install-doc-stamp configure-prof-stamp \
 		install-prof-stamp
@@ -179,7 +177,6 @@
 	-rm -f doc/*.pdf doc/*.dvi doc/*.log doc/*.ps
 	dh_clean lib/*so* build/*.so*
 	[ ! -f Makefile ] || $(MAKE) distclean || true
-	rm -vf config.sub config.guess
 	rm -rf doc/
 	rm -rf $(debtmp) $(debprof)
 
diff -u gsl-1.16+dfsg/debian/control gsl-1.16+dfsg/debian/control
--- gsl-1.16+dfsg/debian/control
+++ gsl-1.16+dfsg/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Dirk Eddelbuettel 
 Standards-Version: 3.9.4
-Build-Depends: gawk | awk, debhelper (>= 5.0.0), libtool, gcc (>= 4:4.0), binutils (>= 2.12.90.0.9), autotools-dev
+Build-Depends: gawk | awk, debhelper (>= 5.0.0), gcc (>= 4:4.0), binutils (>= 2.12.90.0.9), dh-autoreconf
 Homepage: http://www.gnu.org/software/gsl
 
 Package: libgsl0ldbl

Bug#742485: debian-installer: debian-test-amd64-gnome-CD1.iso installs XFCE

[Francewhoa]

I can confirm this issue

"debian-jessie-DI-a1-amd64-gnome-CD-1.iso" install Xcfe not Gnome

Steps to reproduce issue
1. Go to http://cdimage.debian.org/cdimage/jessie_di_alpha_1/amd64/iso-cd/
Download "debian-jessie-DI-a1-amd64-gnome-CD-1.iso"
2. Install using the "Graphical install" from the top menu
3. When ask "Configure the package manager" > "Use a network mirror?"
select "Yes". This is the default option.
4. Once the installation is completed reboot. "Xcfe" was install. Expected
result is the default installer for that .iso file should install Gnome not
Xcfe.

Using
*
http://cdimage.debian.org/cdimage/jessie_di_alpha_1/amd64/iso-cd/debian-jessie-DI-a1-amd64-gnome-CD-1.iso
downloaded today June 30, 2014
* Laptop Toshiba Tecra A8 at 64 bit
* Internet/Network access

Bug#749769:

[Daniel M.]

Is there a way to work around this bug until 4.13.2 will be in
experimental? I've got most of my files on my NAS and running debian
testing right now...

Bug#753099: glibc FTBFS on alpha: test suite failures

[Aurelien Jarno]

On Sun, Jun 29, 2014 at 09:53:30PM +1200, Michael Cree wrote:
> Source: glibc
> Version: 2.19-4
> Severity: important
> User: debian-al...@lists.debian.org
> Usertags: alpha
> Justification: Fails to build from source but built in the past.
> 
> Finally the fixed gcc-4.8 arrived, however the rebuild of glibc on alpha
> failed with unexpected test suite failures.  From the log:
>
> Encountered regressions that don't match expected failures 
> (debian/testsuite-checking/expected-results-alpha-linux-gnu-libc):
> badsalttest.out, Error 1

This one looks might be worrying, as it might affect the crypt()
function, and thus safety of passwords. Do you have more details about
the failure.

> test-double.out, Error 1
> test-float.out, Error 1
> test-snan.out, Error 1

I guess these three are actually due to the new FP tests that have been
added in 2.19, so it should be relatively fine ignoring them, though it
might be a good idea to confirm that. However it also means that any
new serious failure that might happen latter would not be detected that
way.

> tst-backtrace2.out, Error 1
> tst-backtrace3.out, Error 1
> tst-backtrace4.out, Error 1
> tst-backtrace5.out, Error 1
> tst-backtrace6.out, Error 1

I don't think having the backtrace function working is something
critical for a system, so yes they can be ignored. It might be
interesting to see what caused them to stop working though.

> tst-ptrguard1.o, Error 1
> tst-stackguard1-static.o, Error 1
> tst-stackguard1.o, Error 1
> 
> The last three are fixed by upstream commit a3df56fcae7
> (alpha: Fix __pointer_chk_guard definition for the testsuite).

Thanks for the pointer, I have just committed the patch to the SVN.

> The others I am inclined to have added to the expected failure list in
> debian/testsuite-checking/expected-results-alpha-linux-gnu-libc.  Note
> that they only need to be added to the alpha libc library not to 
> the alphaev67 variant libary as all of these tests pass correctly
> under the latter library.

I think that's fine, except for badsalttest.out. Do you have more
details about the failure, so that we can conclude if it is fine
ignoring it or not? Then I'll do the changes in the expected results.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753358: Bug#743977: drbd8: Xen resource script fails when using the xl stack

[Apollon Oikonomopoulos]

Hi Arno,

On 00:31 Wed 09 Apr , Arno Töll wrote:
> Source: drbd8
> Severity: important
> 
> The DRBD resource script for Xen (/etc/xen/scripts/block-drbd) does not work 
> when
> using the xl toolstack anymore, which is exclusively available in xen 4.2 and
> later (i.e. the current Testing).
> 
> First of all, it needs the patch mentioned in [1] for basic support. However, 
> when
> using it in conjunction with pygrub, it fails to find its boot device, whereas
> this worked fine earlier.

These are actually two separate bugs. The first bug is indeed addressed 
with the patch you mention. The pygrub malfunction is a bug probably in 
Xen and already known to the Xen devs:

  http://lists.xen.org/archives/html/xen-devel/2013-01/msg01523.html

For this reason, I'm cloning this bug and reassigning the clone to xen.

Regards,
Apollon


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#244582: Version 2.5 is out

[John Doe]

Version 2.5 is out!!!
http://sourceforge.net/projects/ufoai/files/UFO_AI%202.x/2.5/
Now is totally a free (as in freedom) game.
Please, put it in official repositories.
Thanks!

Bug#743977: drbd8: Xen resource script fails when using the xl stack

[Apollon Oikonomopoulos]

clone 743977 -1
reassign -1 xen
retitle -1 pygrub not working when a disk script is in use
tags 743977 +pending
thanks

Hi Arno,

On 00:31 Wed 09 Apr , Arno Töll wrote:
> Source: drbd8
> Severity: important
> 
> The DRBD resource script for Xen (/etc/xen/scripts/block-drbd) does not work 
> when
> using the xl toolstack anymore, which is exclusively available in xen 4.2 and
> later (i.e. the current Testing).
> 
> First of all, it needs the patch mentioned in [1] for basic support. However, 
> when
> using it in conjunction with pygrub, it fails to find its boot device, whereas
> this worked fine earlier.

These are actually two separate bugs. The first bug is indeed addressed 
with the patch you mention. The pygrub malfunction is a bug probably in 
Xen and already known to the Xen devs:

  http://lists.xen.org/archives/html/xen-devel/2013-01/msg01523.html

For this reason, I'm cloning this bug and reassigning the clone to xen.

Regards,
Apollon


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750757: wheezy-pu: package mobile-broadband-provider-info/20140317-1~deb7u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2014-06-06 at 17:55 +0200, Raphael Geissert wrote:
> On 6 June 2014 17:22, Adam D. Barratt  wrote:
[...]
> > What does the debdiff between current wheezy and the new package look like,
> > given that's what we'd be accepting? :)
> 
> Attached is the full debdiff. There's some autoconf and configure
> noise, the rest is pretty much the same.

Thanks.

+ mobile-broadband-provider-info (20140317-1~deb7u1) wheezy-updates; urgency=low
+
+  * Stable update.

Please just use "wheezy" as the distribution. A slightly more verbose
changelog entry might be useful, but I guess it'll do. :-)

With the above change, please feel free to go ahead, bearing in mind
that the window for 7.6 closes over the coming weekend.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753359: ITP: node-level -- convenience package bundling LevelUP & LevelDOWN

[Andrew Kelley]

Package: wnpp
Severity: wishlist
Owner: Andrew Kelley 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-level
  Version : 0.18.0
  Upstream Author : Rod Vagg 
* URL : https://github.com/Level/level
* License : Expat
  Programming Lang: JavaScript
  Description : convenience package bundling LevelUP & LevelDOWN -
Node.js module

 This is a convenience package that bundles the current release of LevelUP
and
 LevelDOWN and exposes LevelUP on its export.
 .
 Use this package to avoid having to explicitly install LevelDOWN when you
just
 want plain old LevelDB from LevelUP.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#686947: udev tries to modprobe kvm in parallel for every cpu

[Stephan Springl]

Hi Marco,

sorry for taking so long to reply.

On Wed, 25 Jun 2014, intrigeri wrote:

Marco d'Itri wrote (26 Apr 2014 16:15:46 GMT) :

On Sep 07, Stephan Springl  wrote:

when starting and generating the initial events, udevd tries to load
modules kvm and kvm-intel for every running cpu in the system in
parallel.

I understand that this has been fixed by recent kernels or udev
releases, do you mind trying again with the latest from unstable?


Any news?
With home-compiled kernel 3.14.8 and udev 204-8 from jessie, the problem 
seems to have gone. We haven't seen it here for some time.


Regards,
Stephan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752269: texstudio: please enable parallel building

[Tom Jampen]

tag 752269 pending
thanks

On 22.06.2014 01:20, Pino Toscano wrote:
> texstudio seems to build fine with multiple build jobs when building.
> Thus, my suggestion is to enable the parallel build (with the
> --parallel option of dh) to speed up the compilation when requested
> (see also Policy §4.9.1).

Thanks for the patch, Pino. Fixed in git.

Cheers
Tom


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753357: Power button broken due to systemd stealthily installed

[Juliusz Chroboczek]

Package: systemd
Version: 204-8

After a recent upgrade, the power button on my laptop stopped doing
anything useful.

It turned out that a recent upgrade had installed systemd, but without
replacing init with it.  The powerbtn-acpi-support.sh script was detecting
a running systemd-logind, and therefore doing nothing.

Folks, I understand that you're excited about systemd, but this sort of
stealthy pulling in of code is something that really pisses people off.
If I'd rather not be running 15 lines of code as pid 1, please respect
my wishes.

-- Juliusz


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753339: FTBFS with clang instead of gcc

[Iker Salmon San Millan]

Thanks for the report.  The problem is that my sponsor is not longer 
mantaining wicd and is trying to find an adopter for it,  therefore he is not 
longer my sponsor (he already upload a fix after telling me this) .  As soon as 
i find a new one  i will fix it.  

Regards, Iker

El Lunes, 30 de junio de 2014 22:10:14 usted escribió:
> Package: wicd-kde
> Severity: minor
> Tags: patch
> User: pkg-llvm-t...@lists.alioth.debian.org
> Usertags: clang-ftbfs
> 
> Hello,
> 
> Using the rebuild infrastructure, your package fails to build with clang
> (instead of gcc).
> 
> We detected this kinf of error:
> http://clang.debian.net/status.php?version=3.4.2&key=DEFAULT_CONSTRUCTOR
> 
> Full build log is available here:
> http://clang.debian.net/logs/2014-06-16/wicd-kde_0.3.1-1_unstable_clang.log
> 
> Thanks,
> Alexander
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.2.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


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

Bug#753353: debian-policy contains ungrammatical phrase "must by installed"

[Bill Allombert]

On Mon, Jun 30, 2014 at 09:06:36PM +0200, Benedikt Wildenhain wrote:
> Package: debian-policy
> Version: 3.9.5.0
> Severity: minor
> Tags: patch
> 
> Hello,
> 
> policy.sgml contains the following sentence:
> 
> The special value byhand for the section in a .changes
> file indicates that the file in question is not an ordinary package file
> and must by installed by hand by the distribution maintainers.
> ^^^
> 
> This should probably mean "must be installed".

Applied, thanks!

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750017: perl-policy: All packages using Perl vendorarch directory need a perlapi-* dependency

[Bill Allombert]

On Sun, Jun 15, 2014 at 08:49:24PM +0300, Niko Tyni wrote:
> On Fri, Jun 13, 2014 at 10:10:33PM +0200, Bill Allombert wrote:
> 
> > Done. I added the following to upgrading-checklist:
> > 
> > perl
> >Perl package should use the %Config hash to locate module
> >  paths instead of hardcoding paths in @INC.
> >   
> > perl
> >Perl binary modules and any modules installed into
> >  $Config{vendorarch} must depend on the relevant
> >  perlapi-* package.
> > 
> > Hoping this is adequate.
> 
> Thanks! Looks good to me. As a very minor nit,
>  s/Perl package/Perl packages/

Applied, thanks!

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751796: gnutls26: dh-autoreconf (patch available)

[Mauricio Faria de Oliveira]

Hi Andreas,


I will take a look at using a newer automake, and the implied
changes/fixes it might need.


Thank you.


Nicely, only a few minor changes were required.



Would you be OK with carrying a patch for that matter?


Yes, sure. Given that it probably will not be big and gnutls26 does
not get new upstream releases there should not be a maintainance cost.


Cool. I added a patch with more documentation in its description field.

With it applied, gnutls26 builds fine on ppc64el, with no difference
to the packages from powerpc (other than build-id, sure); details below.

Is the attached patch OK for a new upload?



Please note that I will try very hard to get rid of gnutls26 in
jessie.


Ok. I see gnutls28 already runs dh-autoreconf, so it would be OK on
the ppc64el side, AFAICT.

Thank you.




Details:


Comparison of gnutls26's binary packages (powerpc and ppc64el):

$ for arch in powerpc ppc64el; do
mkdir -p contents/$arch &&
cd $arch &&
for deb in *.deb; do
  dpkg-deb -c $deb
| sed 's,\(powerpc\)\|\(powerpc64le\),GNU_ARCH,g'
| cut -d. -f2-
| sort
> ../contents/$arch/${deb%%_*}.contents;
done &&
cd ..;
  done

$ diff -r contents/*
	diff -r contents/powerpc/libgnutls26-dbg.contents 
contents/ppc64el/libgnutls26-dbg.contents

15,20c15,20
< /usr/lib/debug/.build-id/b5/
< 
/usr/lib/debug/.build-id/b5/5a9ca34e104923db1e02451bc4279884af6bf1.debug
< /usr/lib/debug/.build-id/e3/
< 
/usr/lib/debug/.build-id/e3/2523acc3a59567161fd1048e2d6f1058bfd0c9.debug
< /usr/lib/debug/.build-id/ef/
< 
/usr/lib/debug/.build-id/ef/aa8275a54ac989b6b86bf1dc21688b45063446.debug
---
> /usr/lib/debug/.build-id/6b/
> 
/usr/lib/debug/.build-id/6b/e3020e7fa04aacce93d5b27639fadf4bb9c580.debug
> /usr/lib/debug/.build-id/de/
> 
/usr/lib/debug/.build-id/de/f9f14b8787bbe79f40703f1ae57b46a594e774.debug
> /usr/lib/debug/.build-id/f6/
> 
/usr/lib/debug/.build-id/f6/fd796c7c0ec15e54ed16d8bf5bc8d85a85621b.debug
$


--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru gnutls26-2.12.23/debian/changelog gnutls26-2.12.23/debian/changelog
--- gnutls26-2.12.23/debian/changelog   2014-05-31 11:14:33.0 -0300
+++ gnutls26-2.12.23/debian/changelog   2014-06-30 15:10:04.0 -0300
@@ -1,3 +1,10 @@
+gnutls26 (2.12.23-16.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Run dh-autoreconf on build; add fixes for automake 
(30_fix_automake_oldies.patch). (Closes: #751796)
+
+ -- Mauricio Faria de Oliveira   Mon, 30 Jun 2014 
12:56:42 -0300
+
 gnutls26 (2.12.23-16) unstable; urgency=high
 
   * Drop libgnutls26-dbg Conflicts with libgnutls13-dbg, libgnutls28-dbg.
diff -Nru gnutls26-2.12.23/debian/control gnutls26-2.12.23/debian/control
--- gnutls26-2.12.23/debian/control 2014-05-25 03:32:12.0 -0300
+++ gnutls26-2.12.23/debian/control 2014-06-30 15:10:07.0 -0300
@@ -9,7 +9,8 @@
 Build-Depends: debhelper (>= 9), libgcrypt11-dev (>= 1.4.0), zlib1g-dev,
  cdbs (>= 0.4.93), gtk-doc-tools, texinfo (>= 4.8),
  libtasn1-6-dev, autotools-dev, datefudge,
- libp11-kit-dev (>= 0.11) [!or1k], pkg-config, chrpath
+ libp11-kit-dev (>= 0.11) [!or1k], pkg-config, chrpath,
+ dh-autoreconf
 Build-Conflicts: libgnutls-dev
 Standards-Version: 3.9.5
 Vcs-Git: git://anonscm.debian.org/pkg-gnutls/gnutls.git -b gnutls26-master
diff -Nru gnutls26-2.12.23/debian/patches/30_fix_automake_oldies.patch 
gnutls26-2.12.23/debian/patches/30_fix_automake_oldies.patch
--- gnutls26-2.12.23/debian/patches/30_fix_automake_oldies.patch
1969-12-31 21:00:00.0 -0300
+++ gnutls26-2.12.23/debian/patches/30_fix_automake_oldies.patch
2014-06-30 15:10:15.0 -0300
@@ -0,0 +1,125 @@
+Description: Fix warnings from automake oldies
+ This patch fixes the following automake warnings (treated as errors) in order
+ to run dh_autoreconf successfully with current versions of automake (e.g., 
1.14.1):
+ - The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged.
+   You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead,
+   and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files.
+ - warning: 'lib*.la': linking libtool libraries using a non-POSIX
+   archiver requires 'AM_PROG_AR' in 'configure.ac'
+   while processing Libtool library 'lib*.la'
+ - warning: source file '*' is in a subdirectory,
+   but option 'subdir-objects' is disabled
+Forwarded: not-needed
+Last-Update: 2014-06-30
+Author: Mauricio Faria de Oliveira 
+
+Index: gnutls26-2.12.23/aclocal.m4
+===
+--- gnutls26-2.12.23.orig/aclocal.m4   2013-02-04 06:46:27.0 -0200
 gnutls26-2.12.23/aclocal.m42014-06-30 12:36:03.0 -0300
+@@ -495,7 +4

Bug#753345: [pkg-wpa-devel] Bug#753345: wpasupplicant hook for pm-utils breaks pm-suspend when used with wicd

[Stefan Lippers-Hollmann]

Hi

[ CC'ing the wicd maintainers ]

On Monday 30 June 2014, fzacaria...@gmail.com wrote:
> Package: wpasupplicant
> Version: 1.1-1
> Severity: important
> 
> Dear Maintainer,
> 
> After installing wicd and wpasupplicant, suspending the computer
> with pm-suspend stops working.
> The problem lies in the wicd and wpasupplicant installed hooks for
> pm-utils colliding.
> wicd's hook runs first and disconnects my wireless device, causing
> wpa_supplicant process to stop. Then the wpasupplicant's hook runs and
> tries to execute the suspend command but the hook fails because wpa_cli
> can't find the control socket (because it was removed by the previous
> hook!).
> Extract from /var/log/pm-suspend.log:
> ---
> Running hook /usr/lib/pm-utils/sleep.d/60_wpa_supplicant suspend
> suspend:
> Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or
> directory
> /usr/lib/pm-utils/sleep.d/60_wpa_supplicant suspend suspend: Returned
> exit code 255.
> 
> Mon Jun 30 20:03:15 CEST 2014: Inhibit found, will not perform suspend
> Mon Jun 30 20:03:15 CEST 2014: Running hooks for resume
> ---
> 
> This can be reproduced every time. I temporarily fixed it by appending
> "exit 0" to wpasupplicant's hook.
> Better solutions might be:
>   * run this hook before wicd's
>   * verify wpa_supplicant's control socket existance
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
[...]

Unless there is a reason to run wicd's pm-utils hook at 55, rather 
than >= 61[1], I'd tend to reassign this bug to wicd. The reason being
that wicd is the leaf package here, while changing the order for
wpasupplicant might introduce subtile ordering problems with the other 
frontends that are possible to use with wpasupplicant, like ifupdown,
network-manager, networkd (systemd >= 209), connman, et al.

Regards
Stefan Lippers-Hollmann

[1] according to pm-action(8), the 50-74 range seems to be recommended
for these kinds of services.


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

Bug#753356: libraw1394: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4

[Breno Leitao]

Package: libraw1394
Version: 2.1.0-2
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el
User: debian-de...@lists.debian.org
Usertags: autoreconf

Currently libraw1394 FTBFS when compiled in new architectures (as ppc64el) that
is not supported on the outdated package autotools files, with the following
error:

test -z "/usr/lib/powerpc64le-linux-gnu/pkgconfig" || /bin/mkdir -p 
"/«PKGBUILDDIR»/debian/tmp/usr/lib/powerpc64le-linux-gnu/pkgconfig"
 /usr/bin/install -c -m 644 'libraw1394.pc' 
'/«PKGBUILDDIR»/debian/tmp/usr/lib/powerpc64le-linux-gnu/pkgconfig/libraw1394.pc'
make[3]: Leaving directory `/«PKGBUILDDIR»'
make[2]: Leaving directory `/«PKGBUILDDIR»'
make[1]: Leaving directory `/«PKGBUILDDIR»'
   dh_install
dh_install: libraw1394-dev missing files (usr/lib/*/lib*.so), aborting
make: *** [binary] Error 255
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
status 2

The full log could be found at 
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/libraw1394_2.1.0-2_ppc64el.build

I created this patch that call autoreconf to updates the autotool files during
the build, as suggest by the following wiki:

https://wiki.debian.org/qa.debian.org/FTBFS#A2014-01-21_using_dh-autoreconf_during_the_build

I tested it on ppc64el and it worked.

Thank you,
Breno

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

Kernel: Linux 3.13-1-powerpc64le (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
Index: libraw1394-2.1.0/debian/control
===
--- libraw1394-2.1.0.orig/debian/control	2014-06-10 12:31:18.0 +
+++ libraw1394-2.1.0/debian/control	2014-06-30 19:57:34.0 +
@@ -2,7 +2,7 @@
 Priority: optional
 Maintainer: Guus Sliepen 
 Build-Depends: debhelper (>= 9), autotools-dev, dpkg-dev (>= 1.16.1~)
-Build-Depends-Indep: docbook-utils, docbook-xml
+Build-Depends-Indep: docbook-utils, docbook-xml, dh-autoreconf
 Standards-Version: 3.9.5
 Section: libs
 Homepage: https://ieee1394.wiki.kernel.org/
Index: libraw1394-2.1.0/debian/rules
===
--- libraw1394-2.1.0.orig/debian/rules	2013-05-05 09:31:45.0 +
+++ libraw1394-2.1.0/debian/rules	2014-06-30 19:57:28.0 +
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@
+	dh $@ --with autoreconf
 
 override_dh_auto_build-indep:
 	$(MAKE) -C doc libraw1394.pdf libraw1394

Bug#753168: [Pkg-xfce-devel] Bug#753168: xfce4-mailwatch-plugin: Please build against libgnutls28-dev

[Yves-Alexis Perez]

On dim., 2014-06-29 at 19:28 +0200, Andreas Metzler wrote:
> Package: xfce4-mailwatch-plugin
> Version: 1.2.0-1
> Severity: normal
> User: ametz...@debian.org
> Usertags: gnutls3
> 
> Hello,
> 
> Please build xfce4-mailwatch-plugin against libgnutls28-dev (and possibly
> libgcrypt20-dev while you are at it) instead of libgnutls-dev, the
> older GnuTLS version should not be part of jessie.
> 
Unfortunately, it seems that gnutls20 is not API compatible with
gnutls11. For example, gcry_thread_cbs structure has changed (and is
apparently obsolete, too). Is there some kind of porting guide?

Regards,
-- 
Yves-Alexis


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

Bug#752711: libpg-perl: hardcodes /usr/lib/perl5

[Damyan Ivanov]

Control: tag -1 patch

-=| Niko Tyni, 25.06.2014 23:36:02 +0300 |=-
> Package: libpg-perl
> Version: 1:2.1.1-4
> Severity: important
> User: debian-p...@lists.debian.org
> Usertags: perl-5.20-transition
> 
> Starting with version 5.20.0 (currently in experimental), the Debian
> perl package is changing the "vendorarch" library paths (currently
> /usr/lib/perl5) to include the multiarch triplet and the perl version. See
> #748380 for details.
> 
> For this to work, packages containing binary perl modules need to migrate
> from using the hardcoded /usr/lib/perl5 directory to the value of the
> $Config{vendorarch} variable, as defined in the 'Config' module.
> 
> This package fails to build with perl_5.20.0-1 from experimental:
> 
>   install -m 644 -D /«PKGBUILDDIR»/debian/libpg-perl/usr/lib/perl5/Pg.pm 
> /«PKGBUILDDIR»/debian/libpg-perl/usr/share/perl5/Pg.pm
>   install: cannot stat 
> '/«PKGBUILDDIR»/debian/libpg-perl/usr/lib/perl5/Pg.pm': No such file or 
> directory
>   make: *** [binary-arch] Error 1
>   debian/rules:31: recipe for target 'binary-arch' failed

Please find a patch that uses $Config{vendorarch} for finding the 
right directory where arch-specific files are installed.

Cheers,
dam
diff --git a/debian/rules b/debian/rules
index 2e327d4..150b153 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,6 +5,7 @@
 
 HERE=$(shell pwd)
 LIB=$(HERE)/debian/libpg-perl
+VENDORARCH := $(shell perl -MConfig -e'print substr($$Config{vendorarch},1)')
 
 ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
 	CONFFLAGS:= OPTIMIZE="-O3 -g"
@@ -32,7 +33,7 @@ binary-arch: build-stamp
 	dh_testroot
 
 	$(MAKE) DESTDIR=$(LIB) pure_vendor_install 
-	install -m 644 -D $(LIB)/usr/lib/perl5/Pg.pm $(LIB)/usr/share/perl5/Pg.pm
+	install -m 644 -D $(LIB)/$(VENDORARCH)/Pg.pm $(LIB)/usr/share/perl5/Pg.pm
 
 	# install general Debian files
 	dh_installdocs -a README

Bug#752778: When upgrading multiarch, complains about ambiguous name

[Aurelien Jarno]

close 752778 2.19-4
forcemerge 752389 752778
thanks

On Sat, Jun 28, 2014 at 07:29:33AM +0300, Andrei POPESCU wrote:
> Control: reassign -1 libc6
> 
> On Jo, 26 iun 14, 15:43:21, Erwan David wrote:
> > Source: libc6
> > Severity: normal
> > 
> > When upgrading libc6 (on a multiarch installation), I get following
> > messages :
> > 
> > Preparing to unpack .../archives/libc6_2.19-3_i386.deb ...
> > De-configuring libc6:amd64 (2.19-1) ...
> > dpkg-query: error: --listfiles needs a valid package name but 'libc6' is 
> > not: ambiguous package name 'libc6' with more than one installed instance
> > 
> > Use --help for help about querying packages.
> > Unpacking libc6:i386 (2.19-3) over (2.19-1) ...
> > Preparing to unpack .../libc6_2.19-3_amd64.deb ...
> > Unpacking libc6:amd64 (2.19-3) over (2.19-1) ...
> > Preparing to unpack .../libgcc1_1%3a4.9.0-7_i386.deb ...
> > 
> > 
> > So I am not sure the previous version was correctly deconfigured...
> > 


This has already been reported and fixed a few days ago. Merging the
bugs.


-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752870: xul-ext-nostalgy: Also get it

[Ben Whyall]

Package: xul-ext-nostalgy
Version: 0.2.31-1
Followup-For: Bug #752870

Dear Maintainer,

I am still getting the problem with the above version of nostalgy.  It doesnt 
display folder listings and my settings are lost.

Ben

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xul-ext-nostalgy depends on:
ii  icedove  31.0~b1-2

xul-ext-nostalgy recommends no packages.

xul-ext-nostalgy suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753354: ITP: node-level-packager -- helper for distributing leveldown-compatible back-end - Node.js module

[Andrew Kelley]

Package: wnpp
Severity: wishlist
Owner: Andrew Kelley 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-level-packager
  Version : 0.18.0
  Upstream Author : Rod Vagg 
* URL : https://github.com/Level/level-packager
* License : Expat
  Programming Lang: JavaScript
  Description : helper for distributing leveldown-compatible back-end -
Node.js module

 level-packager exports single function which takes a single argument, a
 LevelDOWN-API compatible storage back-end for LevelUP. The function returns
 a constructor function that will bundle LevelUP with the given LevelDOWN
 replacement. The full API is supported, including all optional arguments,
 repair(), delete() and copy(). See level, level-hyper or level-lmdb as
example
 use-cases.
 .
 Also available is a test.js file that can be used to verify that the
 user-package works as expected.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#753355: iceweasel: the basic logon form is being skipped, and the authentication fails.

[alex bodnaru]

Package: iceweasel
Version: 31.0~b3-1
Severity: important

Dear Maintainer,

after upgrading iceweasel to experimental v31, 
pages that need ntlm authentication, and return 
status 401, fail to load.
previously, a basic authentication dialog was 
popping up, allowing to login.

thanks in advance,
alex

-- Package-specific info:

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (300, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages iceweasel depends on:
ii  debianutils   4.4
ii  fontconfig2.11.0-5
ii  libasound21.0.27.2-4
ii  libatk1.0-0   2.12.0-1
ii  libc6 2.19-4
ii  libcairo2 1.12.16-2
ii  libdbus-1-3   1.8.4-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-1
ii  libffi6   3.1-2
ii  libfontconfig12.11.0-5
ii  libfreetype6  2.5.2-1
ii  libgcc1   1:4.9.0-7
ii  libgdk-pixbuf2.0-02.30.7-1
ii  libglib2.0-0  2.40.0-3
ii  libgtk2.0-0   2.24.24-1
ii  libhunspell-1.3-0 1.3.3-1
ii  libnspr4  2:4.10.6-1
ii  libnss3   2:3.16.1-1
ii  libpango-1.0-01.36.3-1
ii  libsqlite3-0  3.8.5-2
ii  libstartup-notification0  0.12-3
ii  libstdc++64.9.0-7
ii  libvpx1   1.3.0-2
ii  libx11-6  2:1.6.2-2
ii  libxext6  2:1.3.2-1
ii  libxrender1   1:0.9.8-1
ii  libxt61:1.1.4-1
ii  procps1:3.3.9-5
ii  zlib1g1:1.2.8.dfsg-1

iceweasel recommends no packages.

Versions of packages iceweasel suggests:
ii  fonts-mathjax  2.4-1
pn  fonts-oflb-asana-math  
ii  fonts-stix [otf-stix]  1.1.1-1
ii  libcanberra0   0.30-2
ii  libgnomeui-0   2.24.5-3
ii  libgssapi-krb5-2   1.12.1+dfsg-3
ii  mozplugger 1.14.5-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753308: iceweasel: please close the bug.

[alex bodnaru]

Package: iceweasel
Followup-For: Bug #753308

Dear Maintainer,

it's a server problem. 
the apache header Strict-Transport-Security enforced use of https on this 
server.

thanks a lot,
alex

-- Package-specific info:

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (300, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages iceweasel depends on:
ii  debianutils   4.4
ii  fontconfig2.11.0-5
ii  libasound21.0.27.2-4
ii  libatk1.0-0   2.12.0-1
ii  libc6 2.19-4
ii  libcairo2 1.12.16-2
ii  libdbus-1-3   1.8.4-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-1
ii  libffi6   3.1-2
ii  libfontconfig12.11.0-5
ii  libfreetype6  2.5.2-1
ii  libgcc1   1:4.9.0-7
ii  libgdk-pixbuf2.0-02.30.7-1
ii  libglib2.0-0  2.40.0-3
ii  libgtk2.0-0   2.24.24-1
ii  libhunspell-1.3-0 1.3.3-1
ii  libnspr4  2:4.10.6-1
ii  libnss3   2:3.16.1-1
ii  libpango-1.0-01.36.3-1
ii  libsqlite3-0  3.8.5-2
ii  libstartup-notification0  0.12-3
ii  libstdc++64.9.0-7
ii  libvpx1   1.3.0-2
ii  libx11-6  2:1.6.2-2
ii  libxext6  2:1.3.2-1
ii  libxrender1   1:0.9.8-1
ii  libxt61:1.1.4-1
ii  procps1:3.3.9-5
ii  zlib1g1:1.2.8.dfsg-1

iceweasel recommends no packages.

Versions of packages iceweasel suggests:
ii  fonts-mathjax  2.4-1
pn  fonts-oflb-asana-math  
ii  fonts-stix [otf-stix]  1.1.1-1
ii  libcanberra0   0.30-2
ii  libgnomeui-0   2.24.5-3
ii  libgssapi-krb5-2   1.12.1+dfsg-3
ii  mozplugger 1.14.5-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753353: debian-policy contains ungrammatical phrase "must by installed"

[Benedikt Wildenhain]

Package: debian-policy
Version: 3.9.5.0
Severity: minor
Tags: patch

Hello,

policy.sgml contains the following sentence:

The special value byhand for the section in a .changes
file indicates that the file in question is not an ordinary package file
and must by installed by hand by the distribution maintainers.
^^^

This should probably mean "must be installed".

Regards,
Benedikt
--- a/policy.sgml	2013-10-18 01:02:39.0 +0200
+++ b/policy.sgml	2014-06-30 16:30:42.573238978 +0200
@@ -3674,7 +3674,7 @@
 	  
 	The special value byhand for the section in a
 	.changes file indicates that the file in question
-	is not an ordinary package file and must by installed by
+	is not an ordinary package file and must be installed by
 	hand by the distribution maintainers.  If the section is
 	byhand the priority should be -.
 	  

Bug#707338: Bug#707341: upgrade to important, python-uno should go away

[Karsten Hilbert]

On Sat, Jun 14, 2014 at 10:07:24PM +0200, Rene Engelhard wrote:

> On Sat, Jun 14, 2014 at 04:23:20PM +0200, Rene Engelhard wrote:
> > still supporting python-uno gives much headache (for example it's build is
> > a big hack and right now it's broken for wizard/lightproof usage inside LO.
> > I am trying to fix it but if I don't succeed we should make -common force
> > python3-uno. Which would mean it conflicted against python-uno...)
> [...]
> > Anyway: I'll try to fix python-uno for LO 4.2.x but I have just decided to
> 
> It was easier than it looked after some tries with the build - a simple
> missing file :) [1]
> 
> > disable building it with LO 4.3 (which IS still planned for jessie).
> [...]
> > So expect python-uno going away without further notice once dovert is fixed,
> > or removed - breaking whatever functionality you need it for. As said,
> > you can make it work again by switching to python3-un
> 
> Now that it's fixed: Maybe also only after jessie release because I do
> acknowledge that it's not much time until the freeze.
> 
> Which would means 4.4 or newer, which I already have changed
> to remove the option alltogether [2]
> 
> Still your package must be changed to support python3. ASAP.

Well, since ATM there is neither any python-wxgtk3 (which
would also mean having to port from wxp2 to wxp3)
nor any python-wxgtk2.8-for-python3 this assertion
seems of little use ?

Or am I missing something ?

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753352: Uncaught NameError when drag-and-dropping a picture into media object list to create new media object

[Paul Kilgo]

Package: gramps
Version: 4.0.4+dfsg-1

This is a report of the same bug which I accidentally filed upstream:

https://gramps-project.org/bugs/view.php?id=7872

I'm receiving this traceback:

38710: ERROR: grampsapp.py: line 114: Unhandled exception
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gramps/plugins/view/mediaview.py",
line 189, in drag_data_received
clean_string = conv_to_unicode(
NameError: global name 'conv_to_unicode' is not defined

when doing the following:

1. Open the media tab.
2. Drag-and-drop a photo (for me a JPG) from the system file browser into
the media list

Expected behavior:

Dialog for adding a new media object invoked

Observed behavior:

Uncaught exception

As said in the ticket, it looks like it's just a missing import problem.
The conv_to_unicode() function appears to live in gramps.gen.constfunc.

I'll caution I was using the 4.0.4 package in the backports for Ubuntu
14.04. I have checked out Debian's 4.0.4+dfsg-1 source package and it
appears to be missing the same imports, and I didn't see a patch or issue
for it.

Upstream said they have this fix in a later version.

Thanks, let me know if I can be of help. Sorry if this is not the proper
place.

Bug#753351: ITP: node-levelup -- Fast & simple storage - a Node.js-style LevelDB wrapper

[Andrew Kelley]

Package: wnpp
Severity: wishlist
Owner: Andrew Kelley 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-levelup
  Version : 0.18.5
  Upstream Author : Rod Vagg 
* URL : https://github.com/rvagg/node-levelup
* License : Expat
  Programming Lang: JavaScript
  Description : Fast & simple storage - a Node.js-style LevelDB wrapper

 LevelDB is a simple key/value data store built by Google, inspired by
BigTable.
 It's used in Google Chrome and many other products. LevelDB supports
arbitrary
 byte arrays as both keys and values, singular get, put and delete
operations,
 batched put and delete, bi-directional iterators and simple compression
using
 the very fast Snappy algorithm.
 .
 LevelUP aims to expose the features of LevelDB in a Node.js-friendly way.
All
 standard Buffer encoding types are supported, as is a special JSON
encoding.
 LevelDB's iterators are exposed as a Node.js-style readable stream a
matching
 writeable stream converts writes to batch operations.
 .
 LevelDB stores entries sorted lexicographically by keys. This makes
LevelUP's
 ReadStream interface a very powerful query mechanism.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#752346: graphviz: hardcodes /usr/lib/perl5

[Damyan Ivanov]

Control: tag -1 patch

-=| Niko Tyni, 22.06.2014 23:03:21 +0300 |=-
> Package: graphviz
> Version: 2.26.3-17
> Severity: important
> User: debian-p...@lists.debian.org
> Usertags: perl-5.20-transition
> 
> Starting with version 5.20.0 (currently in experimental), the Debian
> perl package is changing the "vendorarch" library path (currently
> /usr/lib/perl5) to include the multiarch triplet and the perl version. See
> #748380 for details.
> 
> For this to work, packages containing binary perl modules need to migrate
> from using the hardcoded /usr/lib/perl5 directory to the value of the
> $Config{vendorarch} variable, as defined in the 'Config' module.
> 
> This package builds successfully with perl_5.20.0-1 from experimental,
> but still installs the Perl files into /usr/lib/perl5 so they won't be
> on the Perl search path anymore.

Attached is a patch that makes use of $Config{vendorarch} in 
libgv-perl.install. Note that even though the original file used 
${DEB_HOST_MULTIARCH}, $Config{vendorarch} is still better, as the 
later may also change with different perl releases.

Cheers,
dam
diff --git a/debian/libgv-perl.install b/debian/libgv-perl.install
index f607d6c..933d15e 100755
--- a/debian/libgv-perl.install
+++ b/debian/libgv-perl.install
@@ -1,5 +1,8 @@
-#! /usr/bin/dh-exec --with-scripts=subst-multiarch
-usr/lib/*/graphviz/perl/gv.pm usr/lib/perl5
-usr/lib/*/graphviz/perl/gv.so usr/lib/${DEB_HOST_MULTIARCH}/perl5/auto/gv
-usr/lib/*/graphviz/perl/libgv_perl.so usr/lib/${DEB_HOST_MULTIARCH}/perl5/auto/gv
-usr/share/man/man3/gv.3perl
+#! /usr/bin/perl
+use Config;
+my $vendorarch = substr( $Config{vendorarch}, 1 );
+
+print "usr/lib/*/graphviz/perl/gv.pm $vendorarch\n";
+print "usr/lib/*/graphviz/perl/gv.so $vendorarch/auto/gv\n";
+print "usr/lib/*/graphviz/perl/libgv_perl.so $vendorarch/auto/gv\n";
+print "usr/share/man/man3/gv.3perl\n";

Bug#753348: RFS: gnustep-performance/0.5.0-1 [ITP] -- GNUstep performance library

[Yavor Doganov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gnustep-performance".

 * Package name: gnustep-performance
   Version : 0.5.0-1
   Upstream Author : Richard Frith-Macdonald 
 * URL : http://gnustep.org
 * License : LGPL-3+
   Section : libs
   Programing Lang : Objective-C

It builds these binary packages:

libperformance-dev - GNUstep performance library (development files)
libperformance0.5 - GNUstep performance library (runtime library)
libperformance0.5-dbg - GNUstep performance library (debugging symbols)

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

http://mentors.debian.net/package/gnustep-performance

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

dget -x 
http://mentors.debian.net/debian/pool/main/g/gnustep-performance/gnustep-performance_0.5.0-1.dsc

The ITP bug is #753092.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753349: RFP: yasr -- Javascript library for visualization of SPARQL results

[Kjetil Kjernsmo]

Package: wnpp
Severity: wishlist

* Package name: yasr-js
  Version : 1.1.9
  Upstream Author : Laurens Rietveld 
* URL : http://yasr.yasgui.org/
* License : MIT
  Programming Lang: Javascript
  Description : Javascript library for visualization of SPARQL results

YASR is part of the regular YASGUI web application. YASR provides a
plugin-based visualizations for SPARQL resultsets.


YASR features:

Completely client-side
Easily customizable and extendible
Easily integrates with YASQE
Can handle any valid SPARQL resultset format
Use of common libraries such as jQuery Datatables and CodeMirror
Integration of preflabel.org for fetching URI labels


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753347: dvbcut: Crash when exporting to MPEG program stream DVD DVBCUT multiplexer

[Bernhard Übelacker]

Package: dvbcut
Version: 0.5.4+svn178-7
Severity: important
Tags: patch

Dear Maintainer,
   * What led up to the situation?
- opening an DVB-S transport stream
- setting some start and end marks
- export video with default options (MPEG program stream/DVD DVBCUT
multiplexer)

   * What was the outcome of this action?
- dvbcut crashed

   * What outcome did you expect instead?
- mpeg file get saved



Call Stack:
Program received signal SIGSEGV, Segmentation fault.
av_buffer_unref (buf=buf@entry=0x7fff1b74c6b0) at
/home/build/libavutil/libav-10.1/libavutil/buffer.c:111
111 b = (*buf)->buffer;
(gdb) bt
#0  av_buffer_unref (buf=buf@entry=0x7fff1b74c6b0) at
/home/build/libavutil/libav-10.1/libavutil/buffer.c:111
#1  0x7f7aed422f44 in av_free_packet (pkt=pkt@entry=0x7fff1b74c6b0) at
/home/build/libavutil/libav-10.1/libavcodec/avpacket.c:247
#2  0x7f7aed705e40 in avcodec_encode_video2 (avctx=0xfbdea0,
avpkt=0x7fff1b74c6b0, frame=0x149c740, got_packet_ptr=0x7fff1b74c67c) at
/home/build/libavutil/libav-10.1/libavcodec/utils.c:1331
#3  0x0043c00e in mpgfile::recodevideo (this=this@entry=0xf6a510,
mux=..., start=5638, stop=stop@entry=5640, offset=offset@entry=1384514230,
savedpics=savedpics@entry=1524, savepics=1524, log=0x14360b8) at
mpgfile.cpp:753
#4  0x0043d175 in mpgfile::savempg (this=0xf6a510, mux=...,
start=, start@entry=4116, stop=stop@entry=5640, savedpics=1524,
savedpics@entry=0, savepics=1524, log=0x14360b8) at mpgfile.cpp:682
#5  0x00417bc5 in dvbcut::fileExport (this=0xf218b0) at dvbcut.cpp:737
#6  0x7f7aeabe7a0a in QMetaObject::activate(QObject*, QMetaObject const*,
int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4



Reason:
in function mpgfile::recodevideo a variable pkt is declared, but the field
pkt.buf is never initialized.
Later in function av_free_packet this member is checked for being non-zero and
in this case
the memory it points to freed by av_free_packet:

242 void av_free_packet(AVPacket *pkt)
243 {
244 if (pkt) {
245 FF_DISABLE_DEPRECATION_WARNINGS
246 if (pkt->buf)
247 av_buffer_unref(&pkt->buf);



Patch:
--- dvbcut-0.5.4+svn178.orig/src/mpgfile.cpp
+++ dvbcut-0.5.4+svn178/src/mpgfile.cpp
@@ -731,7 +731,7 @@ void mpgfile::recodevideo(muxer &mux, in
   pts_t startpts=idx[idx.indexnr(start)].getpts();
   while (outpicture

Bug#753345: wpasupplicant hook for pm-utils breaks pm-suspend when used with wicd

[fzacarias3k]

Package: wpasupplicant
Version: 1.1-1
Severity: important

Dear Maintainer,

After installing wicd and wpasupplicant, suspending the computer
with pm-suspend stops working.
The problem lies in the wicd and wpasupplicant installed hooks for
pm-utils colliding.
wicd's hook runs first and disconnects my wireless device, causing
wpa_supplicant process to stop. Then the wpasupplicant's hook runs and
tries to execute the suspend command but the hook fails because wpa_cli
can't find the control socket (because it was removed by the previous
hook!).
Extract from /var/log/pm-suspend.log:
---
Running hook /usr/lib/pm-utils/sleep.d/60_wpa_supplicant suspend
suspend:
Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or
directory
/usr/lib/pm-utils/sleep.d/60_wpa_supplicant suspend suspend: Returned
exit code 255.

Mon Jun 30 20:03:15 CEST 2014: Inhibit found, will not perform suspend
Mon Jun 30 20:03:15 CEST 2014: Running hooks for resume
---

This can be reproduced every time. I temporarily fixed it by appending
"exit 0" to wpasupplicant's hook.
Better solutions might be:
  * run this hook before wicd's
  * verify wpa_supplicant's control socket existance

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

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

Versions of packages wpasupplicant depends on:
ii  adduser   3.113+nmu3
ii  initscripts   2.88dsf-53.2
ii  libc6 2.19-3
ii  libdbus-1-3   1.8.4-1
ii  libnl-3-200   3.2.24-2
ii  libnl-genl-3-200  3.2.24-2
ii  libpcsclite1  1.8.11-3
ii  libreadline6  6.3-6
ii  libssl1.0.0   1.0.1h-3
ii  lsb-base  4.1+Debian13

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753346: RFP: yasqe -- Javascript library for the SPARQL query editors

[Kjetil Kjernsmo]

Package: wnpp
Severity: wishlist

* Package name: yasqe
  Version : 1.2.7
  Upstream Author : Laurens Rietveld 
* URL : http://yasqe.yasgui.org/
* License : MIT
  Programming Lang: Javascript
  Description : Javascript library for the SPARQL query editors


YASQE is part of the regular YASGUI web application. YASQE provides a
simple syntax highlighted text area, bundled with features such as
autocompletion, and the option to query SPARQL endpoints.

Features
YASQE features:

Completely client-side
SPARQL syntax highlighting and error checking
Extremely customizable: All functions and handlers from the CodeMirror 
library are accessible
Persistent values (optional): your query is stored for easier reuse between 
browser sessions
Prefix autocompletion (using prefix.cc)
Property and class autocompletion (using the Linked Open Vocabularies API)
Easily add your own property and class autocompletions if you have them
Handy keyboard shortcuts
Possible to execute the query directly


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#753344: FTBFS with clang instead of gcc

[Alexander]

Source: atril
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs

Hello,

Using the rebuild infrastructure, your package fails to build with clang 
(instead of gcc).

We detected this kinf of error:
http://clang.debian.net/status.php?version=3.4.2&key=CONFLICTING_TYPE

Full build log is available here:
http://clang.debian.net/logs/2014-06-16/atril_1.8.0+dfsg1-2_unstable_clang.log

Thanks,
Alexander

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

Kernel: Linux 3.2.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
--- atril-1.8.0+dfsg1/libview/ev-view.c	2014-03-01 15:53:25.0 +0400
+++ atril-1.8.0+dfsg1-my/libview/ev-view.c	2014-06-30 22:25:35.306279684 +0400
@@ -840,7 +840,7 @@
 }
 
 #if !GTK_CHECK_VERSION (3, 0, 0)
-ev_view_set_scroll_adjustments (GtkLayout  *layout,
+void ev_view_set_scroll_adjustments (GtkLayout  *layout,
 GtkAdjustment  *hadjustment,
 GtkAdjustment  *vadjustment)
 {

Bug#753343: libunique: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4

[Breno Leitao]

Package: libunique
Version: 1.1.6-4
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el
User: debian-de...@lists.debian.org
Usertags: autoreconf

Currently libunique FTBFS when compiled in new architectures (as ppc64el) that
is not supported on the outdated package autotools files, with the following
error:

dh_install: libunique-1.0-0 missing files (usr/lib/libunique-1.0.so.*), 
aborting
make: *** [binary-install/libunique-1.0-0] Error 255
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
status 2

The full log could be found at 
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/libunique_1.1.6-4_ppc64el.build

I created this patch that call autoreconf to updates the autotool files during
the build, as suggest by the following wiki:

https://wiki.debian.org/qa.debian.org/FTBFS#A2014-01-21_using_dh-autoreconf_during_the_build

I tested it on ppc64el and it worked.

Thank you,
Breno
Index: libunique-1.1.6/debian/control
===
--- libunique-1.1.6.orig/debian/control	2014-06-30 18:21:27.0 +
+++ libunique-1.1.6/debian/control	2014-06-30 18:22:49.0 +
@@ -17,7 +17,8 @@
libx11-dev,
libdbus-glib-1-dev (>= 0.70),
gtk-doc-tools (>= 1.11),
-   intltool
+   intltool,
+   dh-autoreconf
 Standards-Version: 3.9.2
 Vcs-Svn: svn://anonscm.debian.org/svn/pkg-gnome/packages/unstable/libunique
 Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-gnome/packages/unstable/libunique
Index: libunique-1.1.6/debian/rules
===
--- libunique-1.1.6.orig/debian/rules	2014-06-30 18:21:27.0 +
+++ libunique-1.1.6/debian/rules	2014-06-30 18:22:36.0 +
@@ -5,6 +5,7 @@
 include /usr/share/cdbs/1/rules/utils.mk
 include /usr/share/cdbs/1/class/gnome.mk
 include /usr/share/gnome-pkg-tools/1/rules/uploaders.mk
+include /usr/share/cdbs/1/rules/autoreconf.mk
 -include /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk
 
 LDFLAGS += -Wl,-z,defs -Wl,-O1 -Wl,--as-needed