Bug#702766: epdfview: Often don't show pages

[Dmitrii Kashin]

Package: epdfview
Version: 0.1.8-3
Severity: normal

I very often se a situation that epdfview don't show pages at all. I
see only grey background, and no pages.

Here I put file 02.pdf (sorry for non-english language). Just load it
and open page 247.

If you won't be able tp represent this bug, I will try to collect some
more information. Just ask it.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (100, 'experimental'), (1, 
'unstable')
Architecture: i386 (i686)

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

Versions of packages epdfview depends on:
ii  libc6   2.17-0experimental2
ii  libcairo2   1.12.2-2
ii  libcups21.5.3-2.13
ii  libgcc1 1:4.7.2-5
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-3
ii  libgtk2.0-0 2.24.10-2
ii  libpango1.0-0   1.30.0-1
ii  libpoppler-glib80.18.4-4
ii  libstdc++6  4.7.2-5

epdfview recommends no packages.

Versions of packages epdfview suggests:
ii  poppler-data  0.4.5-10

-- 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#612245: Regarding FCEU/FCEUX

[Alexander Toresson]

Thanks, that's great! I'll look into how to get access to Alioth.

I contacted three people about theur Lua scripts (the three I have
found contact info for so far), I already got replies from two.

// Alexander

On Mon, Mar 11, 2013 at 7:04 AM, Joe Nahmias  wrote:
> On Sun, Mar 10, 2013 at 09:29:55PM +0100, Alexander Toresson wrote:
>> I've gone through the lua scripts. Many of them are by FCEUX
>> contributors who committed them themselves, so GPL-2+ should apply to
>> them.
>>
>> However, there are scripts by a few other authors, with unspecified
>> license. I'll need to investigate those.
>>
>> // Alexander
>
> That's very good.  Just so you know, I've set up a collab-maint git repo
> on alioth for the packaging.  You can find it at:
> http://anonscm.debian.org/gitweb/?p=collab-maint/fceux.git
>
> If you can get access to alioth, then you should be able to commit
> directly there.
>
> --Joe


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

Bug#702767: installation-reports: Installation successful: Acer Aspire One725

[Kokila Mistry]

Package: installation-reports
Severity: wishlist

Dear Maintainer,

Wheezy installtion was sucessful on my laptop.

-- Package-specific info:

Boot method: USB
Image version: Wheezy D-I RC 1
Date: 20130311

Machine: Acer Aspire One725
Partitions: df -Tl output:

Filesystem Type 1K-blocks
Used Available Use% Mounted on
rootfs rootfs 9611492 
1980324   7142928  22% /
udev   devtmpfs 10240   
0 10240   0% /dev
tmpfs  tmpfs   179176 
420178756   1% /run
/dev/disk/by-uuid/f6a0932a-5d2f-456d-b9f5-a59fe9a79d4c ext4   9611492 
1980324   7142928  22% /
tmpfs  tmpfs 5120   
0  5120   0% /run/lock
tmpfs  tmpfs  1082720   
0   1082720   0% /run/shm
/dev/sda6  ext4 467542608  
480708 443312116   1% /home

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:

1. Although two network interfaces were detected, ethernet required non-free 
driver.
2. Despite of #1, no network interfaces were up after installation.
3. Touchpad is only enabled by: fn+f7 keys.
4. Thanks :)

-- 

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="7.0 (wheezy) - installer build 20130304-00:05"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux koki 3.2.0-4-486 #1 Debian 3.2.39-2 i686 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] Family 14h 
Processor Root Complex [1022:1510]
lspci -knn: Subsystem: Advanced Micro Devices [AMD] Family 14h Processor 
Root Complex [1022:1510]
lspci -knn: 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices 
[AMD] nee ATI Device [1002:980a]
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0740]
lspci -knn: 00:01.1 Audio device [0403]: Advanced Micro Devices [AMD] nee ATI 
Wrestler HDMI Audio [Radeon HD 6250/6310] [1002:1314]
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0740]
lspci -knn: 00:04.0 PCI bridge [0604]: Advanced Micro Devices [AMD] Family 14h 
Processor Root Port [1022:1512]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:05.0 PCI bridge [0604]: Advanced Micro Devices [AMD] Family 14h 
Processor Root Port [1022:1513]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:10.0 USB controller [0c03]: Advanced Micro Devices [AMD] FCH USB 
XHCI Controller [1022:7812] (rev 03)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0740]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: 00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] FCH 
SATA Controller [AHCI mode] [1022:7801]
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0740]
lspci -knn: Kernel driver in use: ahci
lspci -knn: 00:12.0 USB controller [0c03]: Advanced Micro Devices [AMD] FCH USB 
OHCI Controller [1022:7807] (rev 11)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0740]
lspci -knn: Kernel driver in use: ohci_hcd
lspci -knn: 00:12.2 USB controller [0c03]: Advanced Micro Devices [AMD] FCH USB 
EHCI Controller [1022:7808] (rev 11)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0740]
lspci -knn: Kernel driver in use: ehci_hcd
lspci -knn: 00:13.0 USB controller [0c03]: Advanced Micro Devices [AMD] FCH USB 
OHCI Controller [1022:7807] (rev 11)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0740]
lspci -knn: Kernel driver in use: ohci_hcd
lspci -knn: 00:13.2 USB controller [0c03]: Advanced Micro Devices [AMD] FCH USB 
EHCI Controller [1022:7808] (rev 11)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0740]
lspci -knn: Kernel driver in use: ehci_hcd
lspci -knn: 00:14.0 SMBus [0c05]: Advanced Micro Devices [AMD] FCH SMBus 
Controller [1022:780b] (rev 14)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0740]
lspci -knn: 00:14.2 Audio device [0403]: Advanced Micro Devices [AMD] FCH 
Azalia Controller [1022:780d] (rev 01)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0740]
lspci -knn:

Bug#700620: Rewriting the .ini parsing bit of openstack-pkg-tools

[Thomas Goirand]

Hi,

This often happens when one do some code: you hack, hack and hack
around, then after a while, you realize your code need some clean up.
I'm at this point in time with the ini parsing functions in all core
packages of Openstack.

As we're supposed to be a team (even though I really feel too much alone
doing the heavy work...), I'd like to discuss the problem publicly.

When Roland was doing some packaging work, we had discussions on how to
do the parsing of .ini files inside Openstack. I first wrote a very ugly
shell script function, which was about 150 lines, which is completely
lame, for such a small task. Then he decided (rightly) that it was crap,
and tried rewriting it in python. The current code in
openstack-pkg-tools is from him, and is like this:

python -c "import configobj
config=configobj.ConfigObj('${FILE}')
config['${SECTION}']['${DIRECTIVE}']='${VALUE}'
config.write()"

Unfortunately, the Openstack .ini files aren't really ini files, and can
have entries this way:

[composite:ec2]
use = egg:Paste#urlmap
/services/Cloud: ec2cloud

As a consequence, the class configobj which is in the minimal default
python installation in Debian crashes. Roland then decided to patch the
nova api-paste.ini to fix the problem, and transform some of the
directives this way:

diff -u etc/nova/api-paste.ini.orig etc/nova/api-paste.ini:
[...]
-/: meta
+/ = meta
[...]

This somehow worked, but unfortunately, what none of us saw is that the
Essex version of some Openstack packages, currently in Wheezy, does
contain some non-standard .ini files. As a consequence, upgrade crashes,
as per this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700620

More over, in Openstack Grizzly, which will be out soon, there's even
more URLs like above, so we have even more problems.

So, I'm at a point where the python code using configobj is not a viable
solution. I didn't like using it and patching nova api-paste.ini (I'm
not trying to put the blame on Roland, but it wasn't my idea), but now
I'm even more convince it's not the solution to our problem.

In Grizzly, there's a new python module called python-oslo.config. It's
very easy to use, and knows how to parse. The problem is that using a
python module means adding a Pre-Depends, which breaks the flow of
Debconf. Indeed, here's what it does currently:

# apt-get install openstack-proxy-node
1/ some downloads
2/ Absolutely all debconf questions
3/ Installation of all packages

But if I add a Pre-Depends: python-oslo.config, it will go like this:

# apt-get install openstack-proxy-node
1/ some downloads
2/ some debconf questions, for example mysqld password
3/ some install with dpkg, including python-oslo.config
4/ some more questions for the packages that have the Pre-Depends:
5/ some install with dpkg of the packages not finished to install

I don't want the 2nd version. Openstack operator all want to answer all
questions, then go to the coffee machine and rest 10 minutes during the
setup... ;)

So, I continue to think that everything should be done in shell script.
Not the way I wrote it the first time though. The goal is to have the
same implementation as this:
https://github.com/openstack/oslo-config/blob/master/oslo/config/iniparser.py

So, I wrote 2 versions: one in pure sh, and one using awk. Both are
using regular expression, so they are easy to fix if the config files
where to evolve in format (which is most probable seeing the history of
nova.conf: from flag file, to config file, to .ini format, to what it is
now ...).

I have attached both versions, and I would like my you, my fellow
Openstack Debian packaging team members, to comment on the
implementation. Which of the 2 seems the most maintainable, easy to
understand, and above all the most correct and bug free?

* Note that I'm aware that the awk version doesn't do all of what is
described before the function, and would need some more work. *

Would any of you use a totally different approach to the problem?

For the moment, I would lean toward the grep + sed version, as I see it
easier to read and understand, plus there's a unique parsing logic for
both get and set, which is nicer.

If you have suggestions on how to improve, or do it better in a totally
different way, please do explain how you would do it and share some code.

*** WARNING ***
With these functions, I'm breaking the current openstack-pkg-os API, so
I will have to edit all core projects (nova, cinder, keystone, glance,
quantum, ceilometer and heat). I do *expect some breakage* doing it,
since I'm also changing parameter order calling, and removing some
parameters which I think are bad. All this is error prone. So if you
need to get a working snapshot of Folsom from my FTP, please do it right
now, before I start uploading new versions. As for the Grizzly release
G3, it's currently broken anyway until all this work is done (so please
be patient and wait for me to fix cinder, quantum and nova in Grizzly,
who are failing at the postinst stage cur

Bug#675345: gnome-shell: current solution, downgrade acpid

[Jacob Barkdull]

As you'll see below, I am running 64-bit Debian 7.0 Wheezy (Testing). I
had been having this problem since I upgraded to Wheezy from the initial
Squeeze installation. I found that somewhere down the line I installed
from and/or upgraded to some software in the Unstable repository.

Notably, acpid.

I noticed in my logs that acpid disconnections always coincided with
gnome-shell's freezes. And after downgrading acpid to the version from
the Testing repository, I have yet to have gnome-shell freeze.


-- System Information:
Release 7.0 (wheezy) 64-bit
Kernel Linux 3.2.0-4-amd64
GNOME 3.4.2
Memory: 3.9 GiB
Processor: AMD Phenom(tm) II X6 1045T Processor × 6
Available disk space: 60.2 GiB
Foreign Architectures: i386
Shell: /bin/sh linked to /bin/dash


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

Bug#700296: RFS: libapache2-mod-geoip/1.2.8-1 [ITA] -- GeoIP support for apache2

[Prach Pongpanich]

Hi Arno,

On Sun, Mar 10, 2013 at 7:27 AM, Arno Töll  wrote:
> Hi Prach,
>
> as promised here is a review for  libapache2-mod-geoip.
>
>
> * Please consider upgrading to new style (dh >= 7) rules style. It makes
> life easier to you and is more forward oriented. That said, your rules
> file looks ok but you could ease life to all of us, including you.
> * While you're at it, remove the boilerplate copyright messages in
> debian/rules. They are not needed.

Done


> * Please consider using the copyright format formerly known as dep5 for
> debian/copyright:
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Updated.

> * Since you build a single binary package only

I agree with your suggestion, done

> * Your watch file does not work:

Upstream file download and the download link doesn't contain the
version number. (explain in debian/watch)


> * There is no policy version 3.9.3.4.

Done, I forget it.

> * Please consider using a VCS for your packaging

This repo is already in GitHub, I can''t access Alioth collab-maint.

> By the way: If you want, we can do another upload to experimental for
> Apache 2.2 with you as a maintainer set.

OK, Thank you very much.

Last updated :
  dget -x 
http://mentors.debian.net/debian/pool/main/liba/libapache2-mod-geoip/libapache2-mod-geoip_1.2.8-1.dsc

Changes since the last upload:

libapache2-mod-geoip (1.2.8-1) experimental; urgency=low

