date:20130329

Package: installation-reports

Boot method: ISO on USB stick on USB 2.0 port
Image version: 
http://cdimage.debian.org/cdimage/wheezy_di_rc1/amd64/iso-cd/debian-wheezy-DI-rc1-amd64-netinst.iso
Date: 2013-03-29

Machine: HP EliteBook 8570p (C6Z56UT)
Processor: Intel Core i5-3320M
Memory: 4 GiB
Partitions:

# df -Tl | human
rootfs   rootfs   /
udev devtmpfs /dev
tmpfstmpfs/run
/dev/mapper/___-root ext4 /   - dm_crypt
tmpfstmpfs/run/lock
tmpfstmpfs/run/shm
/dev/sda_ext4 /boot
/dev/sda_vfat /boot/efi   - ESP


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]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[E]

Comments/Problems:

Xen currently seems not to function with the 3.2.39 kernel for the
dom0 on a UEFI system, so I can't use UEFI.  This is an attempt to use
a GPT-partitioned disk with BIOS.

This assumes a Boot Mode of Legacy.  (HP startup screen  Startup
Menu  BIOS Setup  System Configuration  Boot Options)

Boot to the Startup Menu, F9 Boot Device Options, choose USB Hard
Drive 1, Advanced options, Expert install.  Following the advice
of http://www.debian.org/devel/debian-installer/errata :

  When there is more than one disk available during installation (for
  example one hard disk and one USB stick, as it is commonly the case
  when booting the installer from a USB stick), grub-install may run
  into problems: it was reported several times, that the GRUB
  bootloader was installed onto the USB stick instead of the hard disk
  containing the newly-installed system.

  To avoid running into this, make sure to answer No when the
  following question is asked during the installation process:
  Install the GRUB boot loader to the master boot record?; it should
  be possible to specify the right device at the next step: Device
  for boot loader installation.

or not, the result is the same: The d-i seems to think that GRUB
succeeded in the console:


grub-installer: Installation finished. No error reported.
grub-installer: info: grub-install ran successfully


But rebooting fails to find boot code, gives HP screen:


BootDevice Not Found

Please install an operating system on your hard disk.
[...]


Rebooting the USB stick to rescue mode, I umount the /boot and
/boot/efi partitions--because mount thinks they're mounted--before I
truly mount them.  Running grub-install /dev/sda appears to succeed,
but rebooting yields the same HP screen.

From rescue mode, aptitude install gdisk on the target system, to
confirm that the biosgrub partition has GUID code
21686148-6449-6e6f-744e-656564454649.

So BIOS-GPT GRUB installation doesn't work, and I have no idea how to 
force it to.


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

Bug#704192: virt-manager: Libvirt dies when do 'Force Shutdown' on LXC container

2013-03-29 Thread Daniel Dickinson

Package: virt-manager
Version: 0.9.1-4
Severity: normal

Shutdown doesn't work for an LXC container (known issue), so I tried force 
shutdown, unfortunately libvirtd is suddenly not running anymore when I do 
that.  There is no segfault message in ssylog, but libvirtd is gone.

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

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

Versions of packages virt-manager depends on:
ii  gconf2   3.2.5-1+build1
ii  librsvg2-common  2.36.1-1
ii  python   2.7.3-4
ii  python-dbus  1.1.1-1
ii  python-glade22.24.0-3+b1
ii  python-gnome22.28.1+dfsg-1
ii  python-gtk-vnc   0.5.0-3.1
ii  python-gtk2  2.24.0-3+b1
ii  python-ipy   1:0.75-1
ii  python-libvirt   0.9.12-11
ii  python-spice-client-gtk  0.18-0nocelt1exp
ii  python-support   1.0.15
ii  python-urlgrabber3.9.1-4
ii  python-vte   1:0.28.2-5
ii  virtinst 0.600.1-3

Versions of packages virt-manager recommends:
ii  gnome-icon-theme  3.4.0-2
ii  libvirt-bin   0.9.12-11

Versions of packages virt-manager suggests:
ii  gnome-keyring3.4.1-5
ii  hal  0.5.14-8
pn  python-gnomekeyring  none
pn  python-guestfs   none
ii  ssh-askpass  1:1.2.4.1-9
pn  virt-viewer  none

-- no debconf information


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

Bug#455769: same problem on wheezy + Thinkpad X220T

2013-03-29 Thread Salvo Tomaselli


 What we need is someone who can reliably reproduce the issue and help
 with debugging.

I've had a probably related problem, without using GNOME
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455769#59


-- 
Salvo Tomaselli


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

Bug#704073: [multipath-tools-boot] error when update-initramfs

2013-03-29 Thread Ritesh Raj Sarraf

On Friday 29 March 2013 01:04 AM, Ritesh Raj Sarraf wrote:
 Can you paste the logs when you hit the command?
 The init script denies stopping the daemon since root in on multipath.

 But I guess, your installation would have completed. Can you also paste
 the output of dpkg -l | grep -i multipath-tools

Guy,

Sorry to bug but I would appreciate if you could provide me some
feedback. I am relying on your results before I propose to push this for
Wheezy.

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




signature.asc
Description: OpenPGP digital signature

Bug#612610: lintian: should suggest switching to 3.0 (quilt)

2013-03-29 Thread Lucas Nussbaum

On 29/03/13 at 01:28 +0100, Niels Thykier wrote:
 Hi,
 
 I am not sure we can in general promote the use of 3.0 (quilt) over 1.0
 via Lintian at the moment[1].
 
 Though I noticed that people are writing their own tools to extract
 things like what source format is used or what build systems are
 used.  With #359059 being fixed in 2.5.12, perhaps it is worth for us
 to consider if Lintian could be used for more than mere flaw
 reporting.  Like adding a new kind of tag that is not a flaw but
 simply a property of the package[2].
 
 While it would not directly solve your/Luacs's request for promoting a
 switch to 3.0 (quilt), it would still report which source formats are
 used (and would be importable into UDD).  It is also quite possible that
 some of the metrics on mentors.d.n could be replaced by this new
 property tag[3].
 
 ~Niels
 
 [1] Basically it is the same reasons as mentioned in #702671.
 
 [2] Originally I considered using informational tag here, but I
 figured it would be confused with I tags.
 
 [3] I doubt the current ones will be replaced, but one can hope that
 future metrics would be written as such a tag.

Hi,

Actually, I have two motivations for that:

1) be able to easily track the number of affected packages. But actually, I
solve that using another solution (custom script + snapshot.d.o, see
http://www.lucas-nussbaum.net/blog/?p=751).  [ it just occurred to me that
using lintian to do that analysis would have been possible (esp. with
Property tags) and quite nice. ]

2) push for archive renovation/standardisation on good practices.
As I wrote in https://lists.debian.org/debian-vote/2013/03/msg00193.html:
 Discouraging the use of some development practices is part of that.
 There are good reasons for not using any of dh or cdbs, not using 3.0
 (quilt), so I don't think that we should force that in policy, and make
 that RC bugs.
 But I think that we should discuss adding lintian warning or errors for:
 - packages using 1.0 format and having files modified directly
   = should move to 3.0 (quilt)
 - packages using 1.0 format and simple-patchsys, quilt, or dpatch
   = should move to 3.0 (quilt)
 - packages using debhelper directly (not dh or cdbs)
   = should move to dh
 [ there are good reasons in some cases for doing some of the above.
   Adding lintian override in those cases would be totally OK, and also
   a good way to identify current limitations in 3.0 (quilt) or dh. ]
 
 I would hope that the increasing visibility brought by lintian
 warnings/errors, and as well as the advertised project consensus that
 such practices are discouraged, would help us get rid of such practices.

Now, as was suggested in #702671, there should be prior discussion on -devel@
about that.  I'll raise the topic after the DPL election (it might sound like a
political move if I did it now) -- unless someone beats me with it.

Lucas


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

Bug#703938: udd: please ignore no bug, patch and version difference with Ubuntu

2013-03-29 Thread Lucas Nussbaum

 Quoting Simon Chopin (2013-03-26 19:40:25)
  tags 703938 +patch
  thanks
  
  Quoting Lucas Nussbaum (2013-03-26 09:15:47)
   Indeed, good idea. In case someone is reading this and want to try
   hacking DMD, this is a fairly easy thing to fix.
  
  I took a shot at it, but I have no idea how to test this patch. Beware,
  this is the first time I write something in Ruby :-)

Hi,

It's actually quite easy to test, see http://udd.debian.org/hacking.html

I don't think your patch addresses ignore same version in sid and ubuntu devel
release?

Thanks,

Lucas


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

Bug#542857: ocaml-r: new URL

2013-03-29 Thread Ralf Treinen

ocaml-r is now hosted at

http://home.gna.org/ocaml-r/

-Ralf.


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

Bug#586758: RFP: dypgen -- a GLR parser and lexer generator for OCaml

2013-03-29 Thread Ralf Treinen

The file bugs in the dypgen distribution (version 20120619-1) 
says:


KNOWN BUGS

Dypgen does not handle cyclic grammars : when a non terminal can derive itself.
And it does not warn the user that its grammar is cyclic. The behavior is
not defined.

When there is an error of type with the arguments or the result of a merge
function, Caml reports it and points to the .ml file generated by dypgen,
not to the .dyp input file, which may be puzzling.


This looks like it isn't ready yet for deployment. -Ralf.


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

Bug#703726: [PATCH] libcogl12: SIGSEGV in cogl_onscreen_add_frame_callback

2013-03-29 Thread Daniel Vacek

On Fri, Mar 29, 2013 at 1:57 AM, Daniel Vacek neel...@gmail.com wrote:
 Hi,

   I can confirm the bug and this patch fixes it.

  Ok, the problem is elsewhere. This patch won't fix the bug. Instead
we must realize there is no bug.

  I tested the patch with LD_PRELOAD of 'fixed' library and it was all
right. But after I installed lib to the system the problem did not
disappear. So I investigated a little more.

  The bug is gone even with LD_PRELOAD of unpatched library and it
turned out to this:

neelx@sweeney:~$ ldd `which totem` | grep libcogl.so
libcogl.so.9 = /usr/lib/i386-linux-gnu/libcogl.so.9 (0xb7278000)
libcogl.so.12 = /usr/lib/i386-linux-gnu/libcogl.so.12 (0xb62c4000)
neelx@sweeney:~$ LD_PRELOAD=/usr/lib/i386-linux-gnu/libcogl.so.12 ldd
`which totem` | grep libcogl.so
/usr/lib/i386-linux-gnu/libcogl.so.12 (0xb766)
libcogl.so.9 = /usr/lib/i386-linux-gnu/libcogl.so.9 (0xb7135000)
neelx@sweeney:~$ ldd `which gnome-shell` | grep libcogl.so
libcogl.so.9 = /usr/lib/i386-linux-gnu/libcogl.so.9 (0xb6799000)
libcogl.so.12 = /usr/lib/i386-linux-gnu/libcogl.so.12 (0xb52c)
neelx@sweeney:~$ LD_PRELOAD=/usr/lib/i386-linux-gnu/libcogl.so.12 ldd
`which gnome-shell` | grep libcogl.so
/usr/lib/i386-linux-gnu/libcogl.so.12 (0xb768d000)
libcogl.so.9 = /usr/lib/i386-linux-gnu/libcogl.so.9 (0xb668e000)
llibcogl12

  It's fine as long as it get's loaded _before_the_old_ version (surprisingly).

neelx@sweeney:~$ readelf -d `which totem` | grep libcogl.so
 0x0001 (NEEDED) Shared library: [libcogl.so.9]
neelx@sweeney:~$ readelf -d `which gnome-shell` | grep libcogl.so
 0x0001 (NEEDED) Shared library: [libcogl.so.9]

  Well, so the point is, totem or gnome-shell needs libcogl.so.9, but
other library/ies they depends on (namely package libclutter-1.0-0 (=
1.13.10-1)) needs libcogl.so.12.
  As of version 1.14.0-1 package libclutter-1.0-0 correctly breaks
libcogl9 and libcogl11. So should the package libcogl12 probably Break
libclutter-1.0-0 ( 1.14.0-1)?

--nX


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

Bug#704191: HP EliteBook 8570p BIOS-GPT install succeeds, with bootable flag

Control: retitle -1 HP EliteBook 8570p BIOS-GPT install succeeds, with bootable 
flag

 But rebooting fails to find boot code, gives HP screen:
 
 
 BootDevice Not Found
 
 Please install an operating system on your hard disk.
 [...]
 

With hints from http://www.rodsbooks.com/gdisk/bios.html this can be 
made to work.  In rescue mode, use fdisk to set the bootable flag on the 
one partition in the protective MBR.  Rebooting boots into GRUB/Linux.


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

Bug#704073: [multipath-tools-boot] error when update-initramfs

2013-03-29 Thread Guy Roussin

Le 29/03/2013 08:20, Ritesh Raj Sarraf a écrit :
 On Friday 29 March 2013 01:04 AM, Ritesh Raj Sarraf wrote:
   
 Can you paste the logs when you hit the command?
 The init script denies stopping the daemon since root in on multipath.

 But I guess, your installation would have completed. Can you also paste
 the output of dpkg -l | grep -i multipath-tools
 
 Guy,

 Sorry to bug but I would appreciate if you could provide me some
 feedback. I am relying on your results before I propose to push this for
 Wheezy.
   
Hi,

This is what i get :

LM05q:~# ls *deb
kpartx_0.4.9+git0.4dfdaf2b-7_amd64.deb
multipath-tools_0.4.9+git0.4dfdaf2b-7_amd64.deb
multipath-tools-boot_0.4.9+git0.4dfdaf2b-7_all.deb

LM05q:~# LANG=C dpkg -i *deb
(Reading database ... 31699 files and directories currently installed.)
Preparing to replace kpartx 0.4.9+git0.4dfdaf2b-7 (using
kpartx_0.4.9+git0.4dfdaf2b-7_amd64.deb) ...
Unpacking replacement kpartx ...
Preparing to replace multipath-tools 0.4.9+git0.4dfdaf2b-6 (using
multipath-tools_0.4.9+git0.4dfdaf2b-7_amd64.deb) ...
[] Root is on a multipathed device, multipathd can not be
stopped:invoke-rc.d: initscript multipath-tools, action stop failed.
dpkg: warning: subprocess old pre-removal script returned error exit
status 1
dpkg: trying script from the new package instead ...
[] Root is on a multipathed device, multipathd can not be
stopped:invoke-rc.d: initscript multipath-tools, action stop failed.
dpkg: error processing multipath-tools_0.4.9+git0.4dfdaf2b-7_amd64.deb
(--install):
 subprocess new pre-removal script returned error exit status 1
[ ok ] Starting multipath daemon: multipathd.
Preparing to replace multipath-tools-boot 0.4.9+git0.4dfdaf2b-7 (using
multipath-tools-boot_0.4.9+git0.4dfdaf2b-7_all.deb) ...
Unpacking replacement multipath-tools-boot ...
Setting up kpartx (0.4.9+git0.4dfdaf2b-7) ...
dpkg: dependency problems prevent configuration of multipath-tools-boot:
 multipath-tools-boot depends on multipath-tools (=
0.4.9+git0.4dfdaf2b-7); however:
  Version of multipath-tools on system is 0.4.9+git0.4dfdaf2b-6.

dpkg: error processing multipath-tools-boot (--install):
 dependency problems - leaving unconfigured
Processing triggers for man-db ...
Errors were encountered while processing:
 multipath-tools_0.4.9+git0.4dfdaf2b-7_amd64.deb
 multipath-tools-boot

LM05q:~# dpkg -l | grep -i multipath-tools
ii  multipath-tools0.4.9+git0.4dfdaf2b-6 
amd64maintain multipath block device access
iU  multipath-tools-boot   0.4.9+git0.4dfdaf2b-7 
all  Support booting from multipath devices
LM05q:~#


Guy


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

Bug#704174: CVE-2013-2266 fix for bind9 in stable?

2013-03-29 Thread Richard van den Berg

Thanks a lot for the quick fix. Will bind9 9.7.3.dfsg-1 in stable also be 
fixed? I don't see any reports on http://www.debian.org/security/#DSAS and 
http://lists.debian.org/debian-security-announce/2013/threads.html

Kind regards,

Richard van den Berg

Bug#693921: [Aptitude-devel] Bug#693921: fails to resolve empathy/experimental dependencies, fails with signal 6

2013-03-29 Thread Sjoerd Simons

