date:20130610

reassign 649079 gnome-control-center
forwarded 649079 https://bugzilla.gnome.org/show_bug.cgi?id=575991
thanks

On 10/06/13 03:27, Gonzalo Berm��dez wrote:
 Package: gnome-bluetooth
 Version: 3.4.2-1
 Followup-For: Bug #649079
 
 Although there's no GUI to get that changed, you can set a variable named
 PRETTY_HOSTNAME in /etc/machine-info (this file most likely won't exist) to 
 set
 the bluetooth device's name.

No need for that. gnome-bluetooth could set the adapter name through bluez's
dbus API.

 
 This file is part of a freedesktop tool named hostnamectl, I discovered it
 while playing with Fedora 18. Didn't get a clue from Debian. Guess it hasn't
 landed here yet.

Probably part of newer systemd than what is in Debian.

Emilio


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

Bug#711774: Re: [exact-image] Re: Bug#711774: exactimage: dcraw vs libraw ?

2013-06-10 Thread Mathieu Malaterre

On Sun, Jun 9, 2013 at 9:08 PM, Sven Eckelmann s...@narfation.org wrote:
 Just a small remark at the beginning: I didn't meant dcraw upstream with
 dcraw guys but the Debian maintainers for dcraw. And I really think it is a
 good question because the package is dead since 3 years and missing some
 updates from upstream.

 (Ok, the embedded copy of dcraw in exactimage seems to be older)

 On Sunday 09 June 2013 19:37:03 Rene Rebe wrote:
 I think dcraw did all the original research and he does not want to make it
 a library because he believes an executable to call is the unix way and a
 library he could boy change so flexible. This is why I embedded the not too
 big code to make it a simple built in library inside exact image.

 This is correct, but is not really about the problem here. Just to give more
 insight in what Mathieu Malaterre said:

 Embedded copies of code are bad when used in Distributions because (just some
 examples):
  * they increase the binary size when there would be shared object that could
be used instead
  * they increase memory usage because different programs cannot share the
loaded library
  * they are hard to maintain

 Ok, the first two points are easy to understand but the last one might be
 quite vague. So here an explanation with two different scenarios (actually it
 is the same example but with different impacts):

 dcraw gets a new version (lets call it 9.18 for obvious reasons) with X-Trans
 and EOS C500 support. Now all programs using an embedded copy have to be
 updated in Debian to bring these versions on par with the upstream one and fix
 outstanding bugs/request for EOS C500/X-Trans. This is not really trivial
 because the programs have to be identified first and then the maintainer has
 to be waken up. This is a lot of work and time spend on a task that is
 completely unnecessary. Therefore, it is better to use the library version
 when available. And yes, I am fully aware that interface changes are problems
 which can be a negative effect when switching to external libraries.

 Now to the part with a little more impact. Lets assume that dcraw has a bug
 which can be exploited quite easily (send a prepared image which causes some
 buffer overflows and so on). Now it is extreme important to find all versions
 of the embedded copy because otherwise it is a security risk. You don't really
 want to provide an web service doing raw image conversions when there might be
 a big security hole because the security bug was fixed in the original
 program/library but not in the embedded copy.

 So back to the main questions. Do you see a possible way to switch from your
 dcraw version to libraw and make more of the embedded copies optional? I know,
 the embedded copies from libjpeg for jpeg rotation are for example really hard
 because libjpeg doesn't export the necessary stuff. But it seemed to have
 caused some headaches for the previous maintainers of this package because no
 one updated the embedded copy of jpegint/transupp and it just crashed when
 used together with never versions of libjpeg like libjpeg8. And the current
 one in exactimage upstream still does.

Very well summarized, Sven !

Security was mostly my main objection, since exactimage offer perl,
python and php5 bindings it is quite likely this will be used on
webserver, therefore security risk is not anymore just a theoretical
issue.

Regards,


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

Bug#711254: [php-maint] Bug#711254: It's a problem of PHP and not MySQL

2013-06-10 Thread Ondřej Surý

Please provide your php5 versions (dpkg -l '*php5*').

Ondřej Surý

On 10. 6. 2013, at 2:30, Bob Proulx b...@proulx.com wrote:

 reassign 711254 php5
 tag 711254 + moreinfo
 thanks
 
 Karsten Malcher wrote:
 In case of wikimedia no clear update command is send, but in phpbb i
 could see that the update is blank instead of the content.
 1339 Query UPDATE phpbb_topics SET topic_title = '', topic_type = 0  
 WHERE topic_id = 1066
 The topic_title should contain a text.
 Something goes wrong in PHP5.
 
 Thank you for the bug report.  However this is very little to go
 upon.  From what you have said so far there isn't enough information
 to know what might be happening.  At this point the problem could be
 anything.
 
 Because php has been updated to 5.5.0 it is most likely that your
 wikimedia and phpbb applications are not updated to work with the
 changes in php 5.5.  I think that is the most likely problem.  If it
 didn't work at all then there would be many reports.  Therefore this
 is probably simply an incompatibility with the recent updates and
 changes in upstream php 5.5.
 
 Since you have the problem, and no one else is seeing the problem so
 far, and you have been making progress debugging it then it would be
 most helpful if you could keep going and get to the bottom of the
 problem.
 
 Thanks,
 Bob
 ___
 pkg-php-maint mailing list
 pkg-php-ma...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint


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

Bug#711824: [gcc-4.8] FTBS when trying to backport to testing

2013-06-10 Thread trophime

Package: gcc-4.8
Version: 4.8.1-2
Severity: normal

I just try to backport latest gcc from sid to jessie.
The package FTBS as gcc-as-needed.diff patch is rejected.

Taking a closer look I notice that --hash-style=both 
and not --hash-style=gnu as expected in the files to be patched.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.2.0-4-amd64

Debian Release: jessie/sid
  500 testing-proposed-updates ftp.fr.debian.org 
  500 testing security.debian.org 
  500 testing http.us.debian.org 
  500 testing ftp.fr.debian.org 
  500 testing euler.lcmi.local 
  500 stable  dl.google.com 
  500 jessie  neuro.debian.net 
  500 dataneuro.debian.net 

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

Package's Recommends field is empty.

Package's Suggests field is empty.

-- 


Christophe TROPHIME
Research Engineer

LNCMI
CNRS - LNCMI
25, rue des Martyrs
BP 166
38042 GRENOBLE Cedex 9
FRANCE
CNRS

Tel : +33 (0)4 76 88 90 02 
Fax : +33 (0) 4 76 88 10 01
Office U 19 
M@il : christophe.troph...@lncmi.cnrs.fr 



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

Bug#711825: tgif: Japanese fonts are broken in the exported EPS

2013-06-10 Thread Atsuhito Kohda

Package: tgif
Version: 1:4.2.5-1.2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   If you input Japanese fonts and print a file(ie exported as EPS)
   then you will see broken Japanese (mojibake in Japanese).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Upgraded tgif and modified /etc/X11/ja_JP.eucJP/app-defaults/Tgif
   for Japanese fonts

   * What was the outcome of this action?
   When prit a file containing Japanese font to LaTeX(EPS) format
   I got broken Japanese.

   * What outcome did you expect instead?
   Of course, I expect correct Japanese in EPS file.

FYI.  this is well-known problem and you can get the fix in
http://bourbon.usc.edu/tgif/download.html#tgif-QPL-4.2.5b
it is tgif-QPL-4.2-patch5b.gz 
Thanks for your maintenance.
Best regards,   Mon Jun 10, 2013


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

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

Versions of packages tgif depends on:
ii  debconf [debconf-2.0]  1.5.50
ii  gettext-base   0.18.2.1-1
ii  ghostscript9.05~dfsg-6.3
ii  libc6  2.17-5
ii  libice62:1.0.8-2
ii  libidn11   1.25-2
ii  libsm6 2:1.2.1-2
ii  libx11-6   2:1.5.0-1+deb7u1
ii  libxext6   2:1.3.1-2+deb7u1
ii  libxmu62:1.1.1-1
ii  libxt6 1:1.1.3-1+deb7u1
ii  netpbm 2:10.0-15+b1
ii  python-uniconvertor1.1.4-1+b2
ii  texlive-latex-base 2013.20130530-1
ii  zlib1g 1:1.2.8.dfsg-1

Versions of packages tgif recommends:
ii  xfonts-75dpi  1:1.0.3

tgif suggests no packages.

-- Configuration Files:
/etc/X11/ja_JP.eucJP/app-defaults/Tgif changed [not included]

-- debconf information excluded


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

Bug#711826: no more unattended upgrades since Wheezy is out

2013-06-10 Thread Harald Dunkel

Package: unattended-upgrades
Version: 0.62.2

Since Wheezy is out the unattended-upgrades for Squeeze
don't work anymore. The default configuration in
/etc/apt/apt.conf.d/50unattended-upgrades says

Unattended-Upgrade::Allowed-Origins {
${distro_id} stable;
${distro_id} ${distro_codename}-security;
//  ${distro_id} ${distro_codename}-updates;
//  ${distro_id} ${distro_codename}-proposed-updates;
};

but security upgrades like the most recent libkrb5-3
are not installed automagically. Looking at its
changelog entry I see

krb5 (1.8.3+dfsg-4squeeze7) oldstable-security; urgency=medium

  * Fix cve-2002-2443: kpasswd udp ping-pong  (Closes: #708267)
:
:

Note the oldstable-security.


Regards
Harri


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

Bug#711827: RFA: gthumb -- image viewer and browser

Package: wnpp
Severity: normal

I request an adopter for the gthumb package.

The package description is:
 gThumb is an advanced image viewer and browser. It has many useful
 features, such as filesystem browsing, slide show, image catalogs, web
 album creation, camera import, image CD burning, batch file operations and
 quick image editing features like transformation and color manipulation.
 .
 It's designed for GNOME 2 desktop environment and uses its platform. For
 camera import feature, the gPhoto2 library is used.

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711828: RFA: gtkaml -- XML application markup language for GTK+ and Vala

Package: wnpp
Severity: normal

I request an adopter for the gtkaml package.

The package description is:
 gtkaml is a XML language that extends the Vala.Parser and aimed at creating
 valid GTK+ UI classes.
 It features a compact XML syntax for describing the way Gtk widgets are laid
 out in custom widgets.



-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711839: RFA: gedit-valencia-plugin -- Vala plugin for gedit

Package: wnpp
Severity: normal

I request an adopter for the gedit-valencia-plugin package.

The package description is:
 Valencia is a gedit plugin that turns gedit into a lightweight IDE for Vala.
 Using Valencia, you can easily browse between symbols in a Vala program.  You
 can build a Vala program inside gedit and can easily jump to lines with
 build errors. You can also get tooltips for methods and get autocompletion
 suggestions by invoking autocomplete in the appropriate context.



-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711832: RFA: mockito -- mocking framework for Java

Package: wnpp
Severity: normal

I request an adopter for the mockito package.

The package description is:
 Mockito is a mocking library which lets you write tests with a
 clean and simple API.
 .
 It generates mocks using reflection, it records all mock invocations,
 including methods arguments.



-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711840: RFA: apache-mime4j -- MIME and RFC822 parser for Java

Package: wnpp
Severity: normal

I request an adopter for the apache-mime4j package.

The package description is:
 mime4j provides a parser, MimeStreamParser, for e-mail message streams in
 plain rfc822 and MIME format. The parser uses a callback mechanism to report
 parsing events such as the start of an entity header, the start of a body,
 etc.
 If you are familiar with the SAX XML parser interface you should have no
 problem getting started with mime4j.



-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711833: RFA: postr -- upload photos to Flickr

Package: wnpp
Severity: normal

I request an adopter for the postr package.

The package description is:
 Postr is a Flickr  uploading tool for the GNOME desktop, which aims to be
 simple to use but exposing enough of Flickr to be useful.
 .
 It has a simple user interface, and lets you set common attributes for
 your photos: title, description, tags, sets, groups, privacy, licence, etc.
 .
 It is integrated with Nautilus: you can either run postr when you are
 browsing your photos or just drag them from Nautilus to drop them in Postr.



-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711829: RFA: gphoto2 -- The gphoto2 digital camera command-line client

Package: wnpp
Severity: normal

I request an adopter for the gphoto2 package. The package is currently
maintained by the Debian PhotoTools Team, CCed.

The package description is:
 The gphoto2 library can be used by applications to access various
 digital camera models, via standard protocols such as USB Mass Storage
 and PTP, or vendor-specific protocols.
 .
 This package provide the gphoto2 command-line frontend.

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711837: RFA: mapnik -- C++/Python toolkit for developing GIS applications

Package: wnpp
Severity: normal

I request an adopter for the mapnik package. The package is currently
maintained within the Debian GIS Team, CCed.

The package description is:
 Mapnik is an OpenSource C++/Python toolkit for developing GIS
 (Geographic Information Systems) applications. At the core is a C++
 shared library providing algorithms/patterns for spatial data access and
 visualization.
 .
 Essentially a collection of geographic objects (map, layer, datasource,
 feature, geometry), the library doesn't rely on windowing systems and
 is intended to work in multi-threaded environments
 .
 High-level Python bindings (boost.python) facilitate rapid application
 development, targeting zope3, django, etc.
 .
 This package contains the development headers, API documentation, and
 build utilities.



-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711838: RFA: gettext-ant-tasks -- Java classes for internationalization (i18n)

Package: wnpp
Severity: normal

I request an adopter for the gettext-ant-tasks package.

The package description is:
 Lightweight library combining the power of the unix-style gettext tools
 with the widely used Java ResourceBundles.
 This makes it possible to use the original text instead of arbitrary property
 keys, which is less cumbersome and makes programs easier to read.
 .
 This package contains tasks to be used with the Ant build system.



-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711831: RFA: libgphoto2 -- gphoto2 digital camera library

Package: wnpp
Severity: normal

I request an adopter for the libgphoto2 package. The package is currently
maintained within the Debian PhotoTools Team, CCed.

The package description is:
 The gphoto2 library can be used by applications to access various
 digital camera models, via standard protocols such as USB Mass Storage
 and PTP, or vendor-specific protocols.
 .
 This package contains the library.
 .
 The gphoto2 command-line frontend is shipped separately, in the gphoto2
 package.



-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711834: RFA: pudb -- full-screen, console-based Python debugger

Package: wnpp
Severity: normal

I request an adopter for the pudb package.

The package description is:
 PuDB is a full-screen, console-based visual debugger for Python.
 .
 Its goal is to provide all the niceties of modern GUI-based debuggers
 in a more lightweight and keyboard-friendly package. PuDB allows you
 to debug code right where you write and test it -- in a terminal. If
 you've worked with the excellent (but nowadays ancient) DOS-based
 Turbo Pascal or C tools, PuDB's UI might look familiar.



-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711642: overview at bottom obscures entered letters

2013-06-10 Thread Joachim Breitner

Hi,

thanks for the report. Indeed it should be fixed; I just have to find
out how to scale a TextView the way I currently scale a label, while
retaining the ability to interact with the widget. Then one can simply
edit the man view.

Greetings,
Joachim

-- 
Joachim nomeata Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata




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

Bug#711836: webdruid: unsatisfiable build-dep on automake1.11

2013-06-10 Thread Julien Cristau

Source: webdruid
Version: 0.5.4-12.1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: jessie sid
Control: block 706828 with -1

Hi,

webdruid build-depends on automake1.11, but that package is no longer in
sid (automake is now at 1.13).

Cheers,
Julien


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

Bug#711830: RFA: leocad -- virtual brick CAD software

Package: wnpp
Severity: normal

I request an adopter for the leocad package.

The package description is:
 LeoCAD is a CAD program that can be used to create virtual models
 with bricks similar to those found in many toys.
 It has an easy to use interface and currently features over 2000
 different pieces created by the LDraw community.



-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711835: RFA: valatoys -- Vala Toys for gEdit

Package: wnpp
Severity: normal

I request an adopter for the valatoys package.

The package description is:
 Vala Toys for gEdit is an experimental collection of plugins that
 extends the gEdit editor to make it a better developer editor.
 .
 Vtg tries to make less compromises as possible so, for now, its scope
 is narrowed only to support the Vala programming language.
 .
 Vtg is written in Vala itself and it is currently composed of just
 one plugin with four modules and it adds to gEdit:
 .
  * Bracket completion
  * Symbol completion
  * Project Manager
  * Project build / execute



-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711841: xawtv makes whole system freezed

2013-06-10 Thread Atsuhito Kohda

Package: xawtv
Version: 3.103-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
 only upgrading xawtv from 3.102-3 to 3.103-1

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

   * What was the outcome of this action?
 system was freezex and didn't accept any key iputs etc. so
 I needed to power down by power button.

   * What outcome did you expect instead?
 xawtv runs smoothly

I now downgraded xawtv to 3.102-3 and manually changed version number
in reportbug session.  Please don't ask me try again 3.103-1.
It certainly made my system deep freezed.

Thanks for your maintenance.
Best regards,   Mon Jun 10, 2013


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

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

Versions of packages xawtv depends on:
ii  debconf [debconf-2.0] 1.5.50
ii  lesstif2  1:0.95.2-1.1
ii  libasound21.0.27.1-1
ii  libc6 2.17-3
ii  libfontconfig12.9.0-7.1
ii  libgl1-mesa-glx [libgl1]  8.0.5-6
ii  libice6   2:1.0.8-2
ii  libjpeg8  8d-1
ii  liblircclient00.9.0~pre1-1
ii  libncurses5   5.9+20130504-1
ii  libpng12-01.2.49-4
ii  libsm62:1.2.1-2
ii  libtinfo5 5.9+20130504-1
ii  libx11-6  2:1.5.0-1+deb7u1
ii  libxaw7   2:1.0.10-2
ii  libxext6  2:1.3.1-2+deb7u1
ii  libxft2   2.3.1-1
ii  libxinerama1  2:1.1.2-1+deb7u1
ii  libxmu6   2:1.1.1-1
ii  libxp61:1.0.1-2+deb7u1
ii  libxpm4   1:3.5.10-1
ii  libxrandr22:1.3.2-2+deb7u1
ii  libxrender1   1:0.9.7-1+deb7u1
ii  libxt61:1.1.3-1+deb7u1
ii  libxv12:1.0.7-1+deb7u1
ii  libxxf86dga1  2:1.1.3-2+deb7u1
ii  libxxf86vm1   1:1.1.2-1+deb7u1
ii  libzvbi0  0.2.33-7
ii  pia   3.102-3
ii  scantv3.102-3
ii  v4l-conf  3.103-1
ii  x11-utils 7.7~1
ii  xawtv-plugins 3.102-3
ii  zlib1g1:1.2.8.dfsg-1

xawtv recommends no packages.

Versions of packages xawtv suggests:
pn  tv-fonts none
pn  xawtv-plugin-qt  none

-- debconf information excluded


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

Bug#703424: Regression: CUPS Web interface fails to authenticate Kerberos access to IPP information

Control: tags -1 +moreinfo

Hi Timothy, and thanks for your bugreport,

Le mardi, 19 mars 2013 14.32:33, Timothy Pearson a écrit :
 When using the Web interface to CUPS in a Kerberized environment, CUPS
 fails to pass Kerberos authentication information to the local IPP socket.
  This manifests as access being denied to any pages which access printer
 information, even though the user logged in via Kerberos has been granted
 access to both the pages and printers in question.  The CUPS error log
 shows that it has rejected unauthenticated access to the printers in
 question, even though the prior access to the Web printer list page was
 successfully authenticated.
 
 This appears to be a regression introduced when resolving Bug 640939,
 specifically this patch removes the ability for CUPS to pass Kerberos
 login credentials to the local IPP socket:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=105;filename=cups-1.5.3-2.
 14-nmu.diff;att=1;bug=640939

Can you confirm that this still applies to CUPS 1.6.2 (as uploaded to 
unstable)?

Thanks in advance, cheers,

OdyX


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

Bug#701775: wget: Not reproducible in Debian unstable

Package: wget
Followup-For: Bug #701775

Dear Maintainer,

I just made some tests.
The original bug is not reproducible on current unstable neither on current 
Wheezy.

The same goes for msg#31 - the server seems to have a problem since the
HTTP header looks fine for me (and of course works with an Apache test 
environment).
I also tested all examples of msg#31, all work fine.

It also works on the current Wheezy (i386 kvm virtual machine):
ii  wget1.13.4-3
ii  libc6:i386  2.13-38
ii  libgcrypt11:i3861.5.0-5
ii  libgnutls26:i3862.12.20-7
ii  libgpg-error0:i386  1.10-3.1
ii  libidn11:i386   1.25-2
ii  libuuid1:i386   2.20.1-5.3
ii  zlib1g:i386 1:1.2.7.dfsg-13



-- 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.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 
(charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15)
Shell: /bin/sh linked to /bin/dash

Versions of packages wget depends on:
ii  libc6  2.17-5
ii  libgcrypt111.5.2-2
ii  libgnutls262.12.23-5
ii  libgpg-error0  1.10-3.1
ii  libidn11   1.25-2
ii  libuuid1   2.20.1-5.4
ii  zlib1g 1:1.2.8.dfsg-1

wget recommends no packages.

wget 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#711254: It's a problem of PHP and not MySQL

2013-06-10 Thread Karsten Malcher

Hello Bob,

Am 10.06.2013 02:30, schrieb Bob Proulx:
Thank you for the bug report. However this is very little to go upon. From what you have said so far there isn't
enough information to know what might be happening. At this point the problem could be anything.

Yes - i have the same problem at this time.
But most of the applications are to complex for a simply debug.

Because php has been updated to 5.5.0 it is most likely that your wikimedia and phpbb applications are not updated to
work with the changes in php 5.5. I think that is the most likely problem.

The server installation is complete new (no upgrade) with wheezy from beginning
of may.
I installed most of the applications new to the latest stable releases.
So wikimedia is V 1.20.4.
The migration of the previous version seems not make problems.
What can i do more than to install the actual version?

There is other software that has no newer versions.
E.g. http://www.phpmyedit.org/
Here i have the problem that the software is doing nearly nothing.
There is no error message in the apache2 logs and links and buttons are not
working.
But this error is consistent.

What i cannot understand is why an update is empty depending of the content
(always simple text)?

If it didn't work at all then there would be many reports.

Yes - i wonder about this also .
And i thought that PHP is more downwards compatible.
Hopefully someone will answer with the same problem.

Therefore this is probably simply an incompatibility with the recent updates
and changes in upstream php 5.5.

Up to now i can't find similar problem descriptions.

Since you have the problem, and no one else is seeing the problem so far, and you have been making progress debugging
it then it would be most helpful if you could keep going and get to the bottom of the problem. Thanks, Bob

I must find out how to increase the debug information of php5?

Here the installed packages:

ii libapache2-mod-php5 5.4.4-14 i386 server-side, HTML-embedded
scripting language (Apache 2 module)
ii php5 5.4.4-14 all server-side, HTML-embedded
scripting language (metapackage)
ii php5-cli 5.4.4-14 i386 command-line interpreter for
the php5 scripting language
ii php5-common 5.4.4-14 i386 Common files for packages built
from the php5 source

ii php5-curl5.4.4-14
i386 CURL module for php5
ii php5-exactimage 0.8.5-5i386 fast image manipulation library
(PHP bindings)

ii php5-gd 5.4.4-14
i386 GD module for php5
ii php5-geoip 1.0.7-8
i386 GeoIP module for php5
ii php5-imagick 3.1.0~rc1-1+b2
i386 ImageMagick module for php5
ii php5-imap5.4.4-14
i386 IMAP module for php5
ii php5-intl5.4.4-14 i386 internationalisation module for
php5

ii php5-mcrypt 5.4.4-14
i386 MCrypt module for php5
ii php5-mysql 5.4.4-14
i386 MySQL module for php5
ii php5-pspell 5.4.4-14
i386 pspell module for php5
ii php5-recode 5.4.4-14
i386 recode module for php5
ii php5-sqlite 5.4.4-14
i386 SQLite module for php5

Cheers
Karsten

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

Bug#711842: jabref: Fails to start with openjdk-7

2013-06-10 Thread Tobias Winchen

Package: jabref
Version: 2.10~beta1+ds-2
Severity: important

Dear Maintainer,

jabref fails to start with openjdk-7:

DEBUG_WRAPPER=1 JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/ jabref

[debug] /usr/bin/jabref: Using provided JAVA_HOME = '/usr/lib/jvm/java-7
-openjdk-amd64/'
[debug] /usr/bin/jabref: Found JAVA_HOME = '/usr/lib/jvm/java-7-openjdk-amd64/'
[debug] /usr/bin/jabref: Found JAVA_CMD = '/usr/lib/jvm/java-7-openjdk-
amd64//bin/java'
[debug] /usr/bin/jabref: Environment variable CLASSPATH is ''
[debug] /usr/bin/jabref: Runnning /usr/lib/jvm/java-7-openjdk-amd64//bin/java
-classpath /usr/share/java/jabref.jar:/usr/share/java/JPFCodeGenerator-
rt.jar:/usr/share/java/antlr.jar:/usr/share/java/antlr3.jar:/usr/share/java
/commons-
logging.jar:/usr/share/java/glazedlists.jar:/usr/share/java/jempbox.jar:/usr/share/java
/jgoodies-common.jar:/usr/share/java/jgoodies-forms.jar:/usr/share/java
/jgoodies-looks.jar:/usr/share/java/jpf.jar:/usr/share/java/jpf-
boot.jar:/usr/share/java/microba.jar:/usr/share/java/mysql-connector-
java.jar:/usr/share/java/pdfbox.jar:/usr/share/java/postgresql.jar:/usr/share/java/spin.jar
net.sf.jabref.JabRefMain
log4j:WARN No appenders could be found for logger
(org.java.plugin.ObjectFactory).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
Found 4 plugin(s):
  - net.sf.jabref.core
(jar:file:/usr/share/jabref/JabRef-2.10b.jar!/plugins/net.sf.jabref.core/plugin.xml)
  - adsfetcher
(jar:file:/home/winchen/.jabref/plugins/ADSFetcher-0.3.jar!/plugin.xml)
  - gvkfetcher
(jar:file:/home/winchen/.jabref/plugins/gvkPlugin-0.18.jar!/plugin.xml)
  - net.sf.jabref.export.misq
(jar:file:/usr/share/jabref/JabRef-2.10b.jar!/plugins/net.sf.jabref.export.misq/plugin.xml)

Unable to create graphical interface.


With openjdk-6 jabref works fine.

Brest regards,


Tobias



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

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

Versions of packages jabref depends on:
ii  antlr  2.7.7+dfsg-5
ii  antlr3 3.2-7
ii  default-jre [java6-runtime]1:1.6-47
ii  java-wrappers  0.1.25
ii  libcommons-logging-java1.1.3-1
ii  libglazedlists-java1.8.0.dfsg-4
ii  libjempbox-java1:1.7.0+dfsg-4
ii  libjgoodies-common-java1.4.0-2
ii  libjgoodies-forms-java 1.6.0-4
ii  libjgoodies-looks-java 2.5.2-2
ii  libjpf-java1.5.1+dfsg-4
ii  libjpfcodegen-java 0.4+dfsg-4
ii  libmicroba-java1:0.4.4.3-4
ii  libmysql-java  5.1.16-2
ii  libpdfbox-java 1:1.7.0+dfsg-4
ii  libpostgresql-jdbc-java9.2-1002-1
ii  libspin-java   1.5+dfsg-5
ii  openjdk-6-jre [java6-runtime]  6b27-1.12.5-2
ii  velocity   1.7-4

Versions of packages jabref recommends:
ii  libreoffice-java-common  1:4.0.3-3
ii  libreoffice-writer   1:4.0.3-3
ii  xdg-utils1.1.0~rc1+git20111210-7

Versions of packages jabref suggests:
ii  evince [postscript-viewer]   3.4.0-3.1
ii  ghostscript [postscript-viewer]  9.05~dfsg-6.3
ii  gv [postscript-viewer]   1:3.7.3-1
ii  okular [postscript-viewer]   4:4.8.4-3+b1
pn  xpdf-reader | pdf-viewer none

-- 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#711540: iproute2 FTBFS on sparc

2013-06-10 Thread Michael Tokarev

08.06.2013 15:31, Andreas Henriksson wrote:
 Hello Michael!
 
 I'm mostly offline until next week, but have a quick moment to give
 you a reply on this. (please beware that I've only had a few
 minutes to look into it all.)

And I think that next week is now current, too...
I too was out of the city during the weekend and wasn't able to
reply sooner than now.

Thank you for the the comments.

 It seems the initial bug report mail hasn't reached me... :/

Well, I just submitted a bugreport.  Before, I also wrote to
the address listed in Maintainer: field, -- I sent almost the
same thing as in the bugreport, but were just asking if your
guys need any help or not and what's up with that issue.
After some days without reply I filed the bugreport.

 On Sat, Jun 08, 2013 at 02:21:53AM +0400, Michael Tokarev wrote:
 diff -Nru iproute2-3.9.0/debian/changelog iproute2-3.9.0/debian/changelog
 --- iproute2-3.9.0/debian/changelog  2013-05-08 16:27:40.0 +0400
 +++ iproute2-3.9.0/debian/changelog  2013-06-07 21:54:32.0 +0400
 @@ -1,3 +1,14 @@
 +iproute2 (3.9.0-2.1) unstable; urgency=medium
 +
 +  * Non-maintainer upload.
 +  * Add debian/patches/suseconds-to-long.diff to fix FTBFS on sparc
 +(Closes: #711540)
 
 Not a big issue, your way probably works too... but using the
 upstream commit fixing this would IMHO be better.

I didn't know there's an upstream commit addressing this.  I don't
even know where iproute2 is maintained upstream, -- probaly it'd be
better if I looked.  I just tried to fix the immediate issue (which
is rather trivial), basically leaving the full expertise to someone
who is more familiar with the package.

 +  * Urgency is set to medium because due to the above bug, the package
 +is holding a long and complicated list of other packages which
 +grows and becomes more complicated.
 
 I fail to see this!
 
 Someone would have to have introduced a versioned dependency or
 change from iproute to iproute2. Who has done so?
 
 You mentioned ifupdown, which has the same version in unstable  testing!!!
 
 You also mentioned netcf, which primary reason for not migrating (yet)
 is that it's too young. secondarily that buildds on some arch
 are trying to catch up doesn't seem at all related to iproute2.

Well.  This all may have something to do with my incomplete understanding
of how buildd works.

This is what I have in mind:

 https://buildd.debian.org/status/package.php?p=netcf
 Dependency installability problem for netcf on sparc:

  netcf (= 1:0.2.3-3) build-depends on one of:
  - ifupdown (= 0.7.43)
  - netscript-2.4 (= 5.2.12)

The exact version is not in build-depends, it is from internals of buildd,
it is the version which were available at the time of build but it weren't
installable.  And it _looks_ like inability to install ifupdown on SID
boils down to the fact that iproute[2] just isn't available on SID for sparc,
and ifupdown depends on iproute.

This is the middle of the chain, but it is the most non-obvious step I think.

So as far as I can see, netcf can't be _built_ on _sid_ because one of its
build-deps aren't installable on _sid_ (not testing!), so there's no netcf
available on sid, so any other build-dependent packges can't be built either.

So we're at the situation we're at, with a long(ish) and non-obvious chain
of unsatisfyable build-deps.

My understanding is that a package isn't available as build-dep on sid before
it is built itself on all necessary arches.

Yes you're right that netcf isn't reached 10 days yet (it passes today), but
even if it did, that wont be of any help because of the above.

And yes, netcf is just one of several issues we have with libvirt  qemu.
I'm trying to resolve them all at the same time.

Maybe DELAYED/3 was a bit too soon, especially since we both had no time to
look at it during the weekend.  But on the other hand, the issue and the fix
are so trivial it's a pity this thing is holding anything at all.  If it
actually does -- note I stated at the very beginning that I'm not exactly
sure I understand the working of buildds right.

 No time to look at more of these, but again... I fail to see
 how iproute2 could be blocking anything from migrating.
 
 Please educate me on what I'm missing... (maybe it'll be obvious next
 week when I'm not in such a hurry.)
 
 If you still think the NMU is needed, then don't hold back with
 delayed uploads!

Thank you for the trust!  However, it is always nice, I think, to ask
the maintainer first and to let him to have a chance to review, correct
or maybe even fix the upload, or to implement maybe a better fix he
was planning.  And as I mentioned above, and as you already found out,
I'm not exactly familiar with the package, and I didn't know there's
an upstream fix for that.

How about me cancelling the delayed upload instead, until there's some
time to do that left? ;)

 PS. you mentioned a binNMU which it's clearly not since you're modifying
 the source of the package.

Bug#711822: [Pkg-electronics-devel] Bug#711822: pcb: FTBFS (gtk/gtkgl.h: No such file or directory)

2013-06-10 Thread أحمد المحمودي

reassign 711822 libgtkglext1-dev 1.2.0-3
quit

On Mon, Jun 10, 2013 at 08:13:22AM +0200, Julien Cristau wrote:
 Source: pcb
 Version: 20110918-7
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)
 Tags: jessie sid
 Control: block 706828 with -1
 
 See the build logs at
 https://buildd.debian.org/status/logs.php?pkg=pcbver=20110918-7%2Bb1suite=sid
 
  gcc -std=gnu99 -DLOCALEDIR=\/usr/share/locale\ -DHAVE_CONFIG_H -I. 
  -I../../src -I.. -I../.. -I../../src/icons -I../../src/../gts -I./hid/gtk 
  -D_FORTIFY_SOURCE=2   -DPREFIXDIR=\/usr\ -DBINDIR=\/usr/bin\ 
  -DHOST=\x86_64-pc-linux-gnu\ -DPCBLIBDIR=\/usr/share/pcb\ 
  -DPCBTREEDIR=\/usr/share/pcb/newlib\ 
  -DPCBTREEPATH=\/usr/share/pcb/newlib:/usr/share/pcb/pcblib-newlib\ -g -O2 
  -fstack-protector --param=ssp-buffer-size=4 -Wformat 
  -Werror=format-security-I/usr/include/dbus-1.0 
  -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include   -I/usr/include/glib-2.0 
  -I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -pthread 
  -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include 
  -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 
  -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ 
  -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
  -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 
  -I/usr/include/harfbuzz -pthread -pthread -Wall 
  -Wdeclaration-after-statement -DNDEBUG -g -O2 -fstack-protector 
  --param=ssp-buffer-size=4 -Wformat -Werror=format-security
  -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include   
  -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include   
  -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include 
  -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 
  -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ 
  -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
  -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 
  -I/usr/include/harfbuzz -pthread -pthread -Wall 
  -Wdeclaration-after-statement -MT hid/gtk/libgtk_a-gtkhid-gl.o -MD -MP -MF 
  hid/gtk/.deps/libgtk_a-gtkhid-gl.Tpo -c -o hid/gtk/libgtk_a-gtkhid-gl.o 
  `test -f 'hid/gtk/gtkhid-gl.c' || echo '../../src/'`hid/gtk/gtkhid-gl.c
  ../../src/hid/gtk/gtkhid-gl.c:28:23: fatal error: gtk/gtkgl.h: No such file 
  or directory
  compilation terminated.
  make[6]: *** [hid/gtk/libgtk_a-gtkhid-gl.o] Error 1
---end quoted text---

libgtkglext1-dev needs to add libpangox-1.0-dev to its Depends:

# pkg-config --cflags gtkglext-1.0
Package pangox was not found in the pkg-config search path.
Perhaps you should add the directory containing `pangox.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pangox', required by 'GdkGLExt', not found


-- 
 ‎أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
 GPG KeyID: 0xEDDDA1B7
 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: Digital signature

Bug#711843: libusb-java: Fix FTBFS for distro targets where default-java != openjdk-6

2013-06-10 Thread James Page

Package: libusb-java
Version: 0.8+ztex20090101-5.1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu saucy ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/jniInclude.patch: Restore original auto-detection of JAVAPREFIX so
that package continues to build on targets with default-java != openjdk-6.

Thanks for considering the patch.


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

Kernel: Linux 3.8.0-24-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libusb-java-0.8+ztex20090101/debian/changelog libusb-java-0.8+ztex20090101/debian/changelog
diff -Nru libusb-java-0.8+ztex20090101/debian/patches/jniInclude.patch libusb-java-0.8+ztex20090101/debian/patches/jniInclude.patch
--- libusb-java-0.8+ztex20090101/debian/patches/jniInclude.patch	2012-09-16 19:56:37.0 +0100
+++ libusb-java-0.8+ztex20090101/debian/patches/jniInclude.patch	2013-06-10 09:01:33.0 +0100
@@ -1,14 +1,11 @@
-Index: libusb-java-0.8+ztex20090101/Makefile
-===
 libusb-java-0.8+ztex20090101.orig/Makefile	2011-02-02 13:13:45.0 +0100
-+++ libusb-java-0.8+ztex20090101/Makefile	2012-09-16 20:45:06.0 +0200
-@@ -13,7 +13,8 @@
+--- a/Makefile
 b/Makefile
+@@ -13,7 +13,7 @@
  #
  
  # $(JAVAPREFIX)/include should contain jni.h
 -JAVAPREFIX=/usr/local/java
-+#JAVAPREFIX=$(shell find /usr/lib/jvm/ -name jni.h | sed -e 's/include.*//' | head -n 1)
-+JAVAPREFIX=/usr/lib/jvm/java-6-openjdk-$(shell dpkg-architecture -qDEB_BUILD_ARCH|tr -d \n)
++JAVAPREFIX=$(shell find /usr/lib/jvm/ -name jni.h | sed -e 's/include.*//' | head -n 1)
  
  ###
  # this should not be modified #

Bug#652480: wget: Fails to verify SSL server certificate

Package: wget
Version: 1.14-2
Followup-For: Bug #652480

Dear Maintainer,

while the problem still exists in Debian Sid, a self-compiled wget
(linking to gnutls 3.1) works well.


wget https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip
--2013-06-10 10:08:37--  
https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip
Resolving developer.pidgin.im (developer.pidgin.im)... 67.202.116.116, 
2607:f128:40:2400::16
Connecting to developer.pidgin.im (developer.pidgin.im)|67.202.116.116|:443... 
connected.
ERROR: The certificate of 'developer.pidgin.im' is not trusted.
ERROR: The certificate of 'developer.pidgin.im' hasn't got a known issuer.


../src/wget https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip 
--2013-06-10 10:10:20--  
https://developer.pidgin.im/static/win32/cyrus-sasl-2.1.22.zip
Resolving developer.pidgin.im (developer.pidgin.im)... 67.202.116.116, 
2607:f128:40:2400::16
Connecting to developer.pidgin.im (developer.pidgin.im)|67.202.116.116|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 795294 (777K) [application/zip]
Saving to: 'cyrus-sasl-2.1.22.zip.2'

100%[===]
 795,294  586KB/s   in 1.3s   

2013-06-10 10:10:22 (586 KB/s) - 'cyrus-sasl-2.1.22.zip.2' saved [795294/795294]


[patchwork.sugarlabs.org can't be resolved any more.]



-- 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.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 
(charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15)
Shell: /bin/sh linked to /bin/dash

Versions of packages wget depends on:
ii  libc6  2.17-5
ii  libgcrypt111.5.2-2
ii  libgnutls262.12.23-5
ii  libgpg-error0  1.10-3.1
ii  libidn11   1.25-2
ii  libuuid1   2.20.1-5.4
ii  zlib1g 1:1.2.8.dfsg-1

wget recommends no packages.

wget 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#711780: systemd: boot hangs on checking/mounting FAT or Ext4 filesystems

2013-06-10 Thread Martin Steigerwald

Am Montag, 10. Juni 2013, 00:00:08 schrieb Michael Biebl:
 Am 09.06.2013 19:22, schrieb Martin Steigerwald:
  Package: systemd
  Version: 44-11
  Severity: important
  
  Dear Maintainer,
  
  Today I build a 3.10-rc5 kernel from upstream and rebooted in order to use
  it.
  
  Then systemd hung on mounting or checking /boot/efi (FAT32)
  
  I booted into system rescue mode and commented out /boot/efi in fstab.
  
  Then on reboot systemd hung on mounting or checking /boot (Ext4).
  
  Then I used /sbin/init to boot up the system which comes up just fine.
  
  
  /etc/fstab entries for both:
  
  LABEL=boot  /boot   ext4noatime 
  0   1
  /dev/sda2   /boot/efi   vfatnoatime 
  0   0
  
  
  merkaba:~ blkid | egrep (boot|msdos)
  /dev/sda2: SEC_TYPE=msdos UUID=[…] TYPE=vfat·
  /dev/sda3: LABEL=boot UUID=[…] TYPE=ext4
  
  I am not reporting upstream, since the systemd version in Debian is
  outdated.
  
  
  Since it worked so far I bet some recent update broke it. Can be just a
  few days since I successfully rebooted into a new kernel a few days ago
  with systemd.
 
 The systemd package itself hasn't changed for quite a while, so I
 suspect a change in another package.
 Can you try to use the Debian kernel from sid or wheezy?

Happens also with linux-image-3.9-1-amd64 (3.9.4-1).

With 3.10-rc5 I waited a bit longer for it to happen and got some additional
messages from systemd:

About 9th second of booting:
Started /boot...
EXT4.fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
Started /boot/efi...
FAT-fs (sda2): utf8 is not a recommended IO charset for FAT filesystems will be 
case sensitive!
FAT-fs (sda2): Volume is not properly unmounted. Some data may be corrupt. 
Please run fsck.
[... some kernel messages about psmouse serio2 and IBM Trackpoint ...]

About 15th second of booting:
Dependency failed. Aborted start of /mnt/home-zeit
Welcome to emergency mode. Use systemctl default or ^D to enter default mode.
Give root password for maintenance
(or type Control-D to continue):


I give root password.

Then do

mount /mnt/home-zeit

which works just well.

No errors in dmesg.


/mnt/home-zeit has the root subvol of the /home BTRFS filesystem mounted,
which contains the snapshots so that they can easily be excluded on backup.

LABEL=home  /home   btrfs   
noatime,space_cache,compress=lzo0   0

LABEL=home  /mnt/home-zeit  btrfs   
noatime,space_cache,compress=lzo,subvolid=5 0   0


The filesystem scrubbed just well last Saturday, so I think it is okay.
Will scrub it again today to make sure.


Last update of btrfs-progs was

Start-Date: 2013-05-20  20:32:27
Commandline: apt-get upgrade
Upgrade: libavformat53:amd64 (0.8.6-1, 0.8.7-1), libavformat54:amd64 (9.5-1, 
9.6-1), libstartup-notification0:amd64 (0.12-1, 0.12-3), libevent-2.0-5:amd64 
(2.0.19-stable-3, 2.0.21-stable-1), libavresample1:amd64 (9.5-1, 9.6-1), 
libavfilter2:amd64 (0.8.6-1, 0.8.7-1), libpython2.7-stdlib:amd64 (2.7.5-3, 
2.7.5-4), luatex:amd64 (0.70.1.20120524-3, 0.76.0-1), python-pylibacl:amd64 
(0.5.1-1.1, 0.5.1-1.1+b1), libavcodec-extra-53:amd64 (0.8.6-1, 0.8.7-1), 
libattr1:amd64 (2.4.46-8, 2.4.47-1), libattr1:i386 (2.4.46-8, 2.4.47-1), 
libattr1-dev:amd64 (2.4.46-8, 2.4.47-1), python2.7:amd64 (2.7.5-3, 2.7.5-4), 
libswscale2:amd64 (9.5-1, 9.6-1), ffmpeg:amd64 (0.8.6-1, 0.8.7-1), 
python-pyxattr:amd64 (0.5.1-1.1, 0.5.1-1.1+b1), libav-tools:amd64 (0.8.6-1, 
0.8.7-1), libpython2.7:amd64 (2.7.5-3, 2.7.5-4), libpostproc52:amd64 (0.8.6-1, 
0.8.7-1), dnsmasq-base:amd64 (2.66-1, 2.66-2), libdlrestrictions1:amd64 
(0.15.6, 0.15.7), libgps20:amd64 (3.6-5, 3.9-1), libkpathsea6:amd64 
(2012.20120628-4, 2013.20130516.30500-1), cmake:amd64 (2.8.9-1, 2.8.11-2), 
pkg-kde-tools:amd64 (0.15.6, 0.15.7), python2.7-minimal:amd64 (2.7.5-3, 
2.7.5-4), libavcodec54:amd64 (9.5-1, 9.6-1), libavdevice53:amd64 (0.8.6-1, 
0.8.7-1), cmake-curses-gui:amd64 (2.8.9-1, 2.8.11-2), tex-common:amd64 (4.02, 
4.03), btrfs-tools:amd64 (0.19+20130131-3+really20121004-1, 0.19+20130315-2), 
cmake-data:amd64 (2.8.9-1, 2.8.11-2), printer-driver-m2300w:amd64 (0.51-7, 
0.51-9), ethtool:amd64 (3.4.2-1, 3.9-1), attr:amd64 (2.4.46-8, 2.4.47-1), 
libptexenc1:amd64 (2012.20120628-4, 2013.20130516.30500-1), 
libdbd-mysql-perl:amd64 (4.021-1+b1, 4.023-1), libpython2.7-minimal:amd64 
(2.7.5-3, 2.7.5-4), libavutil51:amd64 (0.8.6-1, 0.8.7-1), libavutil52:amd64 
(9.5-1, 9.6-1), printer-driver-ptouch:amd64 (1.3-4, 1.3-6)
Error: Sub-process /usr/bin/dpkg returned an error code (1)
End-Date: 2013-05-20  20:33:28

I don´t remember the error.

Ah according to term.log.1.gz it was tex:

Log started: 2013-05-20  20:32:27
[…]
tex-common (4.03) wird eingerichtet ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... 
updmap-sys failed. Output has

Bug#711844: illegal-runtime-test-name on capital letters in test names

2013-06-10 Thread Maarten Lankhorst

Package: lintian
Version: 2.5.13

When I was working on some packaging for xorg-integration-tests, I noticed that 
capital letters were not allowed
in a test name. I can run xorg-integration-tests just fine with them, so it 
looks like a bug in lintian, or the
autopkgtest documentation must be changed to explicitly allow capital letters 
in the test names.

$ lintian xorg-integration-tests_0.0.1.20130523-0ubuntu1.dsc
W: xorg-integration-tests source: illegal-runtime-test-name lib.libX11
W: xorg-integration-tests source: illegal-runtime-test-name lib.libXi

The original test binary names are libX11 and libXi in 
xorg-integration-tests.git, so it would make sense to
have the test names the same.


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

Bug#711273: [Pkg-xen-devel] Bug#711273: xen-hypervisor-4.2-amd64: Acn't re-create domains after migration from 4.1 to 4.2

2013-06-10 Thread Bastian Blank

severity -1 important

On Thu, Jun 06, 2013 at 12:57:56AM +0200, JP Pozzi wrote:
 Severity: critical
 Justification: breaks the whole system

Please explain how it breaks the system and not only itself?

 After migration from Xen 4.1 to 4.2 all VMs have disapeared and I am unable to
 re-create my VM from the configfiles.
 When I try xm new com-web i get a python message :

Please provide the config file in question and the contents of
/var/log/xen/xend.log.

 Is it a problem of Python version ?

Unlikely.

The easiest fix is to use the new stack called xl by modifying
/etc/default/xen with TOOLSTACK=xl. This will get the default in the
near future.

Bastian

-- 
What terrible way to die.
There are no good ways.
-- Sulu and Kirk, That Which Survives, stardate unknown


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

Bug#711844: illegal-runtime-test-name on capital letters in test names

2013-06-10 Thread Niels Thykier

reassign 711844 autopkgtest
severity 711844 wishlist
retitle 711844 autopkgtest: Allow uppercase letters in test names
thanks

On 2013-06-10 10:19, Maarten Lankhorst wrote:
 Package: lintian
 Version: 2.5.13
 
 When I was working on some packaging for xorg-integration-tests, I noticed 
 that capital letters were not allowed
 in a test name. I can run xorg-integration-tests just fine with them, so it 
 looks like a bug in lintian, or the
 autopkgtest documentation must be changed to explicitly allow capital letters 
 in the test names.
 

Lintian is following the spec here:


Test names are separated by whitespace and should contain only
characters which are legal in package names, plus `/'.


Uppercase letters are not allowed in package names.

Re-assigning to autopkgtest as a wishlist bug.

 [...]
 
 The original test binary names are libX11 and libXi in 
 xorg-integration-tests.git, so it would make sense to
 have the test names the same.
 
 

~Niels


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

Bug#711254: [php-maint] Bug#711254: It's a problem of PHP and not MySQL

2013-06-10 Thread Ondřej Surý

On Mon, Jun 10, 2013 at 9:58 AM, Karsten Malcher deb...@dct.mine.nu wrote:

 The server installation is complete new (no upgrade) with wheezy from
 beginning of may.
 I installed most of the applications new to the latest stable releases.
 So wikimedia is V 1.20.4.


There was something related to the upgrade of mediawiki in Debian:

http://anonscm.debian.org/viewvc/pkg-mediawiki/mediawiki/trunk/debian/NEWS?view=markup

But I am not sure if this is related to your installation.

Does the affected applications use some common (could be PEAR or PECL or
just some PHP files somewhere) library which you have installed by hand?

Ondrej
-- 
Ondřej Surý ond...@sury.org

Bug#711845: xfce4-verve-plugin: Verve CL plugin breaks auto-hide panel ability

2013-06-10 Thread help

Package: xfce4-verve-plugin
Version: 1.0.0-2
Severity: normal

Dear Maintainer,
When I add verve-plugin to the xfce panel and enter any command, this panel
stops to hide despite of it pointed in panel preferences. Panel stays always
visible until reboot. After reboot this situation repeats again: I enter
anything to verve command-line and panel becomes constantly visible.

I hope it can be solved easily.

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

Kernel: Linux 3.2.0-4-486
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 xfce4-verve-plugin depends on:
ii  exo-utils   0.10.2-2
ii  libc6   2.17-3
ii  libcairo2   1.12.14-4
ii  libdbus-1-3 1.6.10-1
ii  libdbus-glib-1-20.100.2-1
ii  libgdk-pixbuf2.0-0  2.28.1-1
ii  libglib2.0-02.36.1-2build1
ii  libgtk2.0-0 2.24.18-1
ii  libpcre31:8.31-2
ii  libxfce4util6   4.10.1-1
ii  libxfcegui4-4   4.10.0-2
ii  xfce4-panel 4.10.1-1

xfce4-verve-plugin recommends no packages.

xfce4-verve-plugin 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#697158: snappy1.0.3-java: Fixup jar file installation under newer versions of maven-debian-helper

2013-06-10 Thread James Page

Package: snappy1.0.3-java
Version: 1.0.3-rc3~dfsg-3
Followup-For: Bug #697158
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu saucy ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Fixup installation of jar files (LP: #1078012):
- d/snappy1.0.3-java: Use --java-lib to ensure jar file is installed
  to /usr/share/java.
- d/links: Dropped, no longer required.

Ubuntu carried a delta for a while which mean't that jar files where 
automatically
installed to /usr/share/java for the right packages; the links file was 
overwriting
this and causing a link circle.  The same change is now in the Debian version of
m-d-h as well.

Thanks for considering the patch.


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

Kernel: Linux 3.8.0-24-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru snappy1.0.3-java-1.0.3-rc3~dfsg/debian/changelog snappy1.0.3-java-1.0.3-rc3~dfsg/debian/changelog
diff -Nru snappy1.0.3-java-1.0.3-rc3~dfsg/debian/libsnappy1.0.3-java.poms snappy1.0.3-java-1.0.3-rc3~dfsg/debian/libsnappy1.0.3-java.poms
--- snappy1.0.3-java-1.0.3-rc3~dfsg/debian/libsnappy1.0.3-java.poms	2012-09-03 07:36:24.0 +0100
+++ snappy1.0.3-java-1.0.3-rc3~dfsg/debian/libsnappy1.0.3-java.poms	2013-06-10 09:40:16.0 +0100
@@ -25,4 +25,4 @@
 #   --site-xml=location: Optional, the location for site.xml if it needs to be installed.
 # Empty by default. [mh_install]
 #
-pom.xml
+pom.xml --java-lib
diff -Nru snappy1.0.3-java-1.0.3-rc3~dfsg/debian/links snappy1.0.3-java-1.0.3-rc3~dfsg/debian/links
--- snappy1.0.3-java-1.0.3-rc3~dfsg/debian/links	2012-09-03 07:41:38.0 +0100
+++ snappy1.0.3-java-1.0.3-rc3~dfsg/debian/links	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-/usr/share/maven-repo/org/xerial/snappy/snappy1.0.3-java/1.0.3-rc3/snappy1.0.3-java-1.0.3-rc3.jar	/usr/share/java/snappy1.0.3-java.jar

Bug#711254: [php-maint] Bug#711254: It's a problem of PHP and not MySQL

2013-06-10 Thread Karsten Malcher


Hello,

Am 10.06.2013 10:42, schrieb Ondřej Surý:

On Mon, Jun 10, 2013 at 9:58 AM, Karsten Malcher deb...@dct.mine.nu 
mailto:deb...@dct.mine.nu wrote:

The server installation is complete new (no upgrade) with wheezy from 
beginning of may.
I installed most of the applications new to the latest stable releases.
So wikimedia is V 1.20.4.


There was something related to the upgrade of mediawiki in Debian:

http://anonscm.debian.org/viewvc/pkg-mediawiki/mediawiki/trunk/debian/NEWS?view=markup

But I am not sure if this is related to your installation.


The user has all rights for the DB.
There is a good and comfatable installer for mediawiki.
Every checkes and migration works without problem.
I have the reported problems with the user.
For this i will ask the mediawiki team.



Does the affected applications use some common (could be PEAR or PECL or just some PHP files somewhere) library which 
you have installed by hand?


No - i only downloaded the installation file and unpacked it.

Thank you for help.
Karsten



Ondrej
--
Ondřej Surý ond...@sury.org mailto:ond...@sury.org



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

Bug#699274: wget segfault: -T 0 --no-check-certificate

Package: wget
Followup-For: Bug #699274

Dear Maintainer,

this seems to be an issue of wget 1.13 on wheezy.

The following version work as expected:
ii  wget1.11.4-2+lenny2  [lenny]
ii  wget1.12-2.1 [squeeze]
ii  wget1.14-2 [sid]


-- 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.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 
(charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15)
Shell: /bin/sh linked to /bin/dash

Versions of packages wget depends on:
ii  libc6  2.17-5
ii  libgcrypt111.5.2-2
ii  libgnutls262.12.23-5
ii  libgpg-error0  1.10-3.1
ii  libidn11   1.25-2
ii  libuuid1   2.20.1-5.4
ii  zlib1g 1:1.2.8.dfsg-1

wget recommends no packages.

wget 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#711582: jasmin-sable: Patch to fix FTBFS

2013-06-10 Thread James Page

Package: jasmin-sable
Version: 2.4.0-2
Followup-For: Bug #711582
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu saucy ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/rules: Add '-p' option when creating classes dir to prevent FTBFS.

Thanks for considering the patch.


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

Kernel: Linux 3.8.0-24-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru jasmin-sable-2.4.0/debian/changelog jasmin-sable-2.4.0/debian/changelog
diff -Nru jasmin-sable-2.4.0/debian/rules jasmin-sable-2.4.0/debian/rules
--- jasmin-sable-2.4.0/debian/rules	2013-05-22 23:46:56.0 +0100
+++ jasmin-sable-2.4.0/debian/rules	2013-06-10 09:14:41.0 +0100
@@ -10,7 +10,7 @@
 	dh $@
 
 override_dh_auto_build:
-	mkdir classes
+	mkdir -p classes
 	ant build_parser jasmin-jar
 
 override_dh_auto_clean:

Bug#711816: New upstream version available

2013-06-10 Thread Michael Ablassmeier

hi,

On Mon, Jun 10, 2013 at 01:10:20AM -0300, Rog?rio Brito wrote:
 There is a new upstream version available (at the moment, it is 4.34), which
 incorporates both the previous feature request of mine as well as
 canonicalization of the device names.

i will try to care about this in the coming days!


 BTW, the Debian packaging of di could have some some. Do you have it under
 some VCS?

at the moment not, in case we could move it to collab-maint or something!

bye,
- michael


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

Bug#152311: still a bug

2013-06-10 Thread Russell Coker

This one still happens almost 11 years later.

Strangely creating a subdirectory of the freecraft tree that is writable by 
the user doesn't help.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


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

Bug#476545: drbd8-utils: drbd should start before mountnfs.sh mounts ocfs2 filesystems

2013-06-10 Thread Alexis Huxley

Package: drbd8-utils
Version: 2:8.3.13-2
Followup-For: Bug #476545

Hi, just to add that this bug is also preventing ocfs2 filesystems
on drbd devices from being mounted automatically.

I tried using Wiebe's workaround (mentioned earlier in this BTS thread):

 My problem is that drbd is started after xendomains, but drbd needs to be 
 active for starting Xen domains (in my case). 
 
 I added xendomains to the following parameters in /etc/init.d/drbd: 
 
 # X-Start-Before: heartbeat corosync xendomains 
 # X-Stop-After: heartbeat corosync xendomains 

with his xendomains changed to mountnfs (and mountnfs.sh) but without
success.  In the end I just set the mounts to 'noauto' and mount them
from rc.local (and restart nfs-kernel-server too, as my ocfs2 systems
are exported via NFS).

Alexis


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

Bug#711841: xawtv makes whole system freezed

2013-06-10 Thread Maximiliano Curia

¡Hola Atsuhito!

El 2013-06-10 a las 16:02 +0900, Atsuhito Kohda escribió:
* What led up to the situation?
  only upgrading xawtv from 3.102-3 to 3.103-1

* What was the outcome of this action?
  system was freezex and didn't accept any key iputs etc. so
  I needed to power down by power button.
 
 I now downgraded xawtv to 3.102-3 and manually changed version number
 in reportbug session.  Please don't ask me try again 3.103-1.
 It certainly made my system deep freezed.

As much as I understand that you don't want your system to freeze, I can't
reproduce it here so I will need more information about your system.

 -- debconf information excluded

Could you provide the output of: debconf-show xawtv?

Also, what kind of v4l2 input are you using? Could you provide the output of:
lspci and lsusb?

If you have xawtv/build-config in true the postinst script of xawtv might call
scantv, which would open the first v4l2 device and search signals in the
specified frequencies, if this is causing your system to hang I would suspect
of a kernel issue regarding the module for your first v4l2 device (scantv
might be slow, or even buggy, but it shouldn't hang your system, that's
normally a kernel issue.). You can skip the scantv by reconfiguring xawtv and
setting xawtv/build-config: false.

-- 
There are only two things wrong with C++: The initial concept and the
implementation.
-- Bertrand Meyer
Saludos /\/\ /\  `/


signature.asc
Description: Digital signature

Bug#711759: flash-kernel: FTBFS in test_db due to sorting vs. locale issues

2013-06-10 Thread Loïc Minier

On Sun, Jun 09, 2013, Cyril Brulebois wrote:
 I think I'll work around it by exporting LC_ALL=C for wheezy (which is
 affected by a similar issue with the tagged-but-not-uploaded 3.3+deb7u1),
 at least until a proper fix lands in master. Fetching more changes from
 master, including the Bootloader-Sets-Root case change, looks way too
 intrusive for wheezy, and it isn't sufficient anyway.

Yeah, I ran into this when preparing the 3.7 upload, but catched it in
sbuild; I fixed this in 67e61b9cfa883d3b6ec234c773de1e0b01e48476 by
ignoring the case when sorting (and updating the order of fields in the
test), isn't that enough in the backport?

   Cheers,
-- 
Loïc Minier


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

Bug#708548: security policy / root passwords

2013-06-10 Thread Josselin Mouette

Hi,

Le dimanche 09 juin 2013 à 18:45 +0200, Daniel Pocock a écrit : 
 There have been multiple complaints about the new Gnome popup asking for
 the root password
 
 I opened a bug for discussion about the issue, but it was closed by
 another DD (not the maintainer) - [1].  Other users have come across the
 bug too and requested attention for it with the same concerns that I have.
 
 Essentially, my feeling is that users should be encouraged to NEVER put
 their root password into some popup that appears spontaneously on their
 computer.  Having this popup in Debian, by default, desensitizes users
 to the type of popups that will aim to deceive them.

I think there is some big confusion here.

It is not new for GNOME to ask for the root password for actions that
require root permissions. This is done through PolicyKit, which avoids
to run privileged code in the GUI, but which will nevertheless require
to type the root password in an unprivileged process (there is not much
way around that).

What is new is that PackageKit asks for a system update *systematically*
when it finds the system is not up-to-date. I don’t know why, but it
seems to have started with the wheezy release, it did not happen during
the freeze.

I consider it a bug, and one that we should aim to fix in the first
wheezy point release.

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#711846: iceweasel windows resized to 0x0 due to wrongly interpreted maximum width and height

2013-06-10 Thread Robert Bihlmeyer

Package: sawfish
Version: 1:1.5.3-2.1+b1
Severity: serious
Tags: patch

Since iceweasel 17, which hit stable now, resizing a browser window results in 
it being 0x0.
For me, one window is immediately sized to an unusable dimension, another one 
is strangely
unaffected.

This effectively breaks iceweasel for me, thus the severity. If I am the only 
one seeing this,
it can be downgraded, of course.

I am testing backporting an upstream patch right now.


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

Bug#711847: security upgrade to iceweasel 17 (needlessly) breaks cookie monster

2013-06-10 Thread Robert Bihlmeyer

Package: xul-ext-cookie-monster
Version: 1.1.0-4
Severity: grave

With the upgrade to iceweasel 17, cookie monster 1.1.0-4 became uninstallable. 
The changes
from -5 fix that, so this is a request to migrate 1.1.0-5 to wheezy.


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

Bug#708863: GFDL with invariant section

2013-06-10 Thread Bastien ROUCARIES

On Sat, Jun 8, 2013 at 10:01 AM, أحمد المحمودي aelmahmo...@sabily.org wrote:
 On Sun, May 19, 2013 at 11:14:53AM +0200, bastien ROUCARIES wrote:
 dico.info as front cover please render dfsg compliant
 ---end quoted text---

   I don't understand, what is the problem ? and what should I do to fix
   it ?

File under doc/ include license:

Copyright @copyright{} 2008, 2010 Sergey Poznyakoff

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with the Front-Cover texts being ``GNU Dico Manual'',
and with the Back-Cover Texts as in (a) below.  A copy of the license
is included in the section entitled ``GNU Free Documentation License''.

(a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify
this GNU Manual, like GNU software.  Copies published by the Free
Software Foundation raise funds for GNU development.''
@end copying


Please read
http://wiki.debian.org/qa.debian.org/gfdlinvariant


 --
  ‎أحمد المحمودي (Ahmed El-Mahmoudy)
   Digital design engineer
  GPG KeyID: 0xEDDDA1B7
  GPG Fingerprint: 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


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

Bug#711837: RFA: mapnik -- C++/Python toolkit for developing GIS applications

2013-06-10 Thread YunQiang Su

This packages seems in a quite good situation. Is it?

The boost transition will effect this package. Is it will be need to
bump package name then?

On Mon, Jun 10, 2013 at 3:33 PM, David Paleino da...@debian.org wrote:
 Package: wnpp
 Severity: normal

 I request an adopter for the mapnik package. The package is currently
 maintained within the Debian GIS Team, CCed.

 The package description is:
  Mapnik is an OpenSource C++/Python toolkit for developing GIS
  (Geographic Information Systems) applications. At the core is a C++
  shared library providing algorithms/patterns for spatial data access and
  visualization.
  .
  Essentially a collection of geographic objects (map, layer, datasource,
  feature, geometry), the library doesn't rely on windowing systems and
  is intended to work in multi-threaded environments
  .
  High-level Python bindings (boost.python) facilitate rapid application
  development, targeting zope3, django, etc.
  .
  This package contains the development headers, API documentation, and
  build utilities.



 --
  . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
  : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
  `. `'`  GPG: 1392B174 | http://deb.li/dapal
`-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174



-- 
YunQiang Su


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

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

2013-06-10 Thread Vincent Lefevre

Package: cups-client
Version: 1.6.2-8
Severity: grave
Tags: security
Justification: user security hole

I have the following options in .cups/lpoptions:

Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi
Default lipucb-mono-1

The lpq command gives as expected:

lipucb-mono-1 is ready
no entries

But when I print a document with lpr file.pdf, I get nothing on
this printer. Then I tried: lp file.pdf, and I get nothing either
on this printer, but the following line was output in the terminal:

request id is lip-multi-1-292103 (1 file(s))

lip-multi-1 is a printer in a different building...

The LPDEST and PRINTER environment variables are not set.

CUPS 1.5.x didn't have such a problem.

This is a big security problem when one wants to print documents
with confidential information...

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

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

Versions of packages cups-client depends on:
ii  adduser3.113+nmu3
ii  cups-common1.6.2-8
ii  libc6  2.17-5
ii  libcups2   1.6.2-8
ii  libcupsimage2  1.6.2-8

Versions of packages cups-client recommends:
pn  smbclient  none

Versions of packages cups-client suggests:
ii  cups  1.6.2-8
ii  cups-bsd  1.6.2-8
ii  xpp   1.5-cvs20050828-1.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#711846: Patch: iceweasel windows resized to 0x0 due to wrongly interpreted maximum width and height

2013-06-10 Thread Robert Bihlmeyer

Straight from debian/patches.

Description: cap max-width / max-height of a window
 Cherry-picked from upstream commit 798c6992.
 Fixes issues with Iceweasel 17.
Author: Robert Bihlmeyer ro...@orcus.priv.at
Origin: upstream
Bug-Debian: 711846

--- sawfish-1.5.3.orig/src/windows.c
+++ sawfish-1.5.3/src/windows.c
@@ -1286,6 +1286,13 @@ associated with WINDOW. Possible keys in
 hints = VWIN(win)-hints;
 flags = hints-flags;
 
+/* workaround stuff like Firefox 17 that
+ * has enormous max-width/maxh-height */
+if (hints-max_width = 32767)
+   hints-max_width = 32767;
+if (hints-max_height = 32767)
+   hints-max_height = 32767;
+
 /* Some sanity checking */
 if ((flags  PMinSize) 
 (hints-min_width  0 || hints-min_height  0))

Bug#711820: unburden-home-dir: Manpage contains du-related See also

2013-06-10 Thread Axel Beckert

Control: tag -1 + moreinfo

Hi Daniel,

thanks for caring about unburden-home-dir.

Daniel Koch wrote:
 The Man-Page contains this:
 
 SEE ALSO
corekeeper
(http://openvswitch.org/cgi-bin/gitweb.cgi?p=corekeeper),
autotrash(1), agedu(1), bleachbit(1).
 
For du(1)-like but more comfortable tools, see ncdu(1)
(text-mode), baobab(1) (GNOME), filelight(1) (KDE),
xdiskusage(1) (X tool calling du(1) itself), or xdu(1) (X
tool reading du(1) output from STDIN).
 
 This seams to be related to du. I guess it was used as an
 template.

Why should it be from a template?

I actually fail to see the issue here. That entry looks as expected
and intended for me. (... with the exception that there's no more need
for the corekeeper URL as corekeeper is back in Debian. But I guess
that's not what you meant.)

Can you please tell me a little bit more verbose what you think that
is wrong with the cited man-page excerpt?

Or maybe tell me what you would have expected instead of the above
text since it seems not having the effect I intended. My plan was to
point users to tools which can be helpful in finding files they want
to add to their unburden-home-dir configuration.

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


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

Bug#657215: [PATCH videoproto] Xvproto: fix xvEncodingInfo to match actual wire protocol

2013-06-10 Thread Daniel Martin

On 9 June 2013 19:00, Julien Cristau jcris...@debian.org wrote:
 The padding is *before* the rate field, so the rate is placed on a 32bit
 boundary.  This change adds explicit padding between height and rate,
 and removes extraneous padding after the rate field, which the server
 never sent and xlib never read.

 This changes sizeof(xvEncodingInfo).  Hopefully that's not a big deal as
 clients only see the Xlib structure XvEncodingInfo.

(Hopefully, I'm right with that):
I think that's an ABI change and a bit more difficult. Think about an X
server, which is compiled against a xvproto version without that change
and the lib compiled against xvproto with that change. In that case the
lib would start to read the encoding info, where the X server just sended
those extraneous pad bytes.


I just saw that the reply structure itself (xvQueryEncodingsReply) has
such extraneous padding too:
  ...
  CARD32 length B32;
  CARD16 num_encodings B16;
  CARD32 padl3 B32;
  ...
And even without this padding sz_xvQueryEncodingsReply=32 is wrong,
as the fields sum up to 34 and with that padding we're at 36.

Cheers,
Daniel Martin


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

Bug#711837: RFA: mapnik -- C++/Python toolkit for developing GIS applications

On Mon, 10 Jun 2013 17:28:10 +0800, YunQiang Su wrote:

 This packages seems in a quite good situation. Is it?

There is a new upstream version, and it needs to be re-transitioned to
libmapnik (from the current libmapnik2). Also, there's a SONAME bump involved.

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

Control: severity -1 important
Control: tags -1 +moreinfo +unreproducible

Hi Vincent, and thanks for your bugreport,

Le lundi, 10 juin 2013 11.25:57, Vincent Lefevre a écrit :
 I have the following options in .cups/lpoptions:
 
 Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi
 Default lipucb-mono-1

I did lpoptions -d new-default-printer and got that Default line in 
.cups/lpoptions too.

 The lpq command gives as expected:
 
 lipucb-mono-1 is ready
 no entries

Same here.

 But when I print a document with lpr file.pdf, I get nothing on
 this printer. Then I tried: lp file.pdf, and I get nothing either
 on this printer, but the following line was output in the terminal:

When trying here with either lpr or lp, I get the file printed on the correct 
new-default-printer (which is obviously not the same printer as the system's 
default printer) as defined above, so I can't reproduce your problem here.

What are the access rights and contents of /etc/cups/lpoptions and 
.cups/lpoptions ?

 CUPS 1.5.x didn't have such a problem.
 
 This is a big security problem when one wants to print documents
 with confidential information...

Granted, that's a bug, but it doesn't fit my reading of serious [0], it's at 
most important, hereby downgrading.

Cheers,

OdyX

[0] http://www.debian.org/Bugs/Developer.en.html#severities


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

Bug#711837: RFA: mapnik -- C++/Python toolkit for developing GIS applications

2013-06-10 Thread YunQiang Su

On Mon, Jun 10, 2013 at 5:48 PM, David Paleino da...@debian.org wrote:
 On Mon, 10 Jun 2013 17:28:10 +0800, YunQiang Su wrote:

 This packages seems in a quite good situation. Is it?

 There is a new upstream version, and it needs to be re-transitioned to
 libmapnik (from the current libmapnik2). Also, there's a SONAME bump 
 involved.
I am interested. let me have a try first.

 --
  . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
  : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
  `. `'`  GPG: 1392B174 | http://deb.li/dapal
`-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174



--
YunQiang Su


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

Bug#657215: [PATCH videoproto] Xvproto: fix xvEncodingInfo to match actual wire protocol

2013-06-10 Thread Julien Cristau

On Mon, Jun 10, 2013 at 11:41:00 +0200, Daniel Martin wrote:

 On 9 June 2013 19:00, Julien Cristau jcris...@debian.org wrote:
  The padding is *before* the rate field, so the rate is placed on a 32bit
  boundary.  This change adds explicit padding between height and rate,
  and removes extraneous padding after the rate field, which the server
  never sent and xlib never read.
 
  This changes sizeof(xvEncodingInfo).  Hopefully that's not a big deal as
  clients only see the Xlib structure XvEncodingInfo.
 
 (Hopefully, I'm right with that):
 I think that's an ABI change and a bit more difficult. Think about an X
 server, which is compiled against a xvproto version without that change
 and the lib compiled against xvproto with that change. In that case the
 lib would start to read the encoding info, where the X server just sended
 those extraneous pad bytes.
 
No.  As said in the commit message, the server never sent the extraneous
pad bytes, so this patch doesn't change either the server or libXv
behaviour.  Both it and libXv use sz_xvEncodingInfo, which is ok.

 I just saw that the reply structure itself (xvQueryEncodingsReply) has
 such extraneous padding too:
   ...
   CARD32 length B32;
   CARD16 num_encodings B16;
   CARD32 padl3 B32;
   ...
 And even without this padding sz_xvQueryEncodingsReply=32 is wrong,
 as the fields sum up to 34 and with that padding we're at 36.
 
Looks like padl3 should really be CARD16...

Cheers,
Julien


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

Bug#711774: [exact-image] Bug#711774: exactimage: dcraw vs libraw ?

2013-06-10 Thread René Rebe

Hi,

On Jun 10, 2013, at 9:01 , Mathieu Malaterre wrote:

 On Sun, Jun 9, 2013 at 9:08 PM, Sven Eckelmann s...@narfation.org wrote:
 Just a small remark at the beginning: I didn't meant dcraw upstream with
 dcraw guys but the Debian maintainers for dcraw. And I really think it is a
 good question because the package is dead since 3 years and missing some
 updates from upstream.
 
 (Ok, the embedded copy of dcraw in exactimage seems to be older)
 
 On Sunday 09 June 2013 19:37:03 Rene Rebe wrote:
 I think dcraw did all the original research and he does not want to make it
 a library because he believes an executable to call is the unix way and a
 library he could boy change so flexible. This is why I embedded the not too
 big code to make it a simple built in library inside exact image.
 
 This is correct, but is not really about the problem here. Just to give more
 insight in what Mathieu Malaterre said:
 
 Embedded copies of code are bad when used in Distributions because (just some
 examples):
 * they increase the binary size when there would be shared object that could
   be used instead
 * they increase memory usage because different programs cannot share the
   loaded library
 * they are hard to maintain
 
 Ok, the first two points are easy to understand but the last one might be
 quite vague. So here an explanation with two different scenarios (actually it
 is the same example but with different impacts):
 
 dcraw gets a new version (lets call it 9.18 for obvious reasons) with X-Trans
 and EOS C500 support. Now all programs using an embedded copy have to be
 updated in Debian to bring these versions on par with the upstream one and 
 fix
 outstanding bugs/request for EOS C500/X-Trans. This is not really trivial
 because the programs have to be identified first and then the maintainer has
 to be waken up. This is a lot of work and time spend on a task that is
 completely unnecessary. Therefore, it is better to use the library version
 when available. And yes, I am fully aware that interface changes are problems
 which can be a negative effect when switching to external libraries.
 
 Now to the part with a little more impact. Lets assume that dcraw has a bug
 which can be exploited quite easily (send a prepared image which causes some
 buffer overflows and so on). Now it is extreme important to find all versions
 of the embedded copy because otherwise it is a security risk. You don't 
 really
 want to provide an web service doing raw image conversions when there might 
 be
 a big security hole because the security bug was fixed in the original
 program/library but not in the embedded copy.
 
 So back to the main questions. Do you see a possible way to switch from your
 dcraw version to libraw and make more of the embedded copies optional? I 
 know,
 the embedded copies from libjpeg for jpeg rotation are for example really 
 hard
 because libjpeg doesn't export the necessary stuff. But it seemed to have
 caused some headaches for the previous maintainers of this package because no
 one updated the embedded copy of jpegint/transupp and it just crashed when
 used together with never versions of libjpeg like libjpeg8. And the current
 one in exactimage upstream still does.
 
 Very well summarized, Sven !
 
 Security was mostly my main objection, since exactimage offer perl,
 python and php5 bindings it is quite likely this will be used on
 webserver, therefore security risk is not anymore just a theoretical
 issue.


Well, the dcraw author is the authority when it come to RAN reverse 
engineering. I would rather use his, than some other random library. That it is 
not a real library, and the ongoing compatibility breakage of libpng and 
libjpeg is very unfortunate, but honestly not my construction site. After all 
my decade of excessive open source work and contribution I'm left vastly 
disappointment by all this movements, incompatibly, breakage and flamewars. In 
the end all the big companies like Google, Facebook, IBM, Oracle and others 
just make the big money of all our work there. I'm afraid I can not longer 
donate my short life to their profit and thus mostly do other stuff now, like 
for Mac and even Windows.

I adapt ExactImage to new library versions as time allows, but unfortunately 
the random breakage and incompatibility mess does not motivate me too much to 
look into things like that.

Patches welcome.

René
-- 
 http://exactcode.com | http://exactscan.com | http://ocrkit.com | 
http://t2-project.org | http://rene.rebe.de

Bug#711717: pu: package slbackup-php/0.4.3-3

2013-06-10 Thread Mike Gabriel


Hi Adam, Petter,

On So 09 Jun 2013 23:10:53 CEST Adam D. Barratt wrote:


However, can the update of slbackup-php be uploaded to s-p-u? What is
the preferred version? 0.4.3-3 or 0.4.3-2+deb7u1?


In general, the latter is preferable as it clearly indicates that the
upload was made to a suite other than unstable / experimental; -3 would
also work so long as that version has never been used before.

Please feel free to upload for inclusion in 7.2.


uploaded slbackup-php to stable-p-u as 0.4.3-2+deb7u1.

Cheers,
Mike


--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpyi_T5wiZtp.pgp
Description: Digitale PGP-Unterschrift

Bug#692465: Interested in maintenance of aiccu

2013-06-10 Thread Mike Gabriel


Hi Jeroen,

On So 09 Jun 2013 02:24:02 CEST Jeroen Massar wrote:


On 2013-06-08 16:16, Mike Gabriel wrote:

Hi Jeroen,

as a regular user of aiccu (and a DD) I will be happy to take over
maintenance of the aiccu package.

I will also be happy to place you guys from upstream into the Uploaders:
field and train people from Sixxs in Debian packaging (and the distro
workflow) if there is the need.


There would be no need for that, as we know how Debian packaging works,
noting that we have been 'playing' with Debian since 1.2 era (heck, I
have a p200 which was upgraded from there to the current unstable ;) and
that the original Debian packaging was performed by us, and then
extended to support the debconf support by Gary Coady which we
integrated into that packaging and then somewhere along the way it
finally ended up in Debian.


Ack. Good to hear.


Please also see the note in the very bug referenced by your email:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692465#10


Yes, noted.


We still intend to do that and given some free time will come around to
doing that including a full push of that work out to
https://github.com/SixXS/aiccu but this all in due time, real life and
work has to come first.


Here I'd like to step in. I highly recommend sticking to the  
git-buildpackage workflow here. This means having two independent Git  
repositories. The first is the upstream Git project of aiccu (e.g. on  
Github). Upstream releases are done in this repos and tagged properly.  
The second repos is the Debian packaging repos. It imports your  
upstream releases (via uscan --force-download --rename and a proper  
watch file pointing to the upstream tags of aiccu on Github).


The packaging achievements can in regular intervals be adapted on the  
upstream repos (if you like to ship the /debian folder upstream).


Mixing upstream development and debian packaging turns aiccu into some  
sort of a native package which I do disrecommend, as it mixes two  
workflows (upstream, downstream) that should IMHO stay separate.



Greets,
 Jeroen


Greets,
Mike

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpKXJUJyjD_4.pgp
Description: Digitale PGP-Unterschrift

Bug#709687: transition: ptlib, opal

2013-06-10 Thread Adam D. Barratt


On 2013-06-07 18:53, Adam D. Barratt wrote:

On Fri, 2013-06-07 at 18:48 +0100, Adam D. Barratt wrote:

The packages haven't transitioned yet because the last binNMU for
h323plus only finished building a few hours ago and the old 
libraries

haven't been decrufted yet. It's in hand... :)


And then I noticed that openam hasn't been rebuilt yet because it
doesn't actually build-depend on ptlib but gets its runtime 
dependency

transitively via h323plus; I've just scheduled binNMUs.


A quick update:

All of the binNMUs in unstable were successful, and the old packages 
were decrufted. The new packages migrated this morning, but the 
transition isn't quite over yet as a couple of the applications still 
need to migrate. t38modem just isn't quite old enough, which is easily 
resolved, but ekiga is affected by #698627 - please could one of the 
maintainers either verify that the bug does not affect the 4.0 packages 
and add an appropriate fixed version, or fix the bug in that series?


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#711584: gnome-control-center: * Error in `gnome-control-center': free(): invalid pointer: 0x00007f6e3619c000 *

Hi,

On 08/06/13 07:28, Ludovic Lebègue wrote:
 Package: gnome-control-center
 Version: 1:3.4.3.1-3
 Severity: normal
 
 Unable to launch gnome-control-center

Does this happen all the time? How are you starting gnome-control-center?

We would need a valgrind log and a gdb backtrace to better debug this, with
libdrm-nouveau1a-dbg xserver-xorg-video-nouveau-dbg libclutter-1.0-dbg
libcogl9-dbg libc6-dbg libglib2.0-0-dbg installed. But from the trace below this
looks like a bug in nouveau.

@debian-x, does this look familiar?

Cheers,
Emilio

 
 Stack trace :
 
 === Backtrace: =
 /lib/x86_64-linux-gnu/libc.so.6(+0x7aac6)[0x7f6e5c52bac6]
 /lib/x86_64-linux-gnu/libc.so.6(+0x7b843)[0x7f6e5c52c843]
 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0x1a370e)[0x7f6e383b470e]
 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0x211672)[0x7f6e38422672]
 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0xd3617)[0x7f6e382e4617]
 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0x12034a)[0x7f6e3833134a]
 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0x1205c1)[0x7f6e383315c1]
 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0xe6106)[0x7f6e382f7106]
 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so(+0xe66b3)[0x7f6e382f76b3]
 /usr/lib/x86_64-linux-gnu/libcogl.so.9(+0x18b2c)[0x7f6e39f4db2c]
 /usr/lib/x86_64-linux-gnu/libcogl.so.9(+0x6361a)[0x7f6e39f9861a]
 /usr/lib/x86_64-linux-gnu/libcogl.so.9(cogl_context_new
 0x10b)[0x7f6e39f562bb]
 /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0(+0x65333)[0x7f6e3a42f333]
 /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0(+0x7c2b3)[0x7f6e3a4462b3]
 /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0(+0x87cda)[0x7f6e3a451cda]
 /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0(+0x87f0b)[0x7f6e3a451f0b]
 /lib/x86_64-linux-
 gnu/libglib-2.0.so.0(g_option_context_parse+0x3b7)[0x7f6e5ce09757]
 /usr/lib/x86_64-linux-
 gnu/libclutter-1.0.so.0(clutter_init+0xd2)[0x7f6e3a4521d2]
 /usr/lib/x86_64-linux-gnu/libcheese-
 gtk.so.21(cheese_gtk_init+0x24)[0x7f6e3a913e34]
 /usr/lib/control-center-1/panels/libuser-
 accounts.so(g_io_module_load+0x33)[0x7f6e3ab372e3]
 /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0x5c4f6)[0x7f6e5d35c4f6]
 /usr/lib/x86_64-linux-
 gnu/libgobject-2.0.so.0(g_type_module_use+0x81)[0x7f6e5d0e45a1]
 /usr/lib/x86_64-linux-
 gnu/libgio-2.0.so.0(g_io_modules_load_all_in_directory_with_scope
 +0x84)[0x7f6e5d35c8d4]
 gnome-control-center[0x4098da]
 /usr/lib/x86_64-linux-
 gnu/libgobject-2.0.so.0(g_type_create_instance+0x15f)[0x7f6e5d0e193f]
 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x15758)[0x7f6e5d0c6758]
 /usr/lib/x86_64-linux-
 gnu/libgobject-2.0.so.0(g_object_newv+0x781)[0x7f6e5d0c8211]
 /usr/lib/x86_64-linux-
 gnu/libgobject-2.0.so.0(g_object_new+0xec)[0x7f6e5d0c885c]
 gnome-control-center(main+0x72)[0x407c62]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f6e5c4d2a55]
 gnome-control-center[0x407d11]
 === Memory map: 
 0040-00412000 r-xp  08:07 673312
 /usr/bin/gnome-control-center
 00611000-00612000 r--p 00011000 08:07 673312
 /usr/bin/gnome-control-center
 00612000-00613000 rw-p 00012000 08:07 673312
 /usr/bin/gnome-control-center
 02489000-02ef9000 rw-p  00:00 0
 [heap]
 7f6e36108000-7f6e36188000 rw-s 126b9f000 00:05 9973
 /dev/dri/card0
 7f6e36188000-7f6e362a rw-p  00:00 0
 7f6e362a-7f6e362a1000 ---p  00:00 0
 7f6e362a1000-7f6e36aa9000 rw-p  00:00 0
 [stack:10164]
 7f6e36aa9000-7f6e37ef r-xp  08:07 1089975
 /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1
 7f6e37ef-7f6e37ef1000 ---p 01447000 08:07 1089975
 /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1
 7f6e37ef1000-7f6e37ff5000 r--p 01447000 08:07 1089975
 /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1
 7f6e37ff5000-7f6e37ffc000 rw-p 0154b000 08:07 1089975
 /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1
 7f6e37ffc000-7f6e3800a000 rw-p  00:00 0
 7f6e3800a000-7f6e3801 r-xp  08:07 1089971
 /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0
 7f6e3801-7f6e3820f000 ---p 6000 08:07 1089971
 /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0
 7f6e3820f000-7f6e3821 r--p 5000 08:07 1089971
 /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0
 7f6e3821-7f6e38211000 rw-p 6000 08:07 1089971
 /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0
 7f6e38211000-7f6e38811000 r-xp  08:07 1173972
 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
 7f6e38811000-7f6e38a1 ---p 0060 08:07 1173972
 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
 7f6e38a1-7f6e38a3b000 rw-p 005ff000 08:07 1173972
 /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
 7f6e38a3b000-7f6e38c1b000 rw-p  00:00 0
 7f6e38c1b000-7f6e38c2 r-xp  08:07 1589426
 /usr/lib/x86_64-linux-gnu/libxcb-util.so.0.0.0
 7f6e38c2-7f6e38e2 ---p 5000 08:07 1589426
 /usr/lib/x86_64-linux-gnu/libxcb-util.so.0.0.0
 7f6e38e2-7f6e38e21000 rw-p 5000 08:07 1589426
 /usr/lib/x86_64-linux-gnu/libxcb-util.so.0.0.0
 7f6e38e21000-7f6e38e29000 r-xp  08:07 1094096