* New maintainer. (Closes: #670999)
  * New upstream release. (Closes: #666795)
- Support Apache 2.4
  * Adapt "sourceful transition towards Apache 2.4" patch from Arno Töll
- Replace apache2-threaded-dev with apache2-dev in Build-Depends
- Drop apache2.2-common in Depends
- Drop libapache2-mod-geoip.{install,postinst,postrm}
- Add debian/apache2 file
  * Update copyright file to version 1.0 format
  * Bump debhelper compat to level 9
- Convert debian/rules to debhelper-7 style
- Use dh $@ --with apache2 in d/rules
- Remove package prefix libapache2-mod-geoip.{docs,dirs,examples},
  it is useless when build a single binary package
  * Add get-orig-source in debian/rules and README.source
  * Update debian/watch and explain why doesn't work
  * Add Vcs-* fields in debian/control
  * Bump to Standards-Version 3.9.4, no changes needed


-- 
 Prach Pongpanich


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

Bug#699692: [Pkg-openssl-devel] Bug#699692: "Illegal instruction" when installing (creating certificate) with Wheezy's version 1.0.1c-4 of openssl on a system with Cyrix MII / IBM 6x86

[Kurt Roeckx]

On Mon, Mar 11, 2013 at 01:18:10AM +0100, Hans-Juergen Mauser wrote:
> Hello Kurt,
> 
> thanks for your support and for providing the packages! This made
> testing for me very easy - and I can tell you that it works
> perfectly.
> 
> Setting the environment variable was NOT a full workaround as there
> are processes like postgresql which use the libssl internally and
> from a non-interactive shell, which prevented postgresql even from
> starting as it calculates a key at each startup.
> 
> By the way, the internal capability flags have the following values:
> 
> OPENSSL_ia32cap_P[0] = 0x0080A535 (same as before)
> OPENSSL_ia32cap_P[1] = 0x0
> 
> Was the value of OPENSSL_ia32cap_P[1] a "random" value previously
> due to wrong assumptions when reading?

What I understand was that OPENSSL_ia32cap_P[1] comes from ecx,
and that was unititialised and not set by your processor.  And
they now ititialised it to 0.


Kurt


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

Bug#702021: debian wheezy not booting

[Piotrek]

Now there is same result as with acpi=off , a blinking line in left upper
part of screen and I am able to access console just like with acpi=off.

2013/3/10 Ben Hutchings 

> On Sun, 2013-03-10 at 20:48 +0100, Piotrek wrote:
> > So any fix to this I can except ? It's probably related to two
> > graphic cards installed in my computer (Intel hd graphics 4000
> > and nvidia ge force gt 630m) since I installed debian wheezy
> > sucesfully on my older PC with just one graphic card.,,
>
> You should be able to boot the current version with the extra kernel
> parameter 'nomodeset', but this will disable accelerated graphics.
>
> Once you have booted successfully, try upgrading
> linux-image-3.2.0-4-686-pae to version 3.2.39-2, which is currently in
> unstable.  This has later versions of all the DRM/KMS graphics drivers.
>
> Ben.
>
> --
> Ben Hutchings
> Every program is either trivial or else contains at least one bug
>

Bug#678353: openssl communication problems with 1.0.1e with AES-NI

[Benjamin Eikel]

Hello,

Am Samstag, 9. März 2013, 15:44:38 schrieb Kurt Roeckx:
> 
> They asked if you use any LD_* environment variables.

"printenv | grep LD" is empty.

> 
> "lsof -p $pid" of s_client process would also be nice.

See attached file "lsof-sclient.txt".

> 
> If you have a custom /etc/ssl/openssl.cnf, it would also be nice
> if you could send that.

I have the default one created by the Debian package.

> 
> /proc/cpuinfo would also be nice to have.

See attached file "proc-cpuinfo.txt".

> 
> If you know how to use gdb, they ask to print print variables and
> buffers in e_aes_cbc_hmac_sha1.c
> 
> If you want to debug it, debugging might not show you source
> code since you might have the source in a different path.
> The .deb files can be generated from the source above using:
> DEB_BUILD_MAINT_OPTIONS="hardening=-all" DEB_BUILD_OPTIONS="noopt nostrip"
> dpkg-buildpackage -B -uc
> 
> If you build it yourself, you can also just run the
> ./openssl.static binary instead of installing the .deb
> package.

With your instructions I was able to build a static version with debug 
symbols. Now, I get a more helpful backtrace at the point where s_client 
errors out (see attached file "backtrace.txt").

I have set a breakpoint at e_aes_cbc_hmac_sha1.c:450. The function is called 
multiple times before the error occurs and I do not know for what to look 
exactly. I have output the parameters of two calls (see attached file "gdb-
output.txt"). Without knowing for what to look exactly, I think it is very 
difficult to generate helpful information. Maybe somebody here or on the 
openssl-dev mailing list [1] suggests what might be helpful.

Thank you for your support!

Kind regards
Benjamin

[1] http://www.mail-archive.com/openssl-dev@openssl.org/msg32168.html
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
openssl.s 29986 benjamin  cwdDIR  254,0 4096 19791896 
/home/benjamin/src/openssl-1.0.1e
openssl.s 29986 benjamin  rtdDIR8,1 40962 /
openssl.s 29986 benjamin  txtREG  254,0  7723240 19797391 
/home/benjamin/src/openssl-1.0.1e/openssl.static
openssl.s 29986 benjamin  memREG8,184824  5767483 
/lib/x86_64-linux-gnu/libresolv-2.17.so
openssl.s 29986 benjamin  memREG8,122928  5767471 
/lib/x86_64-linux-gnu/libnss_dns-2.17.so
openssl.s 29986 benjamin  memREG8,152136  5767473 
/lib/x86_64-linux-gnu/libnss_files-2.17.so
openssl.s 29986 benjamin  memREG8,1  1741232  5767456 
/lib/x86_64-linux-gnu/libc-2.17.so
openssl.s 29986 benjamin  memREG8,192752  5767258 
/lib/x86_64-linux-gnu/libz.so.1.2.7
openssl.s 29986 benjamin  memREG8,114640  5767462 
/lib/x86_64-linux-gnu/libdl-2.17.so
openssl.s 29986 benjamin  memREG8,1   145128  5767443 
/lib/x86_64-linux-gnu/ld-2.17.so
openssl.s 29986 benjamin0u   CHR  136,5  0t08 
/dev/pts/5
openssl.s 29986 benjamin1u   CHR  136,5  0t08 
/dev/pts/5
openssl.s 29986 benjamin2u   CHR  136,5  0t08 
/dev/pts/5
openssl.s 29986 benjamin3u  unix 0x8807cc15ce00  0t073526 socket
openssl.s 29986 benjamin4u  unix 0x8807d3cf5b80  0t073527 socket
openssl.s 29986 benjamin5r  FIFO0,8  0t073528 pipe
openssl.s 29986 benjamin6w  FIFO0,8  0t073528 pipe
openssl.s 29986 benjamin7u  IPv4  73802  0t0  TCP 
pc-benjamin.cs.uni-paderborn.de:40354->mail.uni-paderborn.de:ssmtp (ESTABLISHED)
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
stepping: 9
microcode   : 0x17
cpu MHz : 1600.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr 
pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c 
rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 6800.88
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
stepping: 9
microcode   : 0x17
cpu MHz : 1600.00

debian-bugs-dist@lists.debian.org

[Adam Reichold]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

This will have to wait until after the release of 0.4.1 since we are
currently in a string freeze.

Could you also give a reference why you consider this standard? Maybe
an HIG or something like that?

Best regards, Adam.

Am 11.03.2013 01:29, schrieb David Fries:
> Package: qpdfview Version: 0.3.1-1 Severity: normal Tags: patch
> 
> Dear Maintainer,
> 
> Please apply the following patch to correct the expected exit key
> sequence to the standard sequence for program exit which uses the x
> not e for the hotkey mnemonic.
> 
>> From d05b57456ca48b7817e32bfa39a7eca0073decd4 Mon Sep 17 00:00:00
>> 2001
> From: David Fries  Date: Sun, 10 Mar 2013 19:04:51
> -0500 Subject: [PATCH] Fix non-standard mnemonic.
> 
> For exiting the mnemonic is Alt-F-X not Alt-F-E, updated. --- 
> sources/mainwindow.cpp  |2 +- translations/qpdfview_de.ts |
> 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/sources/mainwindow.cpp b/sources/mainwindow.cpp index
> 4dc809b..633ddb9 100644 --- a/sources/mainwindow.cpp +++
> b/sources/mainwindow.cpp @@ -1149,7 +1149,7 @@ void
> MainWindow::createActions()
> 
> // exit
> 
> -m_exitAction = new QAction(tr("&Exit"), this); +
> m_exitAction = new QAction(tr("E&xit"), this); 
> m_exitAction->setShortcut(QKeySequence::Quit); 
> m_exitAction->setIcon(QIcon::fromTheme("application-exit")); 
> m_exitAction->setIconVisibleInMenu(true); diff --git
> a/translations/qpdfview_de.ts b/translations/qpdfview_de.ts index
> e1c8505..0b1b461 100644 --- a/translations/qpdfview_de.ts +++
> b/translations/qpdfview_de.ts @@ -260,7 +260,7 @@  
>   line="1152"/> -&Exit +
> E&xit  type="unfinished">&Beenden  
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJRPZprAAoJEPSSjE3STU34k+QH/2Qac31YTZ7VkmFI/Lg4PUbN
1TmWFq7Mge3IKKaufG8p4FRpM8bWboWWCJXgEbHcIdVHnXxG4seSOM8aTqhcs30a
axSFXdAeS9JteCc9w9gwhjgFlnWNkYvm8CBSDFivVF6SO6mwN5C86Kv2vaAWzq94
qU0tj2663EvRxCR0zowdi1Q14DZjeSlbDm5S2v5LbJi6hH7yOhBve7HHB+WJ6arH
W9aVUv3GT6W8AHzlgN+DgwFvPY8avCe0X+pntN2LAkEiY89OJJC/ZzuYAqy+6+Jr
c11DxmTnOHOaZWwu9IJ/GbW9GbKzH8SG2P+j0c8qbFFAV4otL8Gk3dYNJ/FCsIU=
=yKWi
-END PGP SIGNATURE-


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

Bug#630617: Update

[Luca Pertile]

Hello
I'm sorry I forgot to post my solution. After some analysis with a new user
I found that klipper is inserted by default into a inner panel that was
disappeared from KPanel. When I inserted that inner panel, klipper
appeared. This action solves me also the printer_applet disappearing.

I hope this can usefull to somebody.

-- 
Luca Pertile
Venezia
Italy

Bug#702741: boinc-dbg: debian/control Suggests: libssl0.9.8-dbg - Change to libssl1.0.0-dbg

[Gianfranco Costamagna]

I honestly don't know how to deal with this problem, the line in control file 
is this one


Suggests: libcurl3-dbg, libssl0.9.8-dbg, libwxgtk2.8-dbg


should I change 
libssl0.9.8-dbg
to
libssl1.0.0-dbg | libssl0.9.8-dbg

Or maybe just updating to 1.0.0 with not so many problems? I'm pretty sure no 
backports will be issued for debian 6.0 anymore


Gianfranco



>
> Da: mdt 
>A: Debian Bug Tracking System  
>Inviato: Domenica 10 Marzo 2013 23:32
>Oggetto: Bug#702741: boinc-dbg: debian/control Suggests: libssl0.9.8-dbg - 
>Change to libssl1.0.0-dbg
> 
>Package: boinc-dbg
>Version: 7.0.27+dfsg-5
>Severity: important
>
>user@debian:~$ sudo apt-get install libssl0.9.8-dbg
>Reading package lists... Done
>Building dependency tree      
>Reading state information... Done
>Package libssl0.9.8-dbg is not available, but is referred to by another 
>package.
>This may mean that the package is missing, has been obsoleted, or
>is only available from another source
>
>E: Package 'libssl0.9.8-dbg' has no installation candidate
>
>-- System Information:
>Debian Release: 7.0
>  APT prefers testing-updates
>  APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), 
>(500, 'testing')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
>Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>
>Versions of packages boinc-dbg depends on:
>ii  boinc-client   7.0.27+dfsg-5
>ii  boinc-manager  7.0.27+dfsg-5
>
>boinc-dbg recommends no packages.
>
>Versions of packages boinc-dbg suggests:
>ii  libcurl3-dbg     7.26.0-1+wheezy1
>pn  libssl0.9.8-dbg  
>ii  libwxgtk2.8-dbg  2.8.12.1-12
>
>-- no debconf information
>
>-- 
>pkg-boinc-devel mailing list
>pkg-boinc-de...@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel
>
>
>

Bug#702227: Permission of the backend too strict for a backend chain (beh, jasmine)

[Marco Gaiarin]

> > Ok for 'jasmine', but 'beh' is a rather ''standard'' backend, that i
> > use extensively for some ''broken'' printers or print servers... very
> > useful if you don't want to be called on saturday morning at home...
> Is 'beh' not working correctly when used as printer backend?

?! Sorry, i've really not understood your question...

'beh' (in package foomatic-filters) it is a simple perl script that
change the behaviour of the cups queue management: some printers
(mostly USB, but also some networked one) are broken, reply to cups
backend in some strange way and cups (correctly) disable the queue (put
the printer queue in pause).
'beh' simply ignore backend error, do some retry, and then discard the
print.

It is some sort of ''last resort'' for  some situation, but because
restarting a printer queue is a privileged operation, it is very handy
in a 'non-personal computing' setup.


> Quoting Till on that one:
> > access (files, network resources). Opening up the permissions so that "lp"
> > can run the backends makes the backends stop working. What alwyas works
> > would be setting the wrapper backends 750 root.root, but this can lead to
> > some non-root backends being run as root.

also 'jasmine' backend is a perl script, but to make it run i do:

cd /usr/lib/cups/backend-available
chown .lp dnssd http ipp lpd serial usb
chmod 751 dnssd http ipp lpd
chmod 554 serial usb

and all the printer, eg:

neuromante:~# grep jasmine /etc/cups/printers.conf
DeviceURI jasmine:ipp://arcdisanmarc/ipp
DeviceURI jasmine:ipp://arcoiris/ipp
DeviceURI jasmine:socket://i3pps-1:9102
DeviceURI jasmine:ipp://elladan/printer
DeviceURI jasmine:ipp://elrohir/printer
DeviceURI jasmine:socket://hp4000
DeviceURI jasmine:socket://hpljp2055-1
DeviceURI jasmine:socket://hpljp2055-2
DeviceURI jasmine:socket://hpljp3015-1
DeviceURI jasmine:ipp://kmmc4650dn/ipp
DeviceURI jasmine:socket://i3pps-1:9103
DeviceURI jasmine:socket://10.5.1.235
DeviceURI jasmine:ipp://sscx4833fd-1/printer

works like a charme. My currently permission setup is:

neuromante:~# ls -la /usr/lib/cups/backend
totale 400
drwxr-xr-x  2 root root  4096  3 mar 20.23 .
drwxr-xr-x 10 root root  4096 22 dic  2009 ..
-rwxr-xr-x  1 root root  7250  6 mar  2012 beh
-rwx--  1 root root 22320 18 giu  2010 cups-pdf
-rwxr-x--x  2 root lp   18352 12 gen 18.11 dnssd
-rwxr-xr-x  1 root root 16968  3 dic  2011 hp
-rwxr-xr-x  1 root root  8393  3 dic  2011 hpfax
-rwxr-x--x  3 root lp   48160 12 gen 18.11 http
-rwxr-x--x  3 root lp   48160 12 gen 18.11 ipp
-rwxr-x---  1 root lp   20395  5 nov 12.01 jasmine
-rwxr-x--x  2 root lp   44056 12 gen 18.11 lpd
-rwxr-xr-x  1 root root  4988  2 nov 19.14 mailto
-r-xr-xr-x  2 root root 30728 12 gen 18.11 parallel
lrwxrwxrwx  1 root root21  5 feb 20.28 smb -> ../../../bin/smbspool
-r-xr-xr-x  2 root root 26544 12 gen 18.11 snmp
-r-xr-xr-x  2 root root 34824 12 gen 18.11 socket
-r-xr-xr--  2 root lp   43016 12 gen 18.11 usb

'jasmine' cointain the password for the mysql db, so it is 750.


> So, as I would rather not try to fix something not broken for most standard 
> Debian uses, and as I haven't been convinced that fixing that is an 
> improvement over the current situation, I'm hereby tagging this bug as 
> wontfix.

Probably i'm missing something. But i'm only trying to understand...


PS: there's some sort of doc, manual, HOWTO, REDAME... that explain
 backend permission setup?


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

Bug#702741: boinc-dbg: debian/control Suggests: libssl0.9.8-dbg - Change to libssl1.0.0-dbg

[Christian Beer]

libssl0.9.8-dbg is not in testing anymore. So for any future boinc-dbg
release in testing you have to suggest libssl1.0.0-dbg only. If testing
gets stable there will be no libssl0.9.8-dbg there either. You should
also apply this to sid and experimental although libssl0.9.8-dbg is
still available there.

Regards
Christian

Am 11.03.2013 09:50, schrieb Gianfranco Costamagna:
> I honestly don't know how to deal with this problem, the line in
> control file is this one
>
> Suggests: libcurl3-dbg, libssl0.9.8-dbg, libwxgtk2.8-dbg
>
> should I change
> libssl0.9.8-dbg
> to
> libssl1.0.0-dbg | libssl0.9.8-dbg
>
> Or maybe just updating to 1.0.0 with not so many problems? I'm pretty
> sure no backports will be issued for debian 6.0 anymore
>
> Gianfranco
>
> 
> *Da:* mdt 
> *A:* Debian Bug Tracking System 
> *Inviato:* Domenica 10 Marzo 2013 23:32
> *Oggetto:* Bug#702741: boinc-dbg: debian/control Suggests:
> libssl0.9.8-dbg - Change to libssl1.0.0-dbg
>
> Package: boinc-dbg
> Version: 7.0.27+dfsg-5
> Severity: important
>
> user@debian:~$ sudo apt-get install libssl0.9.8-dbg
> Reading package lists... Done
> Building dependency tree 
> Reading state information... Done
> Package libssl0.9.8-dbg is not available, but is referred to by
> another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> E: Package 'libssl0.9.8-dbg' has no installation candidate
>
> -- System Information:
> Debian Release: 7.0
>   APT prefers testing-updates
>   APT policy: (500, 'testing-updates'), (500,
> 'testing-proposed-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages boinc-dbg depends on:
> ii  boinc-client  7.0.27+dfsg-5
> ii  boinc-manager  7.0.27+dfsg-5
>
> boinc-dbg recommends no packages.
>
> Versions of packages boinc-dbg suggests:
> ii  libcurl3-dbg7.26.0-1+wheezy1
> pn  libssl0.9.8-dbg  
> ii  libwxgtk2.8-dbg  2.8.12.1-12
>
> -- no debconf information
>
> -- 
> pkg-boinc-devel mailing list
> pkg-boinc-de...@lists.alioth.debian.org
> 
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel
>
>
>
>

debian-bugs-dist@lists.debian.org

[Adam Reichold]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello again,

I found a reference to the standard mnemonic and will change it
upstream after 0.4.1 is released.

But I don't think this patch should be applied to any version of the
Debian package except 0.3.1 since it will break the other translations.

Best regards, Adam.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJRPaCcAAoJEPSSjE3STU349rQH/i6kfVt21DkYa2NxEMrvJIT+
T5OKYvzrWf/Bt3Ma7FzrbWCNQgVh1dyZj1IozwYq9TbiWTICZsiIzCZ0P1fZ9JSt
xNXMlzhYdhoJJ9ZzxKD4PI7NnI+QW4cd6hDhKgrfAHCCggpzKWFPp2mMYlcDlRA8
G7bLT76JPVLQoVlHug6+XVF75XnuIC/dZKLm/GTs7sBVC+U3FlXUBnbCJurvNhCu
FnMnhHm9n4Cm28deztMCP1BnWcQkNmklb7Lu3jD1xDGi6tBRpuRQJJXqcU1J9zqd
oc6L7ITxaAb6mLYi3CLIohqlXPMxIE7STkAChVdJvXM005ISJJd4sHjFygg3LLY=
=8nux
-END PGP SIGNATURE-


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

Bug#702768: libgtk-3-0: Segfault in _gtk_bubble_window_popdown

[Fabian Greffrath]

Package: libgtk-3-0
Version: 3.7.12-1
Severity: normal

Hi,

recently, gedit crashes due to a segfault in _gtk_bubble_window_popdown in
libgtk-3-0:

(gdb) bt
#0  _gtk_bubble_window_popdown (window=0x0)
at /build/buildd-
gtk+3.0_3.7.12-1-amd64-L0Jcgp/gtk+3.0-3.7.12/./gtk/gtkbubblewindow.c:1135
#1  0x77207f4a in text_window_scroll (dx=0, dy=-522,
win=)
at /build/buildd-
gtk+3.0_3.7.12-1-amd64-L0Jcgp/gtk+3.0-3.7.12/./gtk/gtktextview.c:9104
#2  0x7720b43c in gtk_text_view_value_changed (
adjustment=, text_view=0x8b0300)
at /build/buildd-
gtk+3.0_3.7.12-1-amd64-L0Jcgp/gtk+3.0-3.7.12/./gtk/gtktextview.c:8055

Steps to reproduce: Open a rather long text file in gedit, e.g. gedit
/usr/share/common-licenses/GPL, and press Pg-Down.

$ dpkg -l gedit\* | awk '/^ii/{print $2" " $3}'
gedit 3.4.2-1
gedit-common 3.4.2-1
gedit-plugins 3.4.0-1

BTW, what's wrong in Gnome world, recently? I have never seen that much
segfaults in core applications before...

 - Fabian



-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (901, 'testing'), (501, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libgtk-3-0 depends on:
ii  libatk-bridge2.0-0  2.7.91-1
ii  libatk1.0-0 2.7.91-1
ii  libc6   2.17-0experimental2
ii  libcairo-gobject2   1.12.14-1
ii  libcairo2   1.12.14-1
ii  libcolord1  0.1.21-1
ii  libcomerr2  1.42.5-1
ii  libcups21.5.3-2.15
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgcrypt11 1.5.0-5
ii  libgdk-pixbuf2.0-0  2.27.2-1
ii  libglib2.0-02.35.8-1
ii  libgnutls26 2.12.20-4
ii  libgssapi-krb5-21.10.1+dfsg-4
ii  libgtk-3-common 3.7.12-1
ii  libk5crypto31.10.1+dfsg-4
ii  libkrb5-3   1.10.1+dfsg-4
ii  libpango1.0-0   1.32.5-1
ii  libx11-62:1.5.0-1
ii  libxcomposite1  1:0.4.3-2
ii  libxcursor1 1:1.1.13-1
ii  libxdamage1 1:1.1.3-2
ii  libxext62:1.3.1-2
ii  libxfixes3  1:5.0-4
ii  libxi6  2:1.6.1-1
ii  libxinerama12:1.1.2-1
ii  libxrandr2  2:1.3.2-2
ii  multiarch-support   2.13-38
ii  shared-mime-info1.0-1+b1
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages libgtk-3-0 recommends:
ii  hicolor-icon-theme  0.12-1
ii  libgtk-3-bin3.7.12-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.12.3-4
ii  librsvg2-common  2.36.1-1


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

Bug#696757: ecl and SIGNALS

[Petr Salinger]

 As suggested by Michael Banck on IRC I've been looking at Signals used
by both parts to see if they e.g. battle over SIGUSR?. However libgc
seems to use 32+{5,6} as signals on x86 FREEBSD __GLIBC__ at
least. Petr, Steven: any idea why this is? Are these signals fine for
kfreebsd glibc (signal.h says only 32,33 are reserved). ecl seems to use
SIGRTMIN+2 internally which should not be a problem. I failed to see so
far what signals are used by libgc on linux


glibc uses 32 and 33 normally and 34 for debuging of pthread library.
libgc have to use separate signals, 32+{5,6} satisfies this.

The SIGRTMIN and __SIGRTMIN are different, they used to be 68 and 65.

Petr


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

Bug#702769: FTBFS: bup.git.GitError: no such commit '75cd2b98c52d29ba5d510b37d7c9adb01553bd1f'

[Michael Tautschnig]

Package: bup
Version: 0.25~git2011.11.04-5
Severity: serious
Justification: FTBFS
Usertags: goto-cc

In an attempt to rebuild the package in a clean chroot, the test suite of the
package failed to complete. This is reproducible on different systems, thus
appears to be an error in the package. The key excerpt of the output is as
below, the full build log is attached.

Best,
Michael

[...]
! t/test.sh:174  ls -lR ok
75cd2b98c52d29ba5d510b37d7c9adb01553bd1f
! t/test.sh:175  bup split -r 
:/home/michael/Desktop/debian/goto-cc-debugging/bup-0.25~git2011.11.04/buptest.tmp
 -c --fanout 3 --max-pack-objects 3 -n lslr ok
Traceback (most recent call last):
  File 
"/home/michael/Desktop/debian/goto-cc-debugging/bup-0.25~git2011.11.04/cmd/bup-ls",
 line 11, in 
ret = ls.do_ls(sys.argv[1:], top, default='/', spec_prefix='bup ')
  File 
"/home/michael/Desktop/debian/goto-cc-debugging/bup-0.25~git2011.11.04/lib/bup/ls.py",
 line 48, in do_ls
for sub in n:
  File 
"/home/michael/Desktop/debian/goto-cc-debugging/bup-0.25~git2011.11.04/lib/bup/vfs.py",
 line 179, in __iter__
return iter(self.subs())
  File 
"/home/michael/Desktop/debian/goto-cc-debugging/bup-0.25~git2011.11.04/lib/bup/vfs.py",
 line 196, in subs
self._mksubs()
  File 
"/home/michael/Desktop/debian/goto-cc-debugging/bup-0.25~git2011.11.04/lib/bup/vfs.py",
 line 531, in _mksubs
date = git.rev_get_date(sha.encode('hex'))
  File 
"/home/michael/Desktop/debian/goto-cc-debugging/bup-0.25~git2011.11.04/lib/bup/git.py",
 line 759, in rev_get_date
raise GitError, 'no such commit %r' % ref
bup.git.GitError: no such commit '75cd2b98c52d29ba5d510b37d7c9adb01553bd1f'
! t/test.sh:176  bup ls FAILED
[...]



bup_0.25~git2011.11.04-5.log.gz
Description: application/gunzip


pgpf5MiHTptEc.pgp
Description: PGP signature

Bug#702764: libdspam7-drv-pgsql: fails to install: ERROR: language "plpgsql" already exists

[Thomas Preud'homme]

Le lundi 11 mars 2013 07:37:48, vous avez écrit :
> Package: libdspam7-drv-pgsql
> Version: 3.10.2+dfsg-7
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.

Thanks for the bug report Andreas. Fortunetely, this is already known and 
there is even an unblock request for that: #702293. Right now I'm just waiting 
for a confirmation for a new upload.

Best regards,

Thomas


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

Bug#702770: linux-image-3.2.0-4-amd64: non-fatal oops while dd'ing from USB to USB

[Francesco Potortì]

Package: src:linux
Version: 3.2.35-2
Severity: normal

Dear Maintainer,

this Oops happened while I was dumping a 500GB USB disk image to a 2TB
USB file system using dd.  I suspect the image contains a bad sector, as
I had got SMART telling me that there were uncorrectable errors (but now
it tells me nothing about that any more).  Anyway, after dumping about
280GB dd stopped and cannot be killed, a rm process on the USB partition
cannot be killed either, and the USB partition cannot be unmounted
because it is busy, even if lsof reports no process using it.


-- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 
root=UUID=4ee42fef-c2d5-406d-8aec-6832a5eb2e93 ro gfxpayload=1024x768x8,1024x768

** Tainted: D (128)
 * Kernel has oopsed before.

** Kernel log:
[15608.064863] Oops: 0002 [#1] SMP 
[15608.064939] CPU 2 
[15608.064981] Modules linked in: ext4 jbd2 ext2 cpufreq_userspace 
cpufreq_stats ppdev cpufreq_powersave cpufreq_conservative lp bnep rfcomm 
binfmt_misc fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc dm_crypt 
k8temp hwmon_vid tcp_diag inet_diag firewire_sbp2 firewire_core crc_itu_t 
psmouse joydev btusb parport_pc parport asus_atk0110 bluetooth rfkill crc16 
pcmcia radeon ttm drm_kms_helper drm yenta_socket pcmcia_rsrc pcmcia_core 
power_supply i2c_algo_bit button wmi evdev sp5100_tco snd_hda_codec_via 
powernow_k8 mperf processor snd_hda_intel snd_hda_codec snd_hwdep thermal_sys 
i2c_piix4 pcspkr snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_seq_midi 
snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore 
i2c_core shpchp edac_mce_amd edac_core k10temp ext3 mbcache jbd usbhid hid 
raid1 md_mod dm_mirror dm_region_hash dm_log dm_mod usb_storage sg sr_mod 
sd_mod cdrom crc_t10dif ata_generic pata_atiixp ohci_hcd ahci libahci xhci_hcd 
libata r8169 mii ehci_hcd scsi_mod usbcore usb
[15608.067286] 
[15608.067322] Pid: 8647, comm: dd Not tainted 3.2.0-4-amd64 #1 Debian 3.2.35-2 
System manufacturer System Product Name/M4A88T-M/USB3
[15608.067564] RIP: 0010:[]  [] 
ext2_get_blocks+0x4ad/0x6da [ext2]
[15608.067775] RSP: 0018:8800a89a39b8  EFLAGS: 00010246
[15608.067881] RAX:  RBX: 8802aedc99b0 RCX: 0034
[15608.068020] RDX:  RSI: ea00069e7ea8 RDI: ea00069e7ea8
[15608.068160] RBP:  R08:  R09: 46c2
[15608.068231] R10: 3bbd R11: 3bbd R12: 880062f46200
[15608.068231] R13: 8800a89a3a40 R14: 8800a89a3a40 R15: 0004
[15608.068231] FS:  7f943d8e3700() GS:88031fc8() 
knlGS:ef0fbb70
[15608.068231] CS:  0010 DS:  ES:  CR0: 8005003b
[15608.068231] CR2:  CR3: bc2de000 CR4: 06e0
[15608.068231] DR0:  DR1:  DR2: 
[15608.068231] DR3:  DR6: 0ff0 DR7: 0400
[15608.068231] Process dd (pid: 8647, threadinfo 8800a89a2000, task 
88030f9a89f0)
[15608.068231] Stack:
[15608.068231]   8802 0baa16b0 
0001
[15608.068231]  8802aedc9990 0001 0001 
0430b80c
[15608.068231]  1000 8800a89a3a98  
8802aedc9938
[15608.068231] Call Trace:
[15608.068231]  [] ? kmem_cache_alloc+0x86/0xea
[15608.068231]  [] ? ext2_get_block+0x24/0x3d [ext2]
[15608.068231]  [] ? __block_write_begin+0x139/0x2a9
[15608.068231]  [] ? ext2_get_blocks+0x6da/0x6da [ext2]
[15608.068231]  [] ? grab_cache_page_write_begin+0x68/0xae
[15608.068231]  [] ? block_write_begin+0x44/0x72
[15608.068231]  [] ? ext2_get_blocks+0x6da/0x6da [ext2]
[15608.068231]  [] ? ext2_write_begin+0x2a/0x4b [ext2]
[15608.068231]  [] ? generic_file_buffered_write+0x10f/0x259
[15608.068231]  [] ? __generic_file_aio_write+0x248/0x278
[15608.068231]  [] ? generic_file_aio_read+0x570/0x5cf
[15608.068231]  [] ? should_resched+0x5/0x23
[15608.068231]  [] ? generic_file_aio_write+0x5d/0xb5
[15608.068231]  [] ? do_sync_write+0xb4/0xec
[15608.068231]  [] ? fsnotify+0x1f9/0x20c
[15608.068231]  [] ? dput+0x27/0xee
[15608.068231]  [] ? security_file_permission+0x16/0x2d
[15608.068231]  [] ? vfs_write+0xa2/0xe9
[15608.068231]  [] ? sys_write+0x45/0x6b
[15608.068231]  [] ? system_call_fastpath+0x16/0x1b
[15608.068231] Code: 43 28 48 8b b4 ec b8 00 00 00 48 8b 50 18 48 8b b8 20 01 
00 00 e8 9e 64 ba e0 49 89 46 28 48 89 04 24 e8 87 50 dd e0 48 8b 14 24  0f 
ba 2a 02 19 c0 85 c0 74 10 48 89 d7 48 89 14 24 e8 0e 5d 
[15608.068231] RIP  [] ext2_get_blocks+0x4ad/0x6da [ext2]
[15608.068231]  RSP 
[15608.068231] CR2: 
[15608.106582] ---[ end trace 8688ecdf8986dc79 ]---
[15667.154894] attempt to access beyond end of device
[15667.154908] sde1: rw=1, want=1565565840

Bug#702771: unblock: sqlobject/0.12.4-2.2

[Neil Muller]

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

Please unblock package sqlobject

sqlobject 0.12.4-2.2 fixes #695233, which prevents it from working
properly with the default postgres version in wheezy. Since sqlobject
is a database ORM, this is a reasonably serious regression from
squeeze, so it would be useful to have it fixed.

debdiff sqlobject_0.12.4-2.1.dsc sqlobject_0.12.4-2.2.dsc

diff -Nru sqlobject-0.12.4/debian/changelog sqlobject-0.12.4/debian/changelog
--- sqlobject-0.12.4/debian/changelog   2012-01-14 16:12:15.0 +0200
+++ sqlobject-0.12.4/debian/changelog   2013-02-11 13:03:52.0 +0200
@@ -1,3 +1,13 @@
+sqlobject (0.12.4-2.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix "SQLObject doesn't escape strings correctly for postgresql 9.1":
+new patch postgres_escape_0.12.4 backported from upstream (1.2.0).
+(Closes: #695233)
+
+ -- Neil Muller   Mon, 11 Feb 2013 13:03:04 +0200
+
+
 sqlobject (0.12.4-2.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru sqlobject-0.12.4/debian/patches/postgres_escape_0.12.4 
sqlobject-0.12.4/debian/patches/postgres_escape_0.12.4
--- sqlobject-0.12.4/debian/patches/postgres_escape_0.12.4  1970-01-01 
02:00:00.0 +0200
+++ sqlobject-0.12.4/debian/patches/postgres_escape_0.12.4  2013-02-11 
13:02:03.0 +0200
@@ -0,0 +1,169 @@
+Description: Postgresql 9.1 changed the default value of 
standard_conforming_strings to on. SQLObject only added support for the E'' 
escape syntax in version 1.2.0 
+Origin:  upstream, Version 1.2.0
+Bug-Debian:  http://bugs.debian.org/695233
+Author:  phd
+Last-Update: 2013-02-11
+
+--- a/sqlobject/converters.py  (revision 4567)
 b/sqlobject/converters.py  (working copy)
+@@ -1,6 +1,11 @@
++from array import array
++import datetime
++from decimal import Decimal
+ import sys
+-from array import array
++import time
++from types import ClassType, InstanceType, NoneType
+ 
++
+ try:
+ import mx.DateTime.ISO
+ origISOStr = mx.DateTime.ISO.strGMT
+@@ -15,17 +20,12 @@
+ DateTimeType = None
+ DateTimeDeltaType = None
+ 
+-import time
+-import datetime
+-
+ try:
+ import Sybase
+ NumericType=Sybase.NumericType
+ except ImportError:
+ NumericType = None
+ 
+-from decimal import Decimal
+-from types import ClassType, InstanceType, NoneType
+ 
+ 
+ ## Quoting
+@@ -90,6 +90,8 @@
+ value = value.replace("'", "''")
+ else:
+ assert 0, "Database %s unknown" % db
++if db in ('postgres', 'rdbhost') and ('\\' in value):
++return "E'%s'" % value
+ return "'%s'" % value
+ 
+ registerConverter(str, StringLikeConverter)
+@@ -198,3 +200,17 @@
+ return converter(obj, db)
+ else:
+ return reprFunc(db)
++
++
++def quote_str(s, db):
++if db in ('postgres', 'rdbhost') and ('\\' in s):
++return "E'%s'" % s
++return "'%s'" % s
++
++def unquote_str(s):
++if s.upper().startswith("E'") and s.endswith("'"):
++return s[2:-1]
++elif s.startswith("'") and s.endswith("'"):
++return s[1:-1]
++else:
++return s
+Index: sqlobject/sqlbuilder.py
+===
+--- a/sqlobject/sqlbuilder.py  (revision 4567)
 b/sqlobject/sqlbuilder.py  (working copy)
+@@ -70,7 +70,7 @@
+ import weakref
+ 
+ import classregistry
+-from converters import sqlrepr, registerConverter
++from converters import registerConverter, sqlrepr, quote_str, unquote_str
+ 
+ 
+ class VersionError(Exception):
+@@ -896,18 +896,18 @@
+ if isinstance(s, SQLExpression):
+ values = []
+ if self.prefix:
+-values.append("'%s'" % self.prefix)
++values.append(quote_str(self.prefix, db))
+ s = _quote_like_special(sqlrepr(s, db), db)
+ values.append(s)
+ if self.postfix:
+-values.append("'%s'" % self.postfix)
++values.append(quote_str(self.postfix, db))
+ if db == "mysql":
+ return "CONCAT(%s)" % ", ".join(values)
+ else:
+ return " || ".join(values)
+ elif isinstance(s, basestring):
+-s = _quote_like_special(sqlrepr(s, db)[1:-1], db)
+-return "'%s%s%s'" % (self.prefix, s, self.postfix)
++s = _quote_like_special(unquote_str(sqlrepr(s, db)), db)
++return quote_str("%s%s%s" % (self.prefix, s, self.postfix), db)
+ else:
+raise TypeError, "expected str, unicode or SQLExpression, got %s" 
% type(s)
+ 
+Index: sqlobject/tests/test_converters.py
+===
+--- a/sqlobject/tests/test_converters.py   (revision 4567)
 b/sqlobject/tests/test_converters.py   (working copy)
+@@ -1,9 +1,11 @@
+ import sys
+ from sqlobject.sqlbuilder impo

Bug#702772: Update configure to properly define global_symbol_pipe

[Michael Tautschnig]

Package: siproxd
Version: 0.8.1-3
Usertags: goto-cc

The present configure script yields code with conflicting declarations of int
and char type while determining the value of global_symbol_pipe on all
architectures other than ia64. This is caused by
lt_cv_sys_global_symbol_to_cdecl being redefined on ia64 only, but not on other
architectures. Thus nm_test_var has conflicting types int and char while linking
conftest.

This problem has been fixed in libtool on Tue Sep 14 22:10:37 2004. It seems the
aclocal.m4 ships an ancient version of libtool.m4.

Best,
Michael



pgppt0PcSwzn0.pgp
Description: PGP signature

Bug#698245: unblock: moodle/2.2.3.dfsg-2.6~wheezy2

[Didier 'OdyX' Raboud]

Hi Thomas, hi Release Team, hi Moodle maintainers.

Le jeudi, 28 février 2013 18.00:19, Didier 'OdyX' Raboud a écrit :
> So please just re-issue a correctly-versionned Debian package and I'll
> upload it to unstable (then we'll take a look at the package for
> testing-proposed- updates).

Given that:

a) we fail at releasing Moodle updates to unstable in a timely manner (and I
   have my share of the fault here);
b) we consequently fail at releasing Moodle security updates to wheezy in a
   timely manner (this unblock is opened for almost two months);
c) Moodle 2.2 is already not supported anymore by Moodle HQ for anything (not
   even security), according to [0];
   Furthermore on that point, as far as I can see, there is noone taking
   responsibility to handle Moodle 2.2 security on the long term (Moodle in
   Wheezy will need to be security-handled for roughly three years, yet it is
   _already_ not supported).
d) there is (in my opinion) not enough people behind the maintenance of
   Moodle-in-Debian: Thomas is a good DM, but he's mostly alone, and I'm not
   willing to get more involved.

So as much as I find that unfortunate, I think that the best solution for all 
of Moodle, Moodle-in-Debian and Debian, is to not ship Moodle 2.2 in Wheezy.

Thomasz, as you're the actual de-facto maintainer, please voice your opinion 
as I have voiced mine: the decision is in the hands of the Release Team I 
guess.

Cheers

OdyX


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

Bug#702773: ITP: libcidr0 -- IPv4 and IPv6 address manipulation library

[Daniil Baturin]

Subject: ITP: libcidr0 -- IPv4 and IPv6 address manipulation library
Package: wnpp
Owner: Daniil Baturin 
Severity: wishlist

*** Please type your report below this line ***

* Package name: libcidr0
  Version : 1.2
  Upstream Author : Matthew D. Fuller 
* URL : http://www.over-yonder.net/~fullermd/projects/libcidr
* License : BSD
  Programming Lang: C
  Description : IPv4 and IPv6 address manipulation library

This library supports IPv4 and IPv6 address parsing and manipulation. 
Can parse various human-readable formats including both decimal mask and 
prefix length, expanded and collapsed IPv6 addresses and more.
From parsed addresses one can determine if it's IPv4 or IPv6 address, 
compare subnets, calculate broadcast, min/max host etc.



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

Bug#698245: unblock: moodle/2.2.3.dfsg-2.6~wheezy2

[Didier 'OdyX' Raboud]

Sorry, missed my footnote:

Le lundi, 11 mars 2013 10.49:49, Didier 'OdyX' Raboud a écrit :
> c) Moodle 2.2 is already not supported anymore by Moodle HQ for anything
> (not even security), according to [0];

[0] http://docs.moodle.org/dev/Releases#Moodle_2.2

That allows me to correct what I wrote earlier: Moodle 2.2 is not "yet" out-
of-security support, but it will undoubtedly be from June 2013 on, which is 
still very early in the Wheezy-as-stable lifecycle.

Cheers,

OdyX


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

Bug#702766: epdfview: Often don't show pages

[Yves-Alexis Perez]

On lun., 2013-03-11 at 11:27 +0400, Dmitrii Kashin wrote:
> Here I put file 02.pdf (sorry for non-english language). Just load it
> and open page 247. 

I love having 40 tinys parts of pdf flooding my inbox, thanks. Please
provide a sane pdf file exhibiting your behavior. Does the file open
file under evince?

Regards,
-- 
Yves-Alexis


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

Bug#702774: installation-reports: Error message during installation: An attempt to configure apt to install additional packages from CD failed.

[Ralf Jung]

Package: installation-reports
Severity: normal
Tags: d-i

Dear Maintainer,

-- Package-specific info:

Boot method: CD
Image version: 
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/wheezy_di_rc1/amd64/iso-cd/firmware-wheezy-DI-rc1-amd64-netinst.iso
 (2013-02-14)
Date: 2013-03-11

Machine: Assembled myself around 6 years ago: Intel Core2 E6420 on a Gigabyte 
GA-965P-DS3 with 2GB RAM and a GeForce 8500
Partitions: fdisk -l says:
   Device Boot  Start End  Blocks   Id  System
/dev/sda1   *2048   586133503   293065728   83  Linux(used as /)
/dev/sda2   586133504   595898367 4882432   82  Linux swap / Solaris
/dev/sda3   595898368   976771071   190436352   83  Linux(used as /home)


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:[E]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Installation was mostly working as expected, the only exception is an error 
message which
was shown after the installation of the base system finished:

An attempt to configure apt to install additional packages from CD failed.

I told it to go on anyway and could not find any issue that might be caused by 
this error.
But of course, the installation should be error-free.

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="7.0 (wheezy) - installer build 20130211"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux r-desktop 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82P965/G965 Memory 
Controller Hub [8086:29a0] (rev 02)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:5000]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation 82P965/G965 PCI 
Express Root Port [8086:29a1] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #4 [8086:2834] (rev 02)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:5004]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1a.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #5 [8086:2835] (rev 02)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:5004]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1a.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB2 EHCI Controller #2 [8086:283a] (rev 02)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:5006]
lspci -knn: Kernel driver in use: ehci_hcd
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) 
HD Audio Controller [8086:284b] (rev 02)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:a002]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) 
PCI Express Port 1 [8086:283f] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) 
PCI Express Port 4 [8086:2845] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) 
PCI Express Port 5 [8086:2847] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #1 [8086:2830] (rev 02)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:5004]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #2 [8086:2831] (rev 02)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:5004]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1d.2 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #3 [8086:2832] (rev 02)
lspci -knn: Subsystem: Giga-byte Technology Device [1458:5004]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1d.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB2 EHCI Controller #1 [8086:2836] (rev 02)
lspci -knn: Subsystem:

Bug#702768: libgtk-3-0: Segfault in _gtk_bubble_window_popdown

[Emilio Pozuelo Monfort]

forwarded 702768 https://bugzilla.gnome.org/show_bug.cgi?id=695304
tags 702768 pending
thanks

Hi,

On 03/11/2013 10:36 AM, Fabian Greffrath wrote:

recently, gedit crashes due to a segfault in _gtk_bubble_window_popdown in
libgtk-3-0:

(gdb) bt
#0  _gtk_bubble_window_popdown (window=0x0)
 at /build/buildd-
gtk+3.0_3.7.12-1-amd64-L0Jcgp/gtk+3.0-3.7.12/./gtk/gtkbubblewindow.c:1135


This is https://bugzilla.gnome.org/show_bug.cgi?id=695304, which is fixed 
upstream. It'll be in the next upload.



BTW, what's wrong in Gnome world, recently? I have never seen that much
segfaults in core applications before...


G3.4/3.6/3.7 do not like each other all that much... We need to add some Breaks 
so that people don't install bad combinations of packages.


Regards,
Emilio


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

Bug#698245: unblock: moodle/2.2.3.dfsg-2.6~wheezy2

[Tomasz Muras]

On 03/11/2013 10:49 AM, Didier 'OdyX' Raboud wrote:

a) we fail at releasing Moodle updates to unstable in a timely manner (and I
have my share of the fault here);
b) we consequently fail at releasing Moodle security updates to wheezy in a
timely manner (this unblock is opened for almost two months);
c) Moodle 2.2 is already not supported anymore by Moodle HQ for anything (not
even security), according to [0];
Furthermore on that point, as far as I can see, there is noone taking
responsibility to handle Moodle 2.2 security on the long term (Moodle in
Wheezy will need to be security-handled for roughly three years, yet it is
_already_ not supported).
d) there is (in my opinion) not enough people behind the maintenance of
Moodle-in-Debian: Thomas is a good DM, but he's mostly alone, and I'm not
willing to get more involved.

So as much as I find that unfortunate, I think that the best solution for all
of Moodle, Moodle-in-Debian and Debian, is to not ship Moodle 2.2 in Wheezy.

Thomasz, as you're the actual de-facto maintainer, please voice your opinion
as I have voiced mine: the decision is in the hands of the Release Team I
guess.


I have exactly the same concerns. Security fixes has been released for 
Moodle 2.2 today. I could cherry pick the patches and we could close 
this bug - not a big deal. They will probably be another security update 
for Moodle this year but that's it.


Realistically speaking there is no way I can maintain security fixes for 
non-supported (by upstream) software this size.


I have put Moodle 2.2 into Wheezy as that's the only possible upgrade 
path for Moodle (1.9 -> 2.2 -> 2.3+).


By not shipping 2.2 in wheezy, we will break the upgrades for any 
current users. I don't see any other option though. There are talks in 
Moodle about making LTS version (e.g. 2.6LTS) - and that's probably the 
only reasonable way to maintain a high quality package like this in Debian.


+1 for not shipping 2.2, breaking the upgrade path for this package, 
start from 2.5 (or higher) in unstable and provide Moodle LTS editions 
in Debian stable only.


Tomek


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

Bug#702775: ganglia: limiting security support

[Raphael Geissert]

Package: ganglia
Version: 3.3.8-1
Severity: grave
Tags: security
Control: clone -1 -2
Control: reassign -2 src:ganglia-web 3.5.2-1
X-Debbugs-cc: t...@security.debian.org

Hi again,

Given the recent issues in Ganglia's web frontend and a review of some
portions of the code we, as in the security team, have decided to
limit ganglia's security support to installations behind a trusted
HTTP zone.
Any vulnerability that is only relevant when exposing ganglia's web
frontend to a non-secure zone will therefore be treated as a non-issue
by the security team. They could still be fixed via a SPU, however.

As such, please add a README.Debian.security file briefly mentioning
the limited security support, effective for the version in wheezy and
newer.

Thanks in advance.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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

Bug#686200: open-vm-tools: fails to upgrade do failing to stop the old daemon

[Bernd Zeimetz]

Hi,

as you've tagged this bug moreinfo:

In unstable you've added the one second sleep "fix" to the init script
again instead of using the return values of start-stop-daemon properly.
As discussed on #683299 a sleep 1 does not make sense at all, either it
is properly implemented and works as expected, then you don't need a
sleep 1, or its buggy, then sleep 1 might work or not, depending on the
system load and other fun.

Please fix this as suggested in my NMU.

Thanks,

Bernd


-- 
Mit freundlichen Grüßen


Bernd Zeimetz
Systems Engineer
Debian Developer

conova communications GmbH
Web| http://www.conova.com/
E-Mail | b.zeim...@conova.com

Zentrale Salzburg
Karolingerstraße 36A
5020 Salzburg

Tel | +43 (0) 662 22 00 - 313
Fax | +43 (0) 662 22 00 - 209

Es gelten die Allgemeinen Geschäftsbedingungen der
conova communications GmbH, http://www.conova.com/de/agb/


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

Bug#702777: python3: manpage-contains-errors-from-man

[Dmitry Shachnev]

Package: python3
Version: 3.2.3-6
Severity: normal
Tags: patch

Lintian currently reports this:

W: python3: manpage-has-errors-from-man usr/share/man/man1/dh_python3.1.gz 7: 
warning: macro `INDENT' not defined
W: python3: manpage-has-errors-from-man usr/share/man/man1/py3clean.1.gz 7: 
warning: macro `INDENT' not defined
W: python3: manpage-has-errors-from-man usr/share/man/man1/py3compile.1.gz 7: 
warning: macro `INDENT' not defined
W: python3: manpage-has-errors-from-man usr/share/man/man1/pybuild.1.gz 7: 
warning: macro `INDENT' not defined

This should be fixed by adding docinfo blocks to the .rst files.
Please consider the following branches:

bzr+ssh://bzr.debian.org/~mitya57-guest/public_bzr/python3-defaults/manpage-fixes
bzr+ssh://bzr.debian.org/~mitya57-guest/public_bzr/python-defaults/manpage-fixes

Cheers,

--
Dmitry Shachnev


-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'experimental')
Architecture: i386 (i686)

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

Versions of packages python3 depends on:
ii  python3-minimal  3.2.3-6
ii  python3.23.2.3-7

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc  
pn  python3-tk   

-- 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#702778: midori: file:/// urls in speed dial tabs may be opened only via context menu

[Alex 'AdUser' Z]

Package: midori
Version: 0.4.3+dfsg-0.1
Severity: normal
Tags: upstream

Greetings!

I'm using midori mainly as browser for local html documentation. So, this bug
is very annoying for me.

Steps to reproduce:
- Click on any speed dial and add url, points to local file.
- Try to click on newly created dial. Nothing happends.
- Call context menu on this dial and select "Open in new tab". Tab opens as it
should be.



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

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

Versions of packages midori depends on:
ii  dbus-x111.6.8-1
ii  libc6   2.13-38
ii  libcairo2   1.12.2-3
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgtk2.0-0 2.24.10-2
ii  libjavascriptcoregtk-1.0-0  1.8.1-3.4
ii  libnotify4  0.7.5-1
ii  libpango1.0-0   1.30.0-1
ii  libsoup2.4-12.38.1-2
ii  libsqlite3-03.7.13-1
ii  libunique-1.0-0 1.1.6-4
ii  libwebkitgtk-1.0-0  1.8.1-3.4
ii  libx11-62:1.5.0-1
ii  libxml2 2.8.0+dfsg1-7
ii  libxss1 1:1.2.2-1

Versions of packages midori recommends:
ii  gnome-icon-theme  3.4.0-2

midori 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#702779: [netdisco-frontend] cannot use SVG netmap

[Landry MINOZA]

Package: netdisco-frontend
Version: 1.0-3
Severity: important
Tags: patch

--- Please enter the report below this line. ---
The SVG netmap is not usable, it triggers a 404 error saying that 
/var/lib/netdisco/html/netmap.svg does not exists even if this file exists.

This is also true for gif netmap.
I had to do this to be able to use those functionnalities:

1/ symlink /var/lib/netdisco/html/netmap.svg to /usr/share/netdisco/html.
2/ symlink /var/lib/netdisco/html/netmap.gif to /usr/share/netdisco/html.
3/ add the files zgrviewer-0.8.2.jar, zvtm-0.9.8.jar (and 
zvtm.license.txt) from upstream tarballs in /usr/share/netdisco/html/svg.


After this, all netmaps are working smoothly.

The file zvtm.license.txt is a copy of LGPL license so i think there is 
no problem to include those files.
The upstream project of this java applet is 
http://zvtm.sf.net/zgrviewer.html if this is an option to include this 
as a different package.


--- System information. ---
Architecture: amd64
Kernel: Linux 3.6-trunk-amd64

Debian Release: 7.0
500 unstable http.debian.net
500 testing http.debian.net
500 stable security.debian.org
500 stable http.debian.net
101 experimental http.debian.net

--- Package information. ---
Depends (Version) | Installed
===-+-===
netdisco-common | 1.0-3
adduser | 3.113+nmu3
perl | 5.14.2-20
apache2 | 2.2.22-13
libmasonx-request-withapachesession-perl (>= 0.30) | 0.30-3.1
libhtml-mason-perl (>= 1.32) | 1:1.50-1
libapache2-mod-perl2 (>= 2.0.2) | 2.0.7-2
libapache2-request-perl (>= 2.06) | 2.13-1+b2
libapache-dbi-perl (>= 0.94) | 1.11-1


Package's Recommends field is empty.

Suggests (Version) | Installed
===-+-===
libgraph-perl (>= 0.50) | 1:0.91-1
graphviz (>= 2.2.0) | 2.26.3-13
libgraphviz-perl (>= 2.02) | 2.10-1





--

*Landry MINOZA*
MGI Sud-Ouest/
Chef de projet technique Linux et réseaux/
E-mail : lmin...@mgi.fr 



Tél :01 40 49 47 15

MGI France :5 rue Sextius Michel - 75015 Paris | RCS: Paris B 382 770 
584 |www.mgi.fr 
MGI SO :281 route d'Espagne - 31100 Toulouse | RCS: Toulouse B 421 125 
816 |www.mgi.fr 
MGI Suisse :5 avenue de Rothorn - CH3960 Sierre | TVA 517-269 
|www.mgiconsultants.ch 

Bug#602145: mutt: Display problems for mbox-files > 2GiB

[Ansgar Burchardt]

Control: tag -1 - unreproducible

I could repreduce the problem when I wrote the patch. It doesn't happen
when you look at a mail beyond the 2 GB limit the first time, but I
could reproduce it on i386 with these steps:

- Create a large mbox (e.g. using the script in this bug report).
- $ mutt -f ./mbox
- Look at the first mail.
- Look at the last mail.
- Look again at the first mail.
- Look again at the last mail. It should display a bit of garbage now.

Ansgar


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

Bug#702372: Please build against gstreamer 1.0

[Guido Günther]

On Sun, Mar 10, 2013 at 08:18:37PM -0400, Andres Mejia wrote:
> You should send the patch to the mailing list instead.

Done

http://www.mail-archive.com/linux-media@vger.kernel.org/msg59561.html

Cheers,
 -- Guido

> 
> On Sun, Mar 10, 2013 at 9:31 AM, Guido Günther  wrote:
> > Hi Andres,
> > On Sun, Mar 10, 2013 at 01:59:16AM -0500, Andres Mejia wrote:
> >> On Wed, Mar 6, 2013 at 2:49 PM, Guido Günther  wrote:
> >> > tag 702372 +patch
> >> > thanks
> >> >
> >> > On Tue, Mar 05, 2013 at 08:38:22PM +0100, Guido Günther wrote:
> >> >> Package: gstreamer0.10-crystalhd
> >> >> Version: 1:0.0~git20110715.fdd2f19-9
> >> >> Severity: wishlist
> >> >> Tags: patch
> >> >>
> >> >> Hi,
> >> >> I'd be great to have a version built against gstreamer 1.0 in
> >> >> experimental since GNOME/totem uses gstreamer 1.0 there already. I've
> >> >> added patches here:
> >> >>
> >> >>   https://github.com/agx/crystalhd
> >> >>
> >> >> Tested with totem and gst-launch it reduces CPU usage from 60% to <25%
> >> >> when playing h264 video. It's a straight forward port of the gst0.10
> >> >> version you were previously tracking.
> >> > Attached patch updates the package.
> >> >  -- Guido
> >>
> >> Hi, great work here. Have you tried submitting a patch to linuxtv.org
> >> as well? I would like changes done to the upstream source be committed
> >> upstream first.
> > I mailed Jarod Wilson  but got no reply so far. What
> > would be the right place, the linux-media list?
> > Cheers,
> >  -- Guido
> 
> 
> 
> --
> ~ Andres
> 


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

Bug#702780: GdkPixbuf:ERROR:gdk-pixbuf-animation.c:242:gdk_pixbuf_animation_new_from_file: assertion failed: (animation)

[Vincent Danjean]

Package: libgdk-pixbuf2.0-0
Version: 2.27.2-1
Severity: important
Tags: upstream

  Hi,

  While trying to run wicd-gtk with libgdk-pixbuf2.0-0 from experimental,
I got a assertion fail. Running under gdb with -dbg packages, I got the
backtrace copy-pasted at the end of this message.
  I recompiled libgdk-pixbuf2.0-0 with a patch that revert the upstream
commit 9201fcfdcafd865bc10624c5c3a12192b5eeea9a "animation: Improve error
handling".
  This fixed the problem for me (ie wicd-gtk works perfectly again now).

  I do not know if the real bug is this commit or an bad use of
libgdk-pixbuf2.0-0 by wicd.
  Note that a similar symptome is described in 702517 that uses the same
version of libgdk-pixbuf2.0-0 (according to the bug report). I did not checked
if my workaround also work for this bug.

  Regards,
Vincent


Backtrace of wicd-gtk when the problem occurs:

vdanjean@eyak:~$ gdb --args /usr/bin/python -O 
/usr/share/wicd/gtk/wicd-client.py
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/python -O /usr/share/wicd/gtk/wicd-client.py
warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x77ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Has notifications support True
Loading...
Connecting to daemon...
Connected.
**
GdkPixbuf:ERROR:gdk-pixbuf-animation.c:242:gdk_pixbuf_animation_new_from_file: 
assertion failed: (animation)

Program received signal SIGABRT, Aborted.
0x76f2b2a5 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce 
type.
(gdb) bt
#0  0x76f2b2a5 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x76f2e448 in __GI_abort () at abort.c:90
#2  0x75f5167c in g_assertion_message ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x75f51be2 in g_assertion_message_expr ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x73d06b0a in gdk_pixbuf_animation_new_from_file (
filename=, error=0x0) at gdk-pixbuf-animation.c:242
#5  0x74ca6b0f in IA__gtk_image_set_from_file (image=0x1097440, 
filename=0x1209414 "/usr/share/pixmaps/wicd/wired-gui.svg")
at 
/build/buildd-gtk+2.0_2.24.17-1-amd64-V1Dr8g/gtk+2.0-2.24.17/gtk/gtkimage.c:971
#6  0x75327d30 in ?? ()
   from /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/_gtk.so