On Wed, Nov 28, 2012 at 11:32:51AM -0800, Christoph Egger wrote:
 Hi!
 
 Christoph Egger christ...@debian.org writes:
  Daniel Hartwig mand...@gmail.com writes:
  On 22 November 2012 03:36, Christoph Egger christ...@debian.org wrote:

 It's also easily reproducible with a `mk-build-dep` in
 empathy/experimental and isntalling aptitude in a minimal chroot, dpkg
 -i the build-dep and have aptitude [1] resolve it
 
 [1] aptitude -y --without-recommends -o Dpkg::Options::=--force-confold -o 
 Aptitude::CmdLine::Ignore-Trust-Violations=false -o 
 Aptitude::ProblemResolver::StepScore=100 -o 
 Aptitude::ProblemResolver::SolutionCost=safety, priority, 
 non-default-versions -o Aptitude::ProblemResolver::Hints::KeepDummy=reject 
 empathy-build-deps :UNINST -o 
 Aptitude::ProblemResolver::Keep-All-Level=55000 -o 
 Aptitude::ProblemResolver::Remove-Essential-Level=maximum install 
 empathy-build-deps

I used this method to reproduce the issue for current gnome-shell/experimental.
The trigger seems to be the usage of non-default-versions in the SolutionCost,
using the default (safety, priority) like e.g. pbuilder does results in
aptitude successfully finding a solution.

-- 
Information is the inverse of entropy.


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

Bug#704191: HP EliteBook 8570p BIOS-GPT install succeeds, with bootable flag

Xen/Linux also runs properly with this configuration.


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

Bug#703586: Xen fails to boot Linux dom0 under UEFI

Control: retitle -1 Xen fails to boot Linux dom0 under UEFI

Xen works on BIOS-GPT: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704191
So this is strictly a UEFI problem.


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

Bug#670921: [i965-va-driver] Wrong description (or built from wrong sources)

2013-03-29 Thread Reinhard Tartler

retitle 670921 missing h264 profiles on G45 hardware
tags 670921 pending
stop

On Mon, Apr 30, 2012 at 2:26 PM, Jan-Benedict Glaw jbg...@getslash.de wrote:

 Package: i965-va-driver
 Version: 1.0.16-4

 Hi!

 The description tells us that H.264 should be somewhat
 supported. However, there's no such profile:

That's hardware dependent. In my sandy bridge laptop, this works just fine:

(sid-amd64)siretart@faui43f:/tmp $ vainfo
libva: VA-API version 0.32.0
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA-API version: 0.32 (libva 1.0.15)
vainfo: Driver version: Intel i965 driver - 1.0.17
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileH264Baseline   : VAEntrypointVLD
  VAProfileH264Baseline   : VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD

 It would be quite nice to have that additional acceleration
 profiles available, even though if you'd ship an older version
 of this VA driver. However, it be nice if you'd add two additional
 patches then, which could be found in the Ubuntu package
 (see 
 http://archive.ubuntu.com/ubuntu/pool/universe/i/intel-vaapi-driver/intel-vaapi-driver_1.0.15-1ubuntu2.debian.tar.gz).
  These patches
 are already on the GIT repo's master branch, but missing on
 the (older) g45-h264 branch. The second one fixes an actual
 assertion, while the first only adds the infrastructure used
 by the second.

We will update to upstream version 1.1 soon. From your description, I
understand that this will address all of your comments.

--
regards,
Reinhard


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

Bug#701694: Recent 3.4-stock-kernel update fixed the VT-graphics-trouble partially

2013-03-29 Thread Andreas Glaeser

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The situation is now on my 'GNOME-box' as I like to call it, that there is no 
dmesg-error
message issued anymore with the most recent 3.2. kernel-version, but 
intermittent
blanking still occurs without showing in dmesg-output.
Full-screen blanking as observed before has become rare, but there is still a 
kind of
flicker visible, that occors periodically either for the whole screen or parts 
of the
screen only on virtual-terminals.
This seems to be on a good way to be completely fixed soon.
dmsg.txt.gz attached.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAlFVWFgACgkQ5+rBHyUt5wvQZQCgrHUesr71xvB/yBxRqSWfnQgy
G0AAoINYZiSBVmiDd8Ic+sXCPkeTrAwS
=7jIS
-END PGP SIGNATURE-


dmsg.txt.gz
Description: GNU Zip compressed data

Bug#702309: workarounds

2013-03-29 Thread jidanni

Any workarounds?


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

Bug#703514: docbook-xsl: New upstream release and watch file no longer working

2013-03-29 Thread Raphael Hertzog

Hi,

On Thu, 28 Mar 2013, Daniel Leidert wrote:
 Am Mittwoch, den 20.03.2013, 14:27 +0100 schrieb Raphaël Hertzog:
 
  We're several upstream release behind... the latest version is 1.78.1.
 
 That' true. The wheezy release is holding things back. There is no way
 to upload an updated version to unstable.

There's experimental, that's where I'm packaging the new version of
publican which requires this. I would be happy to see the latest version
in experimental.

And BTW some of the new upstream releases were released before the freeze,
1.77.0 and 1.77.1 dates back to may and june last year (and in fact
that's the minimal version that I need for publican).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


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

Bug#704193: guaranteed Segmentation fault

2013-03-29 Thread jidanni

Package: locate
Version: 4.5.11-1

# su - nobody
No directory, logging in with HOME=/
nobody@jidanni2:/$ locate 
locate: warning: database '/var/cache/locate/locatedb' is more than 8 days old 
(actual age is 20.4 days)
Segmentation fault

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

Kernel: Linux 3.8-trunk-486
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages locate depends on:
ii  findutils  4.5.11-1
ii  libc6  2.17-0experimental2


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

Bug#703938: udd: please ignore no bug, patch and version difference with Ubuntu

2013-03-29 Thread Simon Chopin

Quoting Lucas Nussbaum (2013-03-29 08:27:36)
 Hi,
 
 It's actually quite easy to test, see http://udd.debian.org/hacking.html
Thanks for that, actual testing helps a lot :-)

 I don't think your patch addresses ignore same version in sid and ubuntu 
 devel
 release?
Indeed, it didn't and had other problems. Here's a fixed version.

Cheers,
Simon
From e44fa68c777c0372bf901b84e74e3865f2884a82 Mon Sep 17 00:00:00 2001
From: Simon Chopin chopin.si...@gmail.com
Date: Tue, 26 Mar 2013 19:29:50 +0100
Subject: [PATCH] Don't show packages without diff, patch nor bug in the
 Ubuntu tab.

Thanks to Ideki Yamane for the idea.
---
 web/dmd.cgi |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/web/dmd.cgi b/web/dmd.cgi
index bd819f4..36648ee 100755
--- a/web/dmd.cgi
+++ b/web/dmd.cgi
@@ -324,7 +324,6 @@ if cgi.params != {}
   $uddd.sources.keys.sort.each do |src|
 next if not $uddd.versions.include?(src)
 next if (not $uddd.versions[src].include?('debian') or not $uddd.versions[src].include?('ubuntu'))
-puts trtd class=\left\#{src_reason(src)}nbsp;/td
 
 ub = $uddd.ubuntu_bugs[src]
 if ub.nil?
@@ -353,7 +352,11 @@ if cgi.params != {}
   ustb += brbpo:nbsp;#{du[#{USTB}-backports][:version]} if du[#{USTB}-backports]
 
   udev = du[UDEV][:version] if du[UDEV]
-  if udev != sid and sid != ''
+  if udev == sid
+if bugs == 0 and patches == 0
+  next
+end
+  elsif sid != ''
 if UDDData.compare_versions(udev, sid) == -1
   if udev =~ /ubuntu/
 udev = a href=\http://ubuntudiff.debian.net/?query=-FPackage+#{src}\;span class=\prio_high\ title=\Outdated version in Ubuntu, with an Ubuntu patch\#{udev}/span/a
@@ -373,6 +376,7 @@ if cgi.params != {}
   udev += brbpo:nbsp;#{du[#{UDEV}-backports][:version]} if du[#{UDEV}-backports]
 end
 
+puts trtd class=\left\#{src_reason(src)}nbsp;/td
 if bugs  0
   puts tda href=\https://bugs.launchpad.net/ubuntu/+source/#{src}\;#{bugs}/a/td
 else
-- 
1.7.10.4

Bug#704194: packaging-tutorial: devscripts is now moved to collab-maint

2013-03-29 Thread Niels Thykier

Package: packaging-tutorial
Version: 0.8
Severity: minor

Hi,

devscripts recently moved to the collab-maint repository (its old Vcs
URLs are mentioned on page 39 or so in the PDFs)

~Niels


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

Bug#670377: i965-va-driver: i965_drv_video.so init failed on Intel GM965/GL960 or 965GM

2013-03-29 Thread Reinhard Tartler

retitle 670377 Please provide better diagnostics
tags 670377 upstream
severity 670377 minor

Hi Jamie,

sorry for taking so long to come back to you.

On Wed, Apr 25, 2012 at 5:13 AM, Jaime Silva
jaimealbertosi...@gmail.com wrote:
 Package: i965-va-driver
 Version: 1.0.16-4
 Severity: important

 Dear Maintainer,

 When I run vainfo I get the following:

 jaime@inspironjaime2:~$ vainfo
 libva: VA-API version 0.32.0
 libva: va_getDriverName() returns 0
 libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
 libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
 libva: va_openDriver() returns -1
 vaInitialize failed with error code -1 (unknown libva error),exit
 jaime@inspironjaime2:~$

 I don't understand why if this card is supported the library fails.

This lack of better diagnostics is indeed annoying here. Do you still
experience this problem with the updated packages from
debian/experimental?

If yes, then we need to talk to upstream about this issue.


 It is also weird that reportbug keeps saying the package is not installed 
 after
 I purged it and reinstalled it:

That seems like a question for the debian user mailing lists.

kind regards,
Reinhard


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

Bug#670377: i915_drv_video.so is unabailable

2013-03-29 Thread Reinhard Tartler

On Thu, Jan 31, 2013 at 5:21 AM, Daniel Karig d...@diy-biogas.eu wrote:
 Problem: no VA support for intel G45 and others
 reason: missing i915_drv_video.so, which is not delivered by any package
 solution: Should the installed i965_drv_video.so be loaded instead of
 the missing i915_drv_video.so?

That's a DRI driver problem that needs to be solved in the mesa
package. Please raise this issue there.

 Additionally it could be useful if vainfo would tell file missing
 instead of unknown libva error.

Indeed. See my other reply in this bug report.

-- 
regards,
Reinhard


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

Bug#704195: update-manager-gnome: installed manually shows various problems

2013-03-29 Thread Andreas Glaeser

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


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

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

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

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

update-manager-gnome should belong to 'task-gnome-desktop', to be installed 
automatically
by default, and in my opinion it should also include 'update-notifier', which I 
also
installed manually, but no notification appears at all.
Also update-manager does not seem to run in the background, although it was 
configured to
look for updates daily and notify me accordingly, but it does not seem to do 
anything.
Then next, I find now that it offers updates, that aptitude does not, or that 
would only
be installable, doing a dist-upgrade.
Under Settings/Software Sources/Updates it still contains the word 'Ubuntu': 
'Notify me
of a new Ubuntu version:'.
These issues should be fixed prior to the Wheezy release, because not everyone 
wants to
upgrade his/her system manually using aptitude/apt-get.
There should be some degree of consistency between updates one installs 
manually and
those offered via graphical update-manager, these should mostly be the same, 
but this is
possibly a problem with apt-pinning in apt-preferences and not specific to 
Wheezy,
because similar things appeared in Squeeze, too.

 -- 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.8.0adt
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

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

update-manager-gnome recommends no packages.

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

- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAlFVYQoACgkQ5+rBHyUt5ws9cQCfcFZO8lEee/WtG/onC9wGgHSB
mjAAoKcpskHZeTqRSzASV1NbcdtUsteT
=KlnJ
-END PGP SIGNATURE-

Bug#704196: ITP: libraries - Drupal module for shared library management

Package: wnpp
Severity: wishlist
Owner: Daniel Pocock dan...@pocock.com.au

Upstream:

  http://drupal.org/project/libraries

License:

  GPL v2 or later

Comments:

This Drupal module allows other Drupal modules to share common code.

Typically, the common code is a third party JavaScript library that is
not wrapped in a Drupal module package itself (Drupal, like Debian,
prefers to avoid embedded library code)

The module appears to be suitable for use with many Debian-packaged
JavaScript libraries.  Each Debian-packaged JavaScript can be made
available in Drupal by creating a symlink from
/usr/share/javascript/something to
/usr/share/drupal7/libraries/something.  As part of this packaging
effort, I will look at whether to automatically create such symlinks for
all installed JavaScript code, or how to allow other packages or the
sysadmin to conveniently create such links as they are required.

I have already tested this paradigm with sipml5 and the drucall module.


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

Bug#622230: unscd: Looks like an error message

2013-03-29 Thread Jérôme Warnier


Actually, it breaks stuff.
Example: installing snmpd fails with the following message:
 dpkg: error processing snmpd (--configure):
  subprocess installed post-installation script returned error exit 
status 128

 Errors were encountered while processing:
  snmpd

And the debug log, when I activate set -x in the postinst:
root@beeznest02:/var/log# dpkg --configure -a
+ dpkg --configure -a
Setting up snmpd (5.4.3~dfsg-2) ...
+ [ xconfigure = xconfigure ]
+ getent group snmp
+ [ ! ]
+ deluser --quiet --system snmp
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
+ adduser --quiet --system --group --no-create-home --home 
/var/lib/snmp snmp

sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(group) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
+ chown -R snmp:snmp /var/lib/snmp
+ . /usr/share/debconf/confmodule
+ [ !  ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [  ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/snmpd.postinst 
configure

+ [ xconfigure = xconfigure ]
+ getent group snmp
+ [ ! ]
+ deluser --quiet --system snmp
+ adduser --quiet --system --group --no-create-home --home 
/var/lib/snmp snmp

+ chown -R snmp:snmp /var/lib/snmp
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z  ]
+ exec
+ [  ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ db_version 2.0
+ _db_cmd VERSION 2.0
+ IFS=  printf %s\n VERSION 2.0
+ IFS=
 read -r _db_internal_line
+ RET=20 Unsupported command sent (full line was sent 
invalidate(passwd) request, exiting) received from confmodule.

+ return 20
+ [ -x /etc/init.d/snmpd ]
+ update-rc.d snmpd defaults
+ which invoke-rc.d
+ [ -x /usr/sbin/invoke-rc.d ]
+ invoke-rc.d snmpd start
Starting network management services: snmpd.
+ exit 0

As you can see, there is a problem with debconf.

Probably a good reason to raise the severity of this bug.
Hope it helps.


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

Bug#700934: This looks like an old friend

2013-03-29 Thread Martin Quinson

Hello,

this bug looks very similar to #649402. As I said in this bug, the
problem impacts many other metrics than max RSS. Bob, you may want to
read
http://lists.gnu.org/archive/html/bug-gnu-utils/2008-12/msg00047.html

Bye, Mt


-- 
If you do not expect the unexpected, you will not find it.   -- Heraclitus  



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

Bug#704197: Please review: systemd checks

2013-03-29 Thread Michael Stapelberg

Package: lintian
Version: 2.5.10.4
Severity: wishlist

Attached you can find my first stab at systemd-related checks for
lintian. While some details in parsing the service files are not
implemented (see the TODOs in the code), I’d like you to have a look at
the checks in general. Is there anything that needs to be improved
before these can be shipped with lintian?

Thanks!
Check-Script: systemd
Author: Michael Stapelberg stapelb...@debian.org
Abbrev: systemd
Type: binary
Info: Checks various systemd policy things
Needs-Info: scripts, index, unpacked, file-info

Tag: systemd-service-file-outside-lib
Severity: serious
Certainty: certain
Info: The package ships a systemd service file outside
 tt/lib/systemd/system//tt
 .
 System administrators should have the possibility to overwrite a service file
 (or parts of it, in newer systemd versions) by placing a file in
 tt/etc/systemd/system/tt, so the canonical location we use for service
 files is tt/lib/systemd/system//tt.

Tag: systemd-tmpfiles.d-outside-usr-lib
Severity: serious
Certainty: certain
Info: The package ships a systemd tmpfiles.d(5) conf file outside
 tt/usr/lib/tmpfiles.d//tt

Tag: systemd-service-file-refers-to-obsolete-target
Severity: normal
Certainty: certain
Info: The systemd service file refers to an obsolete target.
 .
 Some targets are obsolete by now, e.g. syslog.target or dbus.target. For
 example, declaring ttAfter=syslog.target/tt is unnecessary by now because
 syslog is socket-activated and will therefore be started when needed.

Tag: systemd-no-service-for-init-script
Severity: serious
Certainty: certain
Info: The listed init.d script has no systemd equivalent.
 .
 Systemd has a SysV init.d script compatibility mode. It provides access to
 each SysV init.d script as long as there is no native service file with the
 same name (e.g. tt/lib/systemd/system/rsyslog.service/tt corresponds to
 tt/etc/init.d/rsyslog/tt).
 .
 Your package ships a service file, but for the listed init.d script, there is
 no corresponding systemd service file.

Tag: init.d-script-does-not-source-init-functions
Severity: normal
Certainty: certain
Info: The tt/etc/init.d/tt script does not source
 tt/lib/lsb/init-functions/tt. The ttsystemd/tt package provides
 tt/lib/lsb/init-functions.d/40-systemd/tt to redirect
 tt/etc/init.d/$script/tt calls to systemctl.
 .
 Please add a line like this to your tt/etc/init.d/tt script:
 .
  . /lib/lsb/init-functions

Tag: maintainer-script-calls-systemctl
Severity: normal
Certainty: certain
Info: The maintainer script calls systemctl directly. Actions such as enabling
 or starting a service have to be done via ttupdate-rc.d/tt or
 ttinvoke-rc.d/tt, respectively, which both do the right thing when systemd
 is installed/running.
# systemd -- lintian check script -*- perl -*-
#
# Copyright © 2013 Michael Stapelberg
#
# based on the apache2 checks file by:
# Copyright © 2012 Arno Töll
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, you can find it on the World Wide
# Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
# MA 02110-1301, USA.

package Lintian::systemd;

use strict;
use warnings;

use File::Basename;
use Lintian::Collect::Binary ();
use Lintian::Tags qw(tag);
use Lintian::Relation qw(:constants);
use Lintian::Util qw(fail);
use Data::Dumper;

sub run {
my ($pkg, $type, $info) = @_;

if ($type eq 'binary') {
# Figure out whether the maintainer of this package did any effort to
# make the package work with systemd. If not, we will not warn in case
# of an init script that has no systemd equivalent, for example.
my $ships_systemd_file = (scalar ( grep { m,/systemd/, } 
$info-sorted_index )  0);

# An array of names which are provided by the service files.
# This includes Alias= directives, so after parsing
# NetworkManager.service, it will contain NetworkManager and
# network-manager.
my @systemd_targets;

for my $file ($info-sorted_index) {
if ($file =~ m,^etc/tmpfiles\.d/.*\.conf$,) {
tag('systemd-tmpfiles.d-outside-usr-lib', $file);
}
if ($file =~ m,^etc/systemd/system/.*\.service$,) {
tag('systemd-service-file-outside-lib', $file);
}
if ($file =~ m,/systemd/system/.*\.service$,) {

Bug#704198: syslinux doesn't rewrite backup boot sector

2013-03-29 Thread Ian Bruce

Package: syslinux
Version: 3:4.05+dfsg-6+deb7u2
Severity: normal
Tags: upstream

After installing Syslinux on a USB flashdrive:

syslinux -d /boot/syslinux/ -i /dev/sde1

as described here:

http://www.syslinux.org/wiki/index.php/SYSLINUX#Linux

-- I found that dosfsck, from the dosfstools package, isn't happy
about it:

# dosfsck /dev/sde1
dosfsck 3.0.13, 30 Jun 2012, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
...

This doesn't seem to prevent booting from the partition, but such errors
are disconcerting, and presumably the backup is there for a reason.

There is some discussion of the technical issues involved here:

http://en.wikipedia.org/wiki/File_Allocation_Table#Technical_design

For FAT32 file systems, the reserved sectors include a File System
Information Sector at logical sector 1 and a Backup Boot Sector at
logical sector 6. While many other vendors have continued to utilize
a single-sector setup (logical sector 0 only) for the bootstrap
loader, Microsoft's boot sector code has grown to spawn over logical
sectors 0 and 2 since the introduction of FAT32, with logical sector
0 depending on sub-routines in logical sector 2. The Backup Boot
Sector area consists of three logical sectors 6, 7, and 8 as well.

-- but the basic problem seems clear enough. If Syslinux writes its
bootloader code into the VFAT boot sector, shouldn't it write a
duplicate copy into the backup area?

I have attached a copy of the first 32 (512-byte) sectors of the
flashdrive partition in question, in case anybody wants to investigate
this problem in detail, although it shouldn't be difficult to replicate.


-- Ian Bruce



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

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

Versions of packages syslinux depends on:
ii  libc62.13-38
ii  libuuid1 2.20.1-5.3
ii  syslinux-common  3:4.05+dfsg-6+deb7u2

Versions of packages syslinux recommends:
ii  mtools  4.0.17-1

Versions of packages syslinux suggests:
ii  dosfstools  3.0.13-1
ii  os-prober   1.42

-- 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#703630: RFS: libaria/2.7.5.2-1 [ITP] -- C++ library for MobileRobots/ActivMedia robots

2013-03-29 Thread Anton Gladky

Hi,

there are some comments on your package. It looks ok now, but:

1. Use DEP-3 for patches
2. 2.7.5.2-1 version was not in Debian. Remove from changelog.
3. Use VCS for packaging (preferable on alioth).
4. Remove libaria-dev.dirs (it seems, it is useless).
5. Copyright-file should not contain the information about deleted
files. Move it into the README.source.

Please, check also licenses of all files, which are included into the
tarball (I did not that).

Cheers,

Anton

On 03/27/2013 12:10 PM, Srećko Jurić-Kavelj wrote:
 Dear mentors, Anton,
 
 I've just wanted to let you know that I've uploaded a new version of
 libaria package.
 
 I've repackaged the upstream tarball to remove the binaries and other
 non-source files. Reed (upstream maintainer) sad that he will consider
 providing source only tarball from the next major release (2.8).
 
   To access further information about this package, please visit the following
   URL:
 
   http://mentors.debian.net/package/libaria
 
 
   Alternatively, one can download the package with dget using this command:
 
 dget -x 
 http://mentors.debian.net/debian/pool/main/liba/libaria/libaria_2.7.5.2+repack-1.dsc
 
   Changes since the last upload:
 
   * Repack the original tarball to remove unnecesary non-source files.
 
 
 Best,
 
 Srećko Jurić-Kavelj, dipl.ing. (Ms.E.E)
 Research and Teaching Assistant at University of Zagreb
 (Faculty of Electrical Engineering and Computing, Department of
 Control and Computer Engineering)
 
 Phone: +385 (0)1 6129 529
 Fax: +385 (0)1 6129 809
 E-mail: srecko.juric-kav...@fer.hr
 URL: http://www.fer.hr/srecko.juric-kavelj
 
 Sanctus Hieronymus: Parce mihi, Domine, quia dalmata sum!
 




signature.asc
Description: OpenPGP digital signature

Bug#704199: UDD: add columns for Multi-Arch

2013-03-29 Thread Helmut Grohne

Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: udd

It would be nice to be able to query Multi-Arch headers in udd. This
requires changing the schema which I have no clue about. After that it
should be a matter of moving Multi-Arch from ignorable to
non_mandatory in udd/packages_gatherer.py and updating a few more
places such as the insert statements. udd/ftpnew_gatherer.py might also
need an update.

Thanks

Helmut


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

Bug#605332: more info, only happen when not well integrated

2013-03-29 Thread Rene Engelhard

retitle 605332 special paste doesn't work when no matching desktop integration
close 605332 1:3.5.4+dfsg-4
thanks

On Thu, Mar 28, 2013 at 10:29:44PM -0430, PICCORO McKAY Lenz wrote:
 only happen if u have bad integrated env, by example ooo 3.X with
 kde3.X or ooo 3.X with LXDE , due are not reproducible in xfce or
 gnome puach..
 
 trying OOO_FORCE_DESKTOP improve and solves..

Weird.

 this but must be closed due libreoffice from wheeze not have this

We can do (the bug is not marked as affecting libreoffice anyway, though)

 problems, now lxde are well supported and kde was deprecated (trinity
 desktop has own integration patch)

... but not built in Debian ;)

Regards,

Rene


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

Bug#704198: VFAT header from USB flashdrive partition

2013-03-29 Thread ian_bruce

$ dd if=/dev/sde1 bs=512 count=32 | gzip usb-flash-partition-vfat.gz
32+0 records in
32+0 records out
16384 bytes (16 kB) copied, 0.000119295 s, 137 MB/s


usb-flash-partition-vfat.gz
Description: GNU Zip compressed data

Bug#704196: initial package created, uploaded



Some issues to be decided:

- naming convention for source package/orig.tar.gz
- is the version 2.1 or is it 7.x-2-1 ?
- patching it to look in /usr/local/drupal/7/libraries
- is there any packaging team that this could belong to, or would it be
worthwhile creating one?

Overview of the concept is in README.Debian:

http://anonscm.debian.org/gitweb/?p=collab-maint/drupal7-mod-libraries.git;a=blob_plain;f=debian/README.Debian;hb=e3c649e06db8dc996771f422d294e0a230be420a

Here is the VCS browser:

  http://git.debian.org/?p=collab-maint/drupal7-mod-libraries.git;a=summary

To clone a copy and build the package locally:

git clone
git://git.debian.org/git/collab-maint/drupal7-mod-libraries.git

cd drupal7-mod-libraries
dpkg-buildpackage -rfakeroot -i.git


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

Bug#704200: Installation was successfully on Lenovo Thinkpad

2013-03-29 Thread Bernhard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: installation-reports

Boot method: USB Drive with self-made ISO image
Image version: Self-made ISO image with wheezy installer RC1
Date: 2013-03-29

Machine: Lenovo Thinkpad L520
Processor: Intel(R) Pentium(R) CPU B950 @ 2.10GHz
Memory: 4GB
Partitions:

 DateisystemTyp
 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf rootfs
 rootfs 9611492 5381596   3741656   59% / udev
 devtmpfs 10240   0 102400% /dev tmpfs
 tmpfs   390012 3603896521% /run 
 /dev/disk/by-uuid/791a9572-f37f-49aa-9dd9-5851b0500e63 ext4
 9611492 5381596   3741656   59% / tmpfs
 tmpfs 5120   0  51200% /run/lock tmpfs
 tmpfs   975180   09751800% /run/shm /dev/sda7
 ext4 178153992  223764 1688805281% /home

Output of lspci -knn:

00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core
Processor Family DRAM Controller [8086:0104] (rev 09)
Subsystem: Lenovo Device [17aa:21dd]
Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd
Generation Core Processor Family Integrated Graphics Controller
[8086:0106] (rev 09)
Subsystem: Lenovo Device [17aa:21dd]
Kernel driver in use: i915
00:16.0 Communication controller [0780]: Intel Corporation 6
Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
Subsystem: Lenovo Device [17aa:21dd]
00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series
Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04)
Subsystem: Lenovo Device [17aa:21dd]
Kernel driver in use: ehci_hcd
00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series
Chipset Family High Definition Audio Controller [8086:1c20] (rev 04)
Subsystem: Lenovo Device [17aa:21dd]
Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series
Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4)
Kernel driver in use: pcieport
00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series
Chipset Family PCI Express Root Port 2 [8086:1c12] (rev b4)
Kernel driver in use: pcieport
00:1c.2 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series
Chipset Family PCI Express Root Port 3 [8086:1c14] (rev b4)
Kernel driver in use: pcieport
00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series
Chipset Family PCI Express Root Port 4 [8086:1c16] (rev b4)
Kernel driver in use: pcieport
00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series
Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b4)
Kernel driver in use: pcieport
00:1c.5 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series
Chipset Family PCI Express Root Port 6 [8086:1c1a] (rev b4)
Kernel driver in use: pcieport
00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series
Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 04)
Subsystem: Lenovo Device [17aa:21dd]
Kernel driver in use: ehci_hcd
00:1f.0 ISA bridge [0601]: Intel Corporation HM65 Express Chipset
Family LPC Controller [8086:1c49] (rev 04)
Subsystem: Lenovo Device [17aa:21dd]
00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 Series
Chipset Family 6 port SATA AHCI Controller [8086:1c03] (rev 04)
Subsystem: Lenovo Device [17aa:21dd]
Kernel driver in use: ahci
00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset
Family SMBus Controller [8086:1c22] (rev 04)
Subsystem: Lenovo Device [17aa:21dd]
03:00.0 Network controller [0280]: Intel Corporation Centrino
Wireless-N 1000 [Condor Peak] [8086:0084]
Subsystem: Intel Corporation Centrino Wireless-N 1000 BGN [8086:1315]
Kernel driver in use: iwlwifi
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
RTS5209 PCI Express Card Reader [10ec:5209] (rev 01)
Subsystem: Lenovo Device [17aa:21dd]
Kernel driver in use: rts_pstor
09:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 03)
Subsystem: Lenovo Device [17aa:21dd]
Kernel driver in use: r8169

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]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