Bug#711070: python-otr: please port to libotr5-dev

2013-06-10 Thread Kjell Braden


FYI: package is not used anymore and has been superseded.

--
 Kjell

mail/xmpp fn...@pentabarf.de


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

Bug#681248: [Pkg-pdns-maintainers] Bug#681248: Here too, powerdns fails after upgrade to wheezy...

2013-06-10 Thread Tom Laermans


Hi marc,

On 05/17/2013 04:29 PM, Marc Haber wrote:

- placing a nonworking bind backend configuration file in the
include directory.

Please elaborate about the nonworking part.

I did another upgrade yesterday, now with some more attention:

Situation before the upgrade:

- I have launch=gmysql in /etc/powerdns/pdns.conf
- I have gmysql-*= options in /etc/powerdns/pdns.d/pdns.local

I believe this is how the installation was written by default in 
powerdns in earlier version(s).


Now, with the simplebind addition, which contains launch=bind

pdns[22264]: Fatal error: Trying to set unexisting parameter 'gmysql-dbname'

launch=bind overrides the any other launch= (be it in pdns.conf or 
pdns.local, if it were there), which makes my mysql backend not work 
after upgrade and leaves pdns guardian in an infinite retry-loop until I 
remove the simplebind include.


Correct syntax: launch=gmysql,bind