#7  0x004b67ce in PyEval_EvalFrameEx ()
#8  0x004bde18 in PyEval_EvalCodeEx ()
#9  0x004be99c in ?? ()
#10 0x00483fb4 in ?? ()
#11 0x0047d774 in ?? ()
#12 0x00473d22 in ?? ()
#13 0x004b6f28 in PyEval_EvalFrameEx ()
#14 0x004bde18 in PyEval_EvalCodeEx ()
#15 0x004b6e20 in PyEval_EvalFrameEx ()
#16 0x004bde18 in PyEval_EvalCodeEx ()
#17 0x004beac7 in ?? ()
#18 0x00483fb4 in ?? ()
#19 0x0047d774 in ?? ()
#20 0x00473d22 in ?? ()
#21 0x004b6f28 in PyEval_EvalFrameEx ()
#22 0x004b70a0 in PyEval_EvalFrameEx ()
#23 0x004bde18 in PyEval_EvalCodeEx ()
#24 0x004beac7 in ?? ()
#25 0x00483fb4 in ?? ()
#26 0x0047d774 in ?? ()
#27 0x00473d22 in ?? ()
#28 0x004b6f28 in PyEval_EvalFrameEx ()
#29 0x004bde18 in PyEval_EvalCodeEx ()
#30 0x004beac7 in ?? ()
#31 0x004b81b9 in PyEval_EvalFrameEx ()
#32 0x004bde18 in PyEval_EvalCodeEx ()
#33 0x004b6e20 in PyEval_EvalFrameEx ()
#34 0x004bde18 in PyEval_EvalCodeEx ()
#35 0x0055c913 in ?? ()
#36 0x00457452 in PyRun_FileExFlags ()
#37 0x0045794c in PyRun_SimpleFileExFlags ()
#38 0x0045853c in Py_Main ()
#39 0x76f17a55 in __libc_start_main (main=0x44d6bc , argc=3, 
ubp_av=0x7fffe2d8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe2c8) at libc-start.c:260
#40 0x004cfa29 in _start ()
(gdb) 




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

Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Bug#693210: [pkg-firebird-general] Bug#693210: server crash on prearing an empty query with tracing enabled

[Raphael Geissert]

Hi,

On 10 March 2013 10:38, Salvatore Bonaccorso  wrote:
[...]
> I checked the security-tracker about this[1]. It is marked 'no-dsa'
> for Squeeze, so I assume this should go trough a
> stable-proposed-updates upload.
>
>  [1]: https://security-tracker.debian.org/CVE-2012-5529

Since there's also another issue affecting firebird, this less severe
issue could be fixed in the same DSA.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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

Bug#702781: rapidsvn: Crash while checking out working copy

[Christoph Goesgens]

Package: rapidsvn
Version: 0.12.0dfsg-2
Severity: normal

Rapidsvn crashed severel times while i was checking out a copy of one of my
company's repos. It also doesn't appear to be able to recover from this,
since i wasn't able to complete the unfinished checkout, or browse the files
in the repo. Stacktrace as follows.

** glibc detected *** rapidsvn: corrupted double-linked list:
** 0x7f28300185f0 ***
=== Backtrace: =
/lib/libc.so.6(+0x71e16)[0x7f28470dde16]
/lib/libc.so.6(+0x7577f)[0x7f28470e177f]
/lib/libc.so.6(__libc_malloc+0x70)[0x7f28470e2c70]
/usr/lib/libwx_baseu-2.8.so.0(_ZN12wxStringBase11AllocBufferEm+0x54)[0x7f2847c34654]
/usr/lib/libwx_baseu-2.8.so.0(_ZN12wxStringBase8InitWithEPKwmm+0x63)[0x7f2847c34e93]
/usr/lib/libwx_baseu-2.8.so.0(_ZN8wxString6ShrinkEv+0x34)[0x7f2847c36924]
/usr/lib/libwx_baseu-2.8.so.0(_ZN8wxString7PrintfVEPKwP13__va_list_tag+0xf2)[0x7f2847c36a82]
/usr/lib/libwx_baseu-2.8.so.0(_ZN8wxString6PrintfEPKwz+0x88)[0x7f2847c36bc8]
rapidsvn[0x45ae49]
/usr/lib/libsvncpp.so.3(_ZN3svn7Context4Data9onNotify2EPvPK15svn_wc_notify_tP10apr_pool_t+0x3a)[0x7f284b88c69a]
/usr/lib/libsvn_wc-1.so.1(+0x3c8ce)[0x7f284b41f8ce]
/usr/lib/libsvn_delta-1.so.1(+0x2e3a)[0x7f284afd0e3a]
/usr/lib/libsvn_ra_svn-1.so.1(+0xec66)[0x7f28461c6c66]
/usr/lib/libsvn_ra_svn-1.so.1(svn_ra_svn_drive_editor2+0x176)[0x7f28461c5966]
/usr/lib/libsvn_ra_svn-1.so.1(+0x605d)[0x7f28461be05d]
/usr/lib/libsvn_wc-1.so.1(svn_wc_crawl_revisions4+0x1b0)[0x7f284b3f0630]
/usr/lib/libsvn_client-1.so.1(svn_client__update_internal+0x66e)[0x7f284b66a2be]
/usr/lib/libsvn_client-1.so.1(svn_client__checkout_internal+0x606)[0x7f284b63c5b6]
/usr/lib/libsvn_client-1.so.1(svn_client_checkout2+0x4a)[0x7f284b6478fa]
/usr/lib/libsvncpp.so.3(_ZN3svn6Client8checkoutEPKcRKNS_4PathERKNS_8RevisionEbbS8_+0xc7)[0x7f284b884777]
rapidsvn[0x42b502]
rapidsvn[0x48fc61]
rapidsvn[0x48fec8]
/usr/lib/libwx_baseu-2.8.so.0(_ZN16wxThreadInternal12PthreadStartEP8wxThread+0xe1)[0x7f2847c6dd91]
/lib/libpthread.so.0(+0x68ca)[0x7f2849e9f8ca]
/lib/libc.so.6(clone+0x6d)[0x7f284713bb6d]
=== Memory map: 
0040-004de000 r-xp  08:05 271988
/usr/bin/rapidsvn
006dd000-006e rw-p 000dd000 08:05 271988
//usr/bin/rapidsvn
006e-006eb000 rw-p  00:00 0 
02104000-04743000 rw-p  00:00 0
[heap]
7f282800-7f282af97000 rw-p  00:00 0 
7f282af97000-7f282c00 ---p  00:00 0 
7f282fef6000-7f283000 rw-p  00:00 0 
7f283000-7f28329b2000 rw-p  00:00 0 
7f28329b2000-7f283400 ---p  00:00 0 
7f2834033000-7f28343d9000 rw-p  00:00 0 
7f28343d9000-7f28343de000 r-xp  08:05 921446
/lib/libnss_dns-2.11.3.so
7f28343de000-7f28345dd000 ---p 5000 08:05 921446
//lib/libnss_dns-2.11.3.so
7f28345dd000-7f28345de000 r--p 4000 08:05 921446
/lib/libnss_dns-2.11.3.so
7f28345de000-7f28345df000 rw-p 5000 08:05 921446
//lib/libnss_dns-2.11.3.so
7f28345df000-7f28345e1000 r-xp  08:05 927456
/lib/libnss_mdns4_minimal.so.2
7f28345e1000-7f28347e ---p 2000 08:05 927456
//lib/libnss_mdns4_minimal.so.2
7f28347e-7f28347e1000 rw-p 1000 08:05 927456
/lib/libnss_mdns4_minimal.so.2
7f28347e1000-7f28347ed000 r-xp  08:05 917569
//lib/libnss_files-2.11.3.so
7f28347ed000-7f28349ec000 ---p c000 08:05 917569
/lib/libnss_files-2.11.3.so
7f28349ec000-7f28349ed000 r--p b000 08:05 917569
//lib/libnss_files-2.11.3.so
7f28349ed000-7f28349ee000 rw-p c000 08:05 917569
/lib/libnss_files-2.11.3.so
7f28349ee000-7f28349fa000 r-xp  08:05 288246
//usr/lib/sasl2/libdigestmd5.so.2.0.23
7f28349fa000-7f2834bf9000 ---p c000 08:05 288246
/usr/lib/sasl2/libdigestmd5.so.2.0.23
7f2834bf9000-7f2834bfa000 rw-p b000 08:05 288246
//usr/lib/sasl2/libdigestmd5.so.2.0.23
7f2834bfa000-7f2834bfe000 r-xp  08:05 288254
/usr/lib/sasl2/libanonymous.so.2.0.23
7f2834bfe000-7f2834dfd000 ---p 4000 08:05 288254
//usr/lib/sasl2/libanonymous.so.2.0.23
7f2834dfd000-7f2834dfe000 rw-p 3000 08:05 288254
/usr/lib/sasl2/libanonymous.so.2.0.23
7f2834dfe000-7f2834e02000 r-xp  08:05 288245
//usr/lib/sasl2/liblogin.so.2.0.23
7f2834e02000-7f2835001000 ---p 4000 08:05 288245
/usr/lib/sasl2/liblogin.so.2.0.23
7f2835001000-7f2835002000 rw-p 3000 08:05 288245
//usr/lib/sasl2/liblogin.so.2.0.23
7f2835002000-7f2835007000 r-xp  08:05 267922
/usr/lib/sasl2/libsasldb.so.2.0.23
7f2835007000-7f2835206000 ---p 5000 08:05 267922
//usr/lib/sasl2/libsasldb.so.2.0.23
7f2835206000-7f2835207000 rw-p 4000 08:05 267922
/usr/lib/sasl2/libsasldb.so.2.0.23
7f2835207000-7f283520b000 r-xp  08:05 288247
//usr/lib/sasl2/libplain.so.2.0.23
7f283520b000-7f283540a000 ---p 4000 08:05 288247
/usr/lib/sasl2/libplain.so.2.0.23
7f283540a000-7f283540b000 rw-p 3000 08:05 288247
//usr/lib/sasl2/libplain.so.2.0.23
7f283540b000-7f283540f000 r-xp  08:05 288252
/usr/lib/sasl2/libcrammd5.so.2.0.23
7f283540f000-7f283560f000 ---p 4000 08:05 288252
//usr/lib/sa

Bug#702782: broken glx alternative

[Gaudenz Steinlin]

Package: nvidia-graphics-drivers-legacy-173xx
Severity: important

[ Reporting agains nvidia-graphics-drivers-legacy-173xx because this is the
package that's broken in the end. But arguably this is either a bug in any
of the alternative packages. Might even be considered as a dpkg bug. Please 
reassign if you think that another package is more appropriate. ]

If you first installs the current nvidia package, then the legacy-173xx
package and then set the nvidia alternative to the legacy package you
end up with a broken glx alternative:

# apt-get install --no-install-recommends xserver-xorg-video-nvidia
# apt-get install --no-install-recommends xserver-xorg-video-nvidia-legacy-173xx
# update-alternatives --config nvidia -> selecting legacy-173xx

# ldd /usr/lib/nvidia/nvidia/libglx.so
linux-gate.so.1 =>  (0xf7714000)
libGLcore.so.1 => not found
libnvidia-tls.so.1 => not found
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf72b1000)
/lib/ld-linux.so.2 (0xf7715000)
# ls -l /usr/lib/i386-linux-gnu/libGLcore.so.1
ls: cannot access /usr/lib/i386-linux-gnu/libGLcore.so.1: No such file or 
directory
# ls -l /usr/lib/i386-linux-gnu/nvidia/libGLcore.so.1
lrwxrwxrwx 1 root root 55 Mar 11 10:38 
/usr/lib/i386-linux-gnu/nvidia/libGLcore.so.1 -> 
/etc/alternatives/nvidia--libGLcore.so.1-i386-linux-gnu
# dpkg-reconfigure glx-alternative-nvidia
update-alternatives: warning: forcing reinstallation of alternative 
/usr/lib/nvidia because link group glx is broken
# ls -l /usr/lib/i386-linux-gnu/libGLcore.so.1
lrwxrwxrwx 1 root root 52 Mar 11 10:52 /usr/lib/i386-linux-gnu/libGLcore.so.1 
-> /etc/alternatives/glx--libGLcore.so.1-i386-linux-gnu

The root of the problem is that the current driver does not have 
libGLcore.so.1 so this slave alternative link is not installed when 
glx-alternative-nvidia is first configured. Reconfiguring the 
glx-alternative-nvidia package while the legacy alternative is selected
fixes this.

The issue also appears with the following sequence (in addition to the
above commands):
# apt-get install --no-install-recommends libgl1-mesa-glx
# update-alternatives --config nvidia -> select current
# update-alternatives --config glx -> select mesa-diverted
# update-alternatives --config glx -> select nvidia
# update-alternatives --config nvidia -> select legacy-173xx

And now you are in the broken state again.

The root of the problem is that update-alternatives does not create slave
symlinks that would be broken. So the symlink to libGLcore.so.1 in the glx
alternative is not created if the nvidia alternative is set to current, 
because that library does not exist in that package.

The only solution I currently is to drop the nvidia alternative and to show
all the nvidia driver version as individual options in the glx alternative.
This avoids the "double" alternative redirection which leads to this problem.

Gaudenz

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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


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

Bug#701215: dh_python3: sensitive to trailing slash in private dir names

[Dmitry Shachnev]

Here is a trivial patch that fixes this:

--- dh_python3  2013-01-19 22:34:24 +
+++ dh_python3  2013-03-11 11:03:45 +
@@ -157,7 +157,7 @@
 else:
 # scan private directory *only*
 proot = join('debian', package, dname.strip('/'))
-private_to_check = [dname[1:]]
+private_to_check = [dname.rstrip('/')[1:]]
 
 for root, dirs, file_names in os.walk(proot):
 # ignore Python 2.X locations

--
Dmitry Shachnev


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

Bug#683791: Status

[martin f krafft]

What's the status of this ITP?

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems


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

Bug#702783: unblock: gmpc/11.8.16-6

[Etienne Millon]

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

Hello,

