date:20141009

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 , 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  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

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. 888d88""88b 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  
 wrote:

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* 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  
> 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 
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 
Signed-off-by: "Theodore Ts'o" 

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 
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// testkey1 luks,keyscript=decrypt_keyctl
clv2_crypt /dev// 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
> .
> 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/prei

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  
wrote:
> 
> Ralf Treinen  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 
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 
+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 
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   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  wrote:
> On Tue, 7 Oct 2014 23:24:12 -0700 Vincent Cheng  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 

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  = 
+# disable = 
+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 
 #else
 #include 
--- 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 
-#elif __MACH__
+#elif defined(__MACH__) && defined(__APPLE__)
 #include 
 #include 
 #include 
@@ -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 
 #include 
 #define MAX_SEMAPHORE_COUNT 1024
-#elif __MACH__
+#elif defined(__MACH__) && defined(__APPLE__)
 #include 
 #include 
 #include 
@@ -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 
 #include 
 #include "jthread/jsemaphore.h"
-#ifdef __MACH__
+#if defined(__MACH__) && defined(__APPLE__)
 #include 
 #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 
 	#include  //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
 #include 
 #include 
-#ifdef __MACH__
+#if defined(__MACH__) && defined(__APPLE__)
 #include 
 #include 
 #endi

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// testkey1 luks,keyscript=decrypt_keyctl
>>> clv2_crypt /dev// 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  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 

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 1>&2 <<-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 1>&2 <<-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 1>&2 <<-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⎜ 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- 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

2014-10-09 Thread Dimitri John Ledkov

On 9 October 2014 08:43, Mike Gabriel  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 
>> wrote:
>>>
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: Mike Gabriel 
>>>
>>> * 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

2014-10-09 Thread Andreas Henriksson

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

2014-10-09 Thread Andreas Henriksson

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



git bisect 



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
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
wrote:

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel

* 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.

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.

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~git..-.

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]
https://github.com/openSUSE/obs-build/commit/fbb353690da2e4eeca0661e0e8f5f1141bee41ce
[2]
https://github.com/openSUSE/obs-build/commit/dcfcf896cd913c8f2c067ef97ce5176a5358e5d0

DAS-NETZWERKTEAM
mike gabr

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  

-- 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

2014-10-09 Thread Dimitri John Ledkov

On 9 October 2014 10:42, Mike Gabriel  wrote:
> Hi Dimitri,
>
>
> On  Do 09 Okt 2014 11:18:30 CEST, Dimitri John Ledkov wrote:
>
>> On 9 October 2014 08:43, Mike Gabriel 
>> 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 
 wrote:
>
>
> Package: wnpp
> Severity: wishlist
> Owner: Mike Gabriel 
>
> * 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.
>
>
> 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.
>
>> 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.
>

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 t

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

2014-10-09 Thread Dimitri John Ledkov

On 8 October 2014 15:54,   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~git..-.

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  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 
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

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 , 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 , 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 
# This file is distributed under the same license as the ddclient package.
#
# Translators:
# Christian Perrier , 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 \n"
"Language-Team: French \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

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:
>> 
>> 
>>   
>>   
>>   
>> 

> Sorry, I pasted the wrong configuration snipset.

> A VM with this network configuration can be cloned:

> 
>   
>   
>   
>   
> 

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 (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)