Tom


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

Bug#711540: iproute2 FTBFS on sparc

2013-06-10 Thread Andreas Henriksson

Hello again Michael!

Just now trying to catch up with work that piled up during last week.

On Mon, Jun 10, 2013 at 12:02:34PM +0400, Michael Tokarev wrote:
[...]
  It seems the initial bug report mail hasn't reached me... :/
 
 Well, I just submitted a bugreport.  Before, I also wrote to
 the address listed in Maintainer: field, -- I sent almost the
 same thing as in the bugreport, but were just asking if your
 guys need any help or not and what's up with that issue.
 After some days without reply I filed the bugreport.

Seems I also lost the initial mail from you. :/
Feel free to resend if there is any open issue you still want to discuss.

Help is very welcome! There are RFH out and atleast one bug tagged help.
Help with any open bug report is welcome ofcourse!

[...]
 I didn't know there's an upstream commit addressing this.  I don't
 even know where iproute2 is maintained upstream, -- probaly it'd be
 better if I looked.  I just tried to fix the immediate issue (which
 is rather trivial), basically leaving the full expertise to someone
 who is more familiar with the package.

Stephen Hemminger is the upstream maintainer for iproute2.
He has a git repository at git.kernel.org and the primary mailing
list (except for sending patches directly to shemminger) is
net...@vger.kernel.org.