I uploaded gmpc 11.8.16-6 to fix a localization patch that causes gmpc not
to appear in the menu (important bug #694547).

Please see attached debdiff to the version in testing.

Thanks and good luck for the release.

unblock gmpc/11.8.16-6

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

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

-- 
Etienne Millon
diff -Nru gmpc-11.8.16/debian/changelog gmpc-11.8.16/debian/changelog
--- gmpc-11.8.16/debian/changelog	2012-10-12 15:48:23.0 +0200
+++ gmpc-11.8.16/debian/changelog	2013-03-07 18:36:22.0 +0100
@@ -1,3 +1,9 @@
+gmpc (11.8.16-6) unstable; urgency=low
+
+  * Fix catalan menu entry (Closes: #694547)
+
+ -- Etienne Millon   Thu, 07 Mar 2013 18:36:17 +0100
+
 gmpc (11.8.16-5) unstable; urgency=low
 
   * Update translations :
diff -Nru gmpc-11.8.16/debian/patches/0010-Update-translations.patch gmpc-11.8.16/debian/patches/0010-Update-translations.patch
--- gmpc-11.8.16/debian/patches/0010-Update-translations.patch	2012-09-18 14:44:32.0 +0200
+++ gmpc-11.8.16/debian/patches/0010-Update-translations.patch	2012-12-04 14:38:25.0 +0100
@@ -10,11 +10,11 @@
   - [ru] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687999
 ---
  configure.ac |2 +-
- po/ca.po | 2480 ++
+ po/ca.po | 2478 ++
  po/fr.po |  241 +++---
  po/oc.po |   18 +-
  po/ru.po |2 +-
- 5 files changed, 2629 insertions(+), 114 deletions(-)
+ 5 files changed, 2627 insertions(+), 114 deletions(-)
  create mode 100644 po/ca.po
 
 diff --git a/configure.ac b/configure.ac
@@ -32,10 +32,10 @@
  AM_GLIB_GNU_GETTEXT
 diff --git a/po/ca.po b/po/ca.po
 new file mode 100644
-index 000..03d41eb
+index 000..b99e42d
 --- /dev/null
 +++ b/po/ca.po
-@@ -0,0 +1,2480 @@
+@@ -0,0 +1,2478 @@
 +# Catalan translation for gmpc
 +# Copyright (c) 2012 Rosetta Contributors and Canonical Ltd 2012
 +# This file is distributed under the same license as the gmpc package.
@@ -65,9 +65,7 @@
 +#: ../src/browsers/gmpc-nowplaying2.c:2641
 +#: ../src/browsers/gmpc-nowplaying2.c:2645
 +msgid "Gnome Music Player Client"
-+msgstr ""
-+"Client de reproducció\n"
-+"de música del GNOME"
++msgstr "Client de reproducció de música del GNOME"
 +
 +#: ../src/main.c:333
 +msgid "Failed to load the configuration system."

Bug#702784: Use of nested functions in configure check

[Michael Tautschnig]

Package: gnats
Version: 4.1.0-2
Usertags: goto-cc

gnats/configure.in.nse uses AC_TRY_COMPILE to check for a properly supported
"const". The second argument of this macro is supposed to be a function body,
but this configure.in includes two function definitions (see result below),
resulting in nested functions.

| int
| main ()
| {
| const char *foo(const char *x) { return x; }
| int bar(const char *x) { return x == foo(x); }
|   ;
|   return 0;
| }

This is accepted by GCC, but other compilers (including CLANG) reject this GCC
extension. As a result, the gcc command lines include -Dconst=, which breaks
the build when trying to compile fconfigl.c.

Best,
Michael



pgp5anajkQWVy.pgp
Description: PGP signature

Bug#702785: unblock: ifenslave-2.6/1.1.0-21

[Guus Sliepen]

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

Please unblock package ifenslave-2.6

This fixes an important bug (#699445) which causes bonding to fail to work
correctly after booting in those bonding modes where a primary interface has to
be selected.

I also enabled hardening flags, which found some unsafe usages of format
strings, which have been fixed.

unblock ifenslave-2.6/1.1.0-21

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru ifenslave-2.6-1.1.0/debian/changelog ifenslave-2.6-1.1.0/debian/changelog
--- ifenslave-2.6-1.1.0/debian/changelog	2011-11-14 11:36:30.0 +0100
+++ ifenslave-2.6-1.1.0/debian/changelog	2013-02-19 14:43:55.0 +0100
@@ -1,3 +1,17 @@
+ifenslave-2.6 (1.1.0-21) unstable; urgency=low
+
+  [ Jonas Genannt ]
+  * d/pre-up: bond-primary does not apply (Closes: #699445)
+Moved setting primary into own function and call it after enslave_slaves
+
+  [ Guus Sliepen ]
+  * Explicitly mention that 3.x kernels are also supported. Closes: #697454
+  * Bump Standards-Version. 
+  * Enable hardening.
+  * Fix unsafe use of printf() and fprintf() found by the hardening flags.
+
+ -- Guus Sliepen   Tue, 19 Feb 2013 14:43:29 +0100
+
 ifenslave-2.6 (1.1.0-20) unstable; urgency=low
 
   * Use dashes consistently for bonding options in README.Debian.
diff -Nru ifenslave-2.6-1.1.0/debian/control ifenslave-2.6-1.1.0/debian/control
--- ifenslave-2.6-1.1.0/debian/control	2011-05-25 18:42:29.0 +0200
+++ ifenslave-2.6-1.1.0/debian/control	2013-02-19 14:40:32.0 +0100
@@ -2,8 +2,8 @@
 Section: net
 Priority: optional
 Maintainer: Guus Sliepen 
-Build-Depends: debhelper (>> 7.0.0)
-Standards-Version: 3.9.2
+Build-Depends: debhelper (>> 7.0.0), dpkg-dev (>= 1.16.1~)
+Standards-Version: 3.9.4
 
 Package: ifenslave-2.6
 Architecture: linux-any
@@ -19,4 +19,4 @@
  "channel bonding" or "trunking" techniques used in switches.
  .
  The kernel must have support for bonding devices for ifenslave to be useful.
- This package supports 2.6.x kernels and the most recent 2.4.x kernels.
+ This package supports 2.6.x and 3.x kernels and the most recent 2.4.x kernels.
diff -Nru ifenslave-2.6-1.1.0/debian/patches/fix-unsafe-use-of-printf ifenslave-2.6-1.1.0/debian/patches/fix-unsafe-use-of-printf
--- ifenslave-2.6-1.1.0/debian/patches/fix-unsafe-use-of-printf	1970-01-01 01:00:00.0 +0100
+++ ifenslave-2.6-1.1.0/debian/patches/fix-unsafe-use-of-printf	2013-02-19 14:39:05.0 +0100
@@ -0,0 +1,72 @@
+--- a/ifenslave.c
 b/ifenslave.c
+@@ -260,7 +260,7 @@
+ 		case 'V': opt_V++; exclusive++; break;
+ 
+ 		case '?':
+-			fprintf(stderr, usage_msg);
++			fputs(usage_msg, stderr);
+ 			res = 2;
+ 			goto out;
+ 		}
+@@ -268,13 +268,13 @@
+ 
+ 	/* options check */
+ 	if (exclusive > 1) {
+-		fprintf(stderr, usage_msg);
++		fputs(usage_msg, stderr);
+ 		res = 2;
+ 		goto out;
+ 	}
+ 
+ 	if (opt_v || opt_V) {
+-		printf(version);
++		fputs(version, stdout);
+ 		if (opt_V) {
+ 			res = 0;
+ 			goto out;
+@@ -282,14 +282,14 @@
+ 	}
+ 
+ 	if (opt_u) {
+-		printf(usage_msg);
++		fputs(usage_msg, stdout);
+ 		res = 0;
+ 		goto out;
+ 	}
+ 
+ 	if (opt_h) {
+-		printf(usage_msg);
+-		printf(help_msg);
++		fputs(usage_msg, stdout);
++		fputs(help_msg, stdout);
+ 		res = 0;
+ 		goto out;
+ 	}
+@@ -309,7 +309,7 @@
+ 			goto out;
+ 		} else {
+ 			/* Just show usage */
+-			fprintf(stderr, usage_msg);
++			fputs(usage_msg, stderr);
+ 			res = 2;
+ 			goto out;
+ 		}
+@@ -320,7 +320,7 @@
+ 	master_ifname = *spp++;
+ 
+ 	if (master_ifname == NULL) {
+-		fprintf(stderr, usage_msg);
++		fputs(usage_msg, stderr);
+ 		res = 2;
+ 		goto out;
+ 	}
+@@ -339,7 +339,7 @@
+ 
+ 	if (slave_ifname == NULL) {
+ 		if (opt_d || opt_c) {
+-			fprintf(stderr, usage_msg);
++			fputs(usage_msg, stderr);
+ 			res = 2;
+ 			goto out;
+ 		}
diff -Nru ifenslave-2.6-1.1.0/debian/patches/series ifenslave-2.6-1.1.0/debian/patches/series
--- ifenslave-2.6-1.1.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ ifenslave-2.6-1.1.0/debian/patches/series	2013-02-19 14:34:20.0 +0100
@@ -0,0 +1 @@
+fix-unsafe-use-of-printf
diff -Nru ifenslave-2.6-1.1.0/debian/pre-up ifenslave-2.6-1.1.0/debian/pre-up
--- ifenslave-2.6-1.1.0/debian/pre-up	2011-11-14 11:30:07.0 +0100
+++ ifenslave-2.6-1.1.0/debian/pre-up	2013-02-19 13:04:24.0 +0100
@@ -145,21 +145,6 @@
 	# Changing lacp_rate requires $BOND_MASTER to be down.
 	sysfs_change_down lacp_rate "$IF_BOND_LACP_RATE"
 
-	# primary must be set after mode (because only supported in some modes) and after enslavement.
-	# The first slave in bond-primary found in current slaves becomes the primary.
-	# If no slave in bond-

Bug#702786: unblock: inputlirc/23-1

[Guus Sliepen]

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

Please unblock package inputlirc

This version fixes an important bug (#689037) which causes inputlirc to crash
immediately when started with two or more identical input devices specified on
the command line. This can happen inadvertently when combining manually
specified input devices with one or more filter options, it is very difficult
for a user to see what went wrong in such a case.

Note that I am also the upstream author, so I have made a new upstream version
fixing this bug, instead of just applying a Debian patch to the old version.

I have also enabled compiler hardening flags.

unblock inputlirc/23-1

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru inputlirc-19/ChangeLog inputlirc-23/ChangeLog
--- inputlirc-19/ChangeLog	2011-05-19 22:31:22.0 +0200
+++ inputlirc-23/ChangeLog	2013-02-21 16:02:21.0 +0100
@@ -1,3 +1,30 @@
+commit 95e620a7f245cca550b20c9da66fba38125b0790
+Author: Guus Sliepen 
+Date:   Thu Feb 21 15:58:18 2013 +0100
+
+Honour $CPPFLAGS and $LDFLAGS.
+
+commit 81a9275a8345c934ec0b3e6424562520a7b71cd4
+Author: Guus Sliepen 
+Date:   Tue Oct 2 13:09:35 2012 +0200
+
+Query type of input event device, and only accept those that send EV_KEY events.
+
+commit 2c683d7153ceb1ee11be497b70001d79ab62b04f
+Author: Guus Sliepen 
+Date:   Tue Oct 2 13:08:40 2012 +0200
+
+Don't add input event devices to the list that cannot be read.
+
+This fixes a crash caused by FD_SET() not liking a negative file descriptor.
+So also added a check right before FD_SET() just in case.
+
+commit 3de9078edb670481d06968935062efb2a5a46285
+Author: Guus Sliepen 
+Date:   Tue Oct 2 13:05:03 2012 +0200
+
+Send log messages to stderr when not detached.
+
 commit 4d6c054dab4d3ab80a00db69f8cce4b89bf75caa
 Author: Guus Sliepen 
 Date:   Thu May 19 21:40:04 2011 +0200
diff -Nru inputlirc-19/Makefile inputlirc-23/Makefile
--- inputlirc-19/Makefile	2011-05-19 22:31:22.0 +0200
+++ inputlirc-23/Makefile	2013-02-21 16:00:36.0 +0100
@@ -1,5 +1,5 @@
 # inputlircd -- zeroconf LIRC daemon that reads from /dev/input/event devices
-# Copyright (C) 2006  Guus Sliepen 
+# Copyright (C) 2006-2013  Guus Sliepen 
 # 
 # This program is free software; you can redistribute it and/or modify it
 # under the terms of version 2 of the GNU General Public License as published
@@ -31,7 +31,7 @@
 	./gennames $< > $@
 
 inputlircd: inputlircd.c /usr/include/linux/input.h names.h
-	$(CC) $(CFLAGS) -o $@ $<
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $<
 
 install: install-sbin install-man
 
diff -Nru inputlirc-19/debian/changelog inputlirc-23/debian/changelog
--- inputlirc-19/debian/changelog	2013-03-11 12:31:19.0 +0100
+++ inputlirc-23/debian/changelog	2013-03-11 12:31:21.0 +0100
@@ -1,3 +1,13 @@
+inputlirc (23-1) unstable; urgency=low
+
+  * New upstream release.
+- Fixes a crash when one input device is specified more than once on the
+  command line. Closes: 689037
+  * Bump Standards-Version.
+  * Enable hardening flags.
+
+ -- Guus Sliepen   Thu, 21 Feb 2013 16:17:04 +0100
+
 inputlirc (19-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru inputlirc-19/debian/control inputlirc-23/debian/control
--- inputlirc-19/debian/control	2013-03-11 12:31:19.0 +0100
+++ inputlirc-23/debian/control	2013-03-11 12:31:21.0 +0100
@@ -2,8 +2,8 @@
 Section: utils
 Priority: extra
 Maintainer: Guus Sliepen 
-Build-Depends: debhelper (>> 7)
-Standards-Version: 3.9.2
+Build-Depends: debhelper (>> 7), dpkg-dev (>= 1.16.1~)
+Standards-Version: 3.9.4
 
 Package: inputlirc
 Architecture: any
diff -Nru inputlirc-19/debian/rules inputlirc-23/debian/rules
--- inputlirc-19/debian/rules	2013-03-11 12:31:19.0 +0100
+++ inputlirc-23/debian/rules	2013-03-11 12:31:21.0 +0100
@@ -11,18 +11,8 @@
 # This has to be exported to make some magic below work.
 export DH_OPTIONS
 
-
-
-CFLAGS = -Wall -g
-
-ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
-	CFLAGS += -O0
-else
-	CFLAGS += -O2
-endif
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-	INSTALL_PROGRAM += -s
-endif
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
 
 configure: configure-stamp
 configure-stamp:
diff -Nru inputlirc-19/inputlircd.c inputlirc-23/inputlircd.c
--- inputlirc-19/inputlircd.c	2011-05-19 22:31:22.0 +0200
+++ inputlirc-23/inputlircd.c	2013-02-21 16:00:36.0 +0100
@@ -1,6 +1,6 @@
 /*
 inputlircd -- zeroconf LIRC daemon that reads from /dev/input/event devices
-Copyright (C) 2006  Guus Sliepen 
+Copyright (C) 2006-2013  Guus Sliepen 
 
 This 

Bug#702787: pre-approval: unblock: python-pyrrd/0.1.0-2

[Elena Grandi]

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

I'd like to ask if the attached debdiff would be allowed in wheezy.

It fixes important bug #691230 by backporting a small patch from the
upstream repository; of course there are no other versions of the 
package in sid.

The package is team-maintained, and the Uploader has been contacted, 
but didn't answer.

Thanks in advance,

Elena Grandi
diff -u pyrrd-0.1.0/debian/changelog pyrrd-0.1.0/debian/changelog
--- pyrrd-0.1.0/debian/changelog
+++ pyrrd-0.1.0/debian/changelog
@@ -1,3 +1,11 @@
+pyrrd (0.1.0-2) UNRELEASED; urgency=low
+
+  * Team upload.
+  * Backport fix for RRD.fetch from upstream bzr revision 158
+(git commit dcd78df45c52) (Closes: #691230)
+
+ -- Elena Grandi   Mon, 18 Feb 2013 14:49:11 +0100
+
 pyrrd (0.1.0-1) unstable; urgency=low
 
   * Team upload
only in patch2:
unchanged:
--- pyrrd-0.1.0.orig/pyrrd/backend/external.py
+++ pyrrd-0.1.0/pyrrd/backend/external.py
@@ -264,7 +264,7 @@
 data += [unicode(x) for x in obj.rra]
 return (obj.filename, params + data)
 
-if function == 'update':
+elif function == 'update':
 validParams = ['template']
 params = common.buildParameters(obj, validParams)
 FIRST_VALUE = 0
@@ -277,15 +277,15 @@
 data = [data for data, nil in obj.values]
 return (obj.filename, params + data)
 
-if function == 'fetch':
+elif function == 'fetch':
 validParams = ['resolution', 'start', 'end']
 params = common.buildParameters(obj, validParams)
-return (obj.filename, obj.cf, params)
+return (obj.filename, [obj.cf] + params)
 
-if function == 'info':
+elif function == 'info':
 return (obj.filename, obj)
 
-if function == 'graph':
+elif function == 'graph':
 validParams = ['start', 'end', 'step', 'title',
 'vertical_label', 'width', 'height', 'only_graph',
 'upper_limit', 'lower_limit', 'rigid', 'alt_autoscale',

Bug#702788: broadcom-sta-dkms: fails to build dkms module on linux 3.8

[chrysn]

Package: broadcom-sta-dkms
Version: 5.100.82.112-9
Severity: important

when using a 3.8 kernel (linux-image-3.8-trunk-amd64 and
linux-headers-3.8-trunk-amd64 3.8.2-1~experimental.1), the dkms
compilation fails; it worked with kernel 3.7, and which shell /bin/sh is
linked to doesn't make a difference.

$ sudo dpkg-reconfigure broadcom-sta-dkms

--
Deleting module version: 5.100.82.112
completely from the DKMS tree.
--
Done.
Loading new broadcom-sta-5.100.82.112 DKMS files...
Building only for 3.8-trunk-amd64
Building initial module for 3.8-trunk-amd64
Error! Bad return status for module build on kernel: 3.8-trunk-amd64 (x86_64)
Consult /var/lib/dkms/broadcom-sta/5.100.82.112/build/make.log for more 
information.

$ cat /var/lib/dkms/broadcom-sta/5.100.82.112/build/make.log
DKMS make.log for broadcom-sta-5.100.82.112 for kernel 3.8-trunk-amd64 (x86_64)
Mon Mar 11 12:43:15 CET 2013
/bin/sh: 1: [: Illegal number: 
/bin/sh: 1: [: Illegal number: 
Wireless Extension is the only possible API for this kernel version
Using Wireless Extension API
KBUILD_NOPEDANTIC=1 make -C /lib/modules/3.8-trunk-amd64/build 
M=/var/lib/dkms/broadcom-sta/5.100.82.112/build
make[1]: Entering directory `/usr/src/linux-headers-3.8-trunk-amd64'
CFG80211 API is prefered for this kernel version
Using CFG80211 API
Kernel architecture is X86_64
  LD  /var/lib/dkms/broadcom-sta/5.100.82.112/build/built-in.o
  CC [M]  /var/lib/dkms/broadcom-sta/5.100.82.112/build/src/shared/linux_osl.o
  CC [M]  /var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_linux.o
  CC [M]  /var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_iw.o
  CC [M]  /var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.o
/var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.c: In 
function ‘wl_cfg80211_join_ibss’:
/var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.c:747:26: 
error: ‘struct cfg80211_ibss_params’ has no member named ‘channel’
/var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.c: At top 
level:
/var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.c:1654:2: 
warning: initialization from incompatible pointer type [enabled by default]
/var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.c:1654:2: 
warning: (near initialization for ‘wl_cfg80211_ops.set_tx_power’) [enabled by 
default]
/var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.c:1655:2: 
warning: initialization from incompatible pointer type [enabled by default]
/var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.c:1655:2: 
warning: (near initialization for ‘wl_cfg80211_ops.get_tx_power’) [enabled by 
default]
/var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.c: In 
function ‘wl_update_bss_info’:
/var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.c:2082:11: 
error: ‘struct cfg80211_bss’ has no member named ‘information_elements’
/var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.c:2083:15: 
error: ‘struct cfg80211_bss’ has no member named ‘len_information_elements’
make[4]: *** 
[/var/lib/dkms/broadcom-sta/5.100.82.112/build/src/wl/sys/wl_cfg80211.o] Error 1
make[3]: *** [_module_/var/lib/dkms/broadcom-sta/5.100.82.112/build] Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.8-trunk-amd64'
make: *** [all] Error 2

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

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

Versions of packages broadcom-sta-dkms depends on:
ii  dkms  2.2.0.3-1.2

Versions of packages broadcom-sta-dkms recommends:
ii  wireless-tools  30~pre9-8

broadcom-sta-dkms suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#620756: Mail-Followup-To /

[Jeroen Massar]

> [1] http://lists.debian.org/debian-project/2011/03/msg00065.html

Seems to point somewhere called "DELL" and does not seem to relate to
the thread mentioned here.


As Debian uses mailman for their mailinglists, are people aware that it
is has a "Receive your own posts to the list?" option?

If one would disable that (thus setting = "No"), you will not get a copy
of a mail sent to the list and where your destination is already in the
To/cc. Note that this can be set globally/per-list in mailman.

One then does not even have to guess that somebody does or does not want
to receive a direct copy.


As mentioned in the ticket setting Mail-Followup-To: avoids getting a
copy too.

Additionally the current code of conduct:
http://www.debian.org/MailingLists/#codeofconduct

has the following line:
"Do not send automated out-of-office or vacation messages."

While there are apparently some people sending automated

8<--
I'm subscribed to the list, no need to CC me:

http://www.debian.org/MailingLists/#codeofconduct

No need to reply to this message.
-->8

I suggest that people who are able to automatically send that kind of
things should at least do one of the above two things...



Alternative option: is there a addon to Thunderbird which makes/forces
"Reply-All" to behave like "Reply-To-List" for debian.org mailinglists?


Greets,
 Jeroen


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

Bug#566228: icedove-3.0: Lost dictionnaries + Cannot re-install dictionnaries

[VALETTE Eric OLNC/OLPS]

  
  
On 03/09/2013 09:16 PM, Carsten
  Schoenert wrote:
  
  
  > this problems are still exist or this issue no longer happen?
  I belive this bug could be closed.
  Regards
  Carsten


It can be closed indeed

-- eric
  



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

Bug#702789: fresh upstream release (3.0.14) is available (uscan needs adjustment)

[Yaroslav Halchenko]

Package: xul-ext-zotero
Version: 3.0.7-1
Severity: wishlist

apparently upstream was inconsistent and there is only now a link to the
download page from the support page. so watch needs to be 

novo:/tmp/xul-ext-zotero-3.0.7
$> cat debian/watch 
version=3
http://www.zotero.org/download 
http://download.zotero.org/extension/zotero-([\d\.]+)\.xpi debian xpi-repack

then it picks up 3.0.14

Cheers

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages xul-ext-zotero depends on:
ii  iceweasel  10.0.12esr-1

xul-ext-zotero recommends no packages.

xul-ext-zotero suggests no packages.


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

Bug#620756: Mail-Followup-To /

[Alexander Wirt]

Jeroen Massar schrieb am Monday, den 11. March 2013:

> > [1] http://lists.debian.org/debian-project/2011/03/msg00065.html
> 
> Seems to point somewhere called "DELL" and does not seem to relate to
> the thread mentioned here.
> 
> 
> As Debian uses mailman for their mailinglists, are people aware that it
> is has a "Receive your own posts to the list?" option?
we don't use mailman and we don't have these option.

Alex
-- 
Alexander Wirt, formo...@formorer.de 
CC99 2DDD D39E 75B0 B0AA  B25C D35B BC99 BC7D 020A


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

Bug#702790: FTBFS: local changes detected

[Michael Tautschnig]

Package: service-wrapper-java
Version: 3.5.3-4
Severity: serious
Justification: FTBFS
Usertags: goto-cc

In an attempt to rebuild the package, it fails when auto-commits are not
enabled. If these are enabled, it records the following additional changes:

dpkg-source: info: local changes detected, the modified files are:
 service-wrapper-java-3.5.3/build.xml
 service-wrapper-java-3.5.3/src/c/wrapperinfo.c
 service-wrapper-java-3.5.3/src/java/org/tanukisoftware/wrapper/WrapperInfo.java
dpkg-source: info: local changes have been recorded in a new patch: 
service-wrapper-java-3.5.3/debian/patches/debian-changes-3.5.3-4

Looking at debian-changes-3.5.3-4, it contains exactly those changes from 

01_disable_buildtime_in_buildfile.patch
02_update_buildtime.patch

which is indeed strange. To be honest, I'm not entirely sure what is going wrong
here. Reproducing the problem, however, is trivial:

dget -x 
http://http.debian.net/debian/pool/main/s/service-wrapper-java/service-wrapper-java_3.5.3-4.dsc
cd service-wrapper-java-3.5.3
dpkg-buildpackage
(well, I used pdebuild --use-pdebuild-internal instead)

Best,
Michael



pgpCZTAIK9C4e.pgp
Description: PGP signature

Bug#702791: FTBFS: test suite errors

[Michael Tautschnig]

Package: juju
Version: 0.5.1-2
Severity: serious
Justification: FTBFS
Usertags: goto-cc

In an attempt to rebuild the package, the test suite fails reproducibly on
different systems in a clean sid chroot. The full build log is attached, and the
reported errors are also quoted below. I have no idea how to interpret these.

Best,
Michael

===
[FAIL]
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1045, 
in _inlineCallbacks
result = g.send(result)
  File 
"/home/michael/Desktop/debian/goto-cc-debugging/juju-0.5.1/juju/providers/local/tests/test_provider.py",
 line 111, in test_bootstrap
self.provider.config["data-dir"], self.qualified_name, "files")
  File 
"/home/michael/Desktop/debian/goto-cc-debugging/juju-0.5.1/juju/providers/local/tests/test_provider.py",
 line 60, in assertDir
self.assertTrue(os.path.isdir(path))
twisted.trial.unittest.FailTest: None

juju.providers.local.tests.test_provider.LocalProviderTest.test_bootstrap
===
[ERROR]
Traceback (most recent call last):
Failure: twisted.internet.defer.TimeoutError: 
 (test_synchronize_automatic) still 
running at 5.0 secs

juju.unit.tests.test_workflow.UnitWorkflowTest.test_synchronize_automatic
===
[ERROR]
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1101, 
in gotResult
_inlineCallbacks(r, g, deferred)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1091, 
in _inlineCallbacks
deferred.errback()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 397, 
in errback
self._startRunCallbacks(fail)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 457, 
in _startRunCallbacks
raise AlreadyCalledError
twisted.internet.defer.AlreadyCalledError: 

juju.unit.tests.test_workflow.UnitWorkflowTest.test_synchronize_automatic
===
[ERROR]
Traceback (most recent call last):
  File 
"/home/michael/Desktop/debian/goto-cc-debugging/juju-0.5.1/juju/lib/mocker.py", 
line 157, in verify
self.mocker.verify()
  File 
"/home/michael/Desktop/debian/goto-cc-debugging/juju-0.5.1/juju/lib/mocker.py", 
line 579, in verify
raise AssertionError(os.linesep.join(message))
exceptions.AssertionError: [Mocker] Unmet expectations:

=> mock_container.stop()
 - Performed fewer times than expected.

=> mock_container.destroy()
 - Performed fewer times than expected.


juju.providers.local.tests.test_provider.LocalProviderTest.test_destroy_environment
===
[ERROR]
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1045, 
in _inlineCallbacks
result = g.send(result)
  File 
"/home/michael/Desktop/debian/goto-cc-debugging/juju-0.5.1/juju/providers/local/tests/test_provider.py",
 line 200, in test_get_file_storage
os.path.join(data_dir, self.qualified_name, "files")))
exceptions.OSError: [Errno 2] No such file or directory: 
'/tmp/tmppsAFgl/pbuser-local-test/files'

juju.providers.local.tests.test_provider.LocalProviderTest.test_get_file_storage
---



juju_0.5.1-2.log.gz
Description: application/gunzip


pgpGO_uDXr_ep.pgp
Description: PGP signature

Bug#701823: installation-report: Encrypted LVM assisted install failed on Lenovo T430s

[Raphaël Walther]

I reproduce the same issue on the same computer with the new
motherboard. I tried to encrypt a partition and it failed again at the
same step.

Cheers,
Raphaël


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

Bug#702040: Patch to use pango-querymodules in plymouth.hook

[Gerardo Malazdrewicz]

This patch works in experimental.

Just checked squeeze, pango-querymodules does not support --system, so this
patch would give an error there; --version is supported, though.

Regards,
Gerardo


pango_mod_version.patch
Description: Binary data

Bug#696482: mirror submission for mirror.1000mbps.com

[Tim Westervoorde // Base IP]

Hi Raphael,

This has been fixed :)

Kind regards,

Tim

-Oorspronkelijk bericht-
Van: Raphael Geissert [mailto:atom...@gmail.com] Namens Raphael Geissert
Verzonden: donderdag 7 maart 2013 22:34
Aan: mirrorad...@baseip.com; 696...@bugs.debian.org
Onderwerp: Re: Bug#696482: mirror submission for mirror.1000mbps.com

Hi,

On Sunday 03 March 2013 19:46:21 mirrorad...@baseip.com wrote:
> Trace files have been added. If there is anything else please let me 
> know.

They do not match the public host name of your mirror, could you please
rectify that and preferably switch to ftpsync?

Thanks,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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

Bug#693756: follow-up: suspend working, wifi explanation

[chrysn]

another update after some further tests:

* the suspend problem persists at least from kernel version 3.2 through
  to 3.8. an ubuntuforums report[1] claims that it suspend worked in
  ubuntu 12.04 but not in 12.10, the former using kernel 3.2, the latter
  3.5.

* the wifi power problem with brcmsmac persists in 3.8; the nonfree
  driver doesn't work with 3.8 so far at all (see bug #702788).

[1] 
http://forum.ubuntuusers.de/topic/ruhezustand-nach-dem-aufwecken-nur-schwarzer-b/#post-4958217


signature.asc
Description: Digital signature

Bug#702444: Bug#702519: unblock/pre-approval: perl and libencode-perl (memory leak in Encode::decode)

[Adam D. Barratt]

On 10.03.2013 19:00, Adam D. Barratt wrote:

On Sun, 2013-03-10 at 18:40 +0200, Niko Tyni wrote:

On Sat, Mar 09, 2013 at 08:49:59PM +, Adam D. Barratt wrote:
> On Thu, 2013-03-07 at 19:37 +0200, Niko Tyni wrote:
> > The wheezy side would need a tpu upload of libencode-perl and a 
sid

> > upload of perl (obviously after 5.14.2-19 has migrated.)
>
> It looks like libencode-perl was still in sync between sid and 
wheezy
> until Tuesday. :-( The diffs look okay and -19 migrated last 
night, so

> please go ahead.

Thanks, both uploaded earlier today.


Yep, spotted the tpu earlier and approved that; thanks. Once that's
migrated I'll look at the perl unblock.


perl unblocked and aged.

Regards,

Adam


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

Bug#702789: fresh upstream release (3.0.14) is available (uscan needs adjustment)

[Theodore Lytras]

Thanks for the report! I'm aware of this already.
I'm currently waiting for wheezy to be released, before I upload a new
zotero version to sid.

Theodre

2013/3/11 Yaroslav Halchenko :
> Package: xul-ext-zotero
> Version: 3.0.7-1
> Severity: wishlist
>
> apparently upstream was inconsistent and there is only now a link to the
> download page from the support page. so watch needs to be
>
> novo:/tmp/xul-ext-zotero-3.0.7
> $> cat debian/watch
> version=3
> http://www.zotero.org/download 
> http://download.zotero.org/extension/zotero-([\d\.]+)\.xpi debian xpi-repack
>
> then it picks up 3.0.14
>
> Cheers
>
> -- System Information:
> Debian Release: 7.0
>   APT prefers testing
>   APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), 
> (100, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages xul-ext-zotero depends on:
> ii  iceweasel  10.0.12esr-1
>
> xul-ext-zotero recommends no packages.
>
> xul-ext-zotero suggests no packages.


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

Bug#699277: doing lots of disk writes causes oom killer to kill processes

[Michal Suchanek]

On 8 February 2013 17:31, Michal Suchanek  wrote:
> Hello,
>
> I am dealing with VM disk images and performing something like wiping
> free space to prepare image for compressing and storing on server or
> copying it to external USB disk causes
>
> 1) system lockup in order of a few tens of seconds when all CPU cores
> are 100% used by system and the machine is basicaly unusable
>
> 2) oom killer killing processes
>
> This all on system with 8G ram so there should be plenty space to work with.
>
> This happens with kernels 3.6.4 or 3.7.1
>
> With earlier kernel versions (some 3.0 or 3.2 kernels) this was not a
> problem even with less ram.
>
> I have  vm.swappiness = 0 set for a long  time already.
>
>
I did some testing with 3.7.1 and with swappiness as much as 75 the
kernel still causes all cores to loop somewhere in system when writing
lots of data to disk.

With swappiness as much as 90 processes still get killed on large disk writes.

Given that the max is 100 the interval in which mm works at all is
going to be very narrow, less than 10% of the paramater range. This is
a severe regression as is the cpu time consumed by the kernel.

The io scheduler is the default cfq.

If you have any idea what to try other than downgrading to an earlier
unaffected kernel I would like to hear.

Thanks

Michal


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

Bug#702710: smarty: Possible XSS bug in Smarty error messages.

[Jan Lieskovsky]

Hello,

>> https://code.google.com/p/smarty-php/source/detail?r=4660
>
>  Good catch, thanks for your report :) 
> And I've made a debdiff as attached.
> 
>> security team
> I think it would be released as stable-proposed-updates since it has
> no CVEs, so I guess we probably say no DSAs for it.

Just FYI the CVE identifier of CVE-2012-4437 has been previously
assigned to this issue:
  http://www.openwall.com/lists/oss-security/2012/09/20/3
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4437

>
> And I don't know QA upload can be done as such way, so please let me
> know appropriate manner for upload if you know it.

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

>
>
> -- 
> Regards,
>
> Hideki Yamane henrich @ debian.or.jp/org
> http://wiki.debian.org/HidekiYamane


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

Bug#695460: zotero: problems with Bibtex compatibility

[Theodore Lytras]

Dear reporter,

Please check and report back whether this problem remains in the
latest upstream version of zotero (3.0.14).

If the problem remains, please open a bug report upstream. I doubt
this has anything to do with the packaging.

Theodore Lytras


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

Bug#702792: libconfig-model-perl: error when one uses extra chars near placeholders in version specification

[Antonio Valentino]

Package: libconfig-model-perl
Version: 2.021-3+deb7u1
Severity: normal

Dear Maintainer,
the cme tool raises the following error

$ cme check dpkg-control

[CUT]

Configuration item 'binary:polsarpro Depends:2' has a wrong value:
dependency 'polsarpro-bin (<< ${source:Version}.1~)' does not match 
grammar



when one tries to use something like the following

Depends: packagename (>= ${source:Version}),
 packagename (<< ${source:Version}.1~)

in a Depends field of a control file.
The problem seems to be related to extra chars near a version 
placeholder (see also [1]) that should be an allowed syntax.


Please note that the above seems to be the suggested solution to specify 
a dependency of a arch:all package from and arch:any package in a binNUM 
sefe way [2,3]



[1] http://lists.debian.org/debian-mentors/2013/03/msg00144.html
[2] http://lintian.debian.org/tags/not-binnmuable-all-depends-any.html
[3] http://lintian.debian.org/tags/weak-library-dev-dependency.html


thanks


-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 
'testing-proposed-updates'), (500, 'testing'), (1, 'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libconfig-model-perl depends on:
ii  libany-moose-perl 0.17-1
ii  libanyevent-http-perl 2.14-1
ii  libanyevent-perl  7.010-1
ii  libapt-pkg-perl   0.1.26+b1
ii  libcarp-assert-more-perl  1.12-2
ii  libexception-class-perl   1.32-1
ii  libfile-homedir-perl  0.99-1
ii  libhash-merge-perl0.12-2
ii  liblist-moreutils-perl0.33-1+b1
ii  liblog-log4perl-perl  1.29-1
ii  libmouse-perl 0.99-1
ii  libmousex-nativetraits-perl   1.07-1
ii  libmousex-strictconstructor-perl  0.02-1
ii  libnamespace-autoclean-perl   0.13-1
ii  libparse-recdescent-perl  1.967009+dfsg-1
ii  libpod-pom-perl   0.27-1
ii  libsoftware-license-perl  0.103004-2
ii  libtext-autoformat-perl   1.669002-1
ii  libtext-diff-perl 1.41-1
ii  libyaml-perl  0.81-1
ii  lintian   2.5.10.4
ii  perl  5.14.2-19

Versions of packages libconfig-model-perl recommends:
ii  bash-completion 1:2.0-1
ii  fuse-utils  2.9.0-2+deb7u1
ii  libfuse-perl0.15.1-2
ii  libmodule-corelist-perl 2.68-1
ii  perl5.14.2-19
ii  perl-modules [libmodule-corelist-perl]  5.14.2-19

Versions of packages libconfig-model-perl suggests:
pn  libconfig-model-tkui-perl   
pn  libterm-readline-perl-perl | libterm-readline-gnu-perl  

-- 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#692148: slim and systemd don't go along well at first run

[Ruben Pollan]

Package: slim
Version: 1.3.4-2
Followup-For: Bug #692148

I have the same problems. Actually I think most of the bugs reported on this
package are related with systemd.

The new version of slim (1.3.5) seems to include support for systemd:
https://lists.berlios.de/pipermail/slim-dev/2012-December/000352.html

Will be great to have it packaged. I can give a hand if the maintainer don't
have the time for it.

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

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

Versions of packages slim depends on:
ii  consolekit 0.4.5-3.1
ii  dbus   1.6.8-1
ii  debconf [debconf-2.0]  1.5.49
ii  libc6  2.13-38
ii  libck-connector0   0.4.5-3.1
ii  libdbus-1-31.6.8-1
ii  libfontconfig1 2.9.0-7.1
ii  libfreetype6   2.4.9-1.1
ii  libgcc11:4.7.2-5
ii  libjpeg8   8d-1
ii  libpam0g   1.1.3-9
ii  libpng12-0 1.2.49-3
ii  libstdc++6 4.7.2-5
ii  libx11-6   2:1.5.0-1
ii  libxft22.3.1-1
ii  libxmu62:1.1.1-1
ii  libxrender11:0.9.7-1
ii  zlib1g 1:1.2.7.dfsg-13

Versions of packages slim recommends:
ii  xterm  278-4

Versions of packages slim suggests:
pn  scrot  
ii  xauth  1:1.0.7-1

-- Configuration Files:
/etc/slim.conf changed [not included]

-- debconf information excluded

-- 
Rubén Pollán  | http://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   La felicidad no es hacer lo que deseas
 es desear lo que haces.


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

Bug#702793: tor: cached-descriptors is no longer updated

[Christoph Biedl]

Package: tor
Version: 0.2.3.25-1
Severity: normal

Dear Maintainer,

after upgrading from squeeze to wheezy I noticed the
cached-descriptors{,.new} files are no longer updated. Comparing with
another box that runs testing suggests that regression happened in the
0.2.2->0.2.3 upgrade.

Looking into the sources it seems the code to create these files is
still there but - for reasons I failed to identify - is not executed
any more. So I suspect this happened rather by accident, can you
please check?

Christoph

-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.4.33 (SMP w/4 CPU cores; PREEMPT)
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 tor depends on:
ii  adduser 3.113+nmu3
ii  libc6   2.13-38
ii  libevent-2.0-5  2.0.19-stable-3
ii  libssl1.0.0 1.0.1e-1
ii  lsb-base4.1+Debian8
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages tor recommends:
ii  logrotate3.8.1-4
pn  tor-geoipdb  
pn  torsocks 

Versions of packages tor suggests:
pn  apparmor-utils 
pn  mixmaster  
pn  polipo | privoxy   
ii  socat  1.7.1.3-1.4
pn  tor-arm
pn  xul-ext-torbutton  

-- Configuration Files:
/etc/logrotate.d/tor changed [not included]

-- no debconf information


signature.asc
Description: Digital signature

debian-bugs-dist@lists.debian.org

[Benjamin Eltzner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I made a new version (0.3.1-2) of the package currently in Wheezy that
also patches two other bugs identified upstream:
https://bugs.launchpad.net/qpdfview/+bug/1024227
https://bugs.launchpad.net/qpdfview/+bug/1133257

I think that none of these bugs justifies a freeze exception, but I
will send the new package to the sponsor of the qpdfview package so
the updated package is included into wheezy-updates if and when possible.

As Adam mentioned, this bug will be fixed in releases after 0.4.1 and
the fix will eventually trickle to unstable. I hope this solution is
satisfactory.

Best wishes,
Benjamin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRPep3AAoJEK27BRz67lmpPAkP/jpddtwzC7Z4fSJo6ibRUHjn
GmB6mzI1wKUWjQyWdoQtepXEem7YMW/KGkSOwPBwLCZOIIB3Otont850/0HiNAdH
v/S8Ys/tXFpMBu62LNspeXqJBXXxb9nyJKnP1IWzDe1D06XY0YoG/UyqDMd/LX00
VZUkPe3/TwR9Dn4ctY2nE7KYW2Top9GnwJZuw6fzV92jSZO77EIxKzwteKYyQxHI
YGXiZv7x7MJuq6PWMDnjO9cUe+DUS8V8z+YSHBRv7aH6hpoKGv/ZDiEDShXKtQiC
a4W9dAxtVH80/OnAmGxkmEZif2vLdSAU+WldVye3Q0ovl6A6YA0fi+7HzpMQhe1n
qk+VLD+yu+aXSeTGGelD2PZKUgNMleYjjFe67Ls6IiZB+JwN7h8X7bCooi0YbPGH
iol6vMy1UyWXaiYwe+v5YfV0yAHk8cHYxQyG+PyOi4Z9dX//Wb9AyTVIaIcOqGi3
o1mURDYpt+yVx8aKJAwZgnuA7vytkKlRdC8bZ9nh0u3VK3bQzXpMHdRBGpg5Kceu
j8T+FwbWthOp99jF5D5k6zhLCXnmGQP6Ko55CBzUUI7kF5otifdkMXo7ATjfz7nt
XCKk+CjJaAztKBdWqxsRPpVBJyv/KUbc9fynkl6azN9/NZ7otNHeNzIWDHAMc4SI
NzcBRami16UWbA2tZXZS
=ZlPr
-END PGP SIGNATURE-


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

Bug#702794: git-buildpackage: Should extract orig tarball from pristine-tar before building source package

[Felipe Sateler]

Package: git-buildpackage
Version: 0.6.0~git20121124
Severity: normal

When building a full (source+binary) package, dpkg-source is invoked  by
dpkg-buildpackage. dpkg-source needs the orig tarball in order to create
the source package. git-buildpackage should extract the tarball from the
pristine-tar branch (if it exists) before invoking dpkg-source (if the
tarball does not already exist), otherwise the build fails because the
orig tarball was not found.

In case this is a configuration corner case, here is my
~/.gbp.conf:

[DEFAULT]
#pristine-tar = True

[git-buildpackage]
export-dir=../build-area
sign-tags=True

[git-import-orig]
sign-tags=True

[git-dch]
multimaint-merge=True


And debian/gbp.conf:

[DEFAULT]
pristine-tar = True
sign-tags = True

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts   2.12.6
ii  git  1:1.7.10.4-2
ii  python   2.7.3-4
ii  python-dateutil  1.5+dfsg-0.1

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.71
ii  pristine-tar  1.26

Versions of packages git-buildpackage suggests:
ii  python-notify  0.1.1-3
ii  unzip  6.0-9

-- 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#702793: tor: cached-descriptors is no longer updated

[Peter Palfrader]

Hi Christoph,

Christoph Biedl schrieb am Montag, dem 11. März 2013:

> after upgrading from squeeze to wheezy I noticed the
> cached-descriptors{,.new} files are no longer updated. Comparing with
> another box that runs testing suggests that regression happened in the
> 0.2.2->0.2.3 upgrade.

Tor clients no longer need full desctiptors.  Instead they get
microdesctipros where possible.

> Looking into the sources it seems the code to create these files is
> still there but - for reasons I failed to identify - is not executed
> any more. So I suspect this happened rather by accident, can you
> please check?

If your tor needs the full descriptors, it can still get them, and then
it should cache them.  Mostly, it doesn't unless you mirror the
directory for instance.

Why is that a problem?

Cheers,
weasel
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


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

Bug#702795: Package coreutils, application touch fails to set modification time to a file on Mars 10, 2013

[Jose Manuel Abad Hernandez]

Package: coreutils
Version: 8.5-1
Operating System: Debian GNU/Linux 6.0.5 x86_64 Squeeze

Fail description:

When running "touch" to set the modification time of a file on Mars 10, 2013, the 
application return <> as shown with the followings lines copied from 
the server console:

root@pl:~#touch -m -t 20130310.00 /var/tmp/borrame
touch: formato de fecha inválido «20130310.00»
root@pl:~#

Sorry, my server talk spanish.

Any other date in 2013 year runs fine.

Regards,

Jose Manuel Abad Hernandez


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

Bug#699611: xymon: fails to install: chown: invalid user: 'xymon:xymon'

[Axel Beckert]

Hi Andreas,

Andreas Beckmann wrote:
> Package: xymon
> Version: 4.3.7-1
> Severity: serious

I've downgraded the severity as this issue is just present in the
experimental package and hence can't be RC. That package is btw.
really considered experimental and not just because of the freeze in
experimental.

> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.

The culprit was a non-versioned dependency.

>   invoke-rc.d: unknown initscript, /etc/init.d/xymon-client not found.
[...]
>   chown: invalid user: 'xymon:xymon'

The according init script and adduser command is in xymon-client, but
only in version 4.3.7-1 and above. According to the log, xymon-client
4.3.0~beta2.dfsg-9.1 from Sid has been installed.

The fix for that is already in the git repo for a while:
http://anonscm.debian.org/gitweb/?p=collab-maint/xymon.git;a=commitdiff;h=8002cfce2c3b4b659baa3fe48a46da4eb2a03c2e

Guess I should upload another WIP package to experimental soonish to
fix all the known issues.

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#702617: [Pkg-haskell-maintainers] Bug#702617: . fails to match certian characters

[Joachim Breitner]

Hi,

Am Samstag, den 09.03.2013, 11:52 -0400 schrieb Joey Hess:
> Joachim Breitner wrote:
> > regex-compat is but a thin layour around regex-posix, which states
> > Note that the posix library works with single byte characters,
> > and does not understand Unicode. If you need Unicode support you
> > will have to use a different backend.¹
> 
> Right. However, ò is not actually unicode, I think it's ISO8859-15.
> 
> Also I'm not trying to do anything that requires knowledge of unicode.
> Even if the library sees [byte, byte], "^.*$" should still match all
> the bytes.

The library should actually see "\242\0", and gdb verifies that this is
in the CString. Nevertheless, I cannot reproduce this behavior in C:

#include 
#include 
#include 

main () {
regex_t r;
regcomp(&r, ".", 0);
char *s = "\242";
int i = regexec(&r, s, 0, NULL, 0);
printf("%d\n", i);
}

prints 0, i.e. match succeeded.

But on the lowest layer above the FFI, I the strange behaviour already
occurs:

Prelude Foreign.C.String Text.Regex.Posix.Wrap> cs <- newCAString "\242"
Prelude Foreign.C.String Text.Regex.Posix.Wrap> cp <- newCAString "."
Prelude Foreign.C.String Text.Regex.Posix.Wrap> 
Prelude Foreign.C.String Text.Regex.Posix.Wrap> Right r2 <- wrapCompile 0 0 cp
Prelude Foreign.C.String Text.Regex.Posix.Wrap> 
Prelude Foreign.C.String Text.Regex.Posix.Wrap> wrapTest r2 cs
Right False

It is False for \128 and True for \127

The code in question is here:
http://hackage.haskell.org/packages/archive/regex-posix/0.95.2/doc/html/src/Text-Regex-Posix-Wrap.html

Changing the regex to "^$" or "^.*$" does not make a difference, i.e.
the string is not just turned to the empty string. Clearly something is
broken here.

I can reproduce it from within ghc’s address space using gdb:

(gdb) call malloc(32)
$7 = 64943120
(gdb) call regcomp(64943120, ".", 0)
$8 = 0
(gdb) call regexec(64943120,"\242",0,0,0)
$9 = 1
(gdb) call regexec(64943120,"only_ascii",0,0,0)
$10 = 0

And even from gdb while debugging “sleep”. So the behaviour is already
there in regexec, but for some reason it is not triggered from C code,
but only via some variants of FFI (GHC’s or gdb’s).

I’ll leave it at that, as this is not really related to GHC or Haskell
any more.

Greetings,
Joachim

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



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

Bug#695353: Confirmed and already fixed bug in another distros

[Javier Cantero]

I can confirm this bug. Some tumbler instances trying to generate a
thumbnail of a video file prevent the file system to be unmounted. This
happens with a USB memory stick, for example.

The bug is also reported in another debian based distros with the same
package version, and already fixed (see Ubuntu bug #995918,
"02_set-gststate-on-error.patch: close file on error." and related
Xfce bug #8303 https://bugzilla.xfce.org/show_bug.cgi?id=8303 )

This is a quite annoying issue and should be considered to be fixed before
the stable release is launched.


-- 
   Saludos de Javier 



signature.asc
Description: Digital signature

Bug#700580: [PATCH] Make test for gnuplot work with empty strings.

[Martin Steigerwald]

When I launch fio_generate_plots on a system where gnuplot is not installed I
get this error :

$ fio_generate_plots test
Making bw logs
/usr/bin/fio_generate_plots: 42: /usr/bin/fio_generate_plots: -: not found

That's because the test checking whether gnuplot is installed is failing
because of an empty variable :
GNUPLOT=$(which gnuplot)
if [ ! -x $GNUPLOT ]; then
echo You need gnuplot installed to generate graphs
exit 1
fi

Indeed the command "test -x" is exiting with code 0.

To correct this we should enclose the variable with quotes :
if [ ! -x "$GNUPLOT" ]; then

Then the script is going into the test properly :
$ fio_generate_plots test
You need gnuplot installed to generate graphs

I copied problem description by Hervé from the Debian bug report below.

Fixes:
Bug#700580: /usr/bin/fio_generate_plots: -: not found
http://bugs.debian.org/700580

Reported-By: Hervé Werner 
Tested-By: Hervé Werner 
Tested-By: Martin Steigerwald 
---
 fio_generate_plots |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fio_generate_plots b/fio_generate_plots
index 4285415..5e2febd 100755
--- a/fio_generate_plots
+++ b/fio_generate_plots
@@ -8,7 +8,7 @@ if [ "$1"x = "x" ]; then
 fi
 
 GNUPLOT=$(which gnuplot)
-if [ ! -x $GNUPLOT ]; then
+if [ ! -x "$GNUPLOT" ]; then
echo You need gnuplot installed to generate graphs
exit 1
 fi
-- 
1.7.10.4


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

Bug#702747: korganizer: date parsing way too strict, 6:50PM should work

[Lisandro Damián Nicanor Pérez Meyer]

Control: severity -1 wishlist

On Sun 10 Mar 2013 20:53:25 David Fries escribió:
> Package: korganizer
> Version: 4:4.4.11.1+l10n-3+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> korganizer date and time input prasing is too strict.  Enter 6:50PM
> and it complains and suggests '06:44 PM', a leading 0 is not normally
> written by humans writing a time, so computers need to accept that,
> having a space before PM should not be required.  This is with the
> default timeformat, "PH:MM:SS AMPM".

Hi David!

This is an upstream wishlist bug. Saddly korganizer 4.4 is not maintained 
anymore.

Sometime after the Wheezy release we are going to upload a new version of KDE 
PIM (no date promised, though). Please feel free to check if this still 
applies when that happens.

Kinds regards, Lisandro.

-- 
Un viejo proverbio de El.Machi dice que la memoria es como
las papas fritas... ¡nunca sobran!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#701257: Could you provide more info, please

[David García Garzón]

I am one of the developers of the CLAM framework trying to reproduce the
bug in Ubuntu (gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2) with no luck.

My guess is that some system headers (in Debian and Gentoo but not in
Ubuntu) define TIME_UTC as preprocessor macro. If someone being able to
reproduce the bug could confirm this point (by inserting #ifdef TIME_UTC
#error) and locating the header we could move forward.

David Garcia.


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

Bug#702796: unblock: haskell-certificate et. al.

[Joachim Breitner]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is trying to get #701593 into testing. Not all arches have built
everything yet, but I guess I can get the unblock on the way.

The main fixes that we want to get into testing are these:

unblock haskell-tls-extra/0.4.6.1-2
unblock haskell-certificate/1.2.3-2

To migrate, this will also pull some binNMUed reverse dependencies,
including (but probably more):
libghc-http-conduit-dev libghc-tls-dev libghc-warp-tls-dev

Unfortunately, there was a version hiccup that required changes to
debian/control for some of the rebuilds. I’m not yet sure which of these
will have to go in to allow the above transition, but I’m sure that
waiting britney’s output will be easier than manually finding the
minimal set. At least http-conduit will need this, so please also

unblock haskell-http-conduit/1.4.1.6-3

The attached debdiff is represenative for all these
version-hiccup-fixing uploads. The packages that had the hiccup
(haskell-persistent, haskell-blaze-builder-conduit) do not need to
migrate.

Greetings,
Joachim

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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlE9/ZgACgkQ9ijrk0dDIGwGwQCdFQkh3TOPpIuxq+ru5FV/I6jl
zsYAmwSu1JYfL4+ZDxBPvTQ2WBDzCrR1
=noRR
-END PGP SIGNATURE-
diff -Nru haskell-http-conduit-1.4.1.6/debian/changelog haskell-http-conduit-1.4.1.6/debian/changelog
--- haskell-http-conduit-1.4.1.6/debian/changelog	2012-05-19 17:40:51.0 +0200
+++ haskell-http-conduit-1.4.1.6/debian/changelog	2013-03-11 16:48:11.0 +0100
@@ -1,3 +1,16 @@
+haskell-http-conduit (1.4.1.6-3) unstable; urgency=low
+
+  * Allow both strange and normal version in libghc-blaze-builder-conduit-dev
+dependency
+
+ -- Joachim Breitner   Mon, 11 Mar 2013 16:48:11 +0100
+
+haskell-http-conduit (1.4.1.6-2) unstable; urgency=low
+
+  * Allow strange version in libghc-blaze-builder-conduit-dev dependency 
+
+ -- Joachim Breitner   Sun, 10 Mar 2013 22:00:03 +0100
+
 haskell-http-conduit (1.4.1.6-1) unstable; urgency=low
 
   * New upstream version.
diff -Nru haskell-http-conduit-1.4.1.6/debian/control haskell-http-conduit-1.4.1.6/debian/control
--- haskell-http-conduit-1.4.1.6/debian/control	2012-05-19 17:40:57.0 +0200
+++ haskell-http-conduit-1.4.1.6/debian/control	2013-03-11 16:47:48.0 +0100
@@ -24,7 +24,8 @@
   , libghc-blaze-builder-dev (<< 0.4)
   , libghc-blaze-builder-prof
   , libghc-blaze-builder-conduit-dev (>> 0.4)
-  , libghc-blaze-builder-conduit-dev (<< 0.5)
+  , libghc-blaze-builder-conduit-dev (<< 0.5) | libghc-blaze-builder-conduit-dev (>> 0.5.0.1.is.really.0.4),
+  , libghc-blaze-builder-conduit-dev (<< 0.5.0.1.is.really.0.5)
   , libghc-blaze-builder-conduit-prof
   , libghc-case-insensitive-dev (>> 0.2)
   , libghc-case-insensitive-prof
diff -Nru haskell-tls-extra-0.4.6.1/debian/changelog haskell-tls-extra-0.4.6.1/debian/changelog
--- haskell-tls-extra-0.4.6.1/debian/changelog	2013-01-20 23:26:26.0 +0100
+++ haskell-tls-extra-0.4.6.1/debian/changelog	2013-03-10 22:04:56.0 +0100
@@ -1,3 +1,14 @@
+haskell-tls-extra (0.4.6.1-2) unstable; urgency=low
+
+  * Fix regression introduced with the last commit, by adding compatibility
+with a corresponding change in haskell-certificate (Bug #700284), patch
+provided by Joey Hess. Closes: #701593.
+Also Closes: #702151, as the removal should no longer be necessary.
+  * Stop pretending this has a different version, as we need to rebuild stuff
+anyways.
+
+ -- Joachim Breitner   Sun, 10 Mar 2013 22:04:56 +0100
+
 haskell-tls-extra (0.4.6.1-1) unstable; urgency=low
 
   * New upstream release, aimed for wheezy.
diff -Nru haskell-tls-extra-0.4.6.1/debian/control haskell-tls-extra-0.4.6.1/debian/control
--- haskell-tls-extra-0.4.6.1/debian/control	2012-05-15 03:04:36.0 +0200
+++ haskell-tls-extra-0.4.6.1/debian/control	2013-03-10 21:09:26.0 +0100
@@ -8,7 +8,7 @@
   , haskell-devscripts (>= 0.8)
   , ghc
   , ghc-prof
-  , libghc-certificate-dev (>> 1.2.0)
+  , libghc-certificate-dev (>= 1.2.3-2)
   , libghc-certificate-dev (<< 1.3.0)
   , libghc-certificate-prof
   , libghc-crypto-api-dev (>> 0.5)
diff -Nru haskell-tls-extra-0.4.6.1/debian/patches/haskell-tls-extra.patch haskell-tls-extra-0.4.6.1/debian/patches/haskell-tls-extra.patch
--- haskell-tls-extra-0.4.6.1/debian/patches/haskell-tls-extra.patch	1970-01-01 01:00:00.0 +0100
+++ haskell-tls-extra-0.4.6.1/debian/patches/haskell-tls-extra.patch	2013-03-10 21:09:08.0 +0100
@@ -0,0 +1,15 @@
+Author: Joey Hess 
+Bug-Debian: http://

Bug#702617: [Pkg-haskell-maintainers] Bug#702617: . fails to match certian characters

[Joey Hess]

Joachim Breitner wrote:
> I can reproduce it from within ghc’s address space using gdb:
> 
> (gdb) call malloc(32)
> $7 = 64943120
> (gdb) call regcomp(64943120, ".", 0)
> $8 = 0
> (gdb) call regexec(64943120,"\242",0,0,0)
> $9 = 1
> (gdb) call regexec(64943120,"only_ascii",0,0,0)
> $10 = 0
> 
> And even from gdb while debugging “sleep”. So the behaviour is already
> there in regexec, but for some reason it is not triggered from C code,
> but only via some variants of FFI (GHC’s or gdb’s).
> 
> I’ll leave it at that, as this is not really related to GHC or Haskell
> any more.

That's some deep dive!

Sounds like a reassign to glibc is in order?

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#702797: DEB_BUILD_OPTIONS' parallel flag is not parsed correctly

[Robie Basak]

Package: mongodb
Version: 1:2.2.2-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu raring ubuntu-patch

If I use DEB_BUILD_OPTIONS="nocheck parallel=3" then DEB_SCONS_OPTIONS
ends up getting set to "-jnocheck" (or something like that) and the
build fails.

This violates Debian Policy (section 4.9.1).

The fix is trivial. Patch below. I've taken the parsing of the parallel
flag directly from the example in policy.

Thanks

--- debian/rules.orig   2013-03-11 15:41:39.282043551 +
+++ debian/rules2013-03-11 15:42:10.834051515 +
@@ -14,7 +14,7 @@
DEB_SCONS_OPTIONS := --d=DEBUGBUILD
 endif
 ifneq (,$(findstring parallel,$(DEB_BUILD_OPTIONS)))
-   PROCS=$(subst parallel=,,$(DEB_BUILD_OPTIONS))
+   PROCS=$(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
DEB_SCONS_OPTIONS += -j$(PROCS)
 endif
 


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

Bug#702799: unblock: sks/1.1.3-2

[Christoph Martin]

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

Please unblock package sks

I'd like to upload a fix for sks rc bug #699848. The bug prevents sks
from building an initial database. Included are the following minimal
fixes which do not change the functioning of sks.

+  * add Vcs tags to control file
+  * fix watch file because of upstream move
+  * add Homepage tag to control file

included is a debdiff. I would upload to testing-updates(?) as soon as
you approve.

unblock sks/1.1.3-2

Christoph


-- 

Christoph Martin, Zentrum für Datenverarbeitung, Uni-Mainz, Germany
 Instant-Messaging: Jabber: mar...@uni-mainz.de
  (Siehe http://www.zdv.uni-mainz.de/4010.php)
diff -Nru sks-1.1.3/debian/changelog sks-1.1.3/debian/changelog
--- sks-1.1.3/debian/changelog  2012-06-20 11:59:13.0 +0200
+++ sks-1.1.3/debian/changelog  2013-03-11 16:32:52.0 +0100
@@ -1,3 +1,12 @@
+sks (1.1.3-2) UNRELEASED; urgency=high
+
+  * add Vcs tags to control file
+  * fix watch file because of upstream move
+  * add Homepage tag to control file
+  * add db parameter to sksconf to fix db build deadlocks (closes: #699848)
+
+ -- Christoph Martin   Mon, 11 Mar 2013 
16:32:52 +0100
+
 sks (1.1.3-1) unstable; urgency=low
 
   * New upstream release (closes: #663757)
diff -Nru sks-1.1.3/debian/control sks-1.1.3/debian/control
--- sks-1.1.3/debian/control2012-06-20 10:41:30.0 +0200
+++ sks-1.1.3/debian/control2012-10-15 11:45:50.0 +0200
@@ -5,6 +5,8 @@
 Maintainer: Christoph Martin 
 Uploaders: Fabio M. Di Nitto 
 Build-Depends: ocaml (>= 3.08), camlp4, libdb-dev, debhelper (>= 7.0.50~), 
zlib1g-dev, libcryptokit-ocaml-dev (>= 1.2-4), ocaml-nox (>= 1.3-4), perl, 
perl-doc, dh-ocaml (>= 0.9~)
+Vcs-Browser: http://svn.debian.org/wsvn/pkg-sks
+Vcs-Svn: svn://svn.debian.org/pkg-sks/
 
 Package: sks
 Architecture: any
@@ -19,3 +21,4 @@
  This key server implementation uses an efficient and reliable reconciliation
  algorithm to keep the database in sync with other SKS servers.  Additionally
  it can both send and receive PKS style sync emails.
+Homepage: https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home
diff -Nru sks-1.1.3/debian/debcfg/sksconf sks-1.1.3/debian/debcfg/sksconf
--- sks-1.1.3/debian/debcfg/sksconf 2012-06-20 10:41:30.0 +0200
+++ sks-1.1.3/debian/debcfg/sksconf 2013-03-11 16:30:45.0 +0100
@@ -30,3 +30,11 @@
 
 # Runs database statistics calculation on boot (time and cpu expensive)
 #initial_stat:
+
+# bdb's db_tune program suggests a pagesize of 65536 for [K]DB/key. In practice
+# this caused page deadlocks. I found 8K (16) and 16K (32) to be better values
+pagesize:  16
+#
+# The tuner recommended 4096 (8) for the pagesize for PTree/ptree. I have had
+# very good results with 8196
+ptree_pagesize:16
diff -Nru sks-1.1.3/debian/watch sks-1.1.3/debian/watch
--- sks-1.1.3/debian/watch  2012-06-20 10:41:30.0 +0200
+++ sks-1.1.3/debian/watch  2012-10-15 11:43:59.0 +0200
@@ -1,2 +1,2 @@
 version=3
-opts=downloadurlmangle=s/\/\/code.google.com// 
http://code.google.com/p/sks-keyserver/downloads/list?can=1 
.*/sks-(\d[\d.]*)\.(?:zip|tgz|tbz2|txz|tar\.gz|tar\.bz2|tar\.xz)
+https://bitbucket.org/skskeyserver/sks-keyserver/downloads/sks-(\d[\d.]*)\.(?:zip|tgz|tbz2|txz|tar\.gz|tar\.bz2|tar\.xz)
<>

signature.asc
Description: OpenPGP digital signature

Bug#702453: update from squeeze to wheezy breaks because of broken dependencies

[Thomas Rechberger]

Hi

thx for patch, however i also dont know how to test if it happens during 
dist-upgrade.


Am 10.03.2013 21:15, schrieb Thomas Preud'homme:

tags 702453 + patch
thanks

Hi Thomas,

thanks for your bug report.

Le mercredi 6 mars 2013 19:47:45, Thomas Rechberger a écrit :

Did an upgrade from a default squeeze install to wheezy on Vmware
Workstation 8. The apt-get dist-upgrade process failed during installation
of gir1.2-cogl-1.0 because gir1.0-clutter-1.0 is still installed.
The installation was in a non working state after reboot and lost also the
network connection.
Upgrade process was followed as written in:
http://www.debian.org/releases/wheezy/i386/release-notes/ch-upgrading.de.ht
ml

After dpkg -r --force-depends gir1.0-clutter-1.0 the upgrade was able to
continue.

I suggest that the old gir1.0-clutter-1.0 should be removed by new package
before the new one is installed.

Right. Adding a conflicts should do it. They share one file and should thus
not be unpacked at the same time. See attached patch.

Unfortunetely, I couldn't reproduce the bug on my system so I can't check that
this patch work.

Best regards,

Thomas



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

Bug#685230: unblock hylafax 3:6.0.6-4 / -5

[Joachim Wiedorn]

Hallo Giuseppe,

Giuseppe Sacco wrote on 2013-03-11 00:16:

> I checked your package diff, rebuilt the package and tested it. Then I 
> uploaded it, so hopefully it should enter unstable.

Perfectly!

> Tomorrow I will also check capi4hylafax -19. If you still need a 
> sponsor, I'll gladly upload the package.

This would be very nice. Unfortunately until now I haven't any answer
about my pre-approval of capi4hylafax ...300-19 from release team:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699171
But without the updated capi4hylafax the RC bug #661482 cannot be solved.

---
Have a nice day.

Joachim (Germany)


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

Bug#702706: Debirf 0.33 in Wheezy with 3.8.1 kernel. rc=134

[J. Cassidy]

Control: tag 702706 + moreinfo

On 03/10/2013 10:43 AM, J. Cassidy wrote:
Debirf 0.33


some more related stuff.

Debirf has built me a 3.2.x kernel... see below -

root@Carcassonne ~/debirf/xkiosk: ls -als
total 132168
 4 drwxr-xr-x  5 1000 1000  4096 Mar 11 17:43 .
 4 drwxr-xr-x  5 root root  4096 Mar 11 16:37 ..
40 -rw-r--r--  1 root root 39468 Mar 11 17:39 .bootstrap.log 40
-rw-r--r--  1 root root 39468 Mar 11 16:45 bootstrap.log
 4 -rw-r--r--  1 1000 1000  1453 Mar 11 17:34 debirf.conf
128444 -rw-r--r--  1 root root 131521379 Mar 11 17:44
debirf-xkiosk_wheezy_3.2.0-4-amd64.cgz
   856 -rw-r--r--  1 root root873303 Mar 11 17:44
.fakeroot-state.debirf-xkiosk
 4 drwxr-xr-x  2 1000 1000  4096 Dec  5  2011 modules
 4 drwxr-xr-x  4 root root  4096 Mar 11 17:43 nest
 4 drwxr-xr-x 22 root root  4096 Mar 11 17:43 root
  2764 -rw-r--r--  1 root root   2829472 Dec 19 15:16 vmlinuz-3.2.0-4-amd64






=> Hello Daniel,
=>
=> appreciate the time you have taken to look at my problem.
=>
=> Answers below:
=>
=> => Control: tag 702706 + moreinfo
=> =>
=> => On 03/10/2013 10:43 AM, J. Cassidy wrote:
=> =>> Package: Debirf 0.33
=> =>>
=> =>> Debirf 0.33 in Wheezy with 3.8.1 kernel. rc=134
=> =>
=>
=> Are you running your own build of the kernel, or the build from debian
=> experimental?  it looks to me like you're doing this on amd64 as well
-- => is that right? - My own build yes, 64 bit.
=>
=>
=> =>
=> =>> on running "debirf make xkiosk" using the abovementioned setup all
=> seems
=> =>> to proceed well (Retrieving, Validating etc.) until this -
=> =>
=> were you hoping to build a debirf image with the 3.8 kernel?  or with
=> the stock wheezy kernel?  That is, is 3.8 a property of the build
system => or the intended target?  if it is intended for the target, how
were you => instructing debirf to build against the 3.8 kernel?
=>
=> It was my naiive asssumption that the debirf process would use the =>
existing (my own build) kernel  variables / parameters
=> to do it's thing..
=>
=> in particular, can you supply the output of uname -r ?
=>
=> root@Carcassonne ~: uname -ars
=> Linux Carcassonne 3.8.1 #2 SMP PREEMPT Sat Mar 2 11:04:32 CET 2013
x86_64 => GNU/Linux
=>
=>
=> =>
=> => the install-kernel module assumes that the kernel flavor (e.g.
"amd64") => => can be derived from $(uname -r | cut -d- -f3-).  If your
kernel doesn't => => supply that, you can force the matter with an
environment variable, by => => running like:
=> =>
=> =>  DEBIRF_KERNEL_FLAVOR=amd64 debirf make xkiosk
=> =>
=> =>> Debirf with the "r" switch produces a slightly different error
message => -
=> =>
=> We generally discourage running with -r, since it has the possibility
of => modifying the build system itself.
=>
=> I ran with the "r" switch to see if the ensuing output would enlighten
me => more perhaps.
=>
=>
=>
=>
=> Debirf conf (xkiosk)
=> 
=>
=> # DEBIRF configuration file: this will be sourced by bash
=>
=> # Label for debirf system (for hostname and initrd).  "debirf" will be
=> # used if unspecified.
=> #
=> DEBIRF_LABEL="debirf-xkiosk"
=>
=> # Where shoud debirf build the image?  By default, debirf will build =>
# in the profile directory.
=> #
=> #DEBIRF_BUILDD=
=>
=> # What suite should be used?  The default is determined by
=> # lsb_release, and falls back to "sid".
=> #
=> #DEBIRF_SUITE=
=>
=> # The default distro (eg. "debian" or "ubuntu") is based on the distro
=> # of the suite specified.  If you want to use a suite from a
=> # non-Debian/Ubuntu distro, specify the distro explicitly here (all =>
# lowercase).
=> #
=> #DEBIRF_DISTRO=
=>
=> # What mirror should debirf pull the suite from?  By default, this is
=> # based on the DEBIRF_DISTRO
=> # (eg. "http://mirrors.kernel.org/${DEBIRF_DISTRO}";).
=> #
=> #DEBIRF_MIRROR=
=>
=> # What keyring should be used to verify the debootstrap for the => #
specified suite?  This is also based on the DEBIRF_DISTRO by
=> # default.  If you are trying to build a non-Debian/Ubuntu version of
=> # debirf, then you will need to specify the keyring explicitly here if
=> # you want to verify the debootstrap.  Otherwise, uncomment the => #
variable but leave the definition blank to have debirf skip the => #
debootstrap verification.
=> #
=> #DEBIRF_KEYRING=
=>
=> # Use a web proxy for downloading the packages (the "export" in front
=> # of the variable is necessary to have it recognized by all internal =>
# functions).
=> #
=> #export http_proxy=
=>
=>
=>
=> I have just ran --debirf make xkiosk-- again, beforehand I set the =>
variable "DEBIRF_KERNEL_FLAVOR=amd64 debirf make xkiosk" via export. =>
=> Debirf now runs/works... but with a lot of references to Squeeze in the
=> installation dialogue(s).
=>
=> Please see attached bootstrap log.
=>
=> If you need any more information, please let me know.
=>
=>
=> Regards,
=>
=>
=> John Cassidy
=>
=>
=>
=>
=> John Cassidy (Dipl.-Ing.)
=>
=> Kapellenstr. 21a
=>
=> D-65193 Wiesbaden
=>
=

Bug#702706: Debirf 0.33 in Wheezy with 3.8.1 kernel. rc=134

[J. Cassidy]

Hello Daniel,

appreciate the time you have taken to look at my problem.

Answers below:

Control: tag 702706 + moreinfo

On 03/10/2013 10:43 AM, J. Cassidy wrote:
Debirf 0.33

Debirf 0.33 in Wheezy with 3.8.1 kernel. rc=134


Are you running your own build of the kernel, or the build from debian
experimental?  it looks to me like you're doing this on amd64 as well --
is that right? - My own build yes, 64 bit.



were you hoping to build a debirf image with the 3.8 kernel?  or with
the stock wheezy kernel?  That is, is 3.8 a property of the build system
or the intended target?  if it is intended for the target, how were you
instructing debirf to build against the 3.8 kernel?

It was my naiive asssumption that the debirf process would use the
existing (my own build) kernel  variables / parameters to do it's thing..

in particular, can you supply the output of uname -r ?

root@Carcassonne ~: uname -ars
Linux Carcassonne 3.8.1 #2 SMP PREEMPT Sat Mar 2 11:04:32 CET 2013 x86_64




the install-kernel module assumes that the kernel flavor (e.g. "amd64")
can be derived from $(uname -r | cut -d- -f3-).  If your kernel doesn't
supply that, you can force the matter with an environment variable, by
running like:

DEBIRF_KERNEL_FLAVOR=amd64 debirf make xkiosk

Debirf with the "r" switch produces a slightly different error message


We generally discourage running with -r, since it has the possibility of
modifying the build system itself.

I ran with the "r" switch to see if the ensuing output would enlighten me
more perhaps.

John Cassidy (Dipl.-Ing.)

Kapellenstr. 21a

D-65193 Wiesbaden

EU



Mobile: +49 (0) 170 794 3616


http://www.JDCassidy.eu
http://en.federaleurope.org/


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

Bug#702800: grub-efi: Upgrade failed to install properly? symbol not found: grub_efi_secure_boot

[Daniel Kahn Gillmor]

Package: grub-efi
Version: 2.00-13
Severity: normal

i'm running grub from debian experimental on an EFI machine.  I
installed grub 2.00-13 on february 19th, but haven't rebooted from
then until yesterday.

When i booted, i got this failure from grub when invoking the "linux"
command:

  symbol not found: `grub_efi_secure_boot'

i suspect this means that my EFI image is out of date, but i'm a
little confused about why that would be.

i see that i have both of these files:

  /boot/efi/EFI/boot/bootx64.efi 
  /boot/efi/EFI/debian/grubx64.efi

but only the latter was updated on February 19th the other is much
older and the two files have different content.

This suggests that the upgrade process probably did the wrong thing,
but i'm not sure what went awry.

Details:

0 dkg@alice:~$ grep efi /proc/mounts 
/dev/sda1 /boot/efi vfat 
rw,nosuid,nodev,noexec,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro
 0 0
0 dkg@alice:~$ find /boot/efi -type f -ls
12  119 -rwxr-xr-x   1 root root   121856 Feb 19 09:53 
/boot/efi/EFI/debian/grubx64.efi
10  119 -rwxr-xr-x   1 root root   121856 Dec 10 17:56 
/boot/efi/EFI/boot/bootx64.efi
0 dkg@alice:~$ find /boot/efi -type f | xargs sha1sum
44b0772733180e7f5c6f7eb29af6b03c90d15390  /boot/efi/EFI/debian/grubx64.efi
224e3961a229a51a5646d8216d2d5983307d6d48  /boot/efi/EFI/boot/bootx64.efi
0 dkg@alice:~$ grep configure\ grub-efi /var/log/dpkg.log.1 
2013-02-19 09:53:24 configure grub-efi-amd64-bin:amd64 2.00-13 
2013-02-19 09:53:24 configure grub-efi-amd64:amd64 2.00-13 
2013-02-19 09:53:29 configure grub-efi:amd64 2.00-13 
0 dkg@alice:~$ 

Thanks for maintaining grub in debian!

Regards,

  --dkg

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

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

Versions of packages grub-efi depends on:
ii  grub-common 2.00-13
ii  grub-efi-amd64  2.00-13

grub-efi recommends no packages.

grub-efi 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#702412: pre-approval unblock: postfix

[LaMont Jones]

On Sat, Mar 09, 2013 at 05:59:32PM +, Adam D. Barratt wrote:
> A debdiff against the current wheezy package (possibly minus the .po
> changes and some of the repetitive documentation updates) would probably
> have been more useful, fwiw.

Noted for the future.

> > The source and amd64 binaries are to be found at:
> > deb http://people.debian.org/~lamont/postfix .
> > deb-src http://people.debian.org/~lamont/postfix .
> Please go ahead; thanks.

Done


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

Bug#702801: cp2k: dependence of DFTB-results on the input-sequence of heavy atoms

[Michael Banck]

Package: cp2k
Version: 2.2.426-6
Severity: serious

A bug was found in cp2k's DFTB module where the results are dependent on
the input-ordering of heavy atoms.  The following two input files
(attached) from the current upstream regression testsuite differ only in
the order the Carbon and Oxygen atoms are defined:

--- co2_1.inp   2013-03-11 17:03:49.456297517 +0100
+++ co2_2.inp   2013-03-11 17:03:49.459607156 +0100
@@ -30,8 +30,8 @@
   PERIODIC NONE
 &END CELL
 &COORD
-  O  0.0  0.0  +1.2
   C  0.0   0.00.0
+  O  0.0  0.0  +1.2
   O   0.0  0.0  -1.2
 &END COORD
   &END SUBSYS

Yet, the calculated total energy are markedly different:

nighthawk~/cp2k-2.2.426/tests/DFTB/regtest-nonscc$ cp2k.popt co2_1.inp | grep 
ENERGY.*Total
 ENERGY| Total FORCE_EVAL ( QS ) energy (a.u.): -8.555862465666859
nighthawk~/cp2k-2.2.426/tests/DFTB/regtest-nonscc$ cp2k.popt co2_2.inp | grep 
ENERGY.*Total
 ENERGY| Total FORCE_EVAL ( QS ) energy (a.u.): -8.659241457828779


Michael


co2_1.inp
Description: chemical/gamess-input


co2_2.inp
Description: chemical/gamess-input

Bug#698245: unblock: moodle/2.2.3.dfsg-2.6~wheezy2

[Jonathan Wiltshire]

On 2013-03-11 10:18, Tomasz Muras wrote:

On 03/11/2013 10:49 AM, Didier 'OdyX' Raboud wrote:
a) we fail at releasing Moodle updates to unstable in a timely 
manner (and I

have my share of the fault here);
b) we consequently fail at releasing Moodle security updates to 
wheezy in a

timely manner (this unblock is opened for almost two months);
c) Moodle 2.2 is already not supported anymore by Moodle HQ for 
anything (not

even security), according to [0];
Furthermore on that point, as far as I can see, there is noone 
taking
responsibility to handle Moodle 2.2 security on the long term 
(Moodle in
Wheezy will need to be security-handled for roughly three years, 
yet it is

_already_ not supported).
d) there is (in my opinion) not enough people behind the maintenance 
of
Moodle-in-Debian: Thomas is a good DM, but he's mostly alone, 
and I'm not

willing to get more involved.

So as much as I find that unfortunate, I think that the best 
solution for all
of Moodle, Moodle-in-Debian and Debian, is to not ship Moodle 2.2 in 
Wheezy.


Thomasz, as you're the actual de-facto maintainer, please voice your 
opinion
as I have voiced mine: the decision is in the hands of the Release 
Team I

guess.


I have exactly the same concerns. Security fixes has been released
for Moodle 2.2 today. I could cherry pick the patches and we could
close this bug - not a big deal. They will probably be another
security update for Moodle this year but that's it.

Realistically speaking there is no way I can maintain security fixes
for non-supported (by upstream) software this size.

I have put Moodle 2.2 into Wheezy as that's the only possible upgrade
path for Moodle (1.9 -> 2.2 -> 2.3+).

By not shipping 2.2 in wheezy, we will break the upgrades for any
current users. I don't see any other option though. There are talks 
in

Moodle about making LTS version (e.g. 2.6LTS) - and that's probably
the only reasonable way to maintain a high quality package like this
in Debian.


We have found this elsewhere too (e.g. mediawiki, where they are moving 
to a six-month cycle but adding LTS releases for distributions).



+1 for not shipping 2.2, breaking the upgrade path for this package,
start from 2.5 (or higher) in unstable and provide Moodle LTS 
editions

in Debian stable only.


Just to clarify before I do it: stable stays as it is; remove moodle 
from Wheezy and you will work on the basis of getting 2.5 into Jessie? 
Intermediate versions can always go into backports of course.


It is indeed unfortunate, but carrying security support on our own for 
that long does make me nervous.


Thanks,

--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

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

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits


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

Bug#702706: Debirf 0.33 in Wheezy with 3.8.1 kernel. rc=134

[Daniel Kahn Gillmor]

On 03/11/2013 12:05 PM, J. Cassidy wrote:

> My own build yes, 64 bit.

fwiw, debian has multiple 64-bit architectures.  If you mean amd64 (aka
x86_64), using the specific term avoids possible ambiguity :)

> It was my naiive asssumption that the debirf process would use the
> existing (my own build) kernel  variables / parameters to do it's thing..

By default, debirf selects and installs a kernel from the distribution
you're building.

> in particular, can you supply the output of uname -r ?
> 
> root@Carcassonne ~: uname -ars
> Linux Carcassonne 3.8.1 #2 SMP PREEMPT Sat Mar 2 11:04:32 CET 2013 x86_64

right, in this case you'd need to use DEBIRF_KERNEL_FLAVOR to select a
kernel flavor, or explicitly supply a kernel .deb via the --kernel-deb
argument:

  debirf make --kernel-deb=/path/to/linux-image-whatever.deb xkiosk

> the install-kernel module assumes that the kernel flavor (e.g. "amd64")
> can be derived from $(uname -r | cut -d- -f3-).  If your kernel doesn't
> supply that, you can force the matter with an environment variable, by
> running like:
> 
> DEBIRF_KERNEL_FLAVOR=amd64 debirf make xkiosk

I didn't see any report of you trying this.  does it work for you?

> I ran with the "r" switch to see if the ensuing output would enlighten me
> more perhaps.

sure, testing is fine and reasonable -- just be aware that it may cause
changes on your host system that you don't expect.  we hope it won't,
and we'd consider it a bug if it does, but the way to ensure that it
doesn't damage the host system is to build as a non-privileged user.  So
certainly, don't run with -r in a production environment.

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature

Bug#702794: git-buildpackage: Should extract orig tarball from pristine-tar before building source package

[Russ Allbery]

Felipe Sateler  writes:

> When building a full (source+binary) package, dpkg-source is invoked by
> dpkg-buildpackage. dpkg-source needs the orig tarball in order to create
> the source package. git-buildpackage should extract the tarball from the
> pristine-tar branch (if it exists) before invoking dpkg-source (if the
> tarball does not already exist), otherwise the build fails because the
> orig tarball was not found.

git-buildpackage just does this normally, so something is not working
normally for you.

> And debian/gbp.conf:

> [DEFAULT]
> pristine-tar = True
> sign-tags = True

This really should have taken care of this.  Do you see any error messages
or the like when you run git-buildpackage prior to dpkg-source failing
because it can't find the tarball?

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


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

Bug#702802: amarok: [experimental] Amarok 2.7.0-1 missing /usr/lib/libamarok_service_lastfm_shared.so

[Claudio Moretti]

Package: amarok
Version: 2.7.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

   * What led up to the situation?
   Trying to edit Last.FM configuration options, I was presented with a
   "Missing library" message
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I tried to open Settings > Configure Amarok > Plugins > Last.FM
 configuration
   * What was the outcome of this action?
   Error message about missing library
   * What outcome did you expect instead?
   The configuration options window shown

   I have managed to solve this issue by manually downloading
   amarok_2.7.0-1_amd64.deb from the Ubuntu repository, dpkg --extract
   it and copying libamarok_service_lastfm_shared.so in /usr/lib.

   I did not have even to restart Amarok: it worked right away.

   Can Amarok be rebuilt or repackaged with this library included?

   Cheers,

   Claudio

   P.S.
   I don't exactly know how this works for experimental packages; I just
   hope that filing a bug was the right way, but if it is necessary I
   can subscribe to the correct mailing list and report it there.



- -- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (1001, 'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages amarok depends on:
ii  amarok-common 2.7.0-1
ii  amarok-utils  2.7.0-1
ii  kde-runtime   4:4.8.4-2
ii  libaio1   0.3.109-3
ii  libavcodec-extra-53   6:0.8.5-1
ii  libavformat53 6:0.8.5-1
ii  libavutil51   6:0.8.5-1
ii  libc6 2.13-38
ii  libcurl3-gnutls   7.29.0-1
ii  libgcc1   1:4.7.2-5
ii  libgcrypt11   1.5.0-5
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgpod4  0.8.2-7
ii  libkcmutils4  4:4.8.4-4
ii  libkdecore5   4:4.8.4-4
ii  libkdeui5 4:4.8.4-4
ii  libkdewebkit5 4:4.8.4-4
ii  libkdnssd44:4.8.4-4
ii  libkfile4 4:4.8.4-4
ii  libkio5   4:4.8.4-4
ii  libknewstuff3-4   4:4.8.4-4
ii  liblastfm11.0.7-1
ii  libloudmouth1-0   1.4.3-9
ii  libmtp9   1.1.3-35-g0ece104-5
ii  libmysqlclient18  5.5.29+dfsg-1
ii  libofa0   0.9.3-5
ii  libphonon44:4.6.0.0-3
ii  libplasma34:4.8.4-4
ii  libqjson0 0.7.1-7
ii  libqt4-dbus   4:4.8.2+dfsg-11
ii  libqt4-network4:4.8.2+dfsg-11
ii  libqt4-script 4:4.8.2+dfsg-11
ii  libqt4-sql4:4.8.2+dfsg-11
ii  libqt4-svg4:4.8.2+dfsg-11
ii  libqt4-xml4:4.8.2+dfsg-11
ii  libqtcore44:4.8.2+dfsg-11
ii  libqtgui4 4:4.8.2+dfsg-11
ii  libqtscript4-core 0.2.0-1
ii  libqtscript4-gui  0.2.0-1
ii  libqtscript4-network  0.2.0-1
ii  libqtscript4-sql  0.2.0-1
ii  libqtscript4-uitools  0.2.0-1
ii  libqtscript4-xml  0.2.0-1
ii  libqtwebkit4  2.2.1-5
ii  libsolid4 4:4.8.4-4
ii  libstdc++64.7.2-5
ii  libtag-extras11.0.1-3
ii  libtag1c2a1.8-1
ii  libthreadweaver4  4:4.8.4-4
ii  libx11-6  2:1.5.0-1
ii  libxml2   2.8.0+dfsg1-7+nmu1
ii  phonon4:4.6.0.0-3
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages amarok recommends:
ii  clamz  0.5-1
ii  kdemultimedia-kio-plugins  4:4.8.4-2

Versions of packages amarok suggests:
pn  amarok-doc 
ii  libqt4-sql-mysql   4:4.8.2+dfsg-11
pn  libqt4-sql-psql
pn  libqt4-sql-sqlite  
pn  moodbar

Versions of packages amarok-common depends on:
ii  perl  5.14.2-20

amarok-common recommends no packages.

Versions of packages amarok is related to:
ii  phonon-backend-gstreamer [phonon-backend]  4:4.6.0.0-2
ii  phonon-backend-vlc [phonon-backend]0.6.0-1

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlE+CqYACgkQZ0Gi6TDJB+cgOwCdH8lJQDgEvBDSfczuuLCw0SO2
CpgAoMTUnlqANTZBr27NEf2p+IjbA+Ku
=Iss6
-END PGP SIGNATURE-


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

Bug#702794: git-buildpackage: Should extract orig tarball from pristine-tar before building source package

[Guido Günther]

On Mon, Mar 11, 2013 at 10:36:09AM -0400, Felipe Sateler wrote:
> Package: git-buildpackage
> Version: 0.6.0~git20121124
> Severity: normal
> 
> When building a full (source+binary) package, dpkg-source is invoked  by
> dpkg-buildpackage. dpkg-source needs the orig tarball in order to create
> the source package. git-buildpackage should extract the tarball from the
> pristine-tar branch (if it exists) before invoking dpkg-source (if the
> tarball does not already exist), otherwise the build fails because the
> orig tarball was not found.

Please attach the command you're using. gbp should behave exactly as you
describe.
Cheers,
 -- Guido


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

Bug#702803: virtualbox-4.2: modprobe vboxnetflt failed in 4.2.8-83876~Debian~wheezy with Kernel 3.8-1~experimental.1 x86_64

[Amie Wang]

Package: virtualbox-4.2
Version: 4.2.8-83876~Debian~wheezy
Severity: normal

Dear Maintainer,

virtualbox-4.2 is not able to modprobe the vboxnetflt module for the Kernel
3.8.

dmesg output lke required by the error message:

vboxdrv: Found 8 processor cores.
vboxdrv: fAsync=0 offMin=0x1bf offMax=0x1ec9
vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
vboxdrv: Successfully loaded version 4.2.8 (interface 0x001a0004).
vboxnetflt: disagrees about version of symbol skb_copy_bits
vboxnetflt: Unknown symbol skb_copy_bits (err -22)
vboxnetflt: disagrees about version of symbol skb_put
vboxnetflt: Unknown symbol skb_put (err -22)
vboxnetflt: disagrees about version of symbol dev_queue_xmit
vboxnetflt: Unknown symbol dev_queue_xmit (err -22)
vboxnetflt: disagrees about version of symbol consume_skb
vboxnetflt: Unknown symbol consume_skb (err -22)
vboxnetflt: disagrees about version of symbol __netif_schedule
vboxnetflt: Unknown symbol __netif_schedule (err -22)
vboxnetflt: disagrees about version of symbol dev_add_pack
vboxnetflt: Unknown symbol dev_add_pack (err -22)
vboxnetflt: disagrees about version of symbol dev_set_promiscuity
vboxnetflt: Unknown symbol dev_set_promiscuity (err -22)
vboxnetflt: disagrees about version of symbol eth_type_trans
vboxnetflt: Unknown symbol eth_type_trans (err -22)
vboxnetflt: disagrees about version of symbol kfree_skb
vboxnetflt: Unknown symbol kfree_skb (err -22)
vboxnetflt: disagrees about version of symbol skb_checksum_help
vboxnetflt: Unknown symbol skb_checksum_help (err -22)
vboxnetflt: disagrees about version of symbol dev_remove_pack
vboxnetflt: Unknown symbol dev_remove_pack (err -22)
vboxnetflt: disagrees about version of symbol skb_push
vboxnetflt: Unknown symbol skb_push (err -22)
vboxnetflt: disagrees about version of symbol netif_rx_ni
vboxnetflt: Unknown symbol netif_rx_ni (err -22)
vboxnetflt: disagrees about version of symbol __netdev_alloc_skb
vboxnetflt: Unknown symbol __netdev_alloc_skb (err -22)
vboxnetflt: disagrees about version of symbol netif_carrier_off
vboxnetflt: Unknown symbol netif_carrier_off (err -22)
vboxnetflt: disagrees about version of symbol skb_copy
vboxnetflt: Unknown symbol skb_copy (err -22)
vboxnetflt: disagrees about version of symbol netif_carrier_on
vboxnetflt: Unknown symbol netif_carrier_on (err -22)
vboxnetflt: disagrees about version of symbol skb_gso_segment
vboxnetflt: Unknown symbol skb_gso_segment (err -22)

locally installed kernel packets:

dpkg -l linux* | grep ii
  linux-base   3.5
  linux-headers-3.2.0-4-amd64  3.2.35-2
  linux-headers-3.2.0-4-common 3.2.35-2
  linux-headers-3.8-trunk-amd643.8.2-1~experimental.1
  linux-headers-3.8-trunk-common   3.8.2-1~experimental.1
  linux-headers-amd64  3.2+46
  linux-image-3.2.0-4-amd643.2.35-2
  linux-image-3.8-trunk-amd64  3.8-1~experimental.1
  linux-image-amd643.2+46
  linux-kbuild-3.2 3.2.17-1
  linux-kbuild-3.8 3.8.2-1~experimental.1
  linux-libc-dev:amd64 3.2.35-2



-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing'), (90, 'experimental'), (90, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8-trunk-amd64 (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 virtualbox-4.2 depends on:
ii  adduser   3.113+nmu3
ii  debconf [debconf-2.0] 1.5.49
ii  libc6 2.13-38
ii  libcurl3-gnutls   7.26.0-1+wheezy1
ii  libdevmapper1.02.12:1.02.74-6
ii  libgcc1   1:4.7.2-5
ii  libgl1-mesa-glx [libgl1]  8.0.5-3
ii  libpng12-01.2.49-1
ii  libpython2.7  2.7.3-6
ii  libqt4-network4:4.8.2+dfsg-11
ii  libqt4-opengl 4:4.8.2+dfsg-11
ii  libqtcore44:4.8.2+dfsg-11
ii  libqtgui4 4:4.8.2+dfsg-11
ii  libsdl1.2debian   1.2.15-5
ii  libssl1.0.0   1.0.1e-1
ii  libstdc++64.7.2-5
ii  libx11-6  2:1.5.0-1
ii  libxcursor1   1:1.1.13-1
ii  libxext6  2:1.3.1-2
ii  libxinerama1  2:1.1.2-1
ii  libxml2   2.8.0+dfsg1-7+nmu1
ii  libxmu6   2:1.1.1-1
ii  libxt61:1.1.3-1
ii  psmisc22.19-1+deb7u1
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages virtualbox-4.2 recommends:
ii  binutils   2.22-8
ii  dkms   2.2.0.3-1.2
ii  evince [pdf-viewer]3.4.0-3.1
ii  gcc4:4.7.2-1
ii  gv [pdf-viewer]  

Bug#702617: regex /./ fails to match certiain characters

[Joachim Breitner]

Control: reassign -1 libc6
Control: found libc6/2.13-38
Control: affects haskell-regex-compat

Hi,

Am Montag, den 11.03.2013, 11:53 -0400 schrieb Joey Hess:
> Joachim Breitner wrote:
> > I can reproduce it from within ghc’s address space using gdb:
> > 
> > (gdb) call malloc(32)
> > $7 = 64943120
> > (gdb) call regcomp(64943120, ".", 0)
> > $8 = 0
> > (gdb) call regexec(64943120,"\242",0,0,0)
> > $9 = 1
> > (gdb) call regexec(64943120,"only_ascii",0,0,0)
> > $10 = 0
> > 
> > And even from gdb while debugging “sleep”. So the behaviour is already
> > there in regexec, but for some reason it is not triggered from C code,
> > but only via some variants of FFI (GHC’s or gdb’s).
> > 
> > I’ll leave it at that, as this is not really related to GHC or Haskell
> > any more.
> 
> That's some deep dive!
> 
> Sounds like a reassign to glibc is in order?

if you think so...

@glibc maintainers, here is the short story:

This code prints, as expected 0 (for regex matches):

#include 
#include 
#include 

main () {
regex_t r;
regcomp(&r, ".", 0);
char *s = "\242";
int i = regexec(&r, s, 0, NULL, 0);
printf("%d\n", i);
}

But in some circumstances, this does not work as expected. One such
circumstance is Haskell code doing this via the FFI, but also from gdb:

(gdb) call malloc(32)
$1 = 6332464
(gdb) call memset(6332464, 0, 32)
$3 = 6332464
(gdb) call regcomp(6332464, ".", 0)
$4 = 0
(gdb) call regexec(6332464, "\242",0,0,0)
$5 = 1

It fails if there are no ascii characters around:

(gdb) call regexec(6332464, "\242x",0,0,0)
$6 = 0
(gdb) call regexec(6332464, "\242\242",0,0,0)
$7 = 1
(gdb) call regexec(6332464, "only_ascii",0,0,0)
$8 = 0

Greetings,
Joachim


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



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

Bug#702804: [clamz] Amazon URL in manpage invalid

[Thomas Hackert]

Package: clamz
Version: 0.5-1
Severity: normal

--- Please enter the report below this line. ---
Hello @ll,
I tried to download a file and/or an album from amazon.de. As I had no
idea how to use clamz, I read the manpage. There I found the text


In order to use clamz, you must first enable the  ``MP3  dowloader
mode''  by visiting the following URL:

 
http://www.amazon.com/gp/dmusic/after_download_man‐ager_install.html?AMDVersion=1.0.9

.

When I copy this URL in Firefox 21.0a2 (2013-03-11), I get the message


Looking for something?
We're sorry. The Web address you entered is not a functioning page on
our site

Go to Amazon.com's Home Page 

.
And it is the same, if I use amazon.de (as recommend in the manpage)
instead ... :(
Sorry for the inconvience
Thomas.

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

Debian Release: 7.0
  500 wheezy-pgdg apt.postgresql.org 
  500 unstablesnapshots.ekiga.net 
  500 unstabledownload.jitsi.org 
  500 testing www.deb-multimedia.org 
  500 testing security.debian.org 
  500 testing ftp.de.debian.org 
  500 stable  dl.google.com 
  500 stable  deb.opera.com 
  500 precise ppa.launchpad.net 
  500 libreofficebox  LibOx 4.0 Test-ISO 

--- Package information. ---
Depends (Version) | Installed
=-+-==
libc6(>= 2.3) | 2.13-38
libcurl3-gnutls (>= 7.16.2-1) | 7.26.0-1+wheezy1
libexpat1 (>= 1.95.8) | 2.1.0-1
libgcrypt11(>= 1.4.5) | 1.5.0-5


Package's Recommends field is empty.

Package's Suggests field is empty.

-- 
Q: What's the big deal about rm, I have been deleting stuff for years? And
   never lost anything.. oops!
A: ...
-- From the Frequently Unasked Questions


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

Bug#702800: grub-efi: Upgrade failed to install properly? symbol not found: grub_efi_secure_boot

[Colin Watson]

On Mon, Mar 11, 2013 at 12:21:01PM -0400, Daniel Kahn Gillmor wrote:
> i'm running grub from debian experimental on an EFI machine.  I
> installed grub 2.00-13 on february 19th, but haven't rebooted from
> then until yesterday.
> 
> When i booted, i got this failure from grub when invoking the "linux"
> command:
> 
>   symbol not found: `grub_efi_secure_boot'
> 
> i suspect this means that my EFI image is out of date, but i'm a
> little confused about why that would be.

Right.  (Just in case the Internet at large spots this; this has nothing
specifically to do with UEFI secure boot, and would have happened on any
GRUB core/modules ABI change.)

> i see that i have both of these files:
> 
>   /boot/efi/EFI/boot/bootx64.efi 
>   /boot/efi/EFI/debian/grubx64.efi
> 
> but only the latter was updated on February 19th the other is much
> older and the two files have different content.

The former is used on removable media; the latter is used on fixed
disks.  Perhaps, therefore, grub-install was invoked with --removable at
one point, which as far as I know is the only path by which the former
is created.

It's possible that your firmware prefers the former path if it can find
it; not all EFI systems quite work the way the spec says they should.  I
would suggest moving the former aside and seeing what happens, although
you should probably also check that the latter is in efibootmgr if your
firmware doesn't have a way to boot from a nominated file.

Cheers,

-- 
Colin Watson   [cjwat...@debian.org]


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

Bug#702795: Package coreutils, application touch fails to set modification time to a file on Mars 10, 2013

[Bob Proulx]

tag 702795 + moreinfo
thanks

Jose Manuel Abad Hernandez wrote:
> When running "touch" to set the modification time of a file on Mars
> 10, 2013, the application return <> as shown
> with the followings lines copied from the server console:

Thank you for your report.  However what you are seeing is likely not
a bug.  It is likely due to the local timezone change.

> root@pl:~#touch -m -t 20130310.00 /var/tmp/borrame
> touch: formato de fecha inválido «20130310.00»
> root@pl:~#

What is your timezone?  You did not say and it is needed to know if
that time is valid in that timezone.  From your domain name I will
guess that the timezone is Cuba.  Cuba changed to Daylight Saving Time
at that moment.

> Any other date in 2013 year runs fine.

In the Cuba timezone that date is invalid.  Along with other dates in
the gap created when the clock was moved forward for DST.

  $ env LANG=C TZ=Cuba touch -m -t 20130310.00 xx
  touch: invalid date format ‘20130310.00’

  $ env LANG=C TZ=Cuba touch -m -t 201303100059.00 xx
  touch: invalid date format '201303100059.00'

It is much easier to use date to understand this:

  $ env LANG=C TZ=Cuba date -R -d '2013-03-10 00:00'
  date: invalid date '2013-03-10 00:00'

But one second earlier is okay.

  $ env LANG=C TZ=Cuba date -R -d '2013-03-09 23:59'
  Sat, 09 Mar 2013 23:59:00 -0500

This is correct behavior.  The reason is that Cuba changed to Daylight
Savings Time at midnight.  They moved one hour forward.  That
particular time does not exist.

The timezone data can be printed for any timezone with the zdump
command.  Use it to show when DST went into effect in the Cuba timezone.

  $ zdump -v Cuba | grep 2013
  Cuba  Sun Mar 10 04:59:59 2013 UTC = Sat Mar  9 23:59:59 2013 CST isdst=0 
gmtoff=-18000
  Cuba  Sun Mar 10 05:00:00 2013 UTC = Sun Mar 10 01:00:00 2013 CDT isdst=1 
gmtoff=-14400
  Cuba  Sun Nov  3 04:59:59 2013 UTC = Sun Nov  3 00:59:59 2013 CDT isdst=1 
gmtoff=-14400
  Cuba  Sun Nov  3 05:00:00 2013 UTC = Sun Nov  3 00:00:00 2013 CST isdst=0 
gmtoff=-18000

The second before is "Sat Mar 9 23:59:59 2013 CST" and the very next
second in that time is "Sun Mar 10 01:00:00 2013 CDT".  There are no
valid seconds in the timestamps between those two times.

Therefore touch (and date) are behaving correctly.  To avoid this
problem it is best to work in UTC which never has a DST time gap.  It
also avoids the opposite problem when DST changes back.  If local time
is required then working with timestamps near noon instead of midnight
should avoid DST problems.

Please see the GNU Coreutils FAQ entry for date.  It explains this
issue in detail.  It gives advice on how to avoid problems.

  
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

Bob


signature.asc
Description: Digital signature

Bug#702805: hugin crashes on startup after showing the splashscreen

[kie]

Package: hugin
Version: 2013.0.0~beta1+dfsg-1
Severity: normal

Dear Maintainer,

hugin crashes on startup after showing the splashscreen.
I used the version from testing and then tried the experimental version
with exactly the same result.

Xlib:  extension "RANDR" missing on display ":0.0".
/usr/share/hugin/data/plugins/shooting_pattern.py
   CAT:initial distribution
   NAM:6-1-1 Shooting Pattern
/usr/share/hugin/data/plugins/crop_cp.py
   CAT:Control Points
   NAM:Crop Control Points
/usr/share/hugin/data/plugins/top_five.py
   CAT:Control Points
   NAM:keep 5 CPs per image pair
/usr/share/hugin/data/plugins/woa.py
   CAT:Control Points
   NAM:Warped Overlap Analysis
The program 'hugin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 798 error_code 8 request_code 156 minor_code 5)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

btw I get the Xlib:  extension "RANDR" missing on display ":0.0".
error all the time, so I don't think that is the problem.



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

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

Versions of packages hugin depends on:
ii  enblend   4.0+dfsg-4+b3
ii  enfuse4.0+dfsg-4+b3
ii  hugin-tools   2013.0.0~beta1+dfsg-1
ii  libboost-signals1.49.01.49.0-3.2
ii  libboost-system1.49.0 1.49.0-3.2
ii  libboost-thread1.49.0 1.49.0-3.2
ii  libc6 2.13-38
ii  libexiv2-12   0.23-1
ii  libgcc1   1:4.7.2-5
ii  libgl1-mesa-glx [libgl1]  8.0.5-3
ii  libglew1.71.7.0-3
ii  libglu1-mesa [libglu1]8.0.5-3
ii  libimage-exiftool-perl8.60-2
ii  libpano13-2   2.9.18+dfsg-4+b1
ii  libstdc++64.7.2-5
ii  libtiff4  3.9.6-11
ii  libwxbase2.8-02.8.12.1-12
ii  libwxgtk2.8-0 2.8.12.1-12
ii  make  3.81-8.2

hugin recommends no packages.

hugin 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#685886: installation-reports: installing on the second hard disk fails: grub error after reboot

[Jürgen Fuchsberger]

Same problem here, after installing from USB (using unetbootin testing
netinstall 32). Grub was installed to /dev/sda (USB) instead of /dev/sdb
(HD). No option to change install drive was given.

Best,
Jürgen

-- 
| Jürgen Fuchsberger, M.Sc.
| Wegener Center for Climate and Global Change
| University of Graz
| Brandhofgasse 5, A-8010 Graz
| phone: +43-316-380-8438
|   web: www.wegcenter.at
|www.wegenernet.org



signature.asc
Description: OpenPGP digital signature

Bug#698245: unblock: moodle/2.2.3.dfsg-2.6~wheezy2

[Tomasz Muras]

On 03/11/2013 05:22 PM, Jonathan Wiltshire wrote:

On 2013-03-11 10:18, Tomasz Muras wrote:

On 03/11/2013 10:49 AM, Didier 'OdyX' Raboud wrote:

So as much as I find that unfortunate, I think that the best solution
for all
of Moodle, Moodle-in-Debian and Debian, is to not ship Moodle 2.2 in
Wheezy.

I have exactly the same concerns. Security fixes has been released
for Moodle 2.2 today. I could cherry pick the patches and we could
close this bug - not a big deal. They will probably be another
security update for Moodle this year but that's it.

Realistically speaking there is no way I can maintain security fixes
for non-supported (by upstream) software this size.

I have put Moodle 2.2 into Wheezy as that's the only possible upgrade
path for Moodle (1.9 -> 2.2 -> 2.3+).

By not shipping 2.2 in wheezy, we will break the upgrades for any
current users. I don't see any other option though. There are talks in
Moodle about making LTS version (e.g. 2.6LTS) - and that's probably
the only reasonable way to maintain a high quality package like this
in Debian.


We have found this elsewhere too (e.g. mediawiki, where they are moving
to a six-month cycle but adding LTS releases for distributions).


+1 for not shipping 2.2, breaking the upgrade path for this package,
start from 2.5 (or higher) in unstable and provide Moodle LTS editions
in Debian stable only.


Just to clarify before I do it: stable stays as it is; remove moodle
from Wheezy and you will work on the basis of getting 2.5 into Jessie?
Intermediate versions can always go into backports of course.


Correct. 1.9 is still supported (it won't be for long) and can stay in 
stable.
I am thinking that I would would package 2.5 and then 2.6 in unstable 
and do not let it migrate into testing - unless LTS upstream version is 
released. Does it make sense?


One thing I'm not sure about is what will happen to current users of 
moodle package. They have 1.9 in squeeze, there will be nothing in 
wheezy but then the package will appear back in jessie - but with no 
upgrade path. The only way to get moodle back will be to drop the 
package completely (and drop DB) and re-install it. Of course we could 
provide some manual instructions to install 2.2 package and then upgrade 
to 2.4.


Tomek


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