No problems detected.
Installation was done with WLAN interface and WPA encryption.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG

Bug#690367: problem with wheezy fresh install

2013-03-29 Thread Carsten Schoenert

Hello Gevorg,

Am 28.03.2013 13:40, schrieb Gevorg Abrahamian:

Carsten - Sorry don't know what you mean by top posting.

Top-Posting is one of the horrible things that come with the practical
HTML Webmailers or by people that only knowing MS Outlook. But
top-posting makes it hard to find the relevant info from reporters like
you. :)

Here a short copy about top-posting and why don't to use it.

A3: Please.
Q3: Should I avoid top posting on mailing lists etc.?

A2: Because, by reversing the order of a conversation, it leaves the
reader without much context, and makes them read a message in an
unnatural order.
Q2: Why is top posting irritating?

A1: It is the practice of putting your reply to a message before the
quoted message, instead of after the (trimmed) message.
Q1: What is top posting?

Bug#704105: 704105: fixing title, owner and severity

2013-03-29 Thread Mònica Ramírez Arceda

retitle 704105 ITP: desktop-base-oldies -- packages containing theming from 
past releases’ desktop-base package
severity 704105 wishlist
owner 704105 Paul Tagliamonte paul...@debian.org
thanks

Hi,

I'm fixing 704105 title, owner and severity, but I'm not 100% sure 
if the package name and the owner are ok, so please feel free to 
change them if they're wrong.

Cheers.


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

Bug#704197: Please review: systemd checks

2013-03-29 Thread Niels Thykier

On 2013-03-29 11:11, Michael Stapelberg wrote:
 Package: lintian
 Version: 2.5.10.4
 Severity: wishlist
 
 Attached you can find my first stab at systemd-related checks for
 lintian. While some details in parsing the service files are not
 implemented (see the TODOs in the code), I’d like you to have a look at
 the checks in general. Is there anything that needs to be improved
 before these can be shipped with lintian?
 
 Thanks!
 

Hi,

Thanks for working on Lintian checks, it is much appreciated it.  :)

I have annotated some comments with [style], which are minor stylistic
guidelines.  I know Lintian's code style is a mess in general, so it
describes the style I hope we will eventually reach[1].  :)
  Note that I will try to (remember to) not repeat style hints, even if
the same mistake is made multiple times.


~Niels

[1] When in doubt, I tend to use:
  http://www.eyrie.org/~eagle/notes/style/perl.html

 
 systemd.desc
 
 
 Check-Script: systemd
 Author: Michael Stapelberg stapelb...@debian.org
 Abbrev: systemd

Abrrev is optional and is only useful if the name is shorter than the
name in Check-Script (it is an abbrevation of the name, like manpages
is aliased man).

 Type: binary
 Info: Checks various systemd policy things
 Needs-Info: scripts, index, unpacked, file-info
 
 [... some tags ...]

I noticed that there appear to be no use of references (Ref: URL, #bug,
policy X.Y ...).  I would recommend finding such so people can quickly
find more information.  Links to systemd documentation, specification or
even just a Debian wiki page.

 
 systemd
 
 [...]
 
 use File::Basename;

[style] I like to group Lintian modules separately (and after) external
modules.  That basically gives 3-4 groups; pragmas[, constants],
external modules and then Lintian modules.

 use Lintian::Collect::Binary ();

This import is not needed (in general, Perl do not require you to load
modules just because you use instances of classes from that module).

 use Lintian::Relation qw(:constants);