The pkg-iproute repo should be available via debcheckout.


[... snip explanation of netcf build problems in sid...]
 My understanding is that a package isn't available as build-dep on sid before
 it is built itself on all necessary arches.

Thanks for the explanation. As I understand it, the problem is not
the need for iproute2 to transition to testing then but
a(ny) version not being able to the buildds.

[...]
 How about me cancelling the delayed upload instead, until there's some
 time to do that left? ;)
[...]

I've just uploaded -3


Fwiw, another dark cloud just appeared on the sky:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711782


-- 
Andreas Henriksson


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

Bug#711849: cups-browsed depends on avahi-daemon, unnecessarily

2013-06-10 Thread Stephan Boettcher

Package: cups-browsed
Version: 1.0.34-3
Severity: minor

cups-browsed works nicely without avahi when instructed to 
BrowsePoll a specific server.  The avahi-daemon is pulled in 
unnecessaily and needs to be disabled in our setup.

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

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

Versions of packages cups-browsed depends on:
pn  avahi-daemon  none
ii  libavahi-client3  0.6.31-2
ii  libavahi-common3  0.6.31-2
ii  libavahi-glib10.6.31-2
ii  libc6 2.17-5
ii  libcups2  1.6.2-8
ii  libglib2.0-0  2.36.1-2build1

