date:20141009

Hey,

On 9 October 2014 05:21, Mike Gabriel mike.gabr...@das-netzwerkteam.de wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de

 * Package name: obs-build
   Version : Git snapshot (every commit is a release)
   Upstream Author : Michael Schroeder (https://github.com/mlschroe)
 * URL : https://github.com/openSUSE/obs-build
 * License : GPL
   Programming Lang: Perl
   Description : Build DEB/RPM packages for various distributions inside a 
 chroot

  OBS Build creates chroots and builds DEB/RPM packages for various
  Linux distributions. In Debian, this package fills a gap: it allows one to
  build packages for the openSUSE/SLES distributions on Debian system.
  .
  Its only task is to reliably populate a chroot and attempt to build
  a package in that chroot. It is used by the Open Build System provided
  by SUSE, but can also be use as a standalone tool.
  .
  Optionally, builds can take place in KVM or XEN instance.


I think we had a mid-air collision:
https://ftp-master.debian.org/new/obs-build_20140918-1.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762949

I'm happy to co-maintain this package.

-- 
Regards,

Dimitri.


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

Bug#764541: gsm3: When changing user, the sound is not stopped

2014-10-09 Thread Andrei POPESCU

Control: reassign -1 gdm3

On Jo, 09 oct 14, 00:12:07, Thibaut wrote:
 Package: gsm3
 Version: gnome3
 Severity: minor
 
 If a sound is playing on the speaker when a user switch its session to an 
 other
 user, the sound is still playing.
 When a user as started playing a sound (for example through a youtube video
 playing on iceweasel), a user on an other session will not be able to play a
 sound. In the sound option menu, the speakers are not visible. Only the
 internal audio is accessible.
 
 To play a sound on the speakers, it is needed to switch back to the first user
 that played a sound and close the software (for youtube, closing the tab is
 enough). 
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers testing-updates
   APT policy: (500, 'testing-updates'), (500, 'testing')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386
 
 Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores)
 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Bug#764547: bsdutils: script(1) is broken, hangs or crashes

Hello Thorsten Glaser!

On Thu, Oct 09, 2014 at 12:52:29AM +0200, Thorsten Glaser wrote:
 Package: bsdutils
 Version: 1:2.25.1-3
 Severity: serious
 Tags: upstream
 Justification: crashes
 Forwarded: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/1

Thanks for forwarding your issue upstream. Lets try to work it out
ourselfs as well though...

 
 Hi,
 
 as I reported upstream in
 http://article.gmane.org/gmane.linux.utilities.util-linux-ng/1
 the script(1) in util-linux 2.25.1 is broken, whereas the one
 in util-linux 2.20.1 as currently in jessie works fine. This applies
 to both my x32 regular machine as well as a clean, minimal amd64 and
 i386 cowbuilder sid chroot, as well as the OpenSuSE Buildservice setup.

Since you seem to have a way to reproduce the problem, could you please
also git bisect it?

 
 This bug opened in Debian to prevent a crashing script(1) from
 migrating to testing, and to track progress.

(I don't see this as anything else then just yet another bug in
script. I don't understand why your issue would be more important
then getting 200 other issues fixed for other people.)

Regards,
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#764549: ITP: siril -- Astronomical image processing tool

2014-10-09 Thread Andrei POPESCU

Control: reassign -1 wnpp
Control: owner -1 debian-si...@free-astro.vinvin.tf

On Jo, 09 oct 14, 01:22:57, debian-si...@free-astro.vinvin.tf wrote:
 Package: siril
 Version: 0.9.0b
 Severity: wishlist
 
 * Package name: siril
 Version : 0.9.0b
 Upstream author : Vincent Hourdin debian-si...@free-astro.vinvin.tf
 URL : http://free-astro.vinvin.tf/index.php/Siril
 License : GPLv3
 Description : Siril is an image processing tool specially tailored
 for noise reduction and improving the signal/noise ratio of an image
 from multiple captures, as required in astronomy. Siril can align,
 stack and enhance pictures from various file formats, even images
 sequences (movies and SER files).
 
 -- System Information:
 Debian Release: 7.6
   APT prefers testing
   APT policy: (1000, 'testing'), (990, 'stable'), (750, 'testing'), (500, 
 'testing-updates'), (500, 'stable-updates')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
 Shell: /bin/sh linked to /bin/dash

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Bug#720517: configuration files, ownership and dpkg-statoverride

2014-10-09 Thread Paul Gevers

On 09-10-14 02:17, Henrique de Moraes Holschuh wrote:
 On Wed, 08 Oct 2014, Paul Gevers wrote:
 Thanks for the careful response. And no, as mentioned above, I didn't
 mean to use dpkg-statoverride itself. dbconfig-common uses debconf and
 ufc to manage the configuration files. However, dbconfig-common checks
 with dpkg-statoverride if the configuration file is registered there and
 takes action if it is. However, currently it relies only on
 dpkg-statoverride to know if the ownership of the configuration file
 should be different, I want dbconfig-common to leave the ownership as it
 is if the file already exists.
 
 It looks like your problem is the situation where you have dpkg-statoverride
 information and it contradicts whatever is in debconf (or the filesystem,
 for that matter)?

Actually, I was really thinking about the situation where
dpkg-statoverride AND debconf were NOT used. dbconfig-common allows a
package to specify the ownership and permissions of the configuration
file. The package may or may not do this via debconf (cacti currently
does not). If a local admin decides that the ownership and/or
permissions need to be different dbconfig-common should honor that when
updating the package. Until know (hence RC) dbconfig-common changed the
ownership and permissions unconditionally to the ownership and
permissions requested by the package (unless dpkg-statoverride was used
by the admin), which may not be what the admin wants (and as you state
below may not reflect the situation).

 In that case, it is an operator error: I suggest you inform him about it and
 refuse to continue.  There's no other safe choice in the general case,
 AFAIK.

But this indeed is a good idea. Lots more logic to add, but indeed.
Annoying thing is that the script that actually does the file writing
may be called manually as well. Let me ponder on this some time.

 Of course, it might happen that you have specific knowledge (such as you
 know the dpkg-statoverride information was added in error by a previous
 version of the package _and_ the information in the statoverride database
 exactly matches the one the bug would have caused) which allows you to
 automatically repair the problem, instead.

Sure, but AFAICT that is not the case here.

 And if we're talking about an initial question (i.e. there is no conflict
 because there's nothing in the debconf database yet), then wouldn't using
 the dpkg-statoverride information as a pre-seed _and_ not allowing it to
 be overriden through debconf (i.e. don't ask the user about it at all) solve
 the issue?

Not applicable for the bug at hand, because there never was a question
to the user. Just hard-coding in the package, which I think is
acceptable, as well as it should be acceptable that the package leaves
it to dbconfig-common to just do-the-right-thing in this case.

Paul




signature.asc
Description: OpenPGP digital signature

Bug#764571: libpoclu-dev and uthash-dev: error when trying to install together

2014-10-09 Thread Vincent Danjean

  Hi,

On 09/10/2014 08:28, Ralf Treinen wrote:
 Package: uthash-dev,libpoclu-dev
 Version: uthash-dev/1.9.7-1
 Version: libpoclu-dev/0.10-3
 Severity: serious
 User: trei...@debian.org
 Usertags: edos-file-overwrite

Thank for the report. I think (I will check) that this is the same file.
I did not know that this header was already packaged. I will remove
it from libpoclu-dev and add a dependency.

  Regards,
Vincent

 Date: 2014-10-09
 Architecture: amd64
 Distribution: sid
 
 Hi,
 
 automatic installation tests of packages that share a file and at the
 same time do not conflict by their package dependency relationships has
 detected the following problem:
 
 
 Selecting previously unselected package ocl-icd-libopencl1:amd64.
 (Reading database ... 10872 files and directories currently installed.)
 Preparing to unpack .../ocl-icd-libopencl1_2.2.3-1_amd64.deb ...
 Unpacking ocl-icd-libopencl1:amd64 (2.2.3-1) ...
 Selecting previously unselected package libpoclu1:amd64.
 Preparing to unpack .../libpoclu1_0.10-3_amd64.deb ...
 Unpacking libpoclu1:amd64 (0.10-3) ...
 Selecting previously unselected package opencl-headers.
 Preparing to unpack .../opencl-headers_1.2-2014.04.13-1.1_all.deb ...
 Unpacking opencl-headers (1.2-2014.04.13-1.1) ...
 Selecting previously unselected package libpoclu-dev.
 Preparing to unpack .../libpoclu-dev_0.10-3_amd64.deb ...
 Unpacking libpoclu-dev (0.10-3) ...
 Selecting previously unselected package uthash-dev.
 Preparing to unpack .../uthash-dev_1.9.7-1_all.deb ...
 Unpacking uthash-dev (1.9.7-1) ...
 dpkg: error processing archive 
 /var/cache/apt/archives/uthash-dev_1.9.7-1_all.deb (--unpack):
  trying to overwrite '/usr/include/utlist.h', which is also in package 
 libpoclu-dev 0.10-3
 Processing triggers for man-db (2.7.0.2-1) ...
 Errors were encountered while processing:
  /var/cache/apt/archives/uthash-dev_1.9.7-1_all.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 cow-shell unlink .ilist: No such file or directory
 
 
 This is a serious bug as it makes installation fail, and violates
 sections 7.6.1 and 10.1 of the policy. An optimal solution would
 consist in only one of the packages installing that file, and renaming
 or removing the file in the other package. Depending on the
 circumstances you might also consider Replace relations or file
 diversions. If the conflicting situation cannot be resolved then, as a
 last resort, the two packages have to declare a mutual
 Conflict. Please take into account that Replaces, Conflicts and
 diversions should only be used when packages provide different
 implementations for the same functionality.
 
 Here is a list of files that are known to be shared by both packages
 (according to the Contents file for sid/amd64, which may be
 slightly out of sync):
 
   /usr/include/utlist.h
 
 This bug has been filed against both packages. If you, the maintainers of
 the two packages in question, have agreed on which of the packages will
 resolve the problem please reassign the bug to that package. You may then
 also register in the BTS that the other package is affected by the bug.
 
 -Ralf.
 
 PS: for more information about the detection of file overwrite errors
 of this kind see http://edos.debian.net/file-overwrites/.
 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


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

Bug#764561: Bug#764563: pocl: FTBFS: test suite errors and FTBFS on ppc64el

2014-10-09 Thread Vincent Danjean

  Hi,

On 09/10/2014 04:57, Aaron M. Ucko wrote:
 Source: pocl
 Version: 0.10-3
 Severity: serious
 Justification: fails to build from source
 
 The builds of pocl for i386 and (32-bit) powerpc both failed with test
 suite errors: three unexpected failures on i386 and 80 (!) on
 powerpc.  Could you please take a look?  You can find the full logs at
 
 https://buildd.debian.org/status/logs.php?pkg=poclver=0.10-3suite=sid
 
 (So far, most of the remaining failures were due to pocl's configure
 script rejecting the architecture as unsupported; you might want to
 tighten its architecture field in debian/control accordingly.)

Thank for your report. As pocl is a new package, do you really think
it deserve a serious bug (that block migration to testing?) Upstream
is really interested on the results (they cannot test pocl on all Debian
architecture before) but if bugs are filled with a serious severity I will
immediately completely disable non standard architectures in order
to allow pocl in jessie (and the work to try to support other architectures
will be done after jessie release instead of before the freeze).

  Regards,
Vincent

 Thanks!
 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


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

Bug#681572: tested patch #in in http://savannah.gnu.org/bugs/?35757

Hi Alexander,

Alexander Wuerstlein wrote:
 I've tested the patches in comments #4 and #5 in
 http://savannah.gnu.org/bugs/?35757
 
 #4 seems to fix the problem here that is reproducible as described in the
 original submission in http://savannah.gnu.org/bugs/?35757. This problem
 occured for me in Debian stable with my screenrc (I can attach it if you
 need it).

Thanks for testing. Reminded me that I should do an upload with a few
cherry-picked upstream patches. Fixed now. :-)

 The patch from #5 alone doesn't seem to fix the issue, but it might be a
 good idea to apply it anyways.

As I'm unclear about what it actually fixes and I've no test case to
check if it fixes it, I've not included it. Please open a separate bug
report if you are affected by what that patch fixes.

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#764310: manpages-dev and libcerf-doc: error when trying to install together

2014-10-09 Thread Eugen Wintersberger

Hi
  sorry for my late reply - though being listed as a maintainer for the
libcerf package I did not recieve a mail from the Debian bug tracker. 
I am quite new to the Debian packaging world - so most probably I did
something wrong or forgot to regsiter somewher. 

Anyhow ...

On Tue, 7 Oct 2014 22:51:50 +0200 Simon Paillard spaill...@debian.org wrote:
 Hi,
 
 On Tue, Oct 07, 2014 at 08:38:03AM +0200, Ralf Treinen wrote:
  Package: libcerf-doc,manpages-dev
  Version: libcerf-doc/1.3-1
  Version: manpages-dev/3.71-1
  Severity: serious
  User: trei...@debian.org
  Usertags: edos-file-overwrite
 
 Thanks for the report !

Indeed - yes - thanks for the report. 

[...] 
 
 Several facts:
 * both cerf.3 and cerfc.3 are already provided in manpages debian package 
 since
   10 years before libcerf upload in June 2014
 * the function names are reserved for future use in C99.
 
 Options:
 * rename cerf functions and manpages of libcerf (avoid use of reserved names)
 or
 * manpages-dev to stop installing cerf.3 and cerfc.3 manpages
 
 * anyway, Michael, if you read me, I suggest you mention libcerf in the cerf*
   manpages.

Just now I informed the upstream maintainers of libcerf about this. I am pretty 
sure 
they simply where not aware of the fact that these functions are already 
mentioned 
in the C99 standard. I am just not sure if they manage to change the upstream 
code in time to make it until the freeze of Jessie. 

I have not found cerf and cerfc in the documentation for glibc 2.20 so I assume 
that 
these functions would not be provided by the glibc version shipped with Jessie. 
Hence, I suggest to remove cerf.3 and cerfc.3 from manpages-dev as long as 
glibc 
does not provide this functionality. 

I am very well aware of the fact that this looks a bit like makeing this a 
sombody else's problem. However, in my opinion manpages of a package providing 
a particular functionality should have precedence. 

In any case this can only be an intermediate solution until upstream has 
renamed 
the functions. 

regards
  Eugen 



 
 -- 
 Simon Paillard
 
 



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

Bug#761760: add patch

2014-10-09 Thread Matthias Klose

Control: tags -1 + patch

patch at
https://patches.ubuntu.com/j/jbigkit/jbigkit_2.1-3ubuntu1.patch

this patch avoids the libtool usage, and allows cross-building the package.
Please keep this bug report open, if you just decide to add libtool-bin as a
build dependency.


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

Bug#764273:

2014-10-09 Thread Ritesh Raj Sarraf


On Wednesday 08 October 2014 07:21 PM, Thibault, Daniel wrote:
   Yeah, it seems to be very specific to the 
http://rcn-ee.net/deb/wheezy-armhf/v3.8.13-bone47/ Debian Wheezy image 
used for the BeagleBone Black rev. C. Please list the python packages 
your test system(s) have installed, so I can try to identify the 
missing one(s). I’m hoping this is all it will take to fix this.


Whatever is required is already a dependency, and is mentioned in the 
package's dependency relation. Are you using the official package, or 
the source ?


--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.

Bug#728375: libjetty8-java-doc: Questionable dependencies

2014-10-09 Thread Mauro Molinari


Il 06/10/2014 12:09, Emmanuel Bourg ha scritto:
libjetty8-java-doc already recommends default-jdk-doc, maybe you meant 
suggested instead? 


I may have used the wrong terms here, sorry. What I find questionable is 
that, as I said in my original report, if I try to install 
libjetty8-java-doc, APT by default says it will install other Javadoc 
packages as well, for a total of almost 300MB of data... I don't think 
these dependency Javadoc packages are actually needed for me to read the 
Jetty 8 documentation. They might be useful in some cases, but nothing 
more.


I just learnt I can use --no-install-recommends apt-get parameter (I 
expect aptitude to have something similar) to filter out recommended 
packages, but that's not what I would expect by default.


This is just my opinion. Thanks for your feedback!
Mauro


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

Bug#681501: Debian France on Debian's new donations page?

2014-10-09 Thread Raphael Hertzog

Hi,

On Tue, 07 Oct 2014, Paul Wise wrote:
 Since Debian France is a Trusted Organisation and has methods of
 donating to Debian, we should probably add it to Debian's rewritten
 donations page. We need some information before we can add it:
 
 A paragraph introducing Debian France to potential donors.
 
 Available donation methods (looks like PayPal at this point?).

Paypal is offered, but we can accept wire transfers too (SEPA credit),
we have published the IBAN/BIC here currently:
https://france.debian.net/soutenir/

 Details of how to donate (for PayPal some HTML would be best).

The correct link is this one:
https://france.debian.net/galette/plugins/galette-plugin-paypal/paypal_form.php?pref_lang=en_US

It's best to use the form on this page because it will record everything
in the accounting books automatically.

 If anyone reading this mail has the details already and can commit to
 the website CVS repository, please add Debian France there.

ENOTIME sorry

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


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

Bug#764553: base-files: Does neither state which version nor which variant of the Artistic License is in /usr/share/common-licenses/Artistic

Hi Russ,

Russ Allbery wrote:
  neither inside /usr/share/common-licenses/Artistic nor in
  /usr/share/doc/base-files/README nor in
  /usr/share/doc/base-files/changelog.gz is declared (or even hinted)
  which version or variant of The Artistic License is shipped in
  /usr/share/common-licenses/Artistic.
 
  According to https://spdx.org/licenses/ there are at least five
  registered versions and variants of the Artistic License:
 