Does not appear to be used?

 use Data::Dumper;

Left-over from debugging?

 
 sub run {
 my ($pkg, $type, $info) = @_;
 
 if ($type eq 'binary') {

This condition will always be true - the Type:-field determines what
values $type can have.  In this particular case, it is set to binary.

If you do not need $pkg or $type, then you can replace them with undef. E.g.
my (undef, undef, $info) = @_;

That has the advantage that we know that argument is unused.  (As far as
I can tell, $pkg is passed around to various subs but never actually used).

 [...]
 
 for my $file ($info-sorted_index) {
 if ($file =~ m,^etc/tmpfiles\.d/.*\.conf$,) {
 tag('systemd-tmpfiles.d-outside-usr-lib', $file);

[style] The tag sub is a special case in regards to style; it tends to
be treated like a perl built-in or die-like sub (i.e. no parentheses
unless needed for understanding or semantic reasons).  So:

tag 'systemd-tmpfiles.d-outside-usr-lib', $file;

Note if you must use parentheses around tag, a built-in or a die-like
sub, please use the same style as for regular subs (see next comment).

 [...]
 if ($file =~ m,/systemd/system/.*\.service$,) {
 check_systemd_service_file($pkg, $info, $file);

[style] For non-built sub, we tend to have space between the sub name
and the argument parentheses.  For subs that takes no arguments, the
parentheses are omitted where possible.  So:

check_systemd_service_file ($pkg, $info, $file);

  [...]
 my @init_scripts = grep(m,^etc/init\.d/.+,, $info-sorted_index);
 

Erh, I think , might have been a poor choice of regex delimiter here
(as it is also the argument delimiter).  For this you could use :
(among others) or alternatively call grep with a block:

 my @init_scripts = grep {m,^etc/init\.d/.+,} $info-sorted_index;


  [...]
 if ($ships_systemd_file) {
 for my $init_script (@init_scripts) {
 if (grep(/\Q$init_script\E\.service/, @systemd_targets) == 0) 
 {
 tag('systemd-no-service-for-init-script', $init_script);
 }

We sometimes use the reversed form of if/unless to reduce scope level.
 E.g. something like:

tag 'systemd-no-service-for-init-script', $init_script
unless grep /\Q$init_script\E\.service/, @systemd_targets;

There is no hard rule on went; just an FYI that you are free to use it.

  [...]
 
 sub check_init_script {
 my ($pkg, $info, $file) = @_;

$pkg argument does not appear to be used?

 
 my $lsb_source_seen;
 open(my $fh, '', $info-unpacked($file));

No error handling if open fails!  Something as simple as:

   or fail open $file: $!;

is fine.

Secondly, there is no check for file type.  If someone (deliberately)
creates $file as a fifo-pipe or a symlink it will DoS or (possibly) read
host system files (respectively).  Usually, a

$info-index ($file)-is_regular_file

should do (if symlinks/hardlinks can

Bug#704177: libgnome-desktop-3-2: dependency on gnome-desktop3-data=3.4.2-1 blocks gnome-desktop3-data from being updated past 3.4.2-1

2013-03-29 Thread Emilio Pozuelo Monfort

tag 704177 + pending
thanks

On 03/29/2013 12:38 AM, Alex Vanderpol wrote:
 Package: libgnome-desktop-3-2
 Version: 3.4.2-1
 Severity: normal
 
 Dear Maintainer,
 
 This has actually been an issue since GNOME 3.6 entered Experimental.
 
 libgnome-desktop-3-2 version 3.4.2-1 depends on gnome-desktop3-data being
 exactly the same version, preventing gnome-desktop3-data from being updated
 beyond that version. Since Eye of GNOME (eog) still depends on this package
 (even at version 3.8), I cannot update gnome-desktop3-data past version 
 3.4.2-1
 without removing eog and libgnome-desktop-3-2.
 
 I'm not sure if there's anything in gnome-desktop3-data that libgnome-
 desktop-3-2 depends on so strictly that it can't work with newer versions of
 the package and have it's dependency changed to be on gnome-desktop3-data
 greater than or equal to version 3.4.2-1 (which is what libgnome-desktop-3-4
 and libgnome-desktop-3-7 currently have as their dependency on that package),
 but if there's not, would it at all be possible to fix that dependency so
 gnome-desktop3-data can be updated?

I fixed this a month ago in svn, but I didn't deem the change important enough
to upload it to unstable during the freeze.

For now I'm making eog pick the new libgnome-desktop. The other change will have
to wait.

Cheers,
Emilio


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

Bug#704018: git-buildpackage: include the name of the package being built in the debian tag message

On Wed, Mar 27, 2013 at 11:19:52AM -0700, Russ Allbery wrote:
 Daniel Kahn Gillmor d...@fifthhorseman.net writes:
 
  When i make cryptographic signatures, i consider it important that those
  signatures can be successfully interpreted in a context-independent
  manner.  That is, if the same signature was presented in a new place, it
  should not change its interpretation.  The data being signed needs to
  contain its own context explicitly and unambiguously.  For example, i
  would not sign an e-mail if the entire body was: Yes, I think this is a
  good idea. because the message could be trivially replayed in some
  other e-mail conversation to imply my agreement with an idea that i
  might not actually agree to.
 
 Just as a data point, whenever I tag a Git repository corresponding to a
 package upload to Debian, I include the entire *.changes file as the body
 of the signed tag message.  I picked up this habit from Sam Hartman, and
 I'm quite fond of it.  Not only does it achieve that context independence
 that you refer to, it also ties the repository tag together with the
 checksums of the exact packages that I built and uploaded to Debian based
 on that repository state.

That sounds ideal and I wanted to get around to implement this for quiet
some time. There are some patches pending that cleanup the changelog
handling. I'll have a look into adding this after merging those.
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#700443: [git-buildpackage/master] Fix typo

tag 700443 pending
thanks

Date:   Wed Feb 13 07:52:05 2013 +0100
Author: Guido GÃ¼nther a...@sigxcpu.org
Commit ID: b678c6ac458aff22ad50cfd8be29bddee88936ef
Commit URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff;h=b678c6ac458aff22ad50cfd8be29bddee88936ef
Patch URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff_plain;h=b678c6ac458aff22ad50cfd8be29bddee88936ef

Fix typo

Thanks: Andreas Beckmann
Closes: #700443
  


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

Bug#702200: [git-buildpackage/master] Purging of the build dir should be configurable via a config file

tag 702200 pending
thanks

Date:   Fri Mar 22 18:14:33 2013 +0100
Author: Guido GÃ¼nther a...@sigxcpu.org
Commit ID: fc9d019eb9af759c46a7a183d69e248275afe6bc
Commit URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff;h=fc9d019eb9af759c46a7a183d69e248275afe6bc
Patch URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff_plain;h=fc9d019eb9af759c46a7a183d69e248275afe6bc

Purging of the build dir should be configurable via a config file

so introdice --git[-no]-purge which is consistent with the other
boolean options and deprecate --git-dont-purge.

Closes: #702200
  


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

2013-03-29 Thread Adam D. Barratt


On 28.03.2013 21:55, Joachim Breitner wrote:

Am Mittwoch, den 27.03.2013, 23:13 +0100 schrieb Joachim Breitner:
The missing builds are due to some not yet debugged interaction 
between

the test suite and the buildd environment. The test suit fails
unreliably with “send: resource vanished (Broken pipe)”. Probably
network related.

On some arches where this happened, a give back has helped, e.g. on
s390x:

https://buildd.debian.org/status/logs.php?pkg=haskell-warpver=1.2.1.1-2%2Bb2arch=s390x

But with mips and amd64, I have had no luck with just giving it back
yet. Tried it again right now.


nah, this does not work. Disabled the test suite in unstable. Please

unblock haskell-warp/1.2.1.1-3


haskell-certificate migrated in this morning's britney run, along with 
a bunch of other packages including haskell-warp-tls but /not/ 
haskell-warp due to the active unblock being for -2. Do we still need to 
migrate haskell-warp -3?


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#703694: [git-buildpackage/master] Allow for upper case characters in the upstream version

tag 703694 pending
thanks

Date:   Fri Mar 22 17:34:15 2013 +0100
Author: Guido GÃ¼nther a...@sigxcpu.org
Commit ID: eb999f77c3cd4fa806eea54ae82e6b9079b207c8
Commit URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff;h=eb999f77c3cd4fa806eea54ae82e6b9079b207c8
Patch URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff_plain;h=eb999f77c3cd4fa806eea54ae82e6b9079b207c8

Allow for upper case characters in the upstream version

Closes: #703694
  


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

Bug#704018: [git-buildpackage/master] Include the name of the package being built in the debian tag message

2013-03-29 Thread Daniel Kahn Gillmor

tag 704018 pending
thanks

Date:   Tue Mar 26 17:41:53 2013 -0400
Author: Daniel Kahn Gillmor d...@fifthhorseman.net
Commit ID: 4323cc8838ea53008e911811160182f975ffb360
Commit URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff;h=4323cc8838ea53008e911811160182f975ffb360
Patch URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff_plain;h=4323cc8838ea53008e911811160182f975ffb360

Include the name of the package being built in the debian tag message

Currently, the message in the debian tag is just:

  Debian release %s % cp.version

This is a bad idea, because it means that the signed message itself
contains no mention of the project that is being worked on.

Since all git repositories are conceptually the same git repository
(some just have commits that others don't have), a malicious attacker
could inject tags from project A into the repository for project B and
the original developer's signature on those tags would be intact.

This is potentially a security problem.  For example: if there are
automated build systems that pull from a repo and verify signed tags
made by a known developer (and that developer contributes to multiple
projects), this conflation could be used to make those systems build
packages from an entirely other project.

The attached patch enforces the inclusion of the name of the package
into the tag's message.

Closes: #704018
  


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

2013-03-29 Thread Joachim Breitner

Hi,

Am Freitag, den 29.03.2013, 11:31 + schrieb Adam D. Barratt:
 haskell-certificate migrated in this morning's britney run,

great! Thanks to all involved.

  along with 
 a bunch of other packages including haskell-warp-tls but /not/ 
 haskell-warp due to the active unblock being for -2. Do we still need to 
 migrate haskell-warp -3?

No.

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#704018: git-buildpackage: include the name of the package being built in the debian tag message

On Wed, Mar 27, 2013 at 01:55:47PM -0400, Daniel Kahn Gillmor wrote:
 Hi Guido--
 
 Thanks for your prompt and thoughtful response, i appreciate it!
 
 git-buildpackage helps me a lot because it encodes standard workflow
 decisions and operations so i don't have to think about them.  without
 this fix, i have to work around git-buildpackage and do more things
 manually.
 
 On 03/26/2013 06:47 PM, Guido Günther wrote:
 
  We had a complained that this is already too much information (juat
  cp.version was deemed enough).
 
 Who made this complaint?  Is it public?
 
 When i make cryptographic signatures, i consider it important that those
 signatures can be successfully interpreted in a context-independent
 manner.  That is, if the same signature was presented in a new place, it
 should not change its interpretation.  The data being signed needs to
 contain its own context explicitly and unambiguously.  For example, i
 would not sign an e-mail if the entire body was: Yes, I think this is a
 good idea. because the message could be trivially replayed in some
 other e-mail conversation to imply my agreement with an idea that i
 might not actually agree to.
 
 It is critically important that any tool that makes automated signatures
 on my behalf respects the same context-independence constraint.
 
  Given that he has commit access to that repo.
 
 There are lots of ways that an attacker can gain access to a repo
 without having legitimate commit privileges.  Some git repositories are
 accessed in the clear (e.g. via git:// or http://), so anyone in control
 of the network could spoof the repo;  An attacker could compromise
 another developer's account; and so on.
 
 The point of having signed tags is that *it doesn't matter* who has
 access to the repo.  The entire communications infrastructure could fall
 apart or leak like a sieve and you could still verify whether the tag
 was made by one of a list of trusted individuals, and what they intended
 by the tag.
 
  Assuming you don't check that the commit you build can reach the
  debian branch head.
 
 The debian branch head can be moved to any commit in the repo by someone
 with control over the repo.
 
 I agree that it's possible that some automated systems will have an
 fingers-crossed boostrap phase and then only accept fast-forward merges
 before attempting a rebuild, but not all of them work that way, and
 given that we have cryptographic authentication possible, we shouldn't
 have to cross our fingers during the bootstrap phase or require
 fast-forward merges anyway.
 
  I'm not convinced that this helps an automated build system. Isn't this
  just a hint (that can be enforced by a commit hook). It certainly eases
  the detection that the commit belongs to the package.
 
 It doesn't ease the detection -- it makes that detection possible.
 Without it, there is no way to cryptographically guarantee that the tag
 you're looking at was intended for the project you expect.
 
  But if we're
  really after security here we should also document a proper setup for
  automated builds, otherwise the fix isn't useful as is. What workflow is
  on your mind?
 
 I agree that it would be good to have some best-practices documentation
 for folks who have automated build farms.  I don't believe that this fix
 should wait on that documentation.  The fix enables the documentation to
 be written, not the other way around.
 
 I'm not trying to claim that this bug makes the signed tags completely
 worthless; any human who actually examines a repository and is willing
 to think about it would see that a transplanted signed tag is pretty
 fishy.  But (a) i want signed tags to be usable by machines which are
 much worse at detecting fishiness, and (b) not all humans think this
 stuff through.

Convinced and pushed. Thanks for your patch!
 -- Guido

 
 Thanks for your work on git-buildpackage!
 
   --dkg
 




signature.asc
Description: Digital signature

Bug#703239: [PATCH proposed] Bug#703239: virtualbox-guest-x11: Bad return status for module build on kernel

2013-03-29 Thread Francesco Presel

I've also been affected by this bug, and have apparently managed to 
solve it:


$ sudo dpkg-reconfigure virtualbox-guest-dkms
[...]
Building initial module for 3.2.0-4-686-pae
Done.
[...]

$ lsmod|grep vbox
vboxvideo  12405  0
drm   146387  1 vboxvideo
vboxsf 32382  1
vboxguest 128365  6 vboxsf

Shared folders work, as well as shared clipboard.
I've not yet checked 3d acceleration (currently running VM with 3d 
acceleration disabled); I'll report ASAP.


So, I have a patch to propose. I'm sorry if this is not the correct way 
to report this; I'm not a developer, but I hope it can help anyway.


I've been able to compile the module by editing 
vboxvideo/vboxvideo_drm.c (inside /usr/src/virtualbox-guest-4.1.18 ).
The patch works like this: since kernel 3.2 from Debian contains 
backports from other kernels, it must be treated, inside this piece of 
code, as a higher version kernel. This patch will break non-Debian 3.2 
kernels (but should we care for that?), but allows this module to be 
compiled in Wheezy with the kernel Wheezy officially provides. It should 
be very simple and should not, therefore, break anything else (so, I 
hope it's suitable for an RC bug).
If there's a better way to distinguish the Debian kernel from other 
ones, you could preserve compatibility with non-debian 3.2 kernels: the 
bug is the same as reported here ( 
https://www.virtualbox.org/ticket/10756 )  for Fedora, but that fix was 
not working (I guess the variable it was checking was specific to 
Fedora); is there a similar variable for Debian?


This is the patch:

--- vboxvideo/vboxvideo_drm.c.orig2012-06-20 15:09:07.0 +0200
+++ vboxvideo/vboxvideo_drm.c2013-03-29 12:12:37.648816514 +0100

@@ -85,8 +85,10 @@
 return 0;
 #endif
 }
-#if LINUX_VERSION_CODE = KERNEL_VERSION(3,3,0)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(3,2,0)
 /* since linux-3.3.0-rc1 drm_driver::fops is pointer */
+/* For Debian, due to backports in the kernel code, Kernel 3.2 has to 
be treated as 3.3.*

+ * Attention: this will break non-Debian, 3.2 kernels. #703239 */
 static struct file_operations driver_fops =
 {
 .owner = THIS_MODULE,
@@ -109,14 +111,14 @@
 .get_map_ofs = drm_core_get_map_ofs,
 .get_reg_ofs = drm_core_get_reg_ofs,
 #endif
-# if LINUX_VERSION_CODE  KERNEL_VERSION(3,3,0)
+# if LINUX_VERSION_CODE  KERNEL_VERSION(3,2,0)
 .fops =
 {
 .owner = THIS_MODULE,


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

Bug#692006: [git-buildpackage/master] gbp-create-remote-repo: Set HEAD in remote repo

tag 692006 pending
thanks

Date:   Sun Nov 25 18:15:20 2012 +0100
Author: Guido GÃ¼nther a...@sigxcpu.org
Commit ID: 744f85b5d154168abcb95b2762223ac2c76b6956
Commit URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff;h=744f85b5d154168abcb95b2762223ac2c76b6956
Patch URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff_plain;h=744f85b5d154168abcb95b2762223ac2c76b6956

gbp-create-remote-repo: Set HEAD in remote repo

to debian branch

Closes: #692006
  


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

Bug#703540: Inconsistent use of _GNU_SOURCE

2013-03-29 Thread Michael Tautschnig

Hi Sven, hi all,

[...]
  Either all or no file should #define _GNU_SOURCE.
 
 Please add information how to reproduce this the next time you are adding 
 such 
 such a bug. Now I can just assume what you are writing is true (even when the 
 man page about sendto says otherwise). Not knowing how to reproduce it in the 
 best possible way just makes it harder for everyone to check the impact of 
 the 
 problem.
 

Just one question before I elaborate a bit: what information in the man page are
you referring to? I can't quite seem to see anything mentioning _GNU_SOURCE?

I fully understand your concerns and indeed it is a problem that I cannot quite
provide a concrete counterexample witnessing the problem. It may even be the
cast that, at present, this is only a potential problem and not a real one. It's
much like a compiler warning: ok to be ignored if you are doing it intentionally
and you are 100% sure you know what you are doing. In all other cases, however,
it is likely worth fixing, as the problem can only ever be found by link-time
type checking, which usual compilers can't do. Even if done, there is some
non-trivial effort required to tracing back the type inconsistency to
inconsistent order of #include or a missing #define.

The most I can provide right now is all the scripts that suffice to reproduce
the build results and error logs, to be found at
https://github.com/tautschnig/cprover-debian

 I've forwarded it to the upstream maintainer and attached the change for 
 Debian.
 
[...]

Thanks!

Best,
Michael



pgpwWBMSmpqSm.pgp
Description: PGP signature

Bug#672954: [git-buildpackage/experimental] Move debian/changelog manipulation to gbp.deb.changelog.ChangeLog.

2013-03-29 Thread Daniel Dehennin

tag 672954 pending
thanks

Date:   Wed May 30 21:30:45 2012 +0200
Author: Daniel Dehennin daniel.dehen...@baby-gnu.org
Commit ID: a9bf9cfd4b31076c54d4e377c1b31b5bd69f8661
Commit URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff;h=a9bf9cfd4b31076c54d4e377c1b31b5bd69f8661
Patch URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff_plain;h=a9bf9cfd4b31076c54d4e377c1b31b5bd69f8661

Move debian/changelog manipulation to gbp.deb.changelog.ChangeLog.

spawn_dch switch gbp.command.wrappers.Command.

* gbp/deb/changelog.py (ChangeLog.spawn_dch): static method adapted from
  gbp.scripts.dch and converted to gbp.command_wrappers.Command.
  (add_entry): New method adapted from
  gbp.scripts.dch.add_changelog_entry.
  (add_section): New method adapted from
  gbp.scripts.dch.add_changelog_entry. Remove DebianGitRepository and
  options, this has nothing to do with changelog management.

* tests/test_Changelog.py: Test new methods.

* gbp/scripts/dch.py: Remove useless functions: system(), spawn_dch(),
  add_changelog_section() and add_changelog_entry().
  Update calls accordingly.
  (fixup_trailer): Use spawn_dch() method of ChangeLog class.
  (process_options): dch_options became a list.
  (main): Use add_section() and add_entry() methods of ChangeLog object.
  Take care of upstream version since ChangeLog.add_section() does not
  manage it anymore.
  Update exception handling, ChangeLog.spawn_dch() can raise
  CommandExecFailed exception.

Closes: #672954
  


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

Bug#704018: [git-buildpackage/experimental] Include the name of the package being built in the debian tag message

2013-03-29 Thread Daniel Kahn Gillmor

tag 704018 pending
thanks

Date:   Tue Mar 26 17:41:53 2013 -0400
Author: Daniel Kahn Gillmor d...@fifthhorseman.net
Commit ID: 4323cc8838ea53008e911811160182f975ffb360
Commit URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff;h=4323cc8838ea53008e911811160182f975ffb360
Patch URL: 
http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff_plain;h=4323cc8838ea53008e911811160182f975ffb360

Include the name of the package being built in the debian tag message

Currently, the message in the debian tag is just:

  Debian release %s % cp.version

This is a bad idea, because it means that the signed message itself
contains no mention of the project that is being worked on.

Since all git repositories are conceptually the same git repository
(some just have commits that others don't have), a malicious attacker
could inject tags from project A into the repository for project B and
the original developer's signature on those tags would be intact.

This is potentially a security problem.  For example: if there are
automated build systems that pull from a repo and verify signed tags
made by a known developer (and that developer contributes to multiple
projects), this conflation could be used to make those systems build
packages from an entirely other project.

The attached patch enforces the inclusion of the name of the package
into the tag's message.

Closes: #704018
  


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

Bug#660545: CVE-2011-1679 / CVE-2011-1680

2013-03-29 Thread Jonathan Wiltshire

Package: ncpfs

Dear maintainer,

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

squeeze (6.0.8) - use target stable

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

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

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

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

Thanks,

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

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


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

Bug#704201: gnomeradio: crashed with SIGABRT in __libc_message()

2013-03-29 Thread trinitonadam

Package: gnomeradio
Version: 1.8-2
Severity: important
Tags: patch



When I tried to change radio device to, for example /dev/radio 1, and this does 
not exist, gnomeradio crash

Solution is Don't stop radio twice to avoid double free or corruption in file 
radio.c

--
v4l2.c
--
 RadioDev*
 v4l2_radio_dev_new (void)
 {
-RadioDev *dev;
+   RadioDev *dev;
V4L2RadioDev *v4l2_dev;
 
v4l2_dev = malloc (sizeof (V4L2RadioDev));
--
v4l1.c
--
 RadioDev*
 v4l1_radio_dev_new (void)
 {
-RadioDev *dev;
+   RadioDev *dev;
V4L1RadioDev *v4l1_dev;
 
v4l1_dev = malloc(sizeof(V4L1RadioDev));

--
radio.c
This is a bad idea since consecutive radio_stop and radio_start will cause bad
things to happen
--
  
 int radio_init(char *device, DriverType driver)
 {
-int rv = -1;
-   if (dev) {
-   radio_stop();
-   }
+   int rv = -1;
 
switch (driver) {
case DRIVER_ANY:


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

Bug#704202: gnomeradio: crashed with SIGABRT in __libc_message()

2013-03-29 Thread trinitonadam

Package: gnomeradio
Version: 1.8-2
Severity: important

When I tried to change radio device to, for example /dev/radio 1, and this does 
not exist, gnomeradio crash

Solution is Don't stop radio twice to avoid double free or corruption in file 
radio.c

--
v4l2.c
--
 RadioDev*
 v4l2_radio_dev_new (void)
 {
-RadioDev *dev;
+   RadioDev *dev;
V4L2RadioDev *v4l2_dev;
 
v4l2_dev = malloc (sizeof (V4L2RadioDev));
--
v4l1.c
--
 RadioDev*
 v4l1_radio_dev_new (void)
 {
-RadioDev *dev;
+   RadioDev *dev;
V4L1RadioDev *v4l1_dev;
 
v4l1_dev = malloc(sizeof(V4L1RadioDev));

--
radio.c
This is a bad idea since consecutive radio_stop and radio_start will cause bad
things to happen
--
  
 int radio_init(char *device, DriverType driver)
 {
-int rv = -1;
-   if (dev) {
-   radio_stop();
-   }
+   int rv = -1;
 
switch (driver) {
case DRIVER_ANY:


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

Bug#660197: Registration No. 0201GFRM-7

2013-03-29 Thread BlackBerry® Easter Promotion

You Have Won !!!

You Have Won!!!


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

Bug#704201: gnomeradio: crashed with SIGABRT in __libc_message()

2013-03-29 Thread triniton adam

StacktraceSource
#0  0x7f794f3c6067 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
  [Error: ../nptl/sysdeps/unix/sysv/linux/raise.c was not found in source tree]
#1  0x7f794f3c96c8 in __GI_abort () at abort.c:90
  [Error: abort.c was not found in source tree]
#2  0x7f794f4035cb in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x7f794f516840 *** Error in `%s': %s: 0x%s ***\n) at 
../sysdeps/unix/sysv/linux/libc_fatal.c:199
  [Error: ../sysdeps/unix/sysv/linux/libc_fatal.c was not found in source tree]
#3  0x7f794f40fa66 in malloc_printerr (ptr=0xdcfa10, str=0x7f794f516a08 
double free or corruption (fasttop), action=3) at malloc.c:4902
  [Error: malloc.c was not found in source tree]
#4  _int_free (av=optimized out, p=0xdcfa00, have_lock=0) at malloc.c:3758
  [Error: malloc.c was not found in source tree]
#5  0x0040f77a in radio_init (device=0xdcc660 /dev/radio1, 
driver=DRIVER_ANY) at radio.c:40
  35:  
  36: int radio_init(char *device, DriverType driver)
  37: {
  38: int rv = -1;
  39:   if (dev) {
  40:   radio_stop();
  41:   }
  42: 
  43:   switch (driver) {
  44:   case DRIVER_ANY:
  45:   case DRIVER_V4L2:
#6  0x0040b3a4 in start_radio (restart=restart@entry=1, 
app=app@entry=0x0) at gui.c:259
  254: driver = DRIVER_V4L1;
  255: if (0 == strcmp(settings.driver, v4l2))
  256: driver = DRIVER_V4L2;
  257: }
  258: 
  259:  if (!radio_init(settings.device, driver))
  260:  {
  261:  char *caption = g_strdup_printf(_(Could not open device 
\%s\!), settings.device);
  262:  char *detail = g_strdup_printf(_(Check your settings and make 
sure that no other\n
  263:  program is using %s.\nAlso make sure that you 
have read-access to it.), settings.device);
  264:  show_error_message(caption, detail);
#7  0x0040d6c4 in device_entry_activate_cb (widget=optimized out, 
data=0x0) at prefs.c:204
  199:  if (!strcmp(settings.device, text)) return FALSE;
  200:  
  201:  if (settings.device) g_free(settings.device);
  202:  settings.device = g_strdup(text);
  203:  
  204:  start_radio(TRUE, data);
  205:  
  206:  return FALSE;
  207: }
  208: 
  209: static gboolean mixer_combo_change_cb(GtkComboBox *combo, gpointer data)
#8  0x7f79504ee9d0 in g_closure_invoke (closure=0xe3bf20, return_value=0x0, 
n_param_values=1, param_values=0xf7f1f0, invocation_hint=0x7fff67492840) at 
/build/buildd/glib2.0-2.35.4/./gobject/gclosure.c:777
  [Error: /build/buildd/glib2.0-2.35.4/./gobject/gclosure.c was not found in 
source tree]
#9  0x7f7950500c40 in signal_emit_unlocked_R (node=node@entry=0xc53970, 
detail=detail@entry=0, instance=instance@entry=0xbd1920, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0xf7f1f0) at 
/build/buildd/glib2.0-2.35.4/./gobject/gsignal.c:3566
  [Error: /build/buildd/glib2.0-2.35.4/./gobject/gsignal.c was not found in 
source tree]
#10 0x7f7950508097 in g_signal_emitv 
(instance_and_params=instance_and_params@entry=0xf7f1f0, 
signal_id=signal_id@entry=287, detail=detail@entry=0, return_value=0x0, 
return_value@entry=0x7fff67492980) at 
/build/buildd/glib2.0-2.35.4/./gobject/gsignal.c:3055
  [Error: /build/buildd/glib2.0-2.35.4/./gobject/gsignal.c was not found in 
source tree]
#11 0x7f79515e8ab1 in gtk_binding_entry_activate (entry=0xe349e0, 
object=object@entry=0xbd1920) at 
/build/buildd/gtk+3.0-3.6.4/./gtk/gtkbindings.c:651
  [Error: /build/buildd/gtk+3.0-3.6.4/./gtk/gtkbindings.c was not found in 
source tree]
#12 0x7f79515e8fb8 in binding_activate 
(binding_set=binding_set@entry=0xe35570, entries=entries@entry=0xfb2b90, 
object=object@entry=0xbd1920, is_release=is_release@entry=0, 
unbound=unbound@entry=0x7fff67492a74) at 
/build/buildd/gtk+3.0-3.6.4/./gtk/gtkbindings.c:1523
  [Error: /build/buildd/gtk+3.0-3.6.4/./gtk/gtkbindings.c was not found in 
source tree]
#13 0x7f79515e9112 in gtk_bindings_activate_list 
(object=object@entry=0xbd1920, entries=entries@entry=0xfb2b90, is_release=0) at 
/build/buildd/gtk+3.0-3.6.4/./gtk/gtkbindings.c:1584
  [Error: /build/buildd/gtk+3.0-3.6.4/./gtk/gtkbindings.c was not found in 
source tree]
#14 0x7f79515ea456 in gtk_bindings_activate_event (object=0xbd1920, 
event=0xf59890) at /build/buildd/gtk+3.0-3.6.4/./gtk/gtkbindings.c:1669
  [Error: /build/buildd/gtk+3.0-3.6.4/./gtk/gtkbindings.c was not found in 
source tree]
#15 0x7f7951656fc6 in gtk_entry_key_press (widget=0xbd1920, event=0xf59890) 
at /build/buildd/gtk+3.0-3.6.4/./gtk/gtkentry.c:4519
  [Error: /build/buildd/gtk+3.0-3.6.4/./gtk/gtkentry.c was not found in source 
tree]
#16 0x7f79516c52dc in _gtk_marshal_BOOLEAN__BOXEDv (closure=0xa83c20, 
return_value=0x7fff67492c70, instance=optimized out, args=optimized out, 
marshal_data=optimized out, n_params=optimized out, param_types=0xa83c50) 
at

Bug#703540: [B.A.T.M.A.N.] Bug#703540: Inconsistent use of _GNU_SOURCE

2013-03-29 Thread Antonio Quartulli

Hi Michael,

On Fri, Mar 29, 2013 at 11:48:16AM +, Michael Tautschnig wrote:
 Hi Sven, hi all,
 
 [...]
   Either all or no file should #define _GNU_SOURCE.
  
  Please add information how to reproduce this the next time you are adding 
  such 
  such a bug. Now I can just assume what you are writing is true (even when 
  the 
  man page about sendto says otherwise). Not knowing how to reproduce it in 
  the 
  best possible way just makes it harder for everyone to check the impact of 
  the 
  problem.
  
 
 Just one question before I elaborate a bit: what information in the man page 
 are
 you referring to? I can't quite seem to see anything mentioning _GNU_SOURCE?
 
 I fully understand your concerns and indeed it is a problem that I cannot 
 quite
 provide a concrete counterexample witnessing the problem. It may even be the
 cast that, at present, this is only a potential problem and not a real one. 
 It's
 much like a compiler warning: ok to be ignored if you are doing it 
 intentionally
 and you are 100% sure you know what you are doing. In all other cases, 
 however,
 it is likely worth fixing, as the problem can only ever be found by link-time
 type checking, which usual compilers can't do. Even if done, there is some
 non-trivial effort required to tracing back the type inconsistency to
 inconsistent order of #include or a missing #define.
 
 The most I can provide right now is all the scripts that suffice to reproduce
 the build results and error logs, to be found at
 https://github.com/tautschnig/cprover-debian
 
  I've forwarded it to the upstream maintainer and attached the change for 
  Debian.
  
 [...]
 
 Thanks!
 


Elektra provided a patch to fix this issue and it has been applied already.
The patch and the related Applied! message have been posted to the batman ml,
maybe you are not subscribed and you did not get them?

Cheers,


-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto Che Guevara


pgpyjGuqlwk7V.pgp
Description: PGP signature

Bug#704203: python-django: should recommend (or suggest) libgdal1

2013-03-29 Thread Jonas Smedegaard

Package: python-django
Severity: normal

pyhon-django makes use of GDAL if the library is available.

Therefore please have pthon-django either recommend or suggest libgdal1,
depending on how common a feature it this is judged to be.

 - Jonas


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

Bug#704204: gnome-keyring doesn't work with ecdsa keys

2013-03-29 Thread Andy Ruddock

Package: gnome-keyring
Version: 3.4.1-5
Severity: normal

Dear Maintainer,

$ ssh-add

Enter passphrase for /home/user/.ssh/id_rsa: 
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
Error reading response length from authentication socket.
Could not add identity: /home/user/.ssh/id_ecdsa

All keys generated using default values for size, ecdsa key
generated with

$ ssh-keygen -t ecdsa

and accepting defaults values at the prompts for file locations.

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

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

Versions of packages gnome-keyring depends on:
ii  dbus-x11 1.6.8-1
ii  dconf-gsettings-backend [gsettings-backend]  0.12.1-3
ii  gcr  3.4.1-3
ii  libc62.13-38
ii  libcap-ng0   0.6.6-2
ii  libcap2-bin  1:2.22-1.2
ii  libdbus-1-3  1.6.8-1
ii  libgck-1-0   3.4.1-3
ii  libgcr-3-1   3.4.1-3
ii  libgcrypt11  1.5.0-5
ii  libglib2.0-0 2.33.12+really2.32.4-5
ii  libgtk-3-0   3.4.2-6

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.4.1-5

gnome-keyring 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#468235: Debug level alternatives in man page

2013-03-29 Thread John Talbut

Seems to come under this heading.

The man page for wpa_cli needs to at least list and preferably explain
the options for level.  As I understand it they are restricted to:
EXCESSIVE, MSGDUMP, DEBUG, INFO, WARNING, ERROR


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

Bug#704201: gnomeradio: crashed with SIGABRT in __libc_message()

2013-03-29 Thread George Pojar

PATCH:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/gnomeradio/raring/view/head:/debian/patches/gnomeradio-device.patch

Bug#704190: Confirmed

2013-03-29 Thread Anton Gladky

tags 704190 + confirmed
thanks

I tested that and can confirm the same problem.

Anton


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

Bug#704205: git-annex: FTBFS: tries to write to $HOME

Package: src:git-annex
Version: 4.20130323
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi!

Your package failed to build on the buildds:

cabal  configure
cabal: /home/buildd: pConfig file path source is default config file.
Config file /home/buildd/.cabal/config not found.
Writing default configuration to /home/buildd/.cabal/config
ermission denied
make[1]: *** [Build/SysConfig.hs] Error 1
make[1]: Leaving directory 
`/build/buildd-git-annex_4.20130323-armhf-FyQZxb/git-annex-4.20130323'
dh_auto_build: make -j1 returned exit code 2
make: *** [build-arch] Error 2

Full build log at
https://buildd.debian.org/status/fetch.php?pkg=git-annexarch=kfreebsd-amd64ver=4.20130323stamp=1364068291

Note: Packages are not supposed to write to $HOME during build and
  buildds therefore have a non-useable $HOME by default to catch
  this kind of error

Regards

Christoph


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

Bug#703358: virtualbox-guest-dkms: virtualbox guest modules fail to build with the modified 3.2 kernel of Debian 7.0

2013-03-29 Thread J.D.

Package: virtualbox-guest-dkms
Version: 4.1.18-dfsg-2
Followup-For: Bug #703358

Dear Maintainer,

Without a Linux 3.4 kernel and with the 3.2 kernel currently included with
Debian 7.0 (patched to include portions of the 3.4 kernel), build fails
when attempting to build the kernel modules required to support Debian 7.0
inside a virtualbox virtual machine.

Here's an excerpt reporting the error:

 Loading new virtualbox-guest-4.1.18 DKMS files...
 Building only for 3.2.0-4-amd64
 Building initial module for 3.2.0-4-amd64
 Error! Bad return status for module build on kernel: 3.2.0-4-amd64 (x86_64)


To overcome the difficulty, I modified the r42164 fix available from the
following source:  https://www.virtualbox.org/ticket/10756 

After patching the code, dpkg-reconfigure virtualbox-guest-dkms
successfully produces functional modules:

 DKMS: install completed.


The patch here assumes that any kernel at or above 3.2.39 is either
3.3.0+ or is modified with drm code from the later kernel versions for
a Debian 7.0 system.

Obviously, this patch breaks 3.2 compatibility above 3.2.39 for a
non-Debian 7.0 system or a Debian 7.0 system modified to run a clean
3.2 kernel, but Debian 7.0 already breaks version number compatibility
anyway by patching the 3.2 kernel with portions of 3.4 code and calling
it 3.2 instead of using the entire stable 3.4 kernel and calling it 3.4.

In other words, this patch counters one somewhat broken version number
with a version check that is itself somewhat broken.

A broken patch for a broken system.

*** Patch begin (edited by jodarom, licensed for GNU GPLv2) ***
--- vboxvideo_drm.c.orig2012-06-20 08:09:07.0 -0500
+++ vboxvideo_drm.c 2013-03-29 06:19:28.689023873 -0500
@@ -67,6 +67,14 @@
 #   if RHEL_RELEASE_CODE = RHEL_RELEASE_VERSION(6,1)
 #define DRM_RHEL61
 #   endif
+#   if RHEL_RELEASE_CODE = RHEL_RELEASE_VERSION(6,3)
+#define DRM_RHEL63
+#   endif
+#  endif
+/* Debian 7.0 patches kernel 3.2.39 with code from the 3.4 kernel */
+/* Assume a Debian 7.0 system and force it for versions = 3.2.39 */
+#  if LINUX_VERSION_CODE = KERNEL_VERSION(3, 2, 39)
+#   define DRM_DEBIAN70
 #  endif
 # endif

@@ -85,7 +93,7 @@
 return 0;
 #endif
 }
-#if LINUX_VERSION_CODE = KERNEL_VERSION(3,3,0)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(3,3,0) || defined(DRM_RHEL63) || 
defined(DRM_DEBIAN70)
 /* since linux-3.3.0-rc1 drm_driver::fops is pointer */
 static struct file_operations driver_fops =
 {
@@ -109,7 +117,7 @@
 .get_map_ofs = drm_core_get_map_ofs,
 .get_reg_ofs = drm_core_get_reg_ofs,
 #endif
-# if LINUX_VERSION_CODE  KERNEL_VERSION(3,3,0)
+# if LINUX_VERSION_CODE  KERNEL_VERSION(3,3,0)  !defined(DRM_RHEL63)  
!defined(DRM_DEBIAN70)
 .fops =
 {
 .owner = THIS_MODULE,
@@ -126,7 +134,7 @@
 .poll = drm_poll,
 .fasync = drm_fasync,
 },
-#else /* LINUX_VERSION_CODE = KERNEL_VERSION(3,3,0) */
+#else /* LINUX_VERSION_CODE = KERNEL_VERSION(3,3,0) || defined(DRM_RHEL63) || 
defined(DRM_DEBIAN70) */
 .fops = driver_fops,
 #endif
 #if LINUX_VERSION_CODE  KERNEL_VERSION (2, 6, 39)  !defined(DRM_RHEL61)

*** Patch end ***



-- 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/1 CPU core)
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 virtualbox-guest-dkms depends on:
ii  dkms2.2.0.3-1.2
ii  dpkg1.16.9
ii  virtualbox-guest-utils  4.1.18-dfsg-2

virtualbox-guest-dkms recommends no packages.

virtualbox-guest-dkms 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#704206: teem: FTBFS[any-i386]: testsuite failures

Package: src:teem
Version: 1.11.0~svn5906-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi!

Your package failed to build on the buildds:

77% tests passed, 8 tests failed out of 35

Total Test time (real) =  24.32 sec

The following tests FAILED:
  9 - trand (Failed)
 20 - probeScl (Failed)
 26 - kernall (Failed)
 30 - probeSS_cos02 (Failed)
 31 - probeSS_cos04 (Failed)
 32 - probeSS_cos10 (Failed)
 34 - probeSS_ctmr04 (Failed)
 35 - probeSS_ctmr10 (Failed)
Errors while running CTest
make: *** [build/libteem2] Error 8

Full build log at
https://buildd.debian.org/status/fetch.php?pkg=teemarch=i386ver=1.11.0%7Esvn5906-1stamp=1357758591

Regards

Christoph


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

Bug#704208: missing dependency on python2.6

Source: python-gobject-dev
Version: 2.21.4+is.2.21.3-1
Severity: serious

usr/bin/pygobject-codegen-2.0
 #!/bin/sh
 
 prefix=/usr
 datarootdir=${prefix}/share
 datadir=${datarootdir}
 codegendir=${datadir}/pygobject/2.0/codegen
 
 PYTHONPATH=$codegendir
 export PYTHONPATH
 
 exec /usr/bin/python2.6 $codegendir/codegen.py $@

explicitely executes python2.6 while the package only depends on
python (=2.5)

This causes the current gtk-vnc FTBFS

Regards

Christoph

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

Kernel: kFreeBSD 10.0-0-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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#668284: Spice-xpi package in debian

2013-03-29 Thread Laurent Bigonville

Hello,

I'm contacting you as you are packaging the rest of the spice stack.

I was wondering if you saw the RFP (bug #668284) for spice-xpi which is
a in browser plugin that allows people using ovirt to connect the
display of a VM.

Somebody already made some initial work for the packaging. I would
however mayve change the name of the binary package to something else.

Do you think you might be interested in maintaining this package in
Debian?

Cheers

Laurent Bigonville


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

Bug#704207: linux-image-3.2.0-4-686-pae: soft lockup after suspend to disk

2013-03-29 Thread Hendrik Tews

Package: src:linux
Version: 3.2.39-2
Severity: important

Dear Maintainer,

-- Package-specific info:
** Version:
Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 
4.6.3 (Debian 4.6.3-15) ) #1 SMP Debian 3.2.39-2

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-686-pae 
root=UUID=b2ab74ed-fc01-4d81-99d1-bcad9228433b ro splash acpi_osi=Linux 
acpi_backlight=vendor quiet

** Not tainted

** Kernel log:
[   47.162902] cfg80211: (549 KHz - 571 KHz @ 4 KHz), (N/A, 
2700 mBm)
[   58.018904] wlan0: no IPv6 routers present
[  209.505682] PM: Marking nosave pages: 0009c000 - 0010
[  209.505686] PM: Basic memory bitmaps created
[  209.700702] Syncing filesystems ... done.
[  209.701573] Freezing user space processes ... (elapsed 0.01 seconds) done.
[  209.714781] PM: Preallocating image memory... done (allocated 154381 pages)
[  209.847941] PM: Allocated 617524 kbytes in 0.13 seconds (4750.18 MB/s)
[  209.847943] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) 
done.
[  209.862545] Suspending console(s) (use no_console_suspend to debug)
[  209.872483] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  210.401574] PM: freeze of devices complete after 539.922 msecs
[  210.401870] PM: late freeze of devices complete after 0.292 msecs
[  210.402322] ACPI: Preparing to enter system sleep state S4
[  210.544772] PM: Saving platform NVS memory
[  210.545563] Disabling non-boot CPUs ...
[  210.649049] CPU 1 is now offline
[  210.752838] CPU 2 is now offline
[  210.856658] CPU 3 is now offline
[  210.857081] Extended CMOS year: 2000
[  210.857156] PM: Creating hibernation image:
[  210.958915] PM: Need to copy 153414 pages
[  210.958918] PM: Normal pages needed: 45812 + 1024, available pages: 181795
[  210.857188] PM: Restoring platform NVS memory
[  210.857723] Extended CMOS year: 2000
[  210.857769] Enabling non-boot CPUs ...
[  210.857911] Booting Node 0 Processor 1 APIC 0x4
[  210.857912] smpboot cpu 1: start_ip = 98000
[  210.868100] Initializing CPU#1
[  210.868919] Calibrating delay loop (skipped) already calibrated this CPU
[  210.889391] NMI watchdog enabled, takes one hw-pmu counter.
[  210.890127] CPU1 is up
[  210.890647] Booting Node 0 Processor 2 APIC 0x1
[  210.890654] smpboot cpu 2: start_ip = 98000
[  210.900840] Initializing CPU#2
[  210.901670] Calibrating delay loop (skipped) already calibrated this CPU
[  210.922339] NMI watchdog enabled, takes one hw-pmu counter.
[  210.922818] CPU2 is up
[  210.923189] Booting Node 0 Processor 3 APIC 0x5
[  210.923193] smpboot cpu 3: start_ip = 98000
[  210.92] Initializing CPU#3
[  210.934201] Calibrating delay loop (skipped) already calibrated this CPU
[  210.954775] NMI watchdog enabled, takes one hw-pmu counter.
[  210.955302] CPU3 is up
[  210.958171] ACPI: Waking up from system sleep state S4
[  211.321285] PM: early restore of devices complete after 0.632 msecs
[  211.361809] i915 :00:02.0: setting latency timer to 64
[  211.361813] ehci_hcd :00:1a.0: setting latency timer to 64
[  211.361828] snd_hda_intel :00:1b.0: setting latency timer to 64
[  211.361837] usb usb1: root hub lost power or was reset
[  211.365785] ehci_hcd :00:1a.0: cache line size of 64 is not supported
[  211.365796] snd_hda_intel :00:1b.0: irq 42 for MSI/MSI-X
[  211.365799] ehci_hcd :00:1d.0: setting latency timer to 64
[  211.365812] usb usb2: root hub lost power or was reset
[  211.369782] ehci_hcd :00:1d.0: cache line size of 64 is not supported
[  211.369806] pci :00:1e.0: setting latency timer to 64
[  211.369817] ahci :00:1f.2: setting latency timer to 64
[  211.382878] sd 0:0:0:0: [sda] Starting disk
[  211.687845] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  211.695835] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  211.698494] ata5.00: configured for UDMA/100
[  211.715829] usb 1-1: reset high-speed USB device number 2 using ehci_hcd
[  211.739714] ata1.00: configured for UDMA/100
[  211.959399] usb 2-1: reset high-speed USB device number 2 using ehci_hcd
[  212.126556] wlan0: deauthenticated from 00:24:01:21:02:e6 (Reason: 6)
[  212.150154] cfg80211: Calling CRDA to update world regulatory domain
[  212.378774] usb 2-1.5: reset high-speed USB device number 3 using ehci_hcd
[  212.727334] PM: restore of devices complete after 1367.984 msecs
[  212.747957] Restarting kernel threads ... done.
[  212.748111] snapshot_ioctl: ioctl '4004330c' is deprecated and will be 
removed soon, update your suspend-to-disk utilities
[  212.748113] Restarting tasks ... done.
[  212.760045] cfg80211: World regulatory domain updated:
[  212.760048] cfg80211: (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp)
[  212.760052] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[  212.760055] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[  212.760058] cfg80211: (2474000 KHz - 2494000 KHz @

Bug#704209: Esperanto [epo(basic)] layout breaks Right Alt = ISO_Next_Group when activated

2013-03-29 Thread Ivan Shmakov

Package: xkb-data
Version: 2.5.1-3
Tags: patch

After the ‘epo(basic)’ layout is activated with ISO_Next_Group,
bound to Right Alt, it's no longer possible to switch layouts.

The keyboard layout is configured as:

$ setxkbmap -layout us,epo -option grp:toggle 

I believe that symbols/epo shouldn't try to include
‘level3(ralt_switch)’ by itself (although I've seen it being
done in some other symbols/* files), leaving it up to the
explicit user's action; such as, e. g.:

$ setxkbmap -layout us,epo -option grp:switch 

The patch MIME'd fixes the issue for me.

Dankas antaŭe.

-- 
FSF associate member #7257  http://hfday.org/
--- /usr/share/X11/xkb/symbols/epo.~1364561268~	2012-12-25 11:40:03.0 +
+++ /usr/share/X11/xkb/symbols/epo	2013-03-29 12:06:39.359961082 +
@@ -41,7 +41,7 @@
 
   key AE05  { [ 5,percent,  EuroSign,  EuroSign   ] };
 
-  include level3(ralt_switch)
+//  include level3(ralt_switch)
 };

Bug#703588: Actually a bug in python-gobject-dev

See #704208


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

Bug#704208: wheezy

Control: found -1 2.28.6-10
Hi!

  Note btw that the version in wheezy (-10) executes python2.7 without a
dependency on the python2.7 package and is therefore affected as well
(though the bug doesn't show there because python happens to depend on
python2.7 currently)

Christoph


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

Bug#704201: gnomeradio: crashed with SIGABRT in __libc_message()

2013-03-29 Thread George Pojar

Description of problem:

In my sistem I have one PCI TV/FM tuner card and one removable USB TV/FM
tuner.

Gnomeradio is set to use, by default /dev/radio0, device create by PCI
TV/FM card.
I discover this problem when I forgotten to attach USB TV/FM and I try to
set gnomeradio
to use /dev/radio1 (device that would have made it by USB TV/FM and, of
course if USB
isn't connected, it does not exist).

When I tried to change radio device to /dev/radio1, in Preferences Radio
Device
combo textbox and I press ENTER to SAVE settings, results: gnomeradio crash.

Version-Release 1.8-2:

How reproducible:

Steps to Reproduce:

1. Open Gnomeradio
2. Open Preferences Settings
3. Enter in Radio Device settings combo textbox one that not exist (e.g.
/dev/radio5)
4. Press ENTER to SAVE

Actual results:

gnomeradio crashed with SIGABRT in __libc_message()

Expected results:

gnomeradio to display message that device not exist

Additional info:

StacktraceSource:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=StacktraceSource.txt;att=2;bug=704201

PATCH:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/gnomeradio/raring/view/head:/debian/patches/gnomeradio-device.patch

Bug#703313: nvidia-kernel-dkms: Confirmation of this bug

2013-03-29 Thread Diederik de Haas

Package: nvidia-kernel-dkms
Version: 304.84-1
Followup-For: Bug #703313

I don't know if it didn't happen with 304.64-4, but I have just tested
whether switching to VT[1-6] works, and indeed the display is turned off
and when switching to VT7, ie X session, the display is turned on again.
Ran 'whole' reportbug instead of a simple msg in case my details may
help.
Feel free to ask for more info and/or testing.

-- Package-specific info:
uname -a:
Linux bagend 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux

/proc/version:
Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-15) ) #1 SMP Debian 3.2.41-2

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  304.84  Wed Feb 27 04:58:49 PST 
2013
GCC version:  gcc version 4.6.3 (Debian 4.6.3-15) 

lspci 'VGA compatible controller [0300]':
05:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. Device [1462:2304]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d800 (64-bit, prefetchable) [size=128M]
Region 3: Memory at d600 (64-bit, prefetchable) [size=32M]
Region 5: I/O ports at ec00 [size=128]
[virtual] Expansion ROM at fe98 [disabled] [size=512K]
Capabilities: access denied
Kernel driver in use: nvidia

dmesg:
[0.00] No AGP bridge found
[0.00] No AGP bridge found
[0.00] Console: colour VGA+ 80x25
[0.633587] vgaarb: device added: 
PCI::05:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.633587] vgaarb: loaded
[0.633587] vgaarb: bridge control possible :05:00.0
[1.892466] PCI-DMA: Disabling AGP.
[1.892565] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[2.112289] Linux agpgart interface v0.103
[6.041673] nvidia: module license 'NVIDIA' taints kernel.
[6.142593] nvidia :05:00.0: setting latency timer to 64
[6.142607] vgaarb: device changed decodes: 
PCI::05:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[6.142961] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  304.84  Wed Feb 
27 04:58:49 PST 2013
[7.492324] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:02.0/:05:00.1/sound/card1/input6
[7.492599] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:02.0/:05:00.1/sound/card1/input7
[7.492811] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:02.0/:05:00.1/sound/card1/input8
[7.493024] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.0/:05:00.1/sound/card1/input9

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan 25 00:34 /etc/alternatives/glx - 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   43 Jan 25 00:34 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 25 00:34 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 25 00:34 
/etc/alternatives/glx--libXvMCNVIDIA.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libXvMCNVIDIA.so.1
lrwxrwxrwx 1 root root   59 Jan 25 00:34 
/etc/alternatives/glx--libXvMCNVIDIA_dynamic.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libXvMCNVIDIA_dynamic.so.1
lrwxrwxrwx 1 root root   51 Jan 25 00:34 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Jan 25 00:34 
/etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   36 Jan 25 00:34 
/etc/alternatives/glx--nvidia-bug-report.sh - 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   29 Jan 25 00:34 
/etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   23 Jan 25 00:34 /etc/alternatives/nvidia - 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   51 Jan 25 00:34 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 25 00:34 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   59 Jan 25 00:34 
/etc/alternatives/nvidia--libXvMCNVIDIA.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libXvMCNVIDIA.so.1
lrwxrwxrwx 1 root root   67 Jan 25 00:34 
/etc/alternatives/nvidia--libXvMCNVIDIA_dynamic.so.1-x86_64-linux-gnu -

Bug#704210: [nginx] Provide the Fancy Indexes

2013-03-29 Thread Slavko

Package: nginx
Version: 1.2.6-1
Severity: wishlist

Please, include the Fancy Indexes 3th party module into nginx-full or
nginx-extras package.

thanks

-- 
Slavko
http://slavino.sk



signature.asc
Description: OpenPGP digital signature

Bug#704211: [release-notes] [wheezy] issues: NM conflicts with wicd-daemon, Gnome3 now depends on NM

2013-03-29 Thread Chris Knadle

Package: release-notes
Severity: important

--- Please enter the report below this line. ---

Greetings.

I'm looking to add information to the Release Notes and the Wheezy Errata in 
order to handle bug #688772 concerning conflict between NetworkMmanager and 
wicd-daemon.  There are about 1800 known [1] installations in which NM is not 
installed but the gnome metapackage is, and the upgrade to a Depends on NM 
has a likelihood of breaking these installations, and at present there is no 
documentation available for the symptoms or how to fix it.  [I've been hit by 
this conflict myself, so I know how frustrating a problem this is.]

Attached is a text file containing the basic information I'd like to add.  
I've cloned the release-notes SVN repo for making a patch, but I'd appreciate 
a hint as to what section to add it to or if there are wording changes 
desired.

Thanks!

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688772#151

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us

conflicts with other networking manager daemons
~~~

Gnome upstream chose to couple NetworkManager tightly with the Gnome Shell
in order to provide connectivity awareness for both the Shell and Gnome3
applications.  For this reason the Gnome3 maintainers in Debian decided to
follow upstream and upgrade the Recommends on the network-manager stack to a
Depends.  It is known that a small number (about 5.7%) of Squeeze
installations have Gnome installed but not NetworkManager, and this
new Dependency will cause NetowrkManager to be installed upon a distribution
upgrade to Wheezy.

At present, NetworkManager can detect if an interface is managed by ifupdown
to avoid conflicts with it, but does not detect other networking manager
programs such as wicd-daemon.  Problems and unexpected behavior can ensue if
two network manager daemons are managing the same interface when attempting
to make a networking connection.  This issue was discussed by the Debian
Technical Committee in #681834 and #688772.

If wicd-daemon and NetworkManager are both running, a wicd client will fail
to make a connection with the counterintuitive message:

   Connection Failed: bad password

Trying a NetworkManager client may sometimes result in the message (even when
NetworkManager is running):

   NetworkManager is not running.  Please start it.

Or a NetworkManager client may work as expected.  Or some other unexpected
behavior may occur.

If continuing to use another networking manager is desired, the NetworkManager
daemon may remain installed but be permanently disabled (which is persistant
through upgrades) with:

   'update-rc.d network-manager disable'

You will also need to recreate /etc/resolv.conf, as the contents of this file
is replaced by NetworkManager.

Bug#703239: A report of my experience.

2013-03-29 Thread ISHIKAWA,chiaki

Something similar happened at the office today.

I am using 3.2.0-4 debian kernel guest inside virtualbox running on Windows XP
host.
and had a similar issue of miscompiling of vboxvideo_drm.c, after upgrading
virtualbox.

Basically compilation itself was fixed by the brute-force approach
mentioned in message # 50 from From: Francesco Presel f.pre...@alice.it

I defined something like DRM_RHEL63 near the beginning of the code
in the virtualbox-guest-additions-iso image.
virtualbox-guest-additions-iso is
from
http://packages.debian.org/search?keywords=virtualbox-guest-additions-isosearchon=namessuite=allsection=all

But, the video is not working well.

In a properly working set up, if we change the main virtual box window size on
Windows XP,
the X11 window root window inside the virtual box changes the size accordingly.
Unfortunately, this does not seem to be the case. The size doesn't change and so
we occasinally have a portion of the root window hidden when we resize the
virtualbox window size.

(This was tested after downloading pristine virtualbox image from oracle
virtualbox
web site, and installed [or whatever.])

TIA

PS: This happened at the office, and I failed to take detailed memo with me.
I installed a few packages to make this installation proceed as much as this
far.
I think something about kernel level drm module or something was necessary.
(This should be clear when we look in the /var/log/vbox-install.log.

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

Bug#703313: nvidia-kernel-dkms: Confirmation of this bug

2013-03-29 Thread Diederik de Haas

On Friday 29 March 2013 14:39:39 Diederik de Haas wrote:
 Package: nvidia-kernel-dkms
 Version: 304.84-1
 Followup-For: Bug #703313

Just did an aptitude install nvidia-glx -t experimental and rebooted my 
machine and now VT[1-6] do work.
So it looks like version 313.26-1 fixes this bug.


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

Bug#701744: [xen] Update to hypervisor 4.0.1-5.6 or linux-image-2.6.32-5-xen-amd64 2.6.32-48 causes networking (VIF) failures

2013-03-29 Thread Markus Hochholdinger

Hello,

I was also hit by this problem. Perhaps it is related to the xen-netback 
module in the dom0 kernel?

Have a look at:
http://www.gossamer-threads.com/lists/xen/devel/275548


-- 
greetings

eMHa


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

Bug#704212: lldpd init does not have status option

2013-03-29 Thread Lex Rivera

Package: lldpd
Version: 0.5.1-1
Severity: wishlist
Tags: patch

lldpd init script does not have option to check status. 
This is critical if, for example, puppet used to manage lldpd.
I'm including patch to add status argument to lldpd init.d script,
however it's my first patch and i does not know if it's written
correctly. But at least it works :)

Patch below:
---START---
89a90,104
   status)
log_action_begin_msg Checking $DESC $NAME
if pidofproc -p $PIDFILE /dev/null; then
 log_action_end_msg 0 running
 exit 0
else
if [ -e $PIDFILE ]; then
 log_action_end_msg 1 failed to start
 exit 1
else
 log_action_end_msg 0 not running
 exit 3
fi
fi
   ;;
---END---

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

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

Versions of packages lldpd depends on:
ii  adduser3.112+nmu2add and remove users and groups
ii  libc6  2.13-37   Embedded GNU C Library: Shared lib
ii  libsnmp15  5.4.3~dfsg-2.7SNMP (Simple Network Management Pr
ii  libssl0.9.80.9.8o-4squeeze13 SSL shared libraries

lldpd recommends no packages.

Versions of packages lldpd suggests:
ii  snmpd   5.4.3~dfsg-2 SNMP (Simple Network Management Pr

-- Configuration Files:
/etc/default/lldpd changed:
DAEMON_ARGS=-x -c -s -e


-- 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#646684: [PATCH] Add option to manage distribution fields for non snapshot mode.

Hi Daniel,
This is almost good to go in, some minor things below:

On Mon, Nov 21, 2011 at 03:44:41PM +0100, Daniel Dehennin wrote:
[..snip..] 
 -def fixup_trailer(repo, git_author, dch_options):
 +def fixup_section(repo, git_author, options=[], dch_options=[]):

It seems you always pass in all parameters so no need for default values
here.

  
 -Fixup the changelog trailer's comitter and email address.   +Fixup 
 the changelog header and trailer's comitter and email address
  
  It might otherwise point to the last git committer instead of the person
  creating the changelog
 +This apply --distribution and --urgency options passed to git-dch
  
  author, email = get_author_email(repo, git_author)
 -ChangeLog.spawn_dch(msg='', author=author, email=email, 
 dch_options=dch_options)
 +used_options = ['distribution']
 +header_opts = []
 +
 +# This must not be done for snapshots or snapshots changelog entries
 +# will not be concatenated
 +if not options.snapshot:
 +for opt in used_options:
 +if hasattr(options, opt) and getattr(options, opt):

Why can't you just do a getattr(options. opt)? The option should always
be there (but the value might be None). It would also be nice to use a
variable like: 
 val = getattr(options, opt) 
 if val:
   ...
   header_opts.append(--%s=%s % (opt, val))

instead of invoking getattr several times which is hard to read.

 +gbp.log.debug( Set header option '%s' to '%s' % (opt, 
 getattr(options,opt)) )
 +header_opts.append(--%s=%s % (opt, getattr(options,opt)))
 +else:
 +gbp.log.debug(Snapshot enabled: do not fixup options in header)
 +
 +ChangeLog.spawn_dch(msg='', author=author, email=email, 
 dch_options=dch_options+header_opts)
  
  
  def snapshot_version(version):
 @@ -207,6 +221,9 @@ def process_options(options, parser):
  else:
  dch_options.append(--nomultimaint)
  
 +if options.force_distribution:
 +dch_options.append(--force-distribution)
 +
  get_customizations(options.customization_file)
  return dch_options
  
 @@ -279,6 +296,9 @@ def main(argv):
help=mark as release)
  version_group.add_option(-S, --snapshot, action=store_true, 
 dest=snapshot, default=False,
help=mark as snapshot build)
 +version_group.add_option(-D, --distribution, dest=distribution, 
 help=Set distribution)
 +version_group.add_option(--force-distribution, action=store_true, 
 dest=force_distribution, default=False,
 +  help=Force the provided distribution to be used, even 
 if it doesn't match the list of known distributions)
  version_group.add_option(-N, --new-version, dest=new_version,
help=use this as base for the new version number)
  version_group.add_option(--bpo, dest=bpo, action=store_true, 
 default=False,
 @@ -430,7 +450,7 @@ def main(argv):
 version=version_change,
 dch_options=dch_options)
  
 -fixup_trailer(repo, git_author=options.git_author,
 +fixup_section(repo, git_author=options.git_author, options=options,
dch_options=dch_options)
  
  if options.release:
 diff --git a/tests/11_test_dch_main.py b/tests/11_test_dch_main.py
 index f45857e..9b40411 100644
 --- a/tests/11_test_dch_main.py
 +++ b/tests/11_test_dch_main.py
 @@ -194,6 +194,109 @@ class TestScriptDch(DebianGitTestRepo):
  self.repo.create_tag(debian/0.9-1, msg=Pre stable release version 
 0.9-1, commit=HEAD~1)
  self.assertRaises(SystemExit, dch.main, options)
  
 +def test_dch_main_new_upstream_version_with_distribution(self):
 +Test dch.py like git-dch script does: new upstream version - set 
 distribution

 +options = self.options[:]
 +options.append(--distribution=testing)
 +self.repo.create_tag(debian/0.9-1, msg=Pre stable release version 
 0.9-1, commit=HEAD~1)
 +ret = dch.main(options)
 +self.assertEqual(ret, 0)
 +lines = file(debian/changelog).readlines()

This is almost the same in all tests. Could you move this into a common
functtion to ease readability and reduce the amout of copy/paste code?
Seems this only differs in the options passed, so this could be made the
function argument. and the function could return the result of
readlines()

 +self.assertEqual(test-package (1.0-1) testing; urgency=low\n, 
 lines[0])
 +self.assertIn(  * added debian/control\n, lines)
 +
 +def test_dch_main_new_upstream_version_with_release_distribution(self):
 +Test dch.py like git-dch script does: new upstream version - 
 release - set distribution
 +options = self.options[:]
 +options.append(--release)
 +options.append(--distribution=testing)
 +self.repo.create_tag(debian/0.9-1, msg=Pre stable release

Bug#704213: reTurn fails to start, exception: thread: Operation not supported

Package: resiprocate-turn-server
Version: 1.8.5-3
Severity: serious


I just upgraded a system from 1.8.5-1 to 1.8.5-3

The reTurnServer process fails to start, this is the log entry when it
fails:

ERR | 20130329-134514.217 | reTurnServer | RETURN | 140737354057504 |
reTurnServer.cxx:167 | exception: thread: Operation not supported


A search reveals the following:

https://sourceforge.net/tracker/?func=detailaid=3263125group_id=122478atid=694037

This seems odd.  Debdiff shows that none of the compile options for
threading have changed.  In fact, no changes to the makefiles or debian
artifacts at all.

It suggests some difference in the build environment where 1.8.5-3 was
created.

Running under gdb, the exception is thrown here:


144  boost::bind(asio::io_service::run, ioService)));
(gdb)
null_threadboost::_bi::bind_tunsigned long, boost::_mfi::mf0unsigned
long, asio::io_service,
boost::_bi::list1boost::_bi::valueasio::io_service*(f=...,
this=optimized out)
at /usr/include/asio/detail/null_thread.hpp:46
46  asio::error::operation_not_supported, thread);


This code is only active if !defined(BOOST_HAS_THREADS)


1.8.5-1 was tagged in Aug 2012, need to check if anything has changed
for packages based on boost since then.  This may also impact other
packages based on boost if they are recompiled.


The system where I built 1.8.5-3 for upload appears to have this version
of libboost-thread-dev:

ii  libboost-thread-dev   1.42.0.1
 amd64portable C++ multi-threading (default version)

while the latest version in wheezy appears to be v1.49.0.1

It appears to result from this issue:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654425

so this seems to confirm that packages which were built with gcc 4.7
without having boost-dev = 1.46 may be similarly broken.


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

Bug#704214: ITP: numbers -- asdf

2013-03-29 Thread Yaroslav Halchenko

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko deb...@onerussian.com

* Package name: numbers
  Version : 0.4
  Upstream Author : Derek M Jones 
* URL : http://www.coding-guidelines.com/numbers
* License : GPL
  Programming Lang: C
  Description : database of interesting numbers and a tool to compare 
against it

 The numbers program extracts numeric literals, compares them against a
 database of 'interesting' values and prints out any matches; it can also print
 out values that don't match. Current matching algorithms include fuzzy
 numeric matching and matching mantissa digit sequences (using either a
 specified number of significant digits or a Levenstein distance approach).


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

Bug#703239: [Patch proposed] further information

2013-03-29 Thread Francesco Presel

I enabled 3d acceleration; here's the (partial) output of glxgears and 
glxinfo. Glxgears is a bit slow, but that's quite usual on VB (I think), 
and might depend on hardware too. Anyway, things appear to work as 
expected, in my case.


In reply to #55, I did not experience such problems. I'm running Debian 
Wheezy x86 as guest, and Linux Mint Debian Edition (with Wheezy 
repositories, but with the latest version of VB, directly from their own 
repo) as host. Resizing both the window in the host and the screen 
inside the guest had the expected behaviour, ie everything resized 
correctly. Even transparent mode worked. I sometimes needed to wait some 
seconds before the resize occurred, but after a few seconds everything 
was OK.
Anyway, is that related to Debian, or is it a problem with VBox itself? 
Could it depend on the host instead?
If one of the proposed solutions (defining RHEL somewhere, or changing 
the kernel version in #IF_s, or any similar and more elegant solution) 
really allows to compile and run the modules, perhaps the problems with 
rescaling are a different (and less grave - perhaps not RC any more) bug?


$ glxgears
216 frames in 5.0 seconds = 43.041 FPS
262 frames in 5.0 seconds = 52.397 FPS
270 frames in 5.0 seconds = 53.976 FPS
262 frames in 5.0 seconds = 52.115 FPS
206 frames in 5.0 seconds = 41.156 FPS
139 frames in 5.0 seconds = 27.720 FPS
francesco@build-VM:~$ glxinfo
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: Chromium
server glx version string: 1.3 Chromium
server glx extensions:
GLX_ARB_multisample, GLX_EXT_texture_from_pixmap, GLX_SGIX_fbconfig,
GLX_ARB_get_proc_address
client glx vendor string: Chromium
client glx version string: 1.3 Chromium
client glx extensions:
GLX_ARB_multisample, GLX_EXT_texture_from_pixmap, GLX_SGIX_fbconfig,
GLX_ARB_get_proc_address
GLX version: 1.3
GLX extensions:
GLX_ARB_multisample, GLX_EXT_texture_from_pixmap, GLX_SGIX_fbconfig,
GLX_ARB_get_proc_address
OpenGL vendor string: Humper
OpenGL renderer string: Chromium
OpenGL version string: 2.1 Chromium 1.9
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL extensions:
GL_EXT_texture_compression_s3tc, GL_EXT_draw_range_elements,
GL_EXT_framebuffer_object, GL_EXT_compiled_vertex_array,
GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_multisample,
GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters,
GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_ARB_texture_cube_map,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_EXT_texture_env_combine, GL_ARB_texture_env_crossbar,
GL_ARB_texture_env_dot3, GL_EXT_texture_env_dot3,
GL_ARB_texture_mirrored_repeat, GL_IBM_texture_mirrored_repeat,
GL_ATI_texture_mirror_once, GL_ARB_texture_non_power_of_two,
GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,
GL_ARB_pixel_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos,
GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_func_separate,
GL_EXT_blend_subtract, GL_EXT_texture_env_add, GL_EXT_fog_coord,
GL_EXT_multi_draw_arrays, GL_EXT_secondary_color, GL_EXT_shadow_funcs,
GL_EXT_stencil_wrap, GL_EXT_texture_cube_map, 
GL_EXT_texture_edge_clamp,

GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
GL_EXT_texture_object, GL_EXT_texture3D, GL_IBM_rasterpos_clip,
GL_NV_fog_distance, GL_NV_fragment_program, GL_NV_register_combiners,
GL_NV_register_combiners2, GL_NV_texgen_reflection,
GL_NV_texture_rectangle, GL_ARB_texture_rectangle, 
GL_NV_vertex_program,
GL_NV_vertex_program1_1, GL_NV_vertex_program2, 
GL_SGIS_generate_mipmap,
GL_ARB_shading_language_100, GL_ARB_shader_objects, 
GL_ARB_vertex_shader,

GL_ARB_fragment_shader, GL_EXT_texture_sRGB, GL_EXT_framebuffer_blit,
GL_EXT_blend_equation_separate, GL_EXT_stencil_two_side,
GL_CR_state_parameter, GL_CR_cursor_position, GL_CR_bounding_box,
GL_CR_print_string, GL_CR_tilesort_info, GL_CR_synchronization,
GL_CR_head_spu_name, GL_CR_performance_info, GL_CR_window_size,
GL_CR_tile_info, GL_CR_saveframe, GL_CR_readback_barrier_size,
GL_CR_server_id_sharing, GL_CR_server_matrix,  GL_EXT_stencil_two_side

96 GLX Visuals
[...]


From dmesg:
[   68.713959] vboxsf: Successfully loaded version 4.1.18_Debian 
(interface 0x00010004)

[   72.208176] eth0: no IPv6 routers present
[   76.049133] [drm] Initialized drm 1.1.0 20060810
[   76.093270] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   76.093304] [drm] No driver support for vblank timestamp query.
[   76.093323] [drm] Initialized vboxvideo 1.0.0 20090303 for 
:00:02.0 on minor 0



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

Bug#563376: I was also just tripped up by this bug

2013-03-29 Thread Ryan C. Underwood


Cross compiling from an x86-64 host for a less capable i386 host, I
found that I'm unable to build modules on the target because of the
genksyms and friends being built for the wrong arch.

-- 
Ryan C. Underwood, neme...@icequake.net


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

Bug#704215: unblock: resiprocate - built against newer boost-dev

Package: release.debian.org
Severity: normal

I've found that one of the binaries, resiprocate-turn-server, needs to
be built again with the latest gcc and boost-dev or it fails to run

The root cause appears to be this issue:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654425

and the bug report concerning the impact on my package is:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704213

Please confirm if I should do the upload with a new version number
(1.8.5-4), or if there is some other way to force it to be rebuilt for
the existing version?  If I upload a new version, there will be no
changes except a changelog entry.


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

Bug#704160: kpartx says it will create /dev/loop0p1 but uses other names

2013-03-29 Thread Stefan Monnier

 The use of dm-6 makes sense from a technical point of vue, and the
 symlinks in /dev/disk are fine, but please add a symlink from
 /dev/loop0p1 since that's the normal logical name.
 Do you have the multipath-tools package installed ?

I have no idea what it is so I'd guess not.
Let me check ... no it's not installed.


Stefan


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

Bug#695224: perl-modules: Locale::Maketext code injection

2013-03-29 Thread Dominic Hargreaves

On Mon, Mar 25, 2013 at 02:00:03PM +1100, Paul Harvey wrote:
 For the Foswiki project, we can deal with things as-is.
 
 But you have created a new bug, Locale::Maketext 1.23 is being
 shipped as 1.19 and I still don't see how this can ever be a good
 idea. These two versions have different version numbers for a
 reason: there has been a deliberate change which the caller must
 consider carefully before use. If the caller can't trust the API
 version being reported, what is the point of version numbers in the
 first place?

I personally think you're slightly overstating this part; in the vast
majority of cases where bugfixes are cherry-picked into the Debian perl
package and the package version number doesn't get changed, no problems
arise. The situation for Locale::Maketext is indeed regrettable and I'm
sorry we didn't foresee the action-at-a-distance the change has caused,
but I don't think we have any practical options at this point, not least
owing to the deep freeze that Debian is now in. I would certainly want
to get the release team's opinion on any further changes (such as pulling
in the updated Locale::Maketext verbatim).

 Our hack to detect Debian's special franken-version is exactly that,
 a hack - and additional complexity we'd very much rather not incur
 at runtime. Or complicate by pre-computing from yet another
 admin/configure UI prompt which could get out-of-sync should
 liblocale-maketext be updated (resulting in double-escaping mess
 until the user re-runs configure UI).
 
 Perhaps I don't know enough about Debian infrastructure but how can
 this situation be easier to deal with than simply updating the rest
 of the .pm including the $VERSION string and POD lines? Especially
 given that your own grepping hasn't exactly overwhelmed with many
 dependencies on Locale::Maketext.

In general bug-fixes in Debian are pulled in as minimal fixes without
changing the version number. The dual-lived modules in perl make this
all the more complex, especially when the modules don't get the security
fixes in core (maint-5.14 still has Locale::Maketext 1.19). If we did
decide to update the version number of the module in Debian's perl package,
notwithstanding the technical breakage likely to result when it comes
to the packaging infrastructure and Module::Corelist, I wouldn't be
surprised if it resulted in people wondering why we were deviating from
the upstream versioning. (This impedance mismatch is in related to the
fact that perl upstream are more keen to point people at the CPANed
version of modules for bugfixes, whilst in Debian packaging the CPAN
version of a module incurs more overhead, so is less preferred.

I don't claim to know the right way to deal with this problem, now or in
future, but hopefully I've managed to communicate that I don't see an
'obvious' solution.

Again, I welcome comments from other readers.

Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


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

Bug#704197: Please review: systemd checks

2013-03-29 Thread Michael Stapelberg

Hi Niels,

Thanks for the super-fast review. New version is attached, I have fixed
everything you mentioned, and for the other things I commented inline:

Niels Thykier ni...@thykier.net writes:
 guidelines.  I know Lintian's code style is a mess in general, so it
 describes the style I hope we will eventually reach[1].  :)
Have you tried using perltidy for Lintian? I loathe manual source code
formatting after working with gofmt and subsequently perltidy.

 I noticed that there appear to be no use of references (Ref: URL, #bug,
 policy X.Y ...).  I would recommend finding such so people can quickly
 find more information.  Links to systemd documentation, specification or
 even just a Debian wiki page.
Will do once we’ve put up some wiki pages on that.

 If you do not need $pkg or $type, then you can replace them with undef. E.g.
 my (undef, undef, $info) = @_;
I prefer to have the variables around, just in case the code needs to be
changed to use those.

 That has the advantage that we know that argument is unused.
I don’t understand what the advantage of knowing that is :-).

 Secondly, there is no check for file type.  If someone (deliberately)
 creates $file as a fifo-pipe or a symlink it will DoS or (possibly) read
 host system files (respectively).  Usually, a

 $info-index ($file)-is_regular_file

 should do (if symlinks/hardlinks can be ignored).  Alternatively, (for
 symlinks) please check that the symlink can be safely resolved before
 opening the file (e.g. via the link_resolved method).  For more
 information, please see the Lintian::Path module's API.
I came up with this:

sub check_init_script {
my ($pkg, $info, $file) = @_;

my $lsb_source_seen;
my $path = $info-index ($file);
fail $file is neither a regular file nor a resolvable symlink
unless ($path-is_regular_file || defined($path-link_resolved));
open(my $fh, '', $info-unpacked($file))
or fail cannot open $file: $!;

# …
}

Does that seem alright to you?

 sub split_quoted {
 [...]
 }
 

 Is this something that could be done by Text::ParseWords?
I’m not entirely sure about it. The code I’m using is a 1:1 port of the
corresponding systemd C code. This obviously has the benefit that there
are no subtle differences between what we do and what systemd does.

-- 
Best regards,
Michael


systemd
Description: Binary data


systemd.desc
Description: Binary data

Bug#704216: libtorrent-rasterbar6: upstream has released libtorrent-rasterbar-0.16.9 please package it.

2013-03-29 Thread shirish शिरीष

Package: libtorrent-rasterbar6
Version: 0.15.10-1+b1
Severity: wishlist

Dear Maintainer,
Can you upload libtorrent libtorrent-rasterbar-0.16.9 or an earlier
version which is needed to have deluge-torrent 1.3.6 .

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

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

Versions of packages libtorrent-rasterbar6 depends on:
ii  dpkg   1.16.10
ii  libboost-filesystem1.49.0  1.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.17-0experimental2
ii  libgcc11:4.8.0-2
ii  libgeoip1  1.4.8+dfsg-3
ii  libssl1.0.01.0.1e-2
ii  libstdc++6 4.8.0-2
ii  zlib1g 1:1.2.7.dfsg-13

libtorrent-rasterbar6 recommends no packages.

Versions of packages libtorrent-rasterbar6 suggests:
pn  libtorrent-rasterbar-dbg  none

-- no debconf information
-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17


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

Bug#704193: I also see this (i386)

2013-03-29 Thread sacrificial-spam-address

Control: found 704193 4.5.11-1
Architecture: i386

Here's an strace.  The segfault happens just AFTER locatedb is closed.
It also happns on a successful lookup.  I'm running i386 sid userland
on an x86_64 kernel.

execve(/usr/bin/locate, [locate, ], [/* 24 vars */]) = 0
brk(0)  = 0x84a9000
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf77cd000
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=145521, ...}) = 0
mmap2(NULL, 145521, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf77a9000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/i386-linux-gnu/i686/cmov/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\372\202M4\0\0\0..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1756536, ...}) = 0
mmap2(0x4d816000, 1764124, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0x4d816000
mmap2(0x4d9bf000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a9) = 0x4d9bf000
mmap2(0x4d9c2000, 11036, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4d9c2000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf77a8000
set_thread_area({entry_number:-1 - 12, base_addr:0xf77a8900, limit:1048575, 
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, 
useable:1}) = 0
mprotect(0x805a000, 4096, PROT_READ)= 0
mprotect(0x4d9bf000, 8192, PROT_READ)   = 0
mprotect(0x4d812000, 4096, PROT_READ)   = 0
munmap(0xf77a9000, 145521)  = 0
open(/var/cache/locate/locatedb, O_RDONLY|O_LARGEFILE) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
geteuid32() = $UID
getuid32()  = $UID
getgid32()  = $GID
setgid32($GID)  = 0
brk(0)  = 0x84a9000
brk(0x84ca000)  = 0x84ca000
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=21917714, ...}) = 0
time(NULL)  = 1364566351
fcntl64(3, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat64(3, {st_mode=S_IFREG|0644, st_size=21917714, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf77cc000
_llseek(3, 0, [0], SEEK_CUR)= 0
read(3, ..., 4096) = 4096

(Lots of additional reads omitted)

read(3, , 4096)   = 0
close(3)= 0
munmap(0xf77cc000, 4096)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++


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

Bug#704208: missing dependency on python2.6

2013-03-29 Thread John Paul Adrian Glaubitz


 explicitely executes python2.6 while the package only depends on
 python (=2.5)

 This causes the current gtk-vnc FTBFS

Interesting. When I search for the python meta-package, even on Squeeze 
the package already pulls python2.6. How is it possible that it doesn't 
get installed during gtk-vnc build?


In any case, it's an easy fix. Would step up with a patch and propose 
NMU if no one steps up.


Cheers,

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

Bug#704208: missing dependency on python2.6

2013-03-29 Thread John Paul Adrian Glaubitz


On 03/29/2013 03:38 PM, Christoph Egger wrote:

Because in unstable/wheezy python depends on python2.7 not python2.6. if
you depend on python you can assume /usr/bin/python but not either of
python2.6 and python2.7


Ah, you're right. Thanks for the heads-up. I'll be there with a debdiff 
showing my suggested NMU.


Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

Bug#704208: missing dependency on python2.6