cups-browsed recommends no packages.

cups-browsed suggests no packages.

-- Configuration Files:
/etc/cups/cups-browsed.conf changed:
BrowseRemoteProtocols dnssd
BrowsePoll 134.245.xx.xx


-- 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#711848: cups-client: lp and lpr print the document on a wrong printer

2013-06-10 Thread Vincent Lefevre

On 2013-06-10 11:50:52 +0200, Didier 'OdyX' Raboud wrote:
  But when I print a document with lpr file.pdf, I get nothing on
  this printer. Then I tried: lp file.pdf, and I get nothing either
  on this printer, but the following line was output in the terminal:
 
 When trying here with either lpr or lp, I get the file printed on
 the correct new-default-printer (which is obviously not the same
 printer as the system's default printer) as defined above, so I
 can't reproduce your problem here.

Well, this may be server dependent. I suspect a bug related to the
authentication mechanism. When I do lpq, authentication is not
required, so that its output is OK. However some printers need
authentication (the user's password). Perhaps lp and lpr ignore the
default printer when it requires authentication, or something like
that? The printer to which the files had been sent doesn't require
a password.

Note that the -P lpr option works as expected (and the password must
be typed).

 What are the access rights and contents of /etc/cups/lpoptions and 
 .cups/lpoptions ?

ypig:~ cat /etc/cups/lpoptions
cat: /etc/cups/lpoptions: No such file or directory

ypig:~ cat .cups/lpoptions
Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi
Default lipucb-mono-1

  CUPS 1.5.x didn't have such a problem.
  
  This is a big security problem when one wants to print documents
  with confidential information...
 
 Granted, that's a bug, but it doesn't fit my reading of serious [0],
 it's at most important, hereby downgrading.
[...]
 [0] http://www.debian.org/Bugs/Developer.en.html#severities

I disagree. I see [0] as giving a non-exhaustive list of grave/critical
problems. For instance, a bug that would make a mail server an open
relay by default should also be seen as a grave/critical bug, even
though such a problem isn't listed in [0]. It should include problems
like private data disclosure.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Bug#705390: gnome-calculator: gnome-applications.menu (from /etc/sdg/menus) looking for gnome-calculator.desktop

reassign 705390 gnome-menus
forcemerge 705390 711605
thanks

On 14/04/13 09:38, Alex Vanderpol wrote:
 Package: gnome-calculator
 Version: 3.8.0-1
 Severity: important
 
 Dear Maintainer,
 
 After much frustration I finally discovered why GNOME's Calculator is not
 showing up in the GNOME applications menu. The applications menu file is
 looking for a differently named desktop file than is currently being shipped.
 The package currently ships gcalctool.desktop (the old name from the old
 gcalctool package, before it was renamed). The menu file is looking for gnome-
 calculator.desktop (named such after the new package providing the GNOME
 Calculator program).
 
 Could you please correct this?

gnome-menus is wrong here, will fix this shortly.

Thanks for your report.

Emilio


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

Bug#705007: E763: Word characters differ between spell files

2013-06-10 Thread Marcin Szewczyk

On Mon, Apr 08, 2013 at 07:08:01PM +0200, Uwe Storbeck wrote:
 [...] spell files. They are not compatible with spell files which vim
 automatically downloads from ftp.vim.org:
 [...] 
 When I manually download the current English spell files from
 http://ftp.vim.org/pub/vim/runtime/spell/ and copy them to
 /home/uwe/.vim/spell spell checking works as expected without
 any error messages.

An interesting part is my Vim reported errors for English UTF-8 .spl
even after downloading a new version from ftp.vim.org to ~/.vim/spell.
What actually caused an error was an old Polish UTF-8 dictionary. After
downloading it from ftp.vim.org the problem stopped and I still use
packaged English spell files.

-- 
Marcin Szewczyk   http://wodny.org
mailto:marcin.szewc...@wodny.borg  - remove b / usuń b
xmpp:wo...@ubuntu.pl  xmpp:wo...@jabster.pl


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

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

Hi again Vincent,

Le lundi, 10 juin 2013 12.56:33, Vincent Lefevre a écrit :
 Well, this may be server dependent. I suspect a bug related to the
 authentication mechanism. When I do lpq, authentication is not
 required, so that its output is OK. However some printers need
 authentication (the user's password). Perhaps lp and lpr ignore the
 default printer when it requires authentication, or something like
 that? The printer to which the files had been sent doesn't require
 a password.
 
 Note that the -P lpr option works as expected (and the password must
 be typed).

Thanks for the followup.

  What are the access rights and contents of /etc/cups/lpoptions and
  .cups/lpoptions ?
 
 ypig:~ cat /etc/cups/lpoptions
 cat: /etc/cups/lpoptions: No such file or directory
 
 ypig:~ cat .cups/lpoptions
 Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi
 Default lipucb-mono-1

Can you provide the access rights of .cups/lpoptions?

$ ls -l ~/.cups/lpoptions

   CUPS 1.5.x didn't have such a problem.
   
   This is a big security problem when one wants to print documents
   with confidential information...
  
  Granted, that's a bug, but it doesn't fit my reading of serious [0],
  it's at most important, hereby downgrading.
 
 I disagree. I see [0] as giving a non-exhaustive list of grave/critical
 problems. For instance, a bug that would make a mail server an open
 relay by default should also be seen as a grave/critical bug, even
 though such a problem isn't listed in [0]. It should include problems
 like private data disclosure.

It's fine for you to disagree, but the list [0] is considered as authoritative 
on bugs severities. If you think this list should be changed, please start a 
discussion on a proper forum; probably a bug on debian-policy as it's 1.1 
chapter defines what bug corresponds to a serious severity, which is 
completed by the Release Team's RC policy [1]. Under the current rules, this 
bug doesn't fit the defintion of serious in my reading.

(Please also take a look at the Developers' Reference, §5.8.3, alinea 3 [2]).

Cheers,

OdyX

[0] http://www.debian.org/Bugs/Developer.en.html#severities
[1] http://release.debian.org/jessie/rc_policy.txt
[2] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-
housekeeping


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

Bug#711247: freebsd-utils: please ship pflogd

2013-06-10 Thread Steven Chamberlain

Hi Martin,

On 05/06/13 21:59, Martin Zobel-Helas wrote:
 With DSA hat on: Would be nice if freebsd-utils including the pflogd
 binary could be uploaded to backports.

Even with those (fairly generic) patches applied, pflogd still doesn't
compile.

We would additionally need a pcap-int.h (internals) header which
libpcap-dev does not provide currently.  There is probably a reason why
it doesn't;  anything using the header might pick up a tight dependency
on a particular source version of libpcap.

That also means it may not be so trivial to backport.

But otherwise, with a couple of minor changes I got pflogd built on a
Wheezy system.  And it seems to be functioning.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


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

Bug#660932: Double quote in (some) wget's international output for downloaded filename

Package: wget
Version: 1.14-2
Followup-For: Bug #660932

Dear Maintainer,

what happens is that the translation project introduces extra quotes
where the original has none.
Since Wget handles/adds quotes in it's own style, quotation gets out of sync.

I just wrote to translator-team-de NOT to introduce extra quotes for Wget.


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

Bug#698284: usb-modeswitch-data: ttyUSB* rule should have SYMLINK+= not SYMLINK=

Hi Josua,

I have now uploaded your latest usb-modeswitch-data source package to Debian 
and stumbled upon this bug while housekeeping the remnant bugs lying around. 
:)

Apparently you forgot to include this change in the new rules file (also in 
the gen_rules.tcl) apparently; was that intentional?

Keep us posted, cheers,

OdyX

Le mercredi, 16 janvier 2013 20.39:30, Josua Dietze a écrit :
 Am 16.01.2013 10:57, schrieb Didier 'OdyX' Raboud:
  Le mercredi, 16 janvier 2013 09.53:26, John Hedges a écrit :
  Symlinks created by local rules for ttyUSB devices are lost because of
  the following rule in /lib/udev/rules.d/40-usb_modeswitch.rules
  
  KERNEL==ttyUSB*, ATTRS{bNumConfigurations}==*,
  PROGRAM=usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct}
  %E{PRODUCT}, SYMLINK=%c
  
  Chould it be changed to SYMLINK+=%c ?
  
  As I don't have a definite opinion on that, let's see what upstream
  thinks.
  
  Josh: what's your opinion ?
 
 Yes, this definitely should be changed. There is no disadvantage.
 
 I will do so in the next release, but that is not scheduled yet - so you
 might want to correct this prior to my update.


OdyX


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

Bug#689571: CVE-2012-4463: Improper sanitization of MC_EXT_SELECTED variable when viewing multiple files

2013-06-10 Thread Jonathan Wiltshire

Package: mc

Dear maintainer,

Recently you fixed one or more security problems and as a result you closed
this bug. These problems were not serious enough for a Debian Security
Advisory, so they are now on my radar for fixing in the following suites
through point releases:

squeeze (6.0.8) - use target oldstable

Please prepare a minimal-changes upload targetting each of these suites,
and submit a debdiff to the Release Team [0] for consideration. They will
offer additional guidance or instruct you to upload your package.

I will happily assist you at any stage if the patch is straightforward and
you need help. Please keep me in CC at all times so I can
track [1] the progress of this request.

For details of this process and the rationale, please see the original
announcement [2] and my blog post [3].

0: debian-rele...@lists.debian.org
1: http://prsc.debian.net/tracker/689571/
2: 201101232332.11736.th...@debian.org
3: http://deb.li/prsc

Thanks,

with his security hat on:
--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

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


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

Bug#711851: qcontrol: disable watchdog on QNAP devices does not work

2013-06-10 Thread Holger Smolinski

Package: qcontrol
Version: 0.4.2-7+wheezy1
Severity: important


The qcontrol init script in 
/usr/share/initramfs-tools/scripts/init-bottom/qcontrol
contains a command line to be executed on QNAP deveices in order to disable 
their
builtin watchdog and prevent them from rebooting after 5 minutes of runtime.

This line is:

/sbin/qcontrol --direct watchdog off || true

Executing this line interactively returns a Command not found error message:

root@debian:~# /usr/sbin/qcontrol --direct watchdog off
Command not found

root@debian:~#

due to an apparently inappropriate parameter '--direct', which when left out
does not report an error:

root@debian:~# /usr/sbin/qcontrol  watchdog off
root@debian:~#

The qcontrol call is used in the initrd to prevent the device from rebooting
periodically. With the failed call these reboots happen every five minutes,
which is especially tooo short, if the file system check is run. In that case
the reboot happens repeatedlÃy during the fs check, which has a very high risk 
of 
corrupting data.

Since the --direct option is not mentioned in the qcontrol manpage, I conclude
that it is an invalid option and should not be used. Hence I'd suggest this fix
to be applied to the qcontrol init script. I did not yet try this fix, since my
qnap device is geographically distand from my personal location and I'd have
some trouble getting it operational again, if a reboot fails.

Meanwhile I am using the workaround echo -n g /dev/ttyS1 to disable the 
watchdog.

--- /usr/share/initramfs-tools/scripts/init-bottom/qcontrol.orig
2013-06-10 13:45:38.0 +0200
+++ /usr/share/initramfs-tools/scripts/init-bottom/qcontrol 2013-06-10 
13:45:58.0 +0200
@@ -30,6 +30,6 @@
 exit 0
 fi
 
-/sbin/qcontrol --direct watchdog off || true
+/sbin/qcontrol watchdog off || true
 
 exit 0

-- System Information:
Debian Release: 6.0.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.32-5-kirkwood
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages qcontrol depends on:
ii  libc6 2.11.3-4   Embedded GNU C Library: Shared lib
ii  liblua5.1-0   5.1.4-5Simple, extensible, embeddable pro
ii  udev  164-3  /dev/ and hotplug management daemo

qcontrol recommends no packages.

qcontrol 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#711850: java-wrappers: jvm-list.sh fails to find jvm from /etc/alternatives

2013-06-10 Thread Chris Davies

Package: java-wrappers
Version: 0.1.25
Severity: important
Tags: patch

I have just installed freemind. I have Oracle Java installed under
/usr/local/app/java-oracle/jdk1.7.0 and correctly mapped into
/etc/alternatives. I'm aware of issues surrounding Oracle Java but it's
required for another application I use. I also have OpenJDK versions 6 and 7
installed but unused.

Running freemind triggers a calls to java-wrappers, which in turn uses jvm-list
to detect an appropriate jvm. Unfortunately this fails because my jvm is not
installed under /usr/lib/jvm so java-wrappers is led to believe there is no
valid jvm installed, and consequently freemind will not start.

Investigating further it appears that there is a line within /usr/lib/java-
wrappers/jvm-list.sh that assumes a jvm linked from /etc/alternatives/java is
going to be somewhere under /usr/lib/jvm. The attached patch removes this
dependency assumption.



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

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

Versions of packages java-wrappers depends on:
ii  unzip  6.0-8

java-wrappers recommends no packages.

java-wrappers suggests no packages.

-- no debconf information
--- jvm-list.sh.2013-06-10	2011-09-14 17:27:08.0 +0100
+++ jvm-list.sh	2013-06-10 11:43:05.205951794 +0100
@@ -56,7 +56,7 @@
 __jvm_java2=$__jvm_java5 $__jvm_gcj2
 
 # current java alternatives
-__jvm_alt=$(readlink /etc/alternatives/java|sed -n 's/\(\/usr\/lib\/jvm\/[^\/]*\)\/.*/\1/p')
+__jvm_alt=$(readlink /etc/alternatives/java|sed -n 's!\(.*\)/bin/[^/]*$!\1!p')
 
 # All JVMs
 __jvm_all=$__jvm_default /usr/lib/jvm/*

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

2013-06-10 Thread Vincent Lefevre

Hi,

On 2013-06-10 13:27:47 +0200, Didier 'OdyX' Raboud wrote:
 Can you provide the access rights of .cups/lpoptions?
 
   $ ls -l ~/.cups/lpoptions

ypig:~ ls -l ~/.cups/lpoptions
-rw-r--r-- 1 vlefevre vlefevre 74 2013-02-01 16:29:37 
/home/vlefevre/.cups/lpoptions

I've also done a strace diff between:

  (1) strace -o str1.out -f lpr lineskip.pdf
  (2) strace -o str2.out -f lpr -P lip-multi-3 lineskip.pdf

in this order. I can notice in particular:

[...]
 open(/usr/lib/locale/locale-archive, O_RDONLY|O_CLOEXEC) = 3
 fstat(3, {st_mode=S_IFREG|0644, st_size=117407552, ...}) = 0
 mmap(NULL, 117407552, PROT_READ, MAP_PRIVATE, 3, 0) = hex
 close(3)  = 0
 futex(hex, FUTEX_WAKE_PRIVATE, 2147483647) = 0
 geteuid() = 1000
 getuid()  = 1000
 getegid() = 1000
 getgid()  = 1000
-access(lineskip.pdf, R_OK)  = 0
-open(/home/vlefevre/.cups/lpoptions, O_RDONLY) = 3
-fcntl(3, F_GETFD) = 0
-fcntl(3, F_SETFD, FD_CLOEXEC) = 0
-read(3, Dest lip-multi-3 ColorModel=Gray..., 4096) = 74
-close(3)  = 0
 open(/home/vlefevre/.cups/client.conf, O_RDONLY) = -1 ENOENT (No such file 
or directory)
 open(/etc/cups/client.conf, O_RDONLY) = 3
 fcntl(3, F_GETFD) = 0
 fcntl(3, F_SETFD, FD_CLOEXEC) = 0
 read(3, #\n#\n#   Sample client configurat..., 4096) = 2224
 read(3, , 4096) = 0
 close(3)  = 0
 open(/home/vlefevre/.cups/client.conf, O_RDONLY) = -1 ENOENT (No such file 
or directory)
 open(/etc/cups/client.conf, O_RDONLY) = 3
 fcntl(3, F_GETFD) = 0
 fcntl(3, F_SETFD, FD_CLOEXEC) = 0
 read(3, #\n#\n#   Sample client configurat..., 4096) = 2224
 read(3, , 4096) = 0
 close(3)  = 0
 rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, hex}, NULL, 8) = 0
 access(/etc/gcrypt/fips_enabled, F_OK) = -1 ENOENT (No such file or 
directory)
 open(/proc/sys/crypto/fips_enabled, O_RDONLY) = 3
 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
[...]
-getrusage(RUSAGE_SELF, {ru_utime={0, 4000}, ru_stime={0, 8000}, ...}) = 0
-times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1718347093
-getrusage(RUSAGE_SELF, {ru_utime={0, 4000}, ru_stime={0, 8000}, ...}) = 0
-times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1718347093
-open(/etc/cups/lpoptions, O_RDONLY) = -1 ENOENT (No such file or directory)
-open(/home/vlefevre/.cups/lpoptions, O_RDONLY) = 5
-fcntl(5, F_GETFD) = 0
-fcntl(5, F_SETFD, FD_CLOEXEC) = 0
-read(5, Dest lip-multi-3 ColorModel=Gray..., 4096) = 74
+recvfrom(4, [...], 5, 0, NULL, NULL) = 5
+recvfrom(4, [...]..., 784, 0, NULL, NULL) = 784
+getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 12000}, ...}) = 0
+times({tms_utime=0, tms_stime=1, tms_cutime=0, tms_cstime=0}) = 1718362144
+getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 12000}, ...}) = 0
+times({tms_utime=0, tms_stime=1, tms_cutime=0, tms_cstime=0}) = 1718362144
+open(/dev/tty, O_RDONLY)= 5
+ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
+ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
+ioctl(5, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost -isig -icanon -echo 
...}) = 0
+ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost -isig -icanon -echo 
...}) = 0
+fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 9), ...}) = 0
+mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = hex
+write(1, Password for vlefevre on lip-pri..., 60) = 60
[...]

I won't send you the strace as it contains the password and maybe
other private information, but /home/vlefevre/.cups/lpoptions is
read twice (successfully) in case (1) and none in case (2).

In case (1), the file was sent to lip-multi-1 instead of lipucb-mono-1.
In case (2), the file was sent to lip-multi-3 as expected.

 It's fine for you to disagree, but the list [0] is considered as
 authoritative on bugs severities. If you think this list should be
 changed, please start a discussion on a proper forum; probably a bug
 on debian-policy as it's 1.1 chapter defines what bug corresponds to
 a serious severity, which is completed by the Release Team's RC
 policy [1]. Under the current rules, this bug doesn't fit the
 defintion of serious in my reading.

[1] also says:

  in the maintainer's opinion, makes the package unsuitable
  for release
  (these issues are serious severity)

You could also consider that due to security concerns, the package
is unsuitable for release.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Bug#711853: insserv: Design bug: rcN.d unstable and not maintainable

2013-06-10 Thread Alessandro Vesely

Package: insserv
Version: 1.14.0-5
Severity: normal

When update-rc.d calls insserv, the rcN.d directories are rebuilt
without taking into consideration any adjustment that might have
been set up locally.  That seems to be done on the assumption that
the dependencies coded in the LSB blocks are universally accurate.
Now, LSBs are a great improvement over numeric priorities, but to
hamper local system tuning, which is not necessarily related to
LSBs, IMHO is an insult to the legendary versatility of SysV init.

On the other hand, when .legacy-bootordering exists, update-rc.d
does not use LSB blocks at all, and mindlessly links at priority
20.  I understand that maintainers don't put default priority
orders, which are difficult to maintain: That is exactly the
reason why LSB INIT INFO blocks were devised.  So, why not use
them?

A way to use that info and still respect existing priorities is
coded in the attached script.  Thanks to it, I was able to get the
cleanest boot since I upgraded to wheezy.  Unlike update-rc.d,
fix-init does not take a scrip name to operate on.  It assumes all
links older than .legacy-bootordering are to be respected, and
writes any action it deems required to a shell script.

Please have a look at it.

Regards
Ale


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

Kernel: Linux 3.2.41ale20 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages insserv depends on:
ii  libc6  2.13-38

insserv recommends no packages.

Versions of packages insserv suggests:
pn  bootchart2  none

-- debconf-show failed
#! /usr/bin/perl
# written by Alessandro Vesely in June 2013.  This is free software.

=head1 NAME

fix-init - rebuild Finit?.d links according to LSB headers

=head1 SYNOPSIS

fix-init [-n|--dry-run [Ifile]]
 [-r|--renum [Istep]]
 [--root Iroot]
 [-v|--verbose [2|3|4]]

fix-init -h|--help [1|2]

=head1 OPTIONS

=over

=item help

An optional value of I1 displays these options in addition to the synopsis.
Use I2 for a man-like page.

=item root

Default to F/.  Use a different directory for testing.

=item dry-run

Bfix-init writes shell commands on a temporary file, then executes it.
This option prevents that execution.  It is implied if Iroot is not
writable.  If an output Ifile is specified, it will be used instead of a
temporary one, overwriting its previous content if any.

=item renum

Without this option, Bfix-init tries to respect the existing order of links.
Otherwise, it renumbers them.  The default Istep is 6, resulting in names
like FS06xyz, FS12xyzzy, FS18foo, ...  This option is implied if
dependecy based boot sequencing is in effect.

=item verbose

Minimal verbosity (I-v) is recommended, otherwise Bfix-init is almost
silent.  At intermediate verbosity, unsatisfied required dependencies (I-v 2),
optional (should) and satisfied ones (I-v 3) are displayed, as well as some
skipped files and strange facts.  Top verbosity (I-v 4) dumps some internal
structures, such as the initial and resulting order for each level.

=back

=cut

use strict;
use warnings;
use feature switch;

use File::Find;
use File::Temp 'tempfile';
use Getopt::Long;
use List::Util qw(max min);
use Data::Dumper;
use Pod::Usage;

use constant {BROKEN_LINK = 1,
	PLAIN_FILE = 2, STRANGE_LINK = 3, NEW_LINK = 4};

my ($dryrun, $renum, $help, $root, $verbose);

Getopt::Long::Configure('no_ignore_case');
if (!GetOptions('verbose|v:i' = \$verbose,
'dry-run|n:s' = \$dryrun,
'renum|r:i'   = \$renum,
'root=s'  = \$root,
'help|h:i'= \$help))
{
	pod2usage();
	exit 1;
}

if (defined($help))
{
	pod2usage(-verbose = $help);
}

if (defined($verbose))
{
	$verbose = 1 unless ($verbose); # -v same as -v 1
}
else {$verbose = 0;}

$root = '/' unless defined($root);
$root .= '/' unless (substr($root, -1) eq '/');
my $initdir = $root . 'etc/init.d';
my $init_link = ../init.d/;
my $fix_flag = $initdir .'/.legacy-bootordering';
my $overridepath = /usr/share/insserv/overrides;
my $hostoverridepath =  /etc/insserv/overrides;

$Data::Dumper::Terse = 1;

my @levels = map $_, ('S', 0.. 6);
my %rc_d = map {$_ = $root .etc/rc$_.d} @levels;
my $rc_d_length = length($rc_d{0}); # different from length($initdir)
do {
	my @invalid = grep ! -d, values %rc_d;
	push(@invalid, $initdir) unless -d $initdir;
	pod2usage(-msg = 'Invalid dir: '. join(', ', @invalid)) if (@invalid);
};

my $timestamp = (stat($fix_flag))[9];
if (!defined($timestamp))
{
	$timestamp = 0;
	if (!defined($renum))
	{
		$renum = 0;
		print Dependecy based boot sequencing detected, --renum implied\n
			if ($verbose);
	}
}

my $defaultstep = 6;
$renum = $defaultstep if (defined($renum)  $renum == 0);

# cannot do, because order becomes negative or larger than 99
my

Bug#711852: maven.pm: Don't install documentation jar into maven-repo by default

2013-06-10 Thread Jakub Adam


Package: maven-debian-helper
Severity: wishlist
Tags: patch

Standard place where generated javadoc API documentation is installed on Debian 
system
is /usr/share/doc/package-name/api/. Maven dh build installs it also a JAR in 
maven-repo.
Having this duplicate file isn't necessary, so please consider not installing
the javadoc JAR by default.

Required change is implemented in attached patch.

Adding 'export MH_INSTALL_DOC=1' into d/rules overrides the setting.

Regards,

Jakub

From 81c9f308c6a21979f8e3d7feb2a3af232ce825b7 Mon Sep 17 00:00:00 2001
From: Jakub Adam jakub.a...@ktknet.cz
Date: Mon, 10 Jun 2013 13:35:10 +0200
Subject: [PATCH] maven.pm: Don't install documentation jar into maven-repo by
 default

Add 'export MH_INSTALL_DOC=1' into d/rules to override the setting.
---
 share/perl/maven.pm |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/share/perl/maven.pm b/share/perl/maven.pm
index 00520df..ca94eff 100644
--- a/share/perl/maven.pm
+++ b/share/perl/maven.pm
@@ -97,9 +97,11 @@ sub install {
 	$this-doit_in_builddir(mh_resolve_dependencies, --non-interactive,
 		--offline, -p$this-{package}, @resolvedep_args);
 	if ($this-{doc_package}) {
-		$this-doit_in_builddir(@{$this-{maven_cmd}},
-			-Ddebian.package=$this-{doc_package},
-			org.debian.maven:debian-maven-plugin:$maven_debian_version:install-doc);
+		if ($ENV{MH_INSTALL_DOC} == 1) {
+			$this-doit_in_builddir(@{$this-{maven_cmd}},
+-Ddebian.package=$this-{doc_package},
+org.debian.maven:debian-maven-plugin:$maven_debian_version:install-doc);
+		}
 		doit(cp,debian/$this-{package}.substvars,
 			debian/$this-{doc_package}.substvars);
 		# clean up generated docs
-- 
1.7.10.4

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

Hi again,

Le lundi, 10 juin 2013 13.27:47, Didier 'OdyX' Raboud a écrit :
 Under the current rules, this bug doesn't fit the defintion of serious in my
 reading.

As you brought this bug to debian-devel@ [0], let me explain in little more 
details (which I thought were obvious) why I think this bug is neither a 
security or a serious problem:
* it doesn't happen for everyone (it works as expected here);
* not all printed documents carry sensitive information and failing to print
  to the correct printer is not a security problem in all cases.

I never wrote that I wouldn't try to get this bug (which I agree it is)  
fixed, but just corrected the inflated bug severity. That useless debate on 
severities just distracted me from working on the bug itself.

OdyX

[0] http://lists.debian.org/%3c20130610111552.ga17...@ypig.lip.ens-lyon.fr%3E


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

Bug#711854: libunwind8-dev: ship upstream pkg-config files