* Artistic License 1.0
* Artistic License 1.0 (Perl)
 
 What does SPDX think the difference between these two is?

Actually quite a lot. :-(

Artistic-1.0.txt Artistic-1.0-cl8.txt only differ in that added 8th
clause. But Artistic-1.0-Perl.txt differs more from both -- and seems
to also include that new 8th clause, slightly modified, too.

Niko Tyni noticed on IRC yesterday evening that there are at least two
different variants of the Artistic License because of the different
number of clauses (9 vs 10). I digged deeper after that comment and
this bug report is the result of that digging.

Here's the wdiff (as a normal diff doesn't help much on changed words.
Piping it through colordiff helps a lot, otherwise look for the
strings [- and {+. It's based on a checkout of
http://git.spdx.org/?p=license-list.git

→ wdiff Artistic-1.0.txt Artistic-1.0-Perl.txt | colordiff
The [-Artistic License-] {+Artistic License+}

Preamble

The intent of this document is to state the conditions under which a Package 
may be copied, such that the Copyright Holder maintains some semblance of 
artistic control over the development of the package, while giving the users of 
the package the right to use and distribute the Package in a more-or-less 
customary fashion, plus the right to make reasonable modifications.

Definitions:

 Package refers to the collection of files distributed by the Copyright 
Holder, and derivatives of that collection of files created through textual 
modification.

 Standard Version refers to such a Package if it has not been modified, 
or has been modified in accordance with the wishes of the Copyright [-Holder.-] 
{+Holder as specified below.+}

 Copyright Holder is whoever is named in the copyright or copyrights for 
the package.

 You is you, if you're thinking about copying or distributing this 
Package.

 Reasonable copying fee is whatever you can justify on the basis of media 
cost, duplication charges, time of people involved, and so on.  (You will not 
be required to justify it to the Copyright Holder, but only to the computing 
community at large as a market that must bear the fee.)

 Freely Available means that no fee is charged for the item itself, 
though there may be fees involved in handling the item. It also means that 
recipients of the item may redistribute it under the same conditions they 
received it.

1. You may make and give away verbatim copies of the source form of the 
Standard Version of this Package without restriction, provided that you 
duplicate all of the original copyright notices and associated disclaimers.

2. You may apply bug fixes, portability fixes and other modifications derived 
from the Public Domain or from the Copyright Holder.  A Package modified in 
such a way shall still be considered the Standard Version.

3. You may otherwise modify your copy of this Package in any way, provided that 
you insert a prominent notice in each changed file stating how and when you 
changed that file, and provided that you do at least ONE of the following:

 a) place your modifications in the Public Domain or otherwise make them 
Freely Available, such as by posting said modifications to Usenet or an 
equivalent medium, or placing the modifications on a major archive site such as 
[-ftp.uu.net,-] {+uunet.uu.net,+} or by allowing the Copyright Holder to 
include your modifications in the Standard Version of the Package.
 b) use the modified Package only within your corporation or organization.
 c) rename any non-standard executables so the names do not conflict with 
standard executables, which must also be provided, and provide a separate 
manual page for each non-standard executable that clearly documents how it 
differs from the Standard Version.
 d) make other distribution arrangements with the Copyright Holder.

4. You may distribute the programs of this Package in object code or executable 
form, provided that you do at least ONE of the following:

 a) distribute a Standard Version of the executables and library files, 
together with instructions (in the manual page or equivalent) on where to get 
the Standard Version.
 b) accompany the distribution with the machine-readable source of the 
Package with your modifications.
 c) [-accompany any non-standard executables with their corresponding 
Standard Version executables, giving the-] {+give+} non-standard executables 
non-standard names, and clearly [-documenting-] {+document+} the differences in 
manual pages (or equivalent), together

Bug#748859: Output in syslog

2014-10-09 Thread Michael Ott

Hi!

When I try to update the accout I received the following output in
syslog

Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]: **
Message: console message:
https://fbstatic-a.akamaihd.net/rsrc.php/v2/y3/r/KN8zvBUd0-O.js @25:
Oct  7 05:08:57 k-c13
org.gnome.ControlCenter.SearchProvider[2489]: .db.  888
888
Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]: d88P
Y88b 888   888
Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]:
Y88b.  888   888This is a browser feature
intended for
Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]:
Y888b.   88  .d88b.  8b.   888developers. If someone told
you to copy
Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]:
Y88b. 888db 888 88b  888and paste something here to
enable a
Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]: 888
888888  888 888  888  Y8PFacebook feature or hack someone's
Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]: Y88b
d88P Y88b.  Y88..88P 888 d88P account, it is a scam and will
give them
Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]:
YP   Y888  Y88P  8P   888access to your Facebook
account.
Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]: 888
Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]: 888
Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]: 888
Oct  7 05:08:57 k-c13 org.gnome.ControlCenter.SearchProvider[2489]: For
more information, see https://www.facebook.com/selfxss.

CU  
 
  Michael Ott
  
-- 
,''`.   
   : :' :   Michael Ott 
   `. `'e-mail: michael at king-coder dot de
 `-


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

Bug#764567: ITP: obs-build -- Build DEB/RPM packages for various distributions inside a chroot


Hi Dimitri,

On  Do 09 Okt 2014 08:45:17 CEST, Dimitri John Ledkov wrote:


Hey,

On 9 October 2014 05:21, Mike Gabriel  
mike.gabr...@das-netzwerkteam.de wrote:

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de

* Package name: obs-build
  Version : Git snapshot (every commit is a release)
  Upstream Author : Michael Schroeder (https://github.com/mlschroe)
* URL : https://github.com/openSUSE/obs-build
* License : GPL
  Programming Lang: Perl
  Description : Build DEB/RPM packages for various  
distributions inside a chroot


 OBS Build creates chroots and builds DEB/RPM packages for various
 Linux distributions. In Debian, this package fills a gap: it allows one to
 build packages for the openSUSE/SLES distributions on Debian system.
 .
 Its only task is to reliably populate a chroot and attempt to build
 a package in that chroot. It is used by the Open Build System provided
 by SUSE, but can also be use as a standalone tool.
 .
 Optionally, builds can take place in KVM or XEN instance.



I think we had a mid-air collision:
https://ftp-master.debian.org/new/obs-build_20140918-1.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762949

I'm happy to co-maintain this package.


Yeah. I saw Adams mail early this morning.

I have the package nearly ready... Do you have anything packaged, yet?  
Or shall I just add you to Uploaders: (with what mail address)?


I plan to push the packaging Git to collab-maint (or have you already  
provided a packaging repo there?)


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


pgp412MtfjDXg.pgp
Description: Digitale PGP-Signatur

Bug#764395: openvpn-auth-ldap: segmentation fault

2014-10-09 Thread Alberto Gonzalez Iniesta

On Wed, Oct 08, 2014 at 11:44:19AM -0600, Andrew Patterson wrote:
 On Wed, 8 Oct 2014 18:40:40 +0200 Alberto Gonzalez Iniesta a...@inittab.org 
 wrote:
  Hi Andrew,
 
  The plugin segfaults because it needs a config file as a parameter.
  It's not a nice behaviour, but not a critial one (since it needs a
  config file to be useful).
 
  Try:
 
  openvpn --dev null --plugin /usr/lib/openvpn/openvpn-auth-ldap.so ldap.cf
 
  Regards,
 
  Alberto
 
 
 Yes, Specifying the config file fixed my segmentation fault issue. Should we 
 open a new bug? Rename this one? Or consider this one closed?

Hi, feel free to open a new one if you want. This is better off closed,
since the bug is present in all versions of the package, not just
wheezy.

Thanks,

Alberto

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55


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

Bug#762007: Kernel command line handling change breaks d-i user-params functionality

2014-10-09 Thread Ian Campbell

On Sat, 2014-09-27 at 14:01 +0100, Ian Campbell wrote:
 On Wed, 2014-09-17 at 18:45 +0100, Ian Campbell wrote:
  Not sure what we can do about this. Perhaps choose another separator
  (==?) and make user-params support both?
 
 Reading the kernel source it seems it only checks for exactly --. So I
 propose we support --- in addition to --, something like the
 following (untested) patch.

I've built an di-utils with this patch and built a di using that
package. I booted (on x86 FWIW) with a command line ending
--- quiet console=ttyS0,115200n8
instead of -- quiet console=ttyS0,115200n8.

Dropping straight to a shell and running user-params returns those two
options as expected.

I've left a complete install running but I'm pretty confident that it
will succeed.

As well as this fix I think we need to investigate which of these need
fixing too (i.e. with s/--/---/ in appropriate places):
  * The pxe/grub etc configs in debian-installer.git
  * Debian-cd
  * Installation guide

I'm sure that list must be incomplete but it was all I could come up
with. Sadly, as you might imagine, -- is not terribly amenable to grep
or codesearch.d.o.

Ian.

 
 diff --git a/user-params b/user-params
 index 53677b5..2d41e05 100755
 --- a/user-params
 +++ b/user-params
 @@ -14,7 +14,7 @@ for item in $(sed -e 's/[^ =]*=[^]*[ ][^]*//g' \
   # Remove trailing '?' for debconf variables set with '?='
   var=${var%\?}
  
 - if [ $item = -- ]; then
 + if [ $item = -- ] || [ $item = --- ]; then
   inuser=1
   collect=
   elif [ $inuser ]; then
 
 Ian.
 
 


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

Bug#764574: please backport commit a28a9178e8 from v3.8

2014-10-09 Thread Romain Francoise

Package: src:linux
Version: 3.2.63-2
Severity: wishlist

I'm using Apache TrafficServer on wheezy, and I get the following in
dmesg once per day:

[28050.283707] EXT4-fs (dm-0): Unaligned AIO/DIO on inode 7734855 by [ET_NET 
4]; performance will be poor.
[50104.515999] EXT4-fs (dm-0): Unaligned AIO/DIO on inode 7734855 by [ET_NET 
5]; performance will be poor.
[79848.128273] EXT4-fs (dm-0): Unaligned AIO/DIO on inode 7734855 by [ET_NET 
0]; performance will be poor.

This warning isn't very useful, and it looks like it was removed from
the kernel in v3.8 by commit a28a9178e8, it would be great if you could
apply a similar change to the Debian sources (the upstream patch doesn't
cherry-pick cleanly on top of v3.2.63).

commit a28a9178e8fcd9b94f7333184ce78e816c8cb2af
Author: Eric Sandeen sand...@redhat.com
Date:   Tue Dec 25 13:33:13 2012 -0500

ext4: remove unaligned AIO warning printk

Although I put this in, I now think it was a bad decision.  For most
users, there is very little to be done in this case.  They get the
message, once per day, with no real context or proposed action.  TBH,
it generates support calls when it probably does not need to; the
message sounds more dire than the situation really is.

Just nuke it.  Normal investigation via blktrace or whatnot can
reveal poor IO patterns if bad performance is encountered.

Signed-off-by: Eric Sandeen sand...@redhat.com
Signed-off-by: Theodore Ts'o ty...@mit.edu

diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index b64a60b..1c0aad7 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -108,14 +108,6 @@ ext4_file_dio_write(struct kiocb *iocb, const struct iovec 
*iov,
 
/* Unaligned direct AIO must be serialized; see comment above */
if (unaligned_aio) {
-   static unsigned long unaligned_warn_time;
-
-   /* Warn about this once per day */
-   if (printk_timed_ratelimit(unaligned_warn_time, 60*60*24*HZ))
-   ext4_msg(inode-i_sb, KERN_WARNING,
-Unaligned AIO/DIO on inode %ld by %s; 
-performance will be poor.,
-inode-i_ino, current-comm);
mutex_lock(ext4_aio_mutex(inode));
ext4_unwritten_wait(inode);
}

Thanks,
-- 
Romain Francoise rfranco...@debian.org
http://people.debian.org/~rfrancoise/


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

Bug#758788: [pkg-cryptsetup-devel] Bug#758788: Bug#758788: Bug#758788: cryptsetup: Passphrase caching broken in decrypt_keyctl

2014-10-09 Thread luc


Le 2014-10-08 23:21, Jonas Meurer a écrit :

Hey Luc,


Hi Jonas,



Am 03.10.2014 um 21:55 schrieb Jonas Meurer:

Am 03.10.2014 um 21:15 schrieb Luc Maisonobe:
I failed to reproduce the bug you discovered so far. Can you please 
give

the latest packages from
https://people.debian.org/~mejo/debian/mejo-unstable/ a try and see
whether decrypt_keyctl still doesn't work for you?


The new packages allow to boot, but I still have to enter the key 
twice,

once for each encrypted device.


Very strange. I'm still unable to reproduce the issues you encounter.
Could you do some futher testing for me?


Did you find time to do the additional testing/debugging yet? I'd like
to fix this bug in time for Debian Jessie, provided that it's really a
bug in the package and not an issue on your side ;)


Not yet, but I intend to do so.
The problem occurs on a computer with some critical information on it,
and the partitions already use the full disk space. This implies I have 
to do
some careful work of shrinking filesystems, logical volumes and so on 
before I can

set up a test partition aside.



As already mentioned - up to now I'm unable to reproduce the bug. For
me, decrypt_keyctl works in all tested setups. The provided passphrase
is stored in kernel keyring with first invokation and used for all the
following device unlockings that have the same keyscript/keyname 
configured.


I understand your point. It is difficult to debug here (as mentioned 
earlier putting
some echo commands completely trashed the boot sequence). I'll do my 
best.


best regards,
Luc



Kind regards,
 jonas

I test the decrypt_keyctl script with the following setup, and it 
works

as expected. Maybe you could try a similar setup:

- create two small lvm logical volumes (5MB are more than enough)
- luksformat both logical volumes
- add them to your crypttab:

clv1_crypt /dev/VG/LV1 testkey1 luks,keyscript=decrypt_keyctl
clv2_crypt /dev/VG/LV2 testkey1 luks,keyscript=decrypt_keyctl

- try unlocking them via cryptdisks_start:

# cryptdisks_start clv1_crypt
# cryptdisks_start clv2_crypt

The second unlocking should use the key cached during first unlocking.

It would be awesome if you could test this. I as well tested this 
setup
during boot process, and it works as expected as well. Also tested 
with

UUID instead of source device path in crypttab, same result.

I've no glue what's different on your setups, and any help with
debugging would be highly appreciated.


In case that you still encounter the bug, please paste your full
/etc/fstab and /etc/crypttab again.


/etc/crypttab:

sdb1_crypt UUID=9aa983b5-0224-406b-a177-7481162c6172
sda5_sdb1_common_key luks,keyscript=decrypt_keyctl
sda5_crypt UUID=3764df68-de26-4a24-a7dc-1498cb6b20ab
sda5_sdb1_common_key luks,keyscript=decrypt_keyctl


Nothing suspicious here, looks ok to me.

Note that the two partitions contain physical volumes for LVM, as 
shown

here:


Actually the content of your encrypted devices should not matter at 
all.


Kind regards,
 jonas

___
pkg-cryptsetup-devel mailing list
pkg-cryptsetup-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cryptsetup-devel




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

Bug#728375: libjetty8-java-doc: Questionable dependencies

2014-10-09 Thread Jan Henke

Am 09.10.2014 um 09:27 schrieb Mauro Molinari:
 Il 06/10/2014 12:09, Emmanuel Bourg ha scritto:
 libjetty8-java-doc already recommends default-jdk-doc, maybe you
 meant suggested instead? 

 I may have used the wrong terms here, sorry. What I find questionable
 is that, as I said in my original report, if I try to install
 libjetty8-java-doc, APT by default says it will install other Javadoc
 packages as well, for a total of almost 300MB of data... I don't think
 these dependency Javadoc packages are actually needed for me to read
 the Jetty 8 documentation. They might be useful in some cases, but
 nothing more.

 I just learnt I can use --no-install-recommends apt-get parameter (I
 expect aptitude to have something similar) to filter out recommended
 packages, but that's not what I would expect by default.

 This is just my opinion. Thanks for your feedback!
 Mauro

 __
 This is the maintainer address of Debian's Java team
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers.
 Please use
 debian-j...@lists.debian.org for discussions and questions.
Hi,

I do think it is reasonable to assume that installing an optional
documentation package of one component normally also installs the
documentation for other related packages. Especially it does seem to be
logical to have default-jdk-doc installed when you install the
documentation of jetty. As such I am in favour of keeping the current
recommends.

For sure the default behaviour does not suit every use case, but I do
not think changing the default should be done. I still think the current
default is the expected behaviour.
-- 
Best regards,
Jan



signature.asc
Description: OpenPGP digital signature

Bug#764575: libpython3.4-minimal: adequate reports broken-symlink /usr/lib/python3.4/sitecustomize.py

2014-10-09 Thread Thorsten Glaser

Package: libpython3.4-minimal
Version: 3.4.2-1
Severity: minor

The attached patch fixes this apparent mistake, which does
still happen.

I would have provided a bzr diff, but the VCS-Bzr URL
http://bazaar.launchpad.net/~doko/python/pkg3.4-debian
gives a 404. Please fix that too ☺

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

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

Versions of packages libpython3.4-minimal depends on:
ii  libc6  2.19-11
ii  libssl1.0.01.0.1i-2
ii  multiarch-support  2.19-11

Versions of packages libpython3.4-minimal recommends:
ii  libpython3.4-stdlib  3.4.2-1

libpython3.4-minimal suggests no packages.

-- Configuration Files:
/etc/python3.4/sitecustomize.py [Errno 2] No such file or directory: 
u'/etc/python3.4/sitecustomize.py'

-- no debconf information
diff -pru python3.4-3.4.2~/debian/PVER-minimal.postinst.in python3.4-3.4.2/debian/PVER-minimal.postinst.in
--- python3.4-3.4.2~/debian/PVER-minimal.postinst.in	2014-10-09 09:56:26.0 +0200
+++ python3.4-3.4.2/debian/PVER-minimal.postinst.in	2014-10-09 09:57:14.899574723 +0200
@@ -3,7 +3,7 @@
 set -e
 
 if [ ! -f /etc/@PVER@/sitecustomize.py ]; then
-cat -EOF
+cat /etc/@PVER@/sitecustomize.py -EOF
 	# Empty sitecustomize.py to avoid a dangling symlink
 EOF
 fi
diff -pru python3.4-3.4.2~/debian/libPVER-minimal.postinst.in python3.4-3.4.2/debian/libPVER-minimal.postinst.in
--- python3.4-3.4.2~/debian/libPVER-minimal.postinst.in	2014-10-09 09:56:26.0 +0200
+++ python3.4-3.4.2/debian/libPVER-minimal.postinst.in	2014-10-09 09:57:14.571570325 +0200
@@ -3,7 +3,7 @@
 set -e
 
 if [ ! -f /etc/@PVER@/sitecustomize.py ]; then
-cat -EOF
+cat /etc/@PVER@/sitecustomize.py -EOF
 	# Empty sitecustomize.py to avoid a dangling symlink
 EOF
 fi

Bug#764576: linphone-nogtk: Blind Transfer fails with SIP 429

2014-10-09 Thread Florian Bach

Package: linphone-nogtk
Version: 3.5.2-10
Severity: normal

Dear Maintainer,

I have linphonec installed on my Ubuntu 14.04, and I have a SIP account 
registered from my AVM FRITZ!Box 6360. 

When I now try to perform a Blind Transfer using 
transfer $call-id $phonenumber, the transfer fails and I get the SIP error
code 429 Provide Referrer Identity returned from the Fritzbox. 

I suppose this is because of linphonec not sending the Referred-By-header. 

Is it possible to fix this bug so FRITZ!Box users can use the Blind Transfer?

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

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

Versions of packages linphone-nogtk depends on:
ii  bind9-host [host]  1:9.9.3.dfsg.P2-4ubuntu1.1
ii  libc6  2.17-93ubuntu4
ii  liblinphone4   3.5.2-10
ii  libmediastreamer1  3.5.2-10
ii  libortp8   3.5.2-10
ii  libreadline6   6.2-9ubuntu1
ii  libx11-6   2:1.6.1-1ubuntu1
ii  linphone-common3.5.2-10

linphone-nogtk recommends no packages.

linphone-nogtk 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#728375: libjetty8-java-doc: Questionable dependencies

2014-10-09 Thread Mauro Molinari


Il 09/10/2014 09:47, Jan Henke ha scritto:
Hi, I do think it is reasonable to assume that installing an optional 
documentation package of one component normally also installs the 
documentation for other related packages. Especially it does seem to 
be logical to have default-jdk-doc installed when you install the 
documentation of jetty. As such I am in favour of keeping the current 
recommends. For sure the default behaviour does not suit every use 
case, but I do not think changing the default should be done. I still 
think the current default is the expected behaviour. 


Just to say that my opinion was based on the fact that I am an 
experienced Java developer. I really don't need the JDK docs just to 
read the Jetty 8 Javadoc.
I would assume that if one needs to use the Jetty API in its own 
application already knows what a String or an IOException is, just 
to mention the first two JDK classes that come into my mind.


So, it's just a logical vs practical approach. Maybe suggests 
would keep the logical relationship between packages without unexpected 
practical consequences on the weight of the size on disk (almost 8x) and 
download (almost 12x).


After all, the Jetty 8 Javadoc is self-contained, as it is viewable 
online at: http://download.eclipse.org/jetty/stable-8/apidocs/
Even if references towards JDK classes didn't work, they won't limit the 
usability of the documentation in a substantial way.
By the way, I was wondering if inter-javadoc package references work if 
I install all of those 300 MB of packages (do the downloaded HTML files 
contain file:// absolute paths to get to the proper Javadoc files in the 
Debian filesystem structure? I can't test now).


Mauro


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

Bug#764568: cheese: program dies with Attempt to unlock mutex that was not locked

2014-10-09 Thread Emilio Pozuelo Monfort


Version: 3.14.0-1
Control: severity -1 grave

On 08/10/14 19:20, Norbert Gruener wrote:

Package: cheese
Version: 3.12.2-1
Severity: critical

Dear Maintainer,

the program cheese dies with the following message

norbert@norbert-tuxedo:~ $ cheese

Attempt to unlock mutex that was not locked
Aborted


It is the same problem as in querybts, reportbug, and others ...


I can reproduce it with 3.12.2-1 but not with cheese 3.14.0-1. So let's mark it 
as fixed in 3.14.


Emilio


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

Bug#764577: update-manager-gnome: always complains ‘Downloading list of changes failed.’

2014-10-09 Thread Axel Stammler

Package: update-manager-gnome
Version: 0.200.5-2.1
Severity: normal

Dear Maintainer,

I think it would be a good idea if people could see a summary of each package 
update
before they decide to install the update. Unfortunately this is never possible 
even though
there is an actual part of the screen titled ‘Description of update’ as this 
part never
shows any actual content except the error message.

-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages update-manager-gnome depends on:
ii  gconf2   3.2.5-1+build1
ii  gksu 2.0.2-6
ii  python   2.7.3-4+deb7u1
ii  python-dbus  1.1.1-1
ii  python-gconf 2.28.1+dfsg-1
ii  python-gobject   3.2.2-2
ii  python-gtk2  2.24.0-3+b1
ii  python-support   1.0.15
ii  python-vte   1:0.28.2-5
ii  update-manager-core  0.200.5-2.1

update-manager-gnome recommends no packages.

Versions of packages update-manager-gnome suggests:
ii  software-properties-gtk  0.82.7.1debian1
ii  update-notifier  0.99.3debian11

-- debconf-show failed


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

Bug#764373: Chromium is missing from the Kickoff (KDE menu) and the like

2014-10-09 Thread Boris Pek

control: retitle -1 chromium: desktop file, icons and other files are missing 
from binary package

Hi,

  After recent update chromium.desktop file is disappeared from binary 
 package.

 The icons went missing, as well.

Hmm, let's see more detail diff:

$ debdiff chromium_37.0.2062.120-2_i386.deb chromium_37.0.2062.120-4_i386.deb


[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   /etc/chromium.d/README
-rw-r--r--  root/root   /usr/lib/chromium/chrome_200_percent.pak
-rw-r--r--  root/root   /usr/lib/chromium/initial_bookmarks.html
-rw-r--r--  root/root   /usr/lib/chromium/libffmpegsumo.so.TOC
-rw-r--r--  root/root   /usr/lib/chromium/libpdf.so.TOC
-rw-r--r--  root/root   /usr/lib/chromium/master_preferences

Files in first .deb but not in second
-
-rw-r--r--  root/root   /etc/chromium/default
-rw-r--r--  root/root   /etc/chromium/initial_bookmarks.html
-rw-r--r--  root/root   /etc/chromium/master_preferences
-rw-r--r--  root/root   /usr/lib/chromium/pseudo_locales/fake-bidi.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/ar.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/bg.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/ca.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/cs.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/da.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/de.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/el.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/en-GB.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/en.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/es-419.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/es.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/et.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/fi.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/fil.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/fr.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/he.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/hi.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/hr.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/hu.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/id.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/it.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/ja.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/ko.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/lt.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/lv.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/nb.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/nl.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/pl.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/pt-BR.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/pt-PT.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/ro.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/ru.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/sk.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/sl.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/sr.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/sv.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/th.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/tr.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/uk.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/vi.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/zh-CN.pak
-rw-r--r--  root/root   /usr/lib/chromium/remoting_locales/zh-TW.pak
-rw-r--r--  root/root   /usr/lib/chromium/resources/extension/demo/library.js
-rw-r--r--  root/root   /usr/share/applications/chromium.desktop
-rw-r--r--  root/root   /usr/share/doc/chromium/AUTHORS.gz
-rw-r--r--  root/root   /usr/share/doc/chromium/NEWS.Debian.gz
-rw-r--r--  root/root   /usr/share/doc/chromium/README.Debian
-rw-r--r--  root/root   /usr/share/doc/chromium/copyright.problems.gz
-rw-r--r--  root/root   /usr/share/icons/hicolor/128x128/apps/chromium.png
-rw-r--r--  root/root   /usr/share/icons/hicolor/22x22/apps/chromium.png
-rw-r--r--  root/root   /usr/share/icons/hicolor/24x24/apps/chromium.png
-rw-r--r--  root/root   /usr/share/icons/hicolor/256x256/apps/chromium.png
-rw-r--r--  root/root   /usr/share/icons/hicolor/48x48/apps/chromium.png
-rw-r--r--  root/root   /usr/share/icons/hicolor/64x64/apps/chromium.png
-rw-r--r--  root/root   /usr/share/icons/hicolor/scalable/apps/chromium.svg
-rw-r--r--  root/root   /usr/share/pixmaps/chromium.png
-rwxr-xr-x  root/root   DEBIAN/preinst

Bug#728375: libjetty8-java-doc: Questionable dependencies

2014-10-09 Thread Jan Henke

Am 09.10.2014 um 10:06 schrieb Mauro Molinari:
 Il 09/10/2014 09:47, Jan Henke ha scritto:
 Hi, I do think it is reasonable to assume that installing an optional
 documentation package of one component normally also installs the
 documentation for other related packages. Especially it does seem to
 be logical to have default-jdk-doc installed when you install the
 documentation of jetty. As such I am in favour of keeping the current
 recommends. For sure the default behaviour does not suit every use
 case, but I do not think changing the default should be done. I still
 think the current default is the expected behaviour. 

 Just to say that my opinion was based on the fact that I am an
 experienced Java developer. I really don't need the JDK docs just to
 read the Jetty 8 Javadoc.
 I would assume that if one needs to use the Jetty API in its own
 application already knows what a String or an IOException is, just
 to mention the first two JDK classes that come into my mind.

 So, it's just a logical vs practical approach. Maybe suggests
 would keep the logical relationship between packages without
 unexpected practical consequences on the weight of the size on disk
 (almost 8x) and download (almost 12x).

 After all, the Jetty 8 Javadoc is self-contained, as it is viewable
 online at: http://download.eclipse.org/jetty/stable-8/apidocs/
 Even if references towards JDK classes didn't work, they won't limit
 the usability of the documentation in a substantial way.
 By the way, I was wondering if inter-javadoc package references work
 if I install all of those 300 MB of packages (do the downloaded HTML
 files contain file:// absolute paths to get to the proper Javadoc
 files in the Debian filesystem structure? I can't test now).

 Mauro
Hi,

you say yourself you are an experienced Java developer, thus I strongly
feel your use case and expectations are different from what the default
should provide. You know you do not need the openkdk-doc, so nothing
stops you from preventing the installation of it (with the apt parameter
you mentioned) or removing it again.

I strongly feel the requirements and expectations of experienced people
should *not* set the default. The default should be chosen to
accommodate the need of the novice and average user. When you are an
advanced user you normally also have knowledge to modify the default to
fit your need, something the average or novice user might not have.

I see your point and understand it from my personal use case as well.
But I strongly think our use case should never set the default.
Therefore I vote for keeping the recommends instead of a merely suggests.
-- 
Best Regards,
Jan



signature.asc
Description: OpenPGP digital signature

Bug#764441: sinfo and slurm-client: error when trying to install together

2014-10-09 Thread Mehdi Dogguy

Hi Gaudenz,

On Wed, Oct 08, 2014 at 10:34:45AM +0200, Gaudenz Steinlin gaud...@debian.org 
wrote:
 
 Ralf Treinen trei...@free.fr writes:
 
  Here is a list of files that are known to be shared by both packages
  (according to the Contents file for sid/amd64, which may be
  slightly out of sync):
 
/usr/bin/sinfo
/usr/share/man/man1/sinfo.1.gz
 
 This happends because the sinfo binary in slurm moved from slurm-llnl to
 slurm-client and now the conflict specified in sinfo is wrong. To
 restore the previous state, sinfo should update it's conflict to
 slurm-client with appropriate versioning.
 

Since your package had a Conflicts, can you please update it? If you agree
on that, can you also reassign this bug to src:sinfo so that it is tracked
properly?

Cheers.

-- 
Mehdi Dogguy


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

Bug#764508: [Pkg-libvirt-maintainers] Bug#764508: virt-manager: Flagging a USB device as removable fails

Hi Guido  others,

Guido Günther wrote (08 Oct 2014 17:53:18 GMT) :
 Please NMU, just to be sure we get this change in.

Thanks for the prompt answer and for welcoming contributions :)
I've just NMU'd 1:1.0.1-2.1.

I'm attaching the output of git format-patch, to make it easy for you
to integrate my changes into the Vcs-Git (blindly assuming I have no
write access to that repo, since it's not in collab-maint).

BTW, the upstream and pristine-tar branches in the Vcs-Git seem to
be outdated. Could anyone please push them? Thanks in advance!

Cheers,
-- 
intrigeri

From ff359a1171be5f8fdaf5171c891d716b3bb252c0 Mon Sep 17 00:00:00 2001
From: intrigeri intrig...@debian.org
Date: Wed, 8 Oct 2014 17:04:48 +
Subject: [PATCH 1/2] fix-removable-drive-support.patch: new patch,
 cherry-picked from upstream.

---
 debian/patches/fix-removable-drive-support.patch | 20 
 debian/patches/series|  1 +
 2 files changed, 21 insertions(+)
 create mode 100644 debian/patches/fix-removable-drive-support.patch

diff --git a/debian/patches/fix-removable-drive-support.patch b/debian/patches/fix-removable-drive-support.patch
new file mode 100644
index 000..6f08a2d
--- /dev/null
+++ b/debian/patches/fix-removable-drive-support.patch
@@ -0,0 +1,20 @@
+Author: Giuseppe Scrivano gscri...@redhat.com
+Date:   Tue Jun 24 13:59:12 2014 +0200
+Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1112629
+Bug-Debian: https://bugs.debian.org/764508
+Origin: upstream, https://git.fedorahosted.org/cgit/virt-manager.git/commit/?id=eb5b2613110dfaa23626a16704d18df0dbba5086
+Description: details.py: fix typo s|removeable|removable|
+
+diff --git a/virtManager/details.py b/virtManager/details.py
+index dd43259..d3826e5 100644
+--- a/virtManager/details.py
 b/virtManager/details.py
+@@ -2166,7 +2166,7 @@ class vmmDetails(vmmGObjectUI):
+ kwargs[shareable] = self.widget(disk-shareable).get_active()
+ 
+ if self.edited(EDIT_DISK_REMOVABLE):
+-kwargs[removeable] = bool(
++kwargs[removable] = bool(
+ self.widget(disk-removable).get_active())
+ 
+ if self.edited(EDIT_DISK_CACHE):
diff --git a/debian/patches/series b/debian/patches/series
index b028b2a..4ff2c04 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 virtinst/fix-path-to-hvmloader.patch
 virtinst/Fix-patch-to-pygrub.patch
 Move-GConf-values-to-GSettings.patch
+fix-removable-drive-support.patch
-- 
2.1.1

From 74c9bd17b5ac6756243a7b9b8b61451c40fec0af Mon Sep 17 00:00:00 2001
From: intrigeri intrig...@debian.org
Date: Wed, 8 Oct 2014 17:05:16 +
Subject: [PATCH 2/2] virt-manager (1:1.0.1-2.1)

Git-Dch: Ignore
---
 debian/changelog | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index a53773a..262b74d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+virt-manager (1:1.0.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload, with permission from maintainer.
+  * fix-removable-drive-support.patch: new patch, cherry-picked from upstream
+(Closes: #764508).
+
+ -- intrigeri intrig...@debian.org  Thu, 09 Oct 2014 10:20:56 +0200
+
 virt-manager (1:1.0.1-2) unstable; urgency=medium
 
   * Upload to unstable
-- 
2.1.1

Bug#764403: primus-libs:amd64: libGL is too old with driconf/xdriinfo and nouveau

2014-10-09 Thread Vincent Cheng

On Wed, Oct 8, 2014 at 11:48 AM, Adrian Lang deb...@adrianlang.de wrote:
 On Tue, 7 Oct 2014 23:24:12 -0700 Vincent Cheng vch...@debian.org wrote:
 By normal driver, do you mean the proprietary nvidia driver?

 No, I mean intel driver with intel card.

 Does this error still persist if you try rebuilding primus?

 Yes, I just rebuilt primus and primus-libs:amd64 and I still get the
 same error.

Can you please file a bug report upstream at [1]? Also, if you're
willing to try the proprietary nvidia driver, can you please test with
that as well?

[1] https://github.com/amonakov/primus/issues/new


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

Bug#764578: [wine-development] add option to debian/rules to build without stack protection

2014-10-09 Thread Konstantin Demin

Source: wine-development
Version: 1.7.28-2
Severity: wishlist
Tags: patch

Hello!
Would you mind to add option in debian/rules to build without stack protection?
Patch is available.

-- 
SY,
Konstantin Demin
description: add option to disable stack protection in debian/rules
author: Konstantin Demin rockdri...@gmail.com

diff --git a/debian/rules b/debian/rules
index a71b228..3fa7583 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,24 @@ export DH_VERBOSE=1
 # wine build fails with pie enabled
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
 
+# stack smashing protection
+# enable  = any non-empty value
+# disable = empty
+GCC_SSP ?= yes
+
+ifeq ($(DEB_BUILD_ARCH_CPU), amd64)
+GCC_STACK_BOUNDS=4
+else
+GCC_STACK_BOUNDS=2
+endif
+# '2' raised to the power of GCC_STACK_BOUNDS is used as actual stack boundary 
value.
+ifeq (,$(GCC_SSP))
+DEB_BUILD_MAINT_OPTIONS :=$(DEB_BUILD_MAINT_OPTIONS),-stackprotector
+GCC_STACK_OPTS =-fno-stack-protector -mstackrealign 
-mincoming-stack-boundary=$(GCC_STACK_BOUNDS)
+CFLAGS   +=$(GCC_STACK_OPTS)
+CXXFLAGS +=$(GCC_STACK_OPTS)
+endif
+
 VERSION=$(shell dpkg-parsechangelog | grep ^Source | cut -d\  -f2 | sed 
s/wine//g)
 
 DATADIR=/usr/share/wine$(VERSION)
@@ -36,13 +54,18 @@ CONFLAGS=--without-hal \
  --mandir=/$(MANDIR) \
  --datarootdir=$(DATADIR) \
  --includedir=$(INCLUDEDIR) \
- LDFLAGS=$(LDFLAGS) \
 
 # enable wine64 on amd64
 ifeq ($(DEB_BUILD_ARCH_CPU), amd64)
 CONFLAGS+=--enable-win64
 endif
 
+CONFLAGS+= \
+CPPFLAGS=$(CPPFLAGS) \
+CFLAGS=$(CFLAGS) \
+CXXFLAGS=$(CXXFLAGS) \
+LDFLAGS=$(LDFLAGS)
+
 # additional files to generate
 INSTALLS=$(shell ls debian/*VERSION* | sed s/VERSION/$(VERSION)/)

Bug#764579: minetest: FTBFS on hurd-i386

2014-10-09 Thread Svante Signell

Source: minetest
Version: 0.4.10+repack-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

minetest fails to build on GNU/Hurd due to a name clash with OSX/Apple,
both are defining the __MACH__ keyword. This package has built
previously, and the latest building version is 0.4.9+repack-6. The
attached patch fixes the build problems for version 0.4.10+repack-1.

Thanks!
--- a/src/cguittfont/irrUString.h	2014-07-07 00:06:06.0 +0200
+++ b/src/cguittfont/irrUString.h	2014-10-08 08:22:35.0 +0200
@@ -45,7 +45,7 @@
 #define __BYTE_ORDER 0
 #define __LITTLE_ENDIAN 0
 #define __BIG_ENDIAN 1
-#elif __MACH__
+#elif defined(__MACH__)  defined(__APPLE__)
 #include machine/endian.h
 #else
 #include endian.h
--- a/src/jthread/jevent.h	2014-07-07 00:06:06.0 +0200
+++ b/src/jthread/jevent.h	2014-10-08 08:38:33.0 +0200
@@ -30,7 +30,7 @@
 
 #ifdef _WIN32
 #include windows.h
-#elif __MACH__
+#elif defined(__MACH__)  defined(__APPLE__)
 #include mach/mach.h
 #include mach/task.h
 #include mach/semaphore.h
@@ -43,7 +43,7 @@
 class Event {
 #ifdef _WIN32
 	HANDLE hEvent;
-#elif __MACH__
+#elif defined(__MACH__)  defined(__APPLE__)
 	semaphore_t sem;
 #else
 	sem_t sem;
--- a/src/jthread/pthread/jevent.cpp	2014-07-07 00:06:06.0 +0200
+++ b/src/jthread/pthread/jevent.cpp	2014-10-08 08:27:50.0 +0200
@@ -29,7 +29,7 @@
 
 #define UNUSED(expr) do { (void)(expr); } while (0)
 
-#ifdef __MACH__
+#if defined(__MACH__)  defined(__APPLE__)
 #undef sem_t
 #define sem_t semaphore_t
 #undef sem_init
--- a/src/jthread/jsemaphore.h	2014-07-07 00:06:06.0 +0200
+++ b/src/jthread/jsemaphore.h	2014-10-08 08:29:13.0 +0200
@@ -24,7 +24,7 @@
 #include windows.h
 #include assert.h
 #define MAX_SEMAPHORE_COUNT 1024
-#elif __MACH__
+#elif defined(__MACH__)  defined(__APPLE__)
 #include pthread.h
 #include mach/mach.h
 #include mach/task.h
@@ -52,7 +52,7 @@
 private:
 #if defined(WIN32)
 	HANDLE m_hSemaphore;
-#elif __MACH__
+#elif defined(__MACH__)  defined(__APPLE__)
 	semaphore_t m_semaphore;
 	int semcount;
 #else
--- a/src/jthread/pthread/jsemaphore.cpp	2014-07-07 00:06:06.0 +0200
+++ b/src/jthread/pthread/jsemaphore.cpp	2014-10-08 08:30:53.0 +0200
@@ -20,13 +20,13 @@
 #include errno.h
 #include sys/time.h
 #include jthread/jsemaphore.h
-#ifdef __MACH__
+#if defined(__MACH__)  defined(__APPLE__)
 #include unistd.h
 #endif
 
 #define UNUSED(expr) do { (void)(expr); } while (0)
 
-#ifdef __MACH__
+#if defined(__MACH__)  defined(__APPLE__)
 #undef sem_t
 #undef sem_init
 #undef sem_wait
@@ -44,7 +44,7 @@
 	int sem_init_retval = sem_init(m_semaphore,0,0);
 	assert(sem_init_retval == 0);
 	UNUSED(sem_init_retval);
-#ifdef __MACH__
+#if defined(__MACH__)  defined(__APPLE__)
 	semcount = 0;
 #endif
 }
@@ -73,7 +73,7 @@
 	int sem_post_retval = sem_post(m_semaphore);
 	assert(sem_post_retval == 0);
 	UNUSED(sem_post_retval);
-#ifdef __MACH__
+#if defined(__MACH__)  defined(__APPLE__)
 	pthread_mutex_lock(semcount_mutex);
 	semcount++;
 	pthread_mutex_unlock(semcount_mutex);
@@ -84,7 +84,7 @@
 	int sem_wait_retval = sem_wait(m_semaphore);
 	assert(sem_wait_retval == 0);
 	UNUSED(sem_wait_retval);
-#ifdef __MACH__
+#if defined(__MACH__)  defined(__APPLE__)
 	pthread_mutex_lock(semcount_mutex);
 	semcount--;
 	pthread_mutex_unlock(semcount_mutex);
@@ -92,7 +92,7 @@
 }
 
 bool JSemaphore::Wait(unsigned int time_ms) {
-#ifdef __MACH__
+#if defined(__MACH__)  defined(__APPLE__)
 	mach_timespec_t waittime;
 	waittime.tv_sec = time_ms / 1000;
 	waittime.tv_nsec = 100 * (time_ms % 1000);
@@ -106,14 +106,14 @@
 		return false;
 	}
 
-#ifndef __MACH__
+#if !(defined(__MACH__)  defined(__APPLE__))
 	waittime.tv_nsec = ((time_ms % 1000) * 1000 * 1000) + (now.tv_usec * 1000);
 	waittime.tv_sec  = (time_ms / 1000) + (waittime.tv_nsec / (1000*1000*1000)) + now.tv_sec;
 	waittime.tv_nsec %= 1000*1000*1000;
 #endif
 
 	errno = 0;
-#ifdef __MACH__
+#if defined(__MACH__)  defined(__APPLE__)
 	int sem_wait_retval = semaphore_timedwait(m_semaphore, waittime);
 #else
 	int sem_wait_retval = sem_timedwait(m_semaphore, waittime);
@@ -121,7 +121,7 @@
 
 	if (sem_wait_retval == 0)
 	{
-#ifdef __MACH__
+#if defined(__MACH__)  defined(__APPLE__)
 		pthread_mutex_lock(semcount_mutex);
 		semcount--;
 		pthread_mutex_unlock(semcount_mutex);
@@ -137,7 +137,7 @@
 
 int JSemaphore::GetValue() {
 	int retval = 0;
-#ifdef __MACH__
+#if defined(__MACH__)  defined(__APPLE__)
 	pthread_mutex_lock(semcount_mutex);
 	retval = semcount;
 	pthread_mutex_unlock(semcount_mutex);
--- a/src/porting.h	2014-07-07 00:06:06.0 +0200
+++ b/src/porting.h	2014-10-08 08:59:43.0 +0200
@@ -59,7 +59,7 @@
 	#include unistd.h
 	#include stdint.h //for uintptr_t
 
-	#if (defined(linux) || defined(__linux))  !defined(_GNU_SOURCE)
+#if (defined(linux) || defined(__linux) || defined(__GNU__))  !defined(_GNU_SOURCE)
 		#define _GNU_SOURCE
 	#endif
 
@@ -227,7 +227,7 @@
 #else // Posix

Bug#742487: Update of python-ldap to upstream version 2.4.15

2014-10-09 Thread Michael Ströder

Philipp Hahn wrote:
 retitle 742487 Update of python-ldap to upstream version 2.4.16
 tag 742487 patch

Please note that 2.4.18 was released and should be considered for package 
update:

http://pypi.python.org/pypi/python-ldap/2.4.18

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#764310: manpages-dev and libcerf-doc: error when trying to install together

2014-10-09 Thread Joachim Wuttke


As upstream maintainer of libcerf, I would like to express
a clear preference for solving the conflict by withdrawing
cerf.3 and cerfc.3 from manpages-dev.

I already proposed this solution to upstream,
  https://bugzilla.kernel.org/show_bug.cgi?id=80541
where it has been received favorably, but not yet
definitively accepted. It might be helpful if somebody
expressed in the name of Debian that the matter is
somewhat urgent.

I am opposed to the alternative solution of libcerf renaming
the functions cerf and cerfc. Any other names would be less
pertinent. There is no conflict with glibc. On the contrary,
libcerf complements glibc in providing a missing implementation.
Should glibc one day provide an official implementation, then
the two functions will be immediately withdrawn from libcerf.

- Joachim



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#758788: [pkg-cryptsetup-devel] Bug#758788: Bug#758788: Bug#758788: Bug#758788: cryptsetup: Passphrase caching broken in decrypt_keyctl

2014-10-09 Thread Jonas Meurer

Hey Luc,

Am 09.10.2014 um 09:54 schrieb luc:
 Am 03.10.2014 um 21:55 schrieb Jonas Meurer:
 Did you find time to do the additional testing/debugging yet? I'd like
 to fix this bug in time for Debian Jessie, provided that it's really a
 bug in the package and not an issue on your side ;)
 
 Not yet, but I intend to do so.
 The problem occurs on a computer with some critical information on it,
 and the partitions already use the full disk space. This implies I have
 to do
 some careful work of shrinking filesystems, logical volumes and so on
 before I can
 set up a test partition aside.

I see. But you don't need to resize your filesystems or go through
similar hassle. Simply use file containers for testing. The following
commands should setup a testing environment (use carefully, even though
I tested them):

# dd if=/dev/urandom of=/cont1 bs=1M count=3
# dd if=/dev/urandom of=/cont2 bs=1M count=3
# echo testpw | cryptsetup luksFormat /cont1
# echo testpw | cryptsetup luksFormat /cont2
# echo cont1_crypt /cont1 pw1 luks,keyscript=decrypt_keyctl \
 /etc/crypttab
# echo cont2_crypt /cont1 pw1 luks,keyscript=decrypt_keyctl \
 /etc/crypttab
# cryptdisks_start cont1_crypt
# cryptdisks_start cont2_crypt

 As already mentioned - up to now I'm unable to reproduce the bug. For
 me, decrypt_keyctl works in all tested setups. The provided passphrase
 is stored in kernel keyring with first invokation and used for all the
 following device unlockings that have the same keyscript/keyname
 configured.
 
 I understand your point. It is difficult to debug here (as mentioned
 earlier putting
 some echo commands completely trashed the boot sequence). I'll do my best.

I'm sorry that I brought you in troubles here. The echo command was
untested and I at least should have written that. It was meant for
debugging purposes only but it completely broke the keyscript. I'll try
to not make such premature requests again :-/

Cheers,
 jonas

 I test the decrypt_keyctl script with the following setup, and it works
 as expected. Maybe you could try a similar setup:

 - create two small lvm logical volumes (5MB are more than enough)
 - luksformat both logical volumes
 - add them to your crypttab:

 clv1_crypt /dev/VG/LV1 testkey1 luks,keyscript=decrypt_keyctl
 clv2_crypt /dev/VG/LV2 testkey1 luks,keyscript=decrypt_keyctl

 - try unlocking them via cryptdisks_start:

 # cryptdisks_start clv1_crypt
 # cryptdisks_start clv2_crypt

 The second unlocking should use the key cached during first unlocking.

 It would be awesome if you could test this. I as well tested this setup
 during boot process, and it works as expected as well. Also tested with
 UUID instead of source device path in crypttab, same result.

 I've no glue what's different on your setups, and any help with
 debugging would be highly appreciated.

 In case that you still encounter the bug, please paste your full
 /etc/fstab and /etc/crypttab again.

 /etc/crypttab:

 sdb1_crypt UUID=9aa983b5-0224-406b-a177-7481162c6172
 sda5_sdb1_common_key luks,keyscript=decrypt_keyctl
 sda5_crypt UUID=3764df68-de26-4a24-a7dc-1498cb6b20ab
 sda5_sdb1_common_key luks,keyscript=decrypt_keyctl

 Nothing suspicious here, looks ok to me.

 Note that the two partitions contain physical volumes for LVM, as shown
 here:

 Actually the content of your encrypted devices should not matter at all.

 Kind regards,
  jonas

 ___
 pkg-cryptsetup-devel mailing list
 pkg-cryptsetup-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cryptsetup-devel


 
 ___
 pkg-cryptsetup-devel mailing list
 pkg-cryptsetup-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cryptsetup-devel


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

Bug#764569: systemd fails to reboot with nvidia on macpro

2014-10-09 Thread Michael Biebl

Control: tags -1 moreinfo

Am 09.10.2014 um 07:51 schrieb Norbert Preining:
 Package: systemd
 Version: 215-5+b1
 Severity: grave
 Justification: causes non-serious data loss
 
 Hi,
 
 since the switch to systemd my Mac Pro does not reboot anymore
 when I am rebooting from X with nvidia driver.
 
 What happens is that:
 - all connections are capped, I tried it via ssh, but couldn't
   see any logs
 - screen goes blank
 - there is rythmic HD activity forever
 
 hard reset necessary.
 
 It seems that systemd is trying to do whatever it tries to do,
 without success and without giving up, blocking reboot and
 any interaction.
 
 Nothing in the logs, absolutely nothing.
 

- Unit samba.service:
Description: LSB: ensure Samba daemons are started (nmbd and smbd)
Instance: n/a
Unit Load State: loaded
Unit Active State: active

Might be a duplicate of [1]

Can you run
update-rc.d samba remove
systemctl stop samba.service

and try again.


If that doesn't help, follow the debugging hints at [2].
A first step would be, to enable persistent logging, and increase the
verbosity via systemd.log_level=debug and/or enabling the
debug-shell.service .


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740942
[2] http://freedesktop.org/wiki/Software/systemd/Debugging/
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#681501: Debian France on Debian's new donations page?

2014-10-09 Thread Brian Gupta

On Thu, Oct 9, 2014 at 3:31 AM, Raphael Hertzog hert...@debian.org wrote:
Hi,

On Tue, 07 Oct 2014, Paul Wise wrote:
Since Debian France is a Trusted Organisation and has methods of
donating to Debian, we should probably add it to Debian's rewritten
donations page. We need some information before we can add it:

A paragraph introducing Debian France to potential donors.

Available donation methods (looks like PayPal at this point?).

Paypal is offered, but we can accept wire transfers too (SEPA credit),
we have published the IBAN/BIC here currently:
https://france.debian.net/soutenir/

Details of how to donate (for PayPal some HTML would be best).

The correct link is this one:
https://france.debian.net/galette/plugins/galette-plugin-paypal/paypal_form.php?pref_lang=en_US

It's best to use the form on this page because it will record everything
in the accounting books automatically.

Not a rush, but can we work to setup a separate API key for donations
to Debian? We're trying to close the bug that people had to go to a
Trusted Organization website, and also make another decision.

See riseup.net donation page for example:
https://help.riseup.net/en/donate#paypal

(Paul please correct me, if this isn't what you had in mind.)

If anyone reading this mail has the details already and can commit to
the website CVS repository, please add Debian France there.

ENOTIME sorry

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

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

Bug#764212: [wine-development] Error in bash script, fi needed at line 28

2014-10-09 Thread Konstantin Demin

Please review attached patch.

-- 
SY,
Konstantin Demin
description: debian/scripts/wine: support relative WINEPREFIX, remove '-e' from 
hashbang, formatting
author: Konstantin Demin rockdri...@gmail.com

diff --git a/debian/scripts/wine b/debian/scripts/wine
index 0850dff..6950525 100755
--- a/debian/scripts/wine
+++ b/debian/scripts/wine
@@ -1,44 +1,63 @@
-#!/bin/sh -e
-
-name=$(basename $0)
-bindir=/usr/lib/$name
-
-wine32=$bindir/wine
-wine64=$bindir/wine64
-
-if test -x $wine32 -a $WINEARCH != win64; then
-wine=$wine32
-elif test -x $wine64; then
-wine=$wine64
-if [ $(dpkg --print-architecture) = amd64 -a $(dpkg 
--print-foreign-architectures) != i386 ]; then
-echo it looks like multiarch needs to be enabled.  as root, please
-echo execute \dpkg --add-architecture i386  apt-get update 
-echo apt-get install $(echo $name | sed s/wine/wine32/)\
-fi
+#!/bin/sh
+name=$(basename $0)
+bindir=/usr/lib/${name}
+
+wine32=${bindir}/wine
+wine64=${bindir}/wine64
+
+if [ -x ${wine32} -a ${WINEARCH} != win64 ]; then
+   wine=${wine32}
+elif [ -x ${wine64} ]; then
+   wine=${wine64}
+   dpkg_native=$(dpkg --print-architecture)
+   dpkg_foreign=$(dpkg --print-foreign-architectures)
+
+   if [ ${dpkg_native} = amd64 -a ${dpkg_foreign} != i386 ]; then
+   cat 12 -EOF
+   it looks like multiarch needs to be enabled.
+   as root, please execute:
+   »   dpkg --add-architecture i386
+   »   apt-get update
+   »   apt-get install $(echo ${name} | sed -e 
's/wine/wine32/')
+   EOF
+   fi
 else
-echo error: unable to find wine executable.  this shouldn't happen.
-exit 1
+   cat 12 -EOF
+   error: unable to find wine executable. this shouldn't happen.
+   EOF
+   exit 1
 fi
 
-if test -z $WINEPREFIX; then
-if $wine = $wine64; then
-wineprefix=$HOME/.wine64
-else
-wineprefix=$HOME/.wine
-else
-wineprefix=$WINEPREFIX
+if [ -z ${WINELOADER} ];
+then wineloader=${wine}
+else wineloader=${WINELOADER}
 fi
 
-if test -z $WINELOADER; then
-wineloader=$wine
-else
-wineloader=$WINELOADER
+if [ -z ${WINEDEBUG} ];
+then winedebug=-all
+else winedebug=${WINEDEBUG}
 fi
 
-if test -z $WINEDEBUG; then
-winedebug=-all
+if [ -z ${WINEPREFIX} ]; then
+   if [ ${wine} = ${wine64} ];
+   then wineprefix=${HOME}/.wine64
+   else wineprefix=${HOME}/.wine
+   fi
 else
-winedebug=$WINEDEBUG
+   wineprefix=${WINEPREFIX}
+fi
+
+wineprefix_normal=$(readlink -f ${wineprefix})
+if [ -z ${wineprefix_normal} ]; then
+   cat 12 -EOF
+   wine prefix not found and/or cannot be created.
+   check path again:
+   »   ${wineprefix}
+   EOF
+   exit 1
 fi
 
-WINEPREFIX=$wineprefix WINELOADER=$wineloader WINEDEBUG=$winedebug $wine $@
+export WINEPREFIX=${wineprefix_normal}
+export WINELOADER=${wineloader}
+export WINEDEBUG=${winedebug}
+exec ${wine} $@

Bug#764547: bsdutils: script(1) is broken, hangs or crashes

2014-10-09 Thread Thorsten Glaser

Andreas Henriksson dixit:

Since you seem to have a way to reproduce the problem, could you please
also git bisect it?

Not this week ☹ also, never worked with that before, I’d have to
learn it first. Unless it can be automated? If the result of script
contains “Total passed”, it worked, otherwise not.

bye,
//mirabilos
-- 
21:49⎜allamoox:#sendmail I have a question guys,
 ⎜Can I use my PC as SMTP server, I use Windows 7 .
 ⎜Already googled and Installed IIS
 ⎜but Still I can't send E-mail


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

Bug#661849: Please add a symlink /usr/lib/xen - /usr/lib/xen-default

Hi,

(following-up on https://bugs.debian.org/661849)

Guido Günther wrote (13 Apr 2012 19:24:28 GMT) :
 Package: xen
 Version: 4.1.2-3
 Severity: wishlist

 we're patching libvirt (incompletely atm) and also virtinst to cope with
 Debian's derivation from upstream to put things into
 /usr/lib/xen-version managed via alternatives to /usr/lib/xen-default.

 While the basic idea is great to be able to switch between different xen
 versions it would us get closer to upstream if we had a symlink

   /usr/lib/xen - /usr/lib/xen-default

 Can such a link be added? This would (among other things) resolve
 #661849. The alternative would be to patch the 164 test cases.
 Cheers,

FTR, that other bug reported against xen
(https://bugs.debian.org/668641) was marked as fixed in 4.3.0-1, which
is currently in Debian testing/sid. I've not looked at it close
enough, but it might be that this either invalidates this bug, or
makes the patch obsolete. In case someone who's more into Xen than
I am wants to have a look :)

Cheers!


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

Bug#763237: ld problem tracked in #764573

2014-10-09 Thread Michael Tautschnig

Hi,

This is just to let you know that this problem is now being tracked as #764573.

Best,
Michael



pgpcqDlOTBJm1.pgp
Description: PGP signature

Bug#707841: [Pkg-nagios-devel] Help needed with check_mk?

2014-10-09 Thread Bernhard Schmidt

Hi,

 with the freeze approaching, is there anything I can do to get check-mk
 back into Jessie (at least the agent part, see #707841)?
 Thomas are you still alive? Do you plan to upgrade check-mk soon?
 
 I'm still alive but have currently absolute no time to work on check-mk :(

Sorry I missed that reply :-(

I could wrap up a package for the current check-mk-agent fixing a few
minor bugs and updating to the latest version until tomorrow. I don't
feel confident at all packaging the server part, because upstream
support for that is rather bad and I honestly don't know anyone who is
not using check_mk inside OMD.

So I see three options:
a) check_mk and check_mk_agent are not released in Jessie

b) check_mk_agent is split into a seperate source package and migrates
to Jessie in time, the server parts are not released in Jessie

c) someone else updates both server and agent in time for Jessie

I can help with b), but I need a bit of help. First of all I'm not a DD,
just a DM. So I need a sponsor for uploading. Also I have no idea how to
take over a binary package in a new source package. I could not find a
lot of documentation about that. I guess one needs to rebuild the old
source package first, dropping the binary packages for the agent?

Best Regards,
Bernhard


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

Bug#762708: nginx-common: Patch for configurable stop schedule and new graceful-stop command in init script

2014-10-09 Thread Christos Trochalakis


On Wed, Oct 08, 2014 at 06:16:16AM -0700, Tyler Riddle wrote:

I think that gracefully stopping nginx is a better default the forcibly
stopping the process.


I certainly don't - both cases have uses. Please do not force sysadmins
to wait for end user behavior *by default*. When I want end users to be
able to influence my reboot time I'll specify a specific command. The
default should not be to extend reboot time defined by the activity of
people external to the system and this is what you have done by
converting to graceful shutdown by default.



I don't think that reboot times are an issue for a web server (at least
by default). And, for me, it seems that not killing active request, and
giving nginx a few seconds to handle things gracefully is a better
default behavior. We can switch to 5s if 10secs seems like a lot of time
(it might be).

Those 5 or 10 seconds are a capped, well defined, period. External
users can't extend your stop time beyond that time, so this is not a
threat to the system.

This strategy has been made configurable in a /etc/default/ setting, so
it can be easily tweaked to match anyone's needs.


You've reduced the functionality of this patch and decreased the
utility of init. Why are you attempting to optimize for reduced command
count?


Why we should introduce a new command when you can simply run
`nginx -s stop` or `nginx -s quit`?

Also, jessie ships with systemd by default, and systemd doesn't support
custom commands. So, it's not a good plan to divert the initscript from
the service file.

The correct thing to do, for both systemd and sysvinit users, is to keep
the initscript plain simple, and introduce something like a nginxctl
script that handles things like upgrading the nginx executable, and
other complex things that an administrator might need.


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

Bug#707841: [Pkg-nagios-devel] Help needed with check_mk?

2014-10-09 Thread Alexander Wirt

On Thu, 09 Oct 2014, Bernhard Schmidt wrote:

 Hi,
 
  with the freeze approaching, is there anything I can do to get check-mk
  back into Jessie (at least the agent part, see #707841)?
  Thomas are you still alive? Do you plan to upgrade check-mk soon?
  
  I'm still alive but have currently absolute no time to work on check-mk :(
 
 Sorry I missed that reply :-(
 
 I could wrap up a package for the current check-mk-agent fixing a few
 minor bugs and updating to the latest version until tomorrow. I don't
 feel confident at all packaging the server part, because upstream
 support for that is rather bad and I honestly don't know anyone who is
 not using check_mk inside OMD.
 
 So I see three options:
 a) check_mk and check_mk_agent are not released in Jessie
 
 b) check_mk_agent is split into a seperate source package and migrates
 to Jessie in time, the server parts are not released in Jessie
 
 c) someone else updates both server and agent in time for Jessie
 
 I can help with b), but I need a bit of help. First of all I'm not a DD,
 just a DM. So I need a sponsor for uploading. Also I have no idea how to
 take over a binary package in a new source package. I could not find a
 lot of documentation about that. I guess one needs to rebuild the old
 source package first, dropping the binary packages for the agent?
I am more and more in favour of just removing them from debian. 

Alex


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

Bug#724344: ITP: bdsync -- bdsync is a fast block device synchronizing tool

2014-10-09 Thread Dmitry Smirnov

On Tue, 24 Sep 2013 00:01:54 maxigas wrote:
  bdsync was built to do the only thing rsync isn't able to do: syn‐
  chronize block devices.

Actually rsync can be taught to synchronise block devises by applying 
upstream patch copy-devices.diff which introduces --copy-devices option. 

Perhaps instead of packaging bdsync it might be better to convince rsync 
maintainer to enable this option, see #509335.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B


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

Bug#764567: ITP: obs-build -- Build DEB/RPM packages for various distributions inside a chroot

On 9 October 2014 08:43, Mike Gabriel mike.gabr...@das-netzwerkteam.de wrote:
Hi Dimitri,

On Do 09 Okt 2014 08:45:17 CEST, Dimitri John Ledkov wrote:

Hey,

On 9 October 2014 05:21, Mike Gabriel mike.gabr...@das-netzwerkteam.de
wrote:

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de

* Package name: obs-build
Version : Git snapshot (every commit is a release)
Upstream Author : Michael Schroeder (https://github.com/mlschroe)
* URL : https://github.com/openSUSE/obs-build
* License : GPL
Programming Lang: Perl
Description : Build DEB/RPM packages for various distributions
inside a chroot

OBS Build creates chroots and builds DEB/RPM packages for various
Linux distributions. In Debian, this package fills a gap: it allows one
to
build packages for the openSUSE/SLES distributions on Debian system.
.
Its only task is to reliably populate a chroot and attempt to build
a package in that chroot. It is used by the Open Build System provided
by SUSE, but can also be use as a standalone tool.
.
Optionally, builds can take place in KVM or XEN instance.

I think we had a mid-air collision:
https://ftp-master.debian.org/new/obs-build_20140918-1.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762949

I'm happy to co-maintain this package.

Yeah. I saw Adams mail early this morning.

I have the package nearly ready... Do you have anything packaged, yet? Or
shall I just add you to Uploaders: (with what mail address)?

I plan to push the packaging Git to collab-maint (or have you already
provided a packaging repo there?)

It's in the new queue.

I use a combination of git-dpm dgit. Which although useful, has
quilt noise committed as patches. (Maybe I should use stand-alone
branch for dgit/quilt noise).

You should be able to fetch it with:
$ dgit clone obs-build

Or I've now pushed a normal git master branch thus it's
visiable/clonable with git itself as well:
http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/

In terms of patches, I have:
Use obs-build namespace, similar to your patch.
http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/tree/debian/patches/0001-Use-obs-build-in-locations-and-executable-names-inst.patch

I fixed submitted upstream a bug with createzypp repository script.
http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/tree/debian/patches/0002-Fix-Build-Zypp-parsecfg-expected-full-config-file-na.patch

I do not move project configurations to /etc, as I don't think that's
right. Released distribution configurations should be frozen, to have
reproducible builds locally.
Custom/non-upstream distro configs should either be patched/applied in
the Debian package, packaged separately and install into same config
location, or passed to obs-build via command-line option.
We really don't want people to modify build configuration files for
volatile distribution (e.g. Factory, Rawhide, Sid, etc) and then never
get upgraded when those change, due to how config-files are handled.

Maybe it makes sense to patch obs to support multiple locations? E.g.
/etc/obs-build/configs and /usr/lib/obs-build/configs?
--
Regards,

Dimitri.

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

Bug#745969: guile-1.8: FTBFS: conflicting types for 'yyget_leng'

2014-10-09 Thread Edmund Grimley Evans

In case anyone still wants to build guile-1.8, a fix (remove
declarations of 'yy*' functions in c-tokenize.lex) is described here:

http://lists.gnu.org/archive/html/guile-devel/2010-03/msg00081.html

It seems to work on arm64.


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

Bug#764580: m4 eats memory for breakfast

Package: m4
Version: 1.4.17-4
Severity: normal

Dear Maintainer,

While trying to investigate a reported issue in util-linux
I was going to attempt a git bisect but I wasn't even able
to build the old version.

git clone git://git.debian.org/git/collab-maint/pkg-util-linux.git util-linux
cd util-linux
git checkout v2.20.1
./autogen.sh
   autopoint:  /usr/bin/autopoint (GNU gettext-tools) 0.19.2
   aclocal:aclocal (GNU automake) 1.14.1
   autoconf:   autoconf (GNU Autoconf) 2.69
   autoheader: autoheader (GNU Autoconf) 2.69
   automake:   automake (GNU automake) 1.14.1
   libtoolize: libtoolize (GNU libtool) 2.4.2
^C

Before aborting, m4 was observed to have allocated 38g ram (and
counting)


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

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

Versions of packages m4 depends on:
ii  libc62.19-11
ii  libsigsegv2  2.10-4

m4 recommends no packages.

m4 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#764581: RM: webkitgtk [sparc] -- ROM; webkitgtk 2.2.5 contains non-DFSG files

2014-10-09 Thread Alberto Garcia

Package: ftp.debian.org
Severity: serious

webkitgtk 2.2.5 contains some files that are not redistributable so
all its packages should be removed from the archive.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763613 for
details.

All other architectures have already upgraded to a version of
webkitgtk that does not have this problem. sparc however does not have
all the necessary build dependencies.

Berto


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

Bug#758956: quisk still depends on python-wxgtk2.8

2014-10-09 Thread Olly Betts

Control: reopen -1
Control: found -1 3.6.18-1

On Tue, Sep 23, 2014 at 03:51:11AM +, Debian Bug Tracking System wrote:
 We believe that the bug you reported is fixed in the latest version of
 quisk, which is due to be installed in the Debian FTP archive.

Unfortunately not - the BD was updated from python-wxgtk2.8 to
python-wxgtk3.0, but the run-time dependency is still on
python-wxgtk2.8:

$ apt-cache showsrc quisk|grep wx
Build-Depends: debhelper (= 9.0.0~), python, portaudio19-dev, libpulse-dev, 
libusb-dev, libfftw3-dev, python-all-dev, libasound2-dev, python-wxgtk3.0, 
hardening-wrapper
$ apt-cache show quisk|grep wx
Depends: python (= 2.7), python ( 2.8), libasound2 (= 1.0.16), libc6 (= 
2.15), libfftw3-double3, libportaudio2 (= 19+svn20101113), libpulse0 (= 
0.99.1), libusb-0.1-4 (= 2:0.1.12), python-wxgtk2.8

Cheers,
Olly


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

Bug#764275: Additional Info (chromium: Segfaults on Startup)

2014-10-09 Thread Stephen Allen

Okay some further information regarding this bug. I was able to get
chromium to startup without segfaulting by deleting
'~/home/.config/chromium' directory.

Now the issue is that the necessary Google API to log Chromium into the
browser sync network, as it throws 'Service Unavailable Try Again
Later'.

HTH


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

Bug#764547: bsdutils: script(1) is broken, hangs or crashes

On Thu, Oct 09, 2014 at 08:38:09AM +, Thorsten Glaser wrote:
 Andreas Henriksson dixit:
 
 Since you seem to have a way to reproduce the problem, could you please
 also git bisect it?
 
 Not this week ☹ also, never worked with that before, I’d have to
 learn it first. Unless it can be automated? If the result of script
 contains “Total passed”, it worked, otherwise not.

git bisect is a way to automate manual tasks, so I'm not sure how
to make it more automated (or what you question really is).

See 'man git bisect' or http://git-scm.com/docs/git-bisect

basically:

git bisect start v2.25.1 v2.20.1 -- term-utils/script.c

./autogen.sh  ./configure  make

reproduce using ./script (instead of /usr/bin/script)

git bisect bad|good

rinse and repeat step 2+3 until git tells you the bad commit

Regards,
Andreas Henriksson

PS. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764580


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

Bug#681501: Debian France on Debian's new donations page?

2014-10-09 Thread Raphael Hertzog

On Thu, 09 Oct 2014, Brian Gupta wrote:
  The correct link is this one:
  https://france.debian.net/galette/plugins/galette-plugin-paypal/paypal_form.php?pref_lang=en_US
 
  It's best to use the form on this page because it will record everything
  in the accounting books automatically.
 
 Not a rush, but can we work to setup a separate API key for donations
 to Debian?  We're trying to close the bug that people had to go to a
 Trusted Organization website, and also make another decision.

You can take the form on our webpage and hardcode the field used to select
the target organization and put that form on debian.org directly. I guess
this should work.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


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

Bug#764567: ITP: obs-build -- Build DEB/RPM packages for various distributions inside a chroot

Hi Dimitri,

On Do 09 Okt 2014 11:18:30 CEST, Dimitri John Ledkov wrote:

On 9 October 2014 08:43, Mike Gabriel
mike.gabr...@das-netzwerkteam.de wrote:

Hi Dimitri,

On Do 09 Okt 2014 08:45:17 CEST, Dimitri John Ledkov wrote:

Hey,

On 9 October 2014 05:21, Mike Gabriel mike.gabr...@das-netzwerkteam.de
wrote:

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de

I think we had a mid-air collision:
https://ftp-master.debian.org/new/obs-build_20140918-1.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762949

I'm happy to co-maintain this package.

Yeah. I saw Adams mail early this morning.

I have the package nearly ready... Do you have anything packaged, yet? Or
shall I just add you to Uploaders: (with what mail address)?

I plan to push the packaging Git to collab-maint (or have you already
provided a packaging repo there?)

It's in the new queue.

Ah... ok... (damn that I did not notice...).

I use a combination of git-dpm dgit. Which although useful, has
quilt noise committed as patches. (Maybe I should use stand-alone
branch for dgit/quilt noise).

You should be able to fetch it with:
$ dgit clone obs-build

Or I've now pushed a normal git master branch thus it's
visiable/clonable with git itself as well:
http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/

Ok. Thanks. Just did some reading of the debian/ folder.

I also pushed my latest changes to collab-maint/obs-build.git so you
can introspect them.

I do not move project configurations to /etc, as I don't think that's
right. Released distribution configurations should be frozen, to have
reproducible builds locally.

Ok. That sounds reasonable.

Custom/non-upstream distro configs should either be patched/applied in
the Debian package, packaged separately and install into same config
location, or passed to obs-build via command-line option.
We really don't want people to modify build configuration files for
volatile distribution (e.g. Factory, Rawhide, Sid, etc) and then never
get upgraded when those change, due to how config-files are handled.

Ok. Agreeing on that.

Maybe it makes sense to patch obs to support multiple locations? E.g.
/etc/obs-build/configs and /usr/lib/obs-build/configs?

That surely is an option.

What concerns me most about your upload is the version number.

I understand that there are tags on the openSUSE/obs-build.git. I used
them as well till yesterday. However, I had an intensive chat with one
of the upstream authors (Michael Schroeder, from SUSE) yesterday.
Unfortunately in German, so copy+pasting makes no sense here.

About the tags on the Git he said: those tags are actually obs-server
tags (not obs-build). The obs-server devs tagged obs-build with
obs-server versions, so that they know what obs-build version / Git
commit hash was used with what obs-server version.

About obs-build, he said: every commit is a release. So basically, we
should use the version date. With upstream I came to the conclustion
that the best version number would be
0~gitdate.build-on-that-day.commit-hash-debrevision.

So, the question is, if you are open do re-upload obs-build. If so, we
should merge our packaging efforts (I think) and get several other
things going (e.g. the initvm.c tool, tests, etc.).

Also, I could not really find that all files are licensed GPL-2+. I
just asked upstream to do that today [1].

Actually, some files [2] are licensed as GPL-3+, so your copyright
file is not up-to-date anymore for a latest Git snapshot (which is
irrelevant for code older than today's snapshot, of course).

Mike

[1]

Bug#748120: [Pkg-libvirt-maintainers] Bug#748120: Improper device checking with virt-clone on LVM

Hi,

Guido Günther wrote (14 May 2014 15:57:27 GMT) :
 On Wed, May 14, 2014 at 03:52:47PM +0200, Kwadronaut-debian wrote:
 For both me and #706196 this is sort of fixed upstream when it are local
 storage pools:
 https://git.fedorahosted.org/cgit/virt-manager.git/tree/virtinst/CloneManager.py?id=v0.10.0
 Virt-inst is now merged in virt-manager. With attached patch (which
 comes from upstream) I'm happy.

Can you please confirm that the problem is gone with the package
(based on upstream 1.0.1) that's currently in testing/sid?

 I don't know if this patch should get
 into backports or the other 2 bugs can be closed because of this and/or
 upstream changes, an explanation of bug-flow would be welcome.

 Backports would mean backporting the whole virt-manager 1.0 so we can
 only onsider a update via a point update. This would mean we need to
 fix it in unstable first which we should do by bringing virt-manager
 1.0 into sid (currently only in experimental). I try to find the time
 to finally package 1.0 (instead of a git snapshot).

That's now been done, not sure what's the next thing to do here.

Cheers,
--
intrigeri


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

Bug#724344: ITP: bdsync -- bdsync is a fast block device synchronizing tool

Hi maxigas,

did you really intend to file this bug as an ITP (intent to package),
or instead as a RFP (request for package)?

Cheers,
--
intrigeri


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

Bug#764268: Processed: jessie

2014-10-09 Thread Holger Levsen

Hi Ludovic,

On Donnerstag, 9. Oktober 2014, Ludovic Brenta wrote:
 Holger, please stop tagging jessie packages that are not in testing.

I wasn't aware that I'm doing this, thanks for notifying!

 Additionally, the version of libaws referenced in #764268 is neither
 in jessie nor in sid.  This is explained in the bug.  Please do not
 ignore these explanations anymore.

ok
 
 This is the third time I've had to correct your mistake by hand and
 I'm getting tired of this.

How about you'd tell me immediatly?

I'm also quite tired of tagging 1-3 bugs so that they don't show up in the 
list of release critical bugs affecting stable, which is what people see, when 
they use apt-listchanges (so they dont get scary warnings about broken 
packages which dont affect them) or people wanting to fix RC bugs in stable 
also have a better overview, whats releveant. Thats why I do this, and a.) I 
could use help with that and b.) people could tag+file bugs correctly in the 
first place (that only applies to constant submitters who I understand are 
busy+overworked them selves.)

According to my tool, 410 RC bugs affecting wheezy known to the BTS, 896 
known to us. - IOW: I've look at 896 RC bugs affecting wheezy since its 
release. And probably 300-400 I've assigned away not to clutter the views.

I'm sorry I make mistakes when doing so and have thus annoyed you... but I 
hope you understand better now, why I do this. Mistakes happen.

Any idea what to do with 764268 then? Downgrade? Close?


cheers,
Holger




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

Bug#757348: systemd: with SysV init, can no longer suspend and shutdown from lightdm

2014-10-09 Thread Ritesh Raj Sarraf

Package: systemd-shim
Version: 8-2
Followup-For: Bug #757348

Hi, I'm hit by this bug and am not sure what the tag fixed-upstream
here is referring to ?

This issue is very well present and does not seem to have a fix yet.

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

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

Versions of packages systemd-shim depends on:
ii  cgmanager 0.32-4
ii  libc6 2.19-11
ii  libglib2.0-0  2.42.0-2

systemd-shim recommends no packages.

Versions of packages systemd-shim suggests:
pn  pm-utils  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#764567: ITP: obs-build -- Build DEB/RPM packages for various distributions inside a chroot

On 9 October 2014 10:42, Mike Gabriel mike.gabr...@das-netzwerkteam.de wrote:
Hi Dimitri,

On Do 09 Okt 2014 11:18:30 CEST, Dimitri John Ledkov wrote:

On 9 October 2014 08:43, Mike Gabriel mike.gabr...@das-netzwerkteam.de
wrote:

Hi Dimitri,

On Do 09 Okt 2014 08:45:17 CEST, Dimitri John Ledkov wrote:

Hey,

On 9 October 2014 05:21, Mike Gabriel mike.gabr...@das-netzwerkteam.de
wrote:

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de

OBS Build creates chroots and builds DEB/RPM packages for various
Linux distributions. In Debian, this package fills a gap: it allows
one
to
build packages for the openSUSE/SLES distributions on Debian system.
.
Its only task is to reliably populate a chroot and attempt to build
a package in that chroot. It is used by the Open Build System provided
by SUSE, but can also be use as a standalone tool.
.
Optionally, builds can take place in KVM or XEN instance.

I think we had a mid-air collision:
https://ftp-master.debian.org/new/obs-build_20140918-1.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762949

I'm happy to co-maintain this package.

Yeah. I saw Adams mail early this morning.

I have the package nearly ready... Do you have anything packaged, yet? Or
shall I just add you to Uploaders: (with what mail address)?

I plan to push the packaging Git to collab-maint (or have you already
provided a packaging repo there?)

It's in the new queue.

Ah... ok... (damn that I did not notice...).

I use a combination of git-dpm dgit. Which although useful, has
quilt noise committed as patches. (Maybe I should use stand-alone
branch for dgit/quilt noise).

You should be able to fetch it with:
$ dgit clone obs-build

Or I've now pushed a normal git master branch thus it's
visiable/clonable with git itself as well:
http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/

Ok. Thanks. Just did some reading of the debian/ folder.

I also pushed my latest changes to collab-maint/obs-build.git so you can
introspect them.

In terms of patches, I have:
Use obs-build namespace, similar to your patch.

http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/tree/debian/patches/0001-Use-obs-build-in-locations-and-executable-names-inst.patch

I fixed submitted upstream a bug with createzypp repository script.

http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/tree/debian/patches/0002-Fix-Build-Zypp-parsecfg-expected-full-config-file-na.patch

I do not move project configurations to /etc, as I don't think that's
right. Released distribution configurations should be frozen, to have
reproducible builds locally.

Ok. That sounds reasonable.

Ok. Agreeing on that.

Maybe it makes sense to patch obs to support multiple locations? E.g.
/etc/obs-build/configs and /usr/lib/obs-build/configs?

That surely is an option.

What concerns me most about your upload is the version number.

Yeah, I am aware of the crazy version numbering. So I based my version
numbers, on the version numbers that are published and used by
openSUSE itself in the openSUSE:Tools repository.
Which is where they package up daily git snapshot when a release happens.
https://build.opensuse.org/package/show/openSUSE:Tools/build

So At the moment, I have exact same version as the upstream releases
are in the openSUSE:Tools repository. Why should version numbers
diverge from what's used in openSUSE and upstream?

Ich kann nur ein bistchen Deutsch sprechen I did request tags for
matching builds to be pushed into the repository, but it doesn't look
like github issues are being monitored:
https://github.com/openSUSE/obs-build/issues/133

I understand that there are tags on the openSUSE/obs-build.git. I used them
as well till yesterday. However, I had an intensive chat with one of the
upstream authors (Michael Schroeder, from SUSE) yesterday. Unfortunately in
German, so copy+pasting makes no sense here.

About the tags on the Git he said: those tags are actually obs-server tags
(not obs-build). The obs-server devs tagged obs-build with obs-server
versions, so that they know what obs-build version / Git commit hash was

Bug#758121: [Pkg-crosswire-devel] Bug#758121: bibletime: Bibletime is unusable in testing and unstable

On 8 October 2014 15:54,  da...@sandersweb.net wrote:
 retitle 758121 bibletime: New upstream release fixes display problem in jessie
 severity 758121 grave
 thanks

 On Monday, October 06, 2014 10:26:56 PM you wrote:
 Bibletime is unusable in jessie and sid.  When you open any Bible or
 commentary all you see is jibberish.  This needs to be fixed prior to
 the release of jessie.

 I just built the new upstream release (2.10.1) from source.  It does not have
 this problem.  Please update the bibletime package in jessie to the latest
 upstream release available on sourceforge.


Debdiff would be appreciated. I don't use, nor typically updated bibletime.

-- 
Regards,

Dimitri.


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

Bug#465498: Still reproducible with a recent version ?

Hi,

Laurent Léonard wrote (19 Mar 2010 13:13:25 GMT) :
 Is this issue still reproducible with a recent version of
 Virt-manager ?

This bug has been opened, with more information asked, since more than
4 years. Can anyone still reproduce it, or may I close it?

Cheers,
--
intrigeri


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

Bug#486811: Still reproducible with a recent version ?

Control: tags -1 - fixed-upstream

Hi,

Laurent Léonard wrote (19 Mar 2010 13:24:51 GMT) :
 Is this issue still reproducible with a recent version of
 Virt-manager ?

Ping?

The bug was closed as CANTFIX upstream, so I wouldn't be surprised if
non-UTF-8 locales still triggered such bugs.

Cheers,
--
intrigeri


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

Bug#764567: ITP: obs-build -- Build DEB/RPM packages for various distributions inside a chroot


Hi Dimitri,

On  Do 09 Okt 2014 11:55:00 CEST, Dimitri John Ledkov wrote:


What concerns me most about your upload is the version number.



Yeah, I am aware of the crazy version numbering. So I based my version
numbers, on the version numbers that are published and used by
openSUSE itself in the openSUSE:Tools repository.
Which is where they package up daily git snapshot when a release happens.
https://build.opensuse.org/package/show/openSUSE:Tools/build

So At the moment, I have exact same version as the upstream releases
are in the openSUSE:Tools repository. Why should version numbers
diverge from what's used in openSUSE and upstream?

Ich kann nur ein bistchen Deutsch sprechen I did request tags for
matching builds to be pushed into the repository, but it doesn't look
like github issues are being monitored:
https://github.com/openSUSE/obs-build/issues/133


I pinged Michael Schroeder on IRC. I'll send you his nick off-list.


I understand that there are tags on the openSUSE/obs-build.git. I used them
as well till yesterday. However, I had an intensive chat with one of the
upstream authors (Michael Schroeder, from SUSE) yesterday. Unfortunately in
German, so copy+pasting makes no sense here.

About the tags on the Git he said: those tags are actually obs-server tags
(not obs-build). The obs-server devs tagged obs-build with obs-server
versions, so that they know what obs-build version / Git commit hash was
used with what obs-server version.

About obs-build, he said: every commit is a release. So basically, we should
use the version date. With upstream I came to the conclustion that the best
version number would be
0~gitdate.build-on-that-day.commit-hash-debrevision.

So, the question is, if you are open do re-upload obs-build. If so, we
should merge our packaging efforts (I think) and get several other things
going (e.g. the initvm.c tool, tests, etc.).

Also, I could not really find that all files are licensed GPL-2+. I just
asked upstream to do that today [1].



I went by the license information used by OBS packagers in
openSUSE:Tools repository which states GPL-2+. More explicit licensing
info would be appreciated in the repository itself. Thanks for asking
and getting that changed.


Ah. OK. Good point. This really needs to be reflected in upstream Git.


Do i need to join irc and ping adrian to get this reviewed/merged
https://github.com/openSUSE/obs-build/pull/136 ?


I am not aware of a public channel where to grab those SUSE devs. The  
two us meeting up on debian-devel is an idea. I won't be available  
till tonight, though.



Actually, some files [2] are licensed as GPL-3+, so your copyright file is


No, it got changed to 2 or 3, but no later. Given that some other
files are GPL-2-only, it seems like overall it's GPL-2-only.



Ah, ok... Read over the license change commits to quickly then...

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


pgpFwic1YYxDz.pgp
Description: Digitale PGP-Signatur

Bug#764333: jed: tab key does not work by default

2014-10-09 Thread Santiago Vila

  Well, I was looking for a small editor with an emacs-like feel, and
  the TAB key works in emacs by default, so this If you really want [...]
  is pure nonsense to me. Of course I want the TAB key to insert TABs!
 
 Well emacs TAB key is also context-sensitive is it not? jed's TAB key
 works as I expect (and more or less the same as emacs) editing
 makefiles, perl or C, but I agree that in plain text files it does
 nothing useful by default.
 
 You can always get real tabs by typing:
 [`][`][TAB]  (i.e backquote key, backquote key, tab key)
 
 Another small emacs like editor is zile (very small) and the TAB key
 is just TAB by default, with no fancy alignment so just using that
 might be easier, but it is more basic than jed :-)

Yes, I tried zile a lot of time ago. It does not support UTF-8 yet,
which is an essential feature for me, so I stopped using it in favour
of jed.

 Anyway, I take it you would prefer to see the above snippet in the
 default jed config?

Not exactly. I'm reporting what I think it is a misbehaviour, but I
don't really mind about the way to fix it. If there was a way to fix
this by modifying the code and not the default rc file, that would be
fine as well.

 Does that break the magic tabbing in other modes
 (C, make, perl) so we have to choose?

Don't know. I hope we don't have to choose.

 I'd like to keep the mode-sensitive magic tabing _and_ have it put a
 plain tab in in plain text mode as the defalt config. I don't
 actually know how to do that.

I would try forwarding this upstream as an usability problem.

It's funny but TAB does not even work (by default) when I write
this:

jed Makefile


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

Bug#724344: ITP: bdsync -- bdsync is a fast block device synchronizing tool

2014-10-09 Thread maxigas

From: intrigeri intrig...@debian.org
Subject: Re: Bug#724344: ITP: bdsync -- bdsync is a fast block device 
synchronizing tool
Date: Thu, 09 Oct 2014 11:50:49 +0200

 Hi maxigas,

 did you really intend to file this bug as an ITP (intent to package),
 or instead as a RFP (request for package)?

yes, i actually made the package.  but then i found out about the licence 
exception which has to be done for openssl and decided to try porting the 
software to gnutls.  afair it uses only a single function call to the crypto 
library.

then my patch did not work and i am still looking for somebody with enough C 
knowledge to help fixing it.  :)

--
maxigas, kiberpunk
FA00 8129 13E9 2617 C614 0901 7879 63BC 287E D166
http://research.metatron.ai/

People the switches!

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

Bug#623537: virt-manager: does not detect VT-x while creating guest

Hi,

Cole Robinson wrote (03 May 2011 17:42:29 GMT) :
 On 04/21/2011 07:40 PM, 0...@035.pfr.ru wrote:
 virsh --connect xen:/// capabilities
 cat /proc/cpuinfo
 
 It's in attachment.
 
 There's no vmx in cpuinfo, but according to some maillists it's normal. 
 Actually it's exists and enabled.
 
 

 Using that capabilities XML I can't reproduce your issue with latest
 upstream virt-manager and virtinst. Are you definitely using virtinst
 0.500.6 ? If not, I'm not really sure what the issue is.

Ping? Cole asked for more information more than 3 years ago.
Can you still reproduce this on current Wheezy or testing/sid?

Unless the requested information is provided, I think the next person
who passes over this bug report in a month or so (possibly me) should
close this bug report.

Cheers,
--
intrigeri


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

Bug#764553: base-files: Does neither state which version nor which variant of the Artistic License is in /usr/share/common-licenses/Artistic

2014-10-09 Thread Santiago Vila

I'll try to document this in the next version, but not in the README
as it has been suggested. This deserves a place in the copyright file
itself, below the line saying The GNU Public Licenses [...].

Thanks for the report.


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

Bug#764582: cpufrequtils: -r flag for related CPUs broke on transition from 3.14 to 3.16 kernel

2014-10-09 Thread Tim Small

Package: cpufrequtils
Version: 008-1
Severity: normal

Hi,

On 3.14 with Jessie this worked:

cpufreq-set -g ondemand --max 2.1GHz -r

since upgrading to 3.16 (it's possible that another upgrade installed at
the same time impacted this), these CPUs are no longer related.  i.e.
this call only changes:

/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

when it previously changed cpu0 - cpu7.

CPU is Core(TM) i7 CPU 860 quad core +HT.

getSystemId says:

System ID:0x040D
Service Tag:  DYBJM4J
Express Service Code: 30373411267
Product Name: Studio XPS 8100
BIOS Version: A03
Vendor:   Dell Inc.


Kernel seems to be correctly reporting related CPU cores, but don't know
if this API may have changed?

root@ermintrude:~# cat
/sys/devices/system/cpu/cpu0/topology/core_siblings_list 
0-7



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

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

Versions of packages cpufrequtils depends on:
ii  debconf [debconf-2.0]  1.5.53
ii  libc6  2.19-11
ii  libcpufreq0008-1
ii  lsb-base   4.1+Debian13

cpufrequtils recommends no packages.

cpufrequtils suggests no packages.

-- debconf-show failed


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

Bug#764583: luajit: Please add support for hurd-i386

2014-10-09 Thread Svante Signell

Source: luajit
Version: 2.0.3+dfsg-3
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

Currently GNU/Hurd is not in the architecture list for luajit in
debian/control. Doing so reveals that the package builds fine. The
attached patch adds hurd-i386 to the list.

Thanks!
--- a/debian_control	2014-04-25 21:41:09.0 +0200
+++ b/debian/control	2014-10-09 11:27:23.0 +0200
@@ -9,7 +9,7 @@
 Homepage: http://luajit.org
 
 Package: luajit
-Architecture: i386 amd64 kfreebsd-i386 armel armhf powerpc powerpcspe mips mipsel
+Architecture: i386 amd64 kfreebsd-i386 hurd-i386 armel armhf powerpc powerpcspe mips mipsel
 Multi-Arch: foreign
 Pre-Depends: multiarch-support
 Depends: ${shlibs:Depends}, ${misc:Depends}, libluajit-5.1-common (= ${source:Version})
@@ -30,7 +30,7 @@
  by its embeddable (i.e. library) version.
 
 Package: libluajit-5.1-2
-Architecture: i386 amd64 kfreebsd-i386 armel armhf powerpc powerpcspe mips mipsel
+Architecture: i386 amd64 kfreebsd-i386 hurd-i386 armel armhf powerpc powerpcspe mips mipsel
 Multi-Arch: same
 Pre-Depends: multiarch-support
 Depends: ${shlibs:Depends}, ${misc:Depends}, libluajit-5.1-common (= ${source:Version})
@@ -46,7 +46,7 @@
 Section: libdevel
 Multi-Arch: same
 Pre-Depends: multiarch-support
-Architecture: i386 amd64 kfreebsd-i386 armel armhf powerpc powerpcspe mips mipsel
+Architecture: i386 amd64 kfreebsd-i386 hurd-i386 armel armhf powerpc powerpcspe mips mipsel
 Depends: ${shlibs:Depends}, ${misc:Depends}, libluajit-5.1-2 (= ${binary:Version})
 Description: Just in time compiler for Lua - development files
  This package contains header files and a statically linkable library for

Bug#764258: mandos-client loops forever waiting for server

2014-10-09 Thread Teddy Hogeborn

Private correspondence with the initial bug reporter has determined that
this bug is a duplicate of bug #764034, so this bug has been merged with
that one.

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos


pgpEOSBL58R1i.pgp
Description: PGP signature

Bug#764448: mate-applets 1.8.1+dfsg1-1 tries to overwrite files in gnome-applets 3.8.1-1


Hi Giacomo,

On  Mi 08 Okt 2014 09:28:07 CEST, Giacomo Mulas wrote:


Dear Maintainer,

the new version 1.8.1+dfsg1-1 of mate-applets contains files with the same
name as gnome-applets 3.8.1-1. As a consequence, it is uninstallable if one
also installs gnome-applets. This means that on sid, at the moment, I cannot
install on a machine a full gnome desktop and a full mate desktop at the
same time, letting individual users choose which one they prefer to use.

Suggested solutions:

1) quick and dirty (unsatisfactory for me, but can be a temporary band aid):
add a conflicts with gnome-applets

2) optimal solution: change the names of the conflicting applets (possibly
coordinating with the gnome-applets maintainer)

3) less work than 2) but also less good: use the debian alternatives system
to make mate and gnome applets with the same name coexist (definitely
coordinating with the gnome-applets maintainer)

4) something else that I did not think about

Bye
Giacomo Mulas


Thanks for reporting this. This needs to be fixed upstream+downstream.

What are the files that trouble you (and us all)? (Asking, because I  
can't check right now, because I am at a customer).


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


pgp0G70n0UQJ8.pgp
Description: Digitale PGP-Signatur

Bug#764584: Pidgin no longer able to connect to Sametime

2014-10-09 Thread Joelly Alexander

Package: pidgin
Version: 2.10.9-1+b1

I just run a dist-upgrade on Debian Jessie and after reboot it can't
connect to our Sametime server anymore.
My Sametime account is disabled in Pidgin and i cannot enable it
anymore, when i click the enable checkbox it's unchecked immedately.
If i remove and re-create it i get the error message:
'Login verification down or unavailable'
Also the Sametime server name is getting lost, when you create an
account and save it it's in the config but when you modify the account
later it empties the server field and require to set it again.

This is what strace shows up to the point when pidgin starts and opens
the account window automatically - but when enabling or modifying the
account strace gives no additional output anymore:

--- snip ---
execve(/usr/bin/pidgin, [pidgin], [/* 30 vars */]) = 0
brk(0)  = 0x1d52000
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f40d2143000
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=122474, ...}) = 0
mmap(NULL, 122474, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f40d2125000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or
directory)
open(/lib/x86_64-linux-gnu/libtinfo.so.5, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0@\316\0\0\0\0\0
\0..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=171800, ...}) = 0
mmap(NULL, 2269152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f40d1cfb000
mprotect(0x7f40d1d21000, 2093056, PROT_NONE) = 0
mmap(0x7f40d1f2, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x25000) = 0x7f40d1f2
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or
directory)
open(/lib/x86_64-linux-gnu/libdl.so.2, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\320\16\0\0\0\0\0
\0..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14664, ...}) = 0
mmap(NULL, 2109712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f40d1af7000
mprotect(0x7f40d1afa000, 2093056, PROT_NONE) = 0
mmap(0x7f40d1cf9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x2000) = 0x7f40d1cf9000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or
directory)
open(/lib/x86_64-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0P\34\2\0\0\0\0
\0..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1725888, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f40d2124000
mmap(NULL, 3832352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f40d174f000
mprotect(0x7f40d18ee000, 2093056, PROT_NONE) = 0
mmap(0x7f40d1aed000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x19e000) = 0x7f40d1aed000
mmap(0x7f40d1af3000, 14880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0x7f40d1af3000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f40d2123000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f40d2122000
arch_prctl(ARCH_SET_FS, 0x7f40d2123700) = 0
mprotect(0x7f40d1aed000, 16384, PROT_READ) = 0
mprotect(0x7f40d1cf9000, 4096, PROT_READ) = 0
mprotect(0x7f40d1f2, 16384, PROT_READ) = 0
mprotect(0x6f2000, 4096, PROT_READ) = 0
mprotect(0x7f40d2145000, 4096, PROT_READ) = 0
munmap(0x7f40d2125000, 122474)  = 0
open(/dev/tty, O_RDWR|O_NONBLOCK) = 3
close(3)= 0
brk(0)  = 0x1d52000
brk(0x1d53000)  = 0x1d53000
open(/usr/lib/locale/locale-archive, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1607712, ...}) = 0
mmap(NULL, 1607712, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f40d1f99000
close(3)= 0
brk(0x1d54000)  = 0x1d54000
brk(0x1d55000)  = 0x1d55000
getuid()= 1000
getgid()= 1000
geteuid()   = 1000
getegid()   = 1000
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
brk(0x1d56000)  = 0x1d56000
open(/proc/meminfo, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f40d2142000
read(3, MemTotal:8079948 kB\nMemF..., 1024) = 1024
close(3)= 0
munmap(0x7f40d2142000, 4096)= 0
brk(0x1d57000)  =

Bug#695371: virt-manager: Virtual machine does not support sound

Control: tag -1 + moreinfo

Hi,

Singer Michael wrote (07 Dec 2012 16:46:36 GMT) :
 The virt-manager has in a VM configured via GUI no sound support.
 The VM is configured with the audio device ac97 and SPICE (see the
 XML config file).

 In the log file of virt-manager the following entry when starting the VM is 
 created.

 virt-manager.log:
 [Fr, 07 Dez 2012 16:36:25 virt-manager 7970] DEBUG (cli:83) Uncaught 
 exception:
 Traceback (most recent call last):
   File /usr/share/virt-manager/virtManager/console.py, line 518, in 
 _channel_new_cb
   self.audio = spice.Audio(self.spice_session)
   RuntimeError: could not create SpiceAudio object

Sound support works just fine for me in virt-manager on current
Debian unstable, in a VM that has the Spice channels configured.
Are you still experiencing this problem?

Cheers,
--
intrigeri


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

Bug#764448: mate-applets 1.8.1+dfsg1-1 tries to overwrite files in gnome-applets 3.8.1-1

Control: reassign -1 mate-applets,gnome-applets
Control: found -1 mate-applets/1.8.1+dfsg1-1
Control: found -1 gnome-applets/3.8.1-1

Hi,

Giacomo Mulas wrote:
 the new version 1.8.1+dfsg1-1 of mate-applets contains files with the same
 name as gnome-applets 3.8.1-1. As a consequence, it is uninstallable if one
 also installs gnome-applets.

Thanks for the report.

For the MATE maintainers: We also ran into that issue on Ubuntu 12.04
LTS Precise with the packages from MATE PPA, so after this is fixed in
Debian Sid, it should be fixed in the MATE Precise PPA, too.

 Suggested solutions:

There's a standard procedure for such cases:
https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries

 1) quick and dirty (unsatisfactory for me, but can be a temporary band aid):
 add a conflicts with gnome-applets

Yeah, that's usually discouraged.

 2) optimal solution: change the names of the conflicting applets (possibly
 coordinating with the gnome-applets maintainer)

That's the officially recommended way.

 3) less work than 2) but also less good: use the debian alternatives system
 to make mate and gnome applets with the same name coexist (definitely
 coordinating with the gnome-applets maintainer)

For that their API/ABI always needs to be same. Which likely isn't.
And it's also likely much more work than 2).

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#763134: acpi-support-base: /usr/share/acpi-support/power-funcs broken from line 24 if consolekit installed and no dbus running

2014-10-09 Thread Michael Meskes

 from my original report i would guesstimate from:
 + d=/tmp/.X11-unix
 ^^
 ...

Ah, sorry, I was under the impression (no idea why) that you were seeing
the problem in getXconsole.

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


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

Bug#646919: [Pkg-libvirt-maintainers] Bug#646919: virt-manager: memory resource consumption is way too high

Control: tag -1 + moreinfo

Hi,

Ritesh Raj Sarraf wrote (31 Oct 2011 07:57:59 GMT) :
 Maybe you can gain some information running it under valgrind? Here's a
 nice set of parameters or GObject based programs:
 
 https://live.gnome.org/Valgrind

 Thanks. I will look into this and see if I can dig further.

Any update on this front?

Are you still experiencing this problem on current Debian stable or
testing/sid?

Cheers,
--
intrigeri


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

Bug#701097: virt-manager: No keyboard with Spice

Control: tag -1 + moreinfo

Hi Alexey,

Alexey Feldgendler wrote (21 Feb 2013 13:34:46 GMT) :
 When a VM is configured to use Spice, keyboard input from the virt-manager
 viewer does not reach the VM (and neither do the Send Key menu items work). No
 keys at all work, not even A-Z (which sometimes still work when the keyboard
 layout is broken).

 When a stand-alone Spice client is used to access the same VM, keyboard works.
 Also, the viewer in virt-manager works fine with VNC.

On current Debian sid, virt-manager works fine for me with Spice
channels, including keyboard. Can you still reproduce this bug on
Debian testing or sid?

Cheers,
--
intrigeri


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

Bug#764448: mate-applets 1.8.1+dfsg1-1 tries to overwrite files in gnome-applets 3.8.1-1

Hi Mike,

Mike Gabriel wrote:
 What are the files that trouble you (and us all)?

Here you go:

Preparing to unpack .../mate-applets_1.8.1+dfsg1-1_i386.deb ...
Unpacking mate-applets (1.8.1+dfsg1-1) over (1.8.0+dfsg1-1+b2) ...
dpkg: error processing archive 
/var/cache/apt/archives/mate-applets_1.8.1+dfsg1-1_i386.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/whereami_applet.1.gz', which is also 
in package gnome-applets 3.8.1-1
Processing triggers for [...]
Errors were encountered while processing:
 /var/cache/apt/archives/mate-applets_1.8.1+dfsg1-1_i386.deb

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#764585: ddclient: [INTL:fr] French debconf templates translation update

2014-10-09 Thread Christian Perrier

Package: ddclient
Version: N/A
Severity: wishlist
Tags: patch l10n

Please find attached the french debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

If you do not already use it, you might consider using the
podebconf-report-po utility, which helps warning translators about
changes when you modify some debconf templates in your packages.

The usual policy when using it is sending a warning to translators
when you plan to upload a version of your package with debconf
templates changes (even typo corrections). Then leave about one week
for them to update their files (several translation teams have a QA
process which requires time).

podebconf-report-po will take care of sending the translators the
needed material as well as getting the translators adresses from the
PO files. All you have to do is just using the utility..:-)

Example use (from your package build tree):

$ podebconf-report-po

This will go through debian/po/*.po files, find those needing an
update, extract the translators data from these files and prepare a
mail to send to these translators (you can also use the
--languageteam switch to also mail the mail addresses listed in
Language-Team field).

You can also use this utility to request for new translations:

$ podebconf-report-po --call

This will send a mail to debian-i...@lists.debian.org with all the
needed information and material for new translators to add new
languages to your supported languages.

If you apply this policy, please forget about these remarks, of
courseThis message is generic..:-)


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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
# Translation of ddclient debconf templates to French
# Copyright (C) 2005-2009 Debian French l10n team debian-l10n-fre...@lists.debian.org
# This file is distributed under the same license as the ddclient package.
#
# Translators:
# Christian Perrier bubu...@debian.org, 2005, 2009, 2010, 2013, 2014.
msgid 
msgstr 
Project-Id-Version: ddclient\n
Report-Msgid-Bugs-To: ddcli...@packages.debian.org\n
POT-Creation-Date: 2014-01-16 00:49+0100\n
PO-Revision-Date: 2014-10-09 07:33+0200\n
Last-Translator: Christian Perrier bubu...@debian.org\n
Language-Team: French debian-l10n-fre...@lists.debian.org\n
Language: fr\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Generator: Lokalize 1.5\n
Plural-Forms: nplurals=2; plural=(n  1);\n

#. Type: select
#. Choices
#: ../ddclient.templates:2001
msgid other
msgstr Autre

#. Type: select
#. Description
#: ../ddclient.templates:2002
msgid Dynamic DNS service provider:
msgstr Fournisseur de service DNS dynamique :

#. Type: select
#. Description
#: ../ddclient.templates:2002
msgid 
Please select the dynamic DNS service you are using. If the service you use 
is not listed, choose \other\ and you will be asked for the protocol and 
the server name.
msgstr 
Veuillez choisir le service de DNS dynamique que vous utilisez. Si celui-ci 
n'est pas affiché ici, veuillez choisir « Autre ». Le nom du serveur et le 
protocole utilisé vous seront alors demandés.

#. Type: string
#. Description
#: ../ddclient.templates:3001
msgid Dynamic DNS server:
msgstr Serveur de DNS dynamique :

#. Type: string
#. Description
#: ../ddclient.templates:3001
msgid 
Please enter the name of the server which is providing you with dynamic DNS 
service (example: members.dyndns.org).
msgstr 
Veuillez indiquer le nom du serveur qui fournit le DNS dynamique (p. ex. : 
members.dyndns.org).

#. Type: select
#. Description
#: ../ddclient.templates:4001
msgid Dynamic DNS update protocol:
msgstr Protocole de mise à jour du DNS dynamique :

#. Type: select
#. Description
#: ../ddclient.templates:4001
msgid 
Please select the dynamic DNS update protocol used by your dynamic DNS 
service provider.
msgstr 
Veuillez choisir le protocole de mise à jour du DNS dynamique utilisé par le 
fournisseur du service.

#. Type: string
#. Description
#: ../ddclient.templates:5001
msgid DynDNS fully qualified domain names:
msgstr Noms de domaine de DNS dynamique (complètement qualifiés) :

#. Type: string
#. Description
#: ../ddclient.templates:5001
msgid 
Please enter the list of fully qualified domain names for the local host(s) 
(for instance, \myname.dyndns.org\ with only one host or \myname1.dyndns.
org,myname2.dyndns.org\ for two hosts).
msgstr 
Veuillez indiquer la liste des noms de domaine complètement qualifiés des 
machines locales (p. ex. « myname.dyndns.org » pour un nom unique ou 
« myname1.dyndns.org,myname2.dyndns.org » pour deux noms).

#. Type: string
#. Description
#: ../ddclient.templates:6001
msgid Username for dynamic DNS service:
msgstr Identifiant pour le service de DNS

Bug#565895: virt-manager: cannot clone VMs with interface type='ethernet'

Control: tag -1 + moreinfo

Hi,

Tino Keitel wrote (19 Jan 2010 13:47:44 GMT) :
 On Tue, Jan 19, 2010 at 14:39:39 +0100, Tino Keitel wrote:

 [...]

 The culprit seems to be the interface type. This configuration can be
 cloned:
 
 interface type='ethernet'
   mac address='52:54:00:38:53:95'/
   target dev='m0d0'/
   model type='e1000'/
 /interface

 Sorry, I pasted the wrong configuration snipset.

 A VM with this network configuration can be cloned:

 interface type='bridge'
   mac address='52:54:00:38:53:95'/
   source bridge='virbr0'/
   target dev='m0d0'/
   model type='e1000'/
 /interface

Thanks for this bug report, and sorry for not following up earlier.
Can you still reproduce this with on current Debian stable, or
testing/sid?

Cheers,
--
intrigeri


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

Bug#629341: virtinst: fails if umask isn't permissive

Control: tag -1 + moreinfo

Hi,

 I can confirm that this problem still exists and that the proposed
 solution is IMHO adequate.

Can you still reproduce this on current testing/sid?

I suspect this was fixed since then, as I see (1:1.0.1-2):

def _perform_initrd_injections(initrd, injections, scratchdir):

Insert files into the root directory of the initial ram disk

[...]
tempdir = tempfile.mkdtemp(dir=scratchdir)
os.chmod(tempdir, 0775)

OTOH, the two other instances of tempfile.mkdtemp() I could see (in
virtconv/formats.py and virtinst/urlfetcher.py) have no such chmod, so
they may very well be affected by similar issues.

Cheers,
--
intrigeri


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

Bug#764587: installation-reports: After successful installation from usb stick the stick is not recognised on reboot.

2014-10-09 Thread Philip Charles

Package: installation-reports
Severity: normal
 After successful installation from usb stick the stick is not
recognised on reboot.

Boot method: usb stick
Image version: beta 2 installer amd64 DVD1 (copied to usb stick)
Date: Oct 2014

Machine: Self built
Partitions: My test HDD.


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [o ]
Detect network card:[o ]
Configure network:  [o ]
Detect CD:  [o ]
Load installer modules: [o ]
Clock/timezone setup:   [o ]
User/password setup:[o ]
Detect hard drives: [o ]
Partition hard drives:  [o ]
Install base system:[o ]
Install tasks:  [o ]
Install boot loader:[o ]
Overall install:[o ]

Comments/Problems:
Long standing problem since Jessie.
The system will not recognise the usb stich used for the installation.
Fiddling will will not get the stick recognised.
 
This horrible hack works. modifying /etc/apt/apt.conf.d/00CDMountPoint
to read

Acquire::cdrom {
mount /media/usb;
}
Dir::Media::MountPath /media/usb;

usb was originally cdrom.

/etc/apt/sources.list reads (comments removed).
#.

# deb cdrom:[Debian GNU/Linux jessie-DI-b2 _Jessie_ - Official Snapshot
amd64 DVD Binary-1 20141003-18:34]/ jessie contrib main

deb cdrom:[Debian GNU/Linux jessie-DI-b2 _Jessie_ - Official Snapshot
amd64 DVD Binary-1 20141003-18:34]/ jessie contrib main

deb http://security.debian.org/ jessie/updates main contrib
deb-src http://security.debian.org/ jessie/updates main contrib

Related problem.
apt-cdrom add will not detect a usb stick
Do we need an apt-usb?



The test installation was done with this machine, but on a different
HDD.
Identical problems were experienced on two other machines with both
32 and 64 bit versions of the usb sticks.

===


-- 
  Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
   +64 3 488 2818Fax +64 3 488 2875Mobile 027 663 4453
   phil...@copyleft.co.nz - personal.i...@copyleft.co.nz - business


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

Bug#761755: closed by Matthias Klose d...@debian.org (Re: luasocket: libtool split: package needs a b-d on libtool-bin (or avoid using the libtool binary))

2014-10-09 Thread Matthias Klose

Control: reopen 761755

reopening wrong issue, closing the correct one.


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

Bug#760526: Enable AppArmor support (using libapparmor)

Hi,

intrigeri wrote (24 Sep 2014 05:33:37 GMT) :
 So, I don't think that the problem I'm seeing here is a blocker for
 enabling AppArmor support in systemd. The attached patch implements
 this. Once something like this is applied, I'll clone this bug report
 to track the remaining problems.

Anything else I can do to help have this feature enabled in Jessie?

Cheers,
--
intrigeri


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

Bug#629341: virtinst: fails if umask isn't permissive

2014-10-09 Thread martin f krafft

also sprach intrigeri intrig...@debian.org [2014-10-09 12:30 +0200]:
 I suspect this was fixed since then, as I see (1:1.0.1-2):
 
 def _perform_initrd_injections(initrd, injections, scratchdir):
 
 Insert files into the root directory of the initial ram disk
 
 [...]
 tempdir = tempfile.mkdtemp(dir=scratchdir)
 os.chmod(tempdir, 0775)

The original bug report is about direct kernel loading by qemu,
unless I am very mistaken. So I don't think initrd injection code
fixes this.

-- 
 .''`.   martin f. krafft madduck@d.o @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
the problem with america is stupidity. i'm not saying there should
 be a capital punishment for stupidity, but why don't we just take
 the safety labels off of everything and let the problem solve
 itself?
-- seen on irc


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#758121: [Pkg-crosswire-devel] Bug#758121: Bug#758121: bibletime: Bibletime is unusable in testing and unstable

2014-10-09 Thread Roberto C . Sánchez

I do use it.  I was planning on trying to update the package this
weekend.

Regards,

-Roberto

On Thu, Oct 09, 2014 at 10:55:59AM +0100, Dimitri John Ledkov wrote:
 On 8 October 2014 15:54,  da...@sandersweb.net wrote:
  retitle 758121 bibletime: New upstream release fixes display problem in 
  jessie
  severity 758121 grave
  thanks
 
  On Monday, October 06, 2014 10:26:56 PM you wrote:
  Bibletime is unusable in jessie and sid.  When you open any Bible or
  commentary all you see is jibberish.  This needs to be fixed prior to
  the release of jessie.
 
  I just built the new upstream release (2.10.1) from source.  It does not 
  have
  this problem.  Please update the bibletime package in jessie to the latest
  upstream release available on sourceforge.
 
 
 Debdiff would be appreciated. I don't use, nor typically updated bibletime.
 
 -- 
 Regards,
 
 Dimitri.
 
 ___
 Pkg-crosswire-devel mailing list
 pkg-crosswire-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-crosswire-devel

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Bug#764472: cups creates millions of temporary files when printing

2014-10-09 Thread Antonio Sartori

Hello Brian,

Some additional information:

The links are created when printing with evince, but not when printing
with lp. (Actually, printing with evince produces blank pages, but I
don't know whether this is related - maybe it's a problem of my pdf file.)

The links continue to be created after the print command from evince has
been given (about 50 links per minute). During this, a process uses
most of the cpu, and it is

/usr/bin/python /usr/share/system-config-printer/scp-dbus-service.py

Killing this process, the creation of symlinks stops. So I guess this is
what creates this lot of symlinks.

I am not quite sure now whether this is a bug of evince, or of
system-config-printer or something else.

Regards,
Antonio



Il 09/10/2014 01:00, Brian Potkin ha scritto:
 Hello Antonio,

 Thank you for your report. The first thing to say is that this is very
 likely not to be a bug in cups. Please see

   https://bugs.launchpad.net/ubuntu/+source/cups/+bug/890705

 and

   https://bugzilla.redhat.com/show_bug.cgi?id=581748

 So - do you have acroread installed?


 On Wed 08 Oct 2014 at 14:04:46 +0200, Antonio Sartori wrote:

 When trying to print (tried twice from evince, not tested from other
 software), cups creates millions of symbolic links in /tmp to the ppd
 driver in /etc/cups/ppd. The names of the symbolic links are similar
 to 54351da228fae.
 Millions of links would imply lots of printing taking place and not just
 twice. Is that the case? Also, does it occur with other applications? We
 really need to track down under what circumstances the files are created
 and why they are not deleted by the application.
  
 This causes the system to hang on the next reboot while systemd tries
 to empty the tmp folder, making the system unbootable.
 Do you mean it hangs indefinitely and the machine has to powered off to
 be restarted?

 Notice that deleting the files by hand is tricky, since they are too
 many (rm does not work, it is not even possible to list the files with
 ls), I don't know how to do this. For now, I rebooted the system using
 a live dist and I typed mv /tmp /tmp2. This enables the system to boot
 again. Help on how I can delete the folder tmp2 would also be
 appreciated.
 I'm surprised 'ls -l' doesn't work. Is there any error message? What
 about 'ls -l | head'.

 'rm -r /tmp2' should delete /tmp2.

 Regards,

 Brian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54364fe8.2060...@gmail.com

Bug#764472: cups creates millions of temporary files when printing

2014-10-09 Thread Antonio Sartori

Hello Brian,

Thank you for your answer.

Hello Antonio,

Thank you for your report. The first thing to say is that this is very
likely not to be a bug in cups. Please see

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/890705

and

https://bugzilla.redhat.com/show_bug.cgi?id=581748

So - do you have acroread installed?
I looked at the bug reports you mentioned, so probably it is a problem
of another package. I have acroread installed, but acroread was closed -
I was printing with evince. But I will try to reproduce the problem and
find it out.

On Wed 08 Oct 2014 at 14:04:46 +0200, Antonio Sartori wrote:

When trying to print (tried twice from evince, not tested from other
software), cups creates millions of symbolic links in /tmp to the ppd
driver in /etc/cups/ppd. The names of the symbolic links are similar
to 54351da228fae.
Millions of links would imply lots of printing taking place and not just
twice. Is that the case? Also, does it occur with other applications? We
really need to track down under what circumstances the files are created
and why they are not deleted by the application.
No, I tried to print only three or four times.

This causes the system to hang on the next reboot while systemd tries
to empty the tmp folder, making the system unbootable.
Do you mean it hangs indefinitely and the machine has to powered off to
be restarted?
Yes. The problem is that systemd wants to empty the tmp folder during
the boot. I don't know how it does it, but the problem is that removing
millions of files is slow, anyway (see
http://unix.stackexchange.com/questions/96935/faster-way-to-delete-large-number-of-files).

I was finally able to list some of the files using ls -Uf | head -n
100 (it seems the slow part is the sorting of ls). The files where
actually a bit more than 100. For removing the files, I used ionice
-c 2 -n 7 find . -type l -delete, but it took more than one hour to finish.

Notice that deleting the files by hand is tricky, since they are too
many (rm does not work, it is not even possible to list the files with
ls), I don't know how to do this. For now, I rebooted the system using
a live dist and I typed mv /tmp /tmp2. This enables the system to boot
again. Help on how I can delete the folder tmp2 would also be
appreciated.
I'm surprised 'ls -l' doesn't work. Is there any error message? What
about 'ls -l | head'.

'rm -r /tmp2' should delete /tmp2.
rm -r /tmp2 seems also to be extremely slow. Probably it unlinks first
each single file inside tmp2.

For now, I mounted tmp as tmpfs so I can try againg without making the
system unbootable.

Regards,
Antonio
Regards,

Brian.

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5436422c.3020...@gmail.com

Bug#764001: installation-reports: I cannot proceed from tasksel if I select all four desktop environments

2014-10-09 Thread Thomas Skardal

I get the red screen telling me that

An installation step failed. You can try to run the failing installation
item again from the menu, or
skip it and choose something else. The failing step is: Select and install
software.

I checked the output in the 4th console. It tells me that

The following packages have unmet dependencies:
task-gnome desktop: Depends: gnome-core but it is not going to be installed
Recommends: gnome but it is not going to be installed

On Wed, Oct 8, 2014 at 8:55 PM, Joey Hess jo...@debian.org wrote:

 Thomas Skardal wrote:
  If I select all four (Gnome, KDE, XFCE, MATE) desktop environments
  during tasksel I'm unable to continue without an error.

 Tasks should all be co-installable, so it would be useful to know what
 the error message is.

 --
 see shy jo

Bug#764588: ffmpeg: fails to build from source in sid

2014-10-09 Thread Holger Levsen

package: ffmpeg
severity: critical
version: 2.4.1-1

Hi,

ffmpeg fails to build from source in sid in pbuilder as per attached log.

make[1]: Leaving directory '/tmp/buildd/ffmpeg-2.4.1'
   debian/rules override_dh_auto_build-arch
make[1]: Entering directory '/tmp/buildd/ffmpeg-2.4.1'
sem_open: Function not implemented
# Build qt-faststart here, to make it possible to build with 'nocheck'.
make tools/qt-faststart
make[2]: Entering directory '/tmp/buildd/ffmpeg-2.4.1'
touch .version
gcc -I. -I./ -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -
D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -
DZLIB_CONST -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-overflow -
fstack-protector-all   -std=c99 -fomit-frame-pointer -fPIC -pthread -
I/usr/include/p11-kit-1 -I/usr/include/harfbuzz -I/usr/include/freetype2 -
I/usr/include/fribidi -I/usr/include/freetype2  -I/usr/include/bs2b  -
I/usr/include/freetype2 -I/usr/include/freetype2 -I/usr/include/fribidi  -
I/usr/include/opencv -I/usr/include/opus -D_REENTRANT -I/usr/include/p11-kit-1 
-I/usr/include/schroedinger-1.0 -I/usr/include/orc-0.4  -D_GNU_SOURCE=1 -
D_REENTRANT -I/usr/include/SDL -g -Wdeclaration-after-statement -Wall -
Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -
Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-
prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -
Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -
Werror=format-security -Werror=implicit-function-declaration -Werror=missing-
prototypes -Werror=return-type -Werror=vla -Wformat -Wno-maybe-uninitialized  
-MMD -MF tools/qt-faststart.d -MT tools/qt-faststart.o -c -o tools/qt-
faststart.o tools/qt-faststart.c
gcc -Llibavcodec -Llibavdevice -Llibavfilter -Llibavformat -Llibavresample -
Llibavutil -Llibpostproc -Llibswscale -Llibswresample -Wl,-z,relro -Wl,-
z,relro -Wl,-z,now  -Wl,--as-needed -Wl,--warn-common -Wl,-rpath-
link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample
  
-o tools/qt-faststart tools/qt-faststart.o 
make[2]: Leaving directory '/tmp/buildd/ffmpeg-2.4.1'
# Use faketime to make the build more binary reproducible.
faketime -f -m  dh_auto_build -a
sem_open: Function not implemented
debian/rules:195: recipe for target 'override_dh_auto_build-arch' failed
make[1]: *** [override_dh_auto_build-arch] Error 1
make[1]: Leaving directory '/tmp/buildd/ffmpeg-2.4.1'
debian/rules:164: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package


cheers,
Holger
DIST=unstable
ARCH=amd64

W: /root/.pbuilderrc does not exist
I: using fakeroot in build.
I: Current time: Thu Oct  9 12:40:22 CEST 2014
I: pbuilder-time-stamp: 1412851222
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/unstable-amd64-base.tgz]
I: creating local configuration
I: copying local configuration
I: mounting /proc filesystem
I: mounting /dev/pts filesystem
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Installing the build-deps
 - Attempting to satisfy build-dependencies
 - Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team pbuilder-ma...@lists.alioth.debian.org
Description: Dummy package to satisfy dependencies with aptitude - created by pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: bc, debhelper (= 9), flite1-dev, frei0r-plugins-dev, ladspa-sdk, libass-dev, libbluray-dev, libbs2b-dev, libbz2-dev, libcaca-dev, libcdio-paranoia-dev, libcrystalhd-dev, libfribidi-dev, libgme-dev, libgnutls28-dev | libgnutls-dev, libgsm1-dev, libiec61883-dev, libavc1394-dev, libjack-jackd2-dev, libmodplug-dev, libmp3lame-dev, libopenal-dev, libopencv-dev, libopenjpeg-dev, libopus-dev, librtmp-dev, libschroedinger-dev, libsctp-dev, libsdl-dev, libshine-dev (= 3.0.0), libsoxr-dev, libspeex-dev, libssh-dev, libtheora-dev, libtwolame-dev, libva-dev, libvdpau-dev, libvorbis-dev, libvpx-dev, libwavpack-dev, libwebp-dev, libx264-dev, libxvidcore-dev, libxvmc-dev, libzmq3-dev, libzvbi-dev, texinfo, yasm, faketime, cleancss, doxygen, node-less
dpkg-deb: building package `pbuilder-satisfydepends-dummy' in `/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 11926 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring anyway as you requested:
 pbuilder-satisfydepends-dummy depends on bc;

Bug#764547: bsdutils: script(1) is broken, hangs or crashes