Bug#630000: d-i cannot receive an IP address from Mac OS X

[kinneko]

Package: debian-installer
Version: squeeze 6.0.1a netinst
Severity: important
Tags: squeeze

d-i cannot receive an IP address, when Mac OS X used as a DHCP server.
lenny is normally.

Mac OS X: 10.6.7 build 10J869



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

Bug#595298: [Pkg-oss4-maintainers] Bug#595298:

[Rémi Bernon]

Hi Romain,

I'll be happy to help you maintain oss4 if you don't have enough time for that.
I don't think I have any technical difficulty for doing so, but I'm
not very familiar with all the Debian processes that should be
followed before packaging a new version, what kind of tests are you
thinking of?

Rémi

On Fri, Jun 10, 2011 at 01:14, Romain Beauxis  wrote:
> Hi Remi,
>
> I have very little time to test and package unfortunately.
>
> However, I could include you in the team so that you can push your
> changes to our repository. I'll be happy to upload them afterwards!
>
> Romain
>
> Le 9 juin 2011 18:36, Rémi Bernon  a écrit :
>> Is there any plan to package the new upstream version?
>> I've built a package locally, with the new upstream version retrieved
>> with uscan and the required change in os_cmd.patch (see attached), but
>> I'm probably unable to upload it as I'm not a Debian Maintainer, and I
>> don't know how to provide it to the Maintainers.
>> I tried mentors.debian.net, but it seems to have some issues with the
>> registration.
>> It's really not a big deal and this bug is really annoying for people
>> who want OSS with a testing/unstable kernel.
>>
>> Rémi
>>
>> ___
>> Pkg-oss4-maintainers mailing list
>> pkg-oss4-maintain...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-oss4-maintainers
>>
>



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

Bug#629999: gnome-accessibility: I can't start GTK display.

[root]

Package: gnome-accessibility
Severity: normal



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

Kernel: Linux 2.6.26-2-xen-686 (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/bash



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

Bug#629998: suckless-tools and swift: error when trying to install together

[Ralf Treinen]

Package: swift,suckless-tools
Version: swift/1.3.0-1
Version: suckless-tools/38-1
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2011-06-10
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


WARNING: The following packages cannot be authenticated!
  multiarch-support libxau6 libxdmcp6 libxcb1 mime-support python2.6-minimal
  libdb4.8 libexpat1 python2.6 python-minimal python python-support
  libjs-jquery libx11-data libx11-6 libxext6 libxinerama1 python-greenlet
  python-eventlet python-netifaces python-openssl python-pkg-resources
  python-pastedeploy python-setuptools python-simplejson python-webob
  python-xattr python-swift suckless-tools swift
Authentication warning overridden.
Can not write log, openpty() failed (/dev/pts not mounted?)
Selecting previously deselected package multiarch-support.
(Reading database ... 9232 files and directories currently installed.)
Unpacking multiarch-support (from .../multiarch-support_2.13-6_amd64.deb) ...
Can not write log, openpty() failed (/dev/pts not mounted?)
Setting up multiarch-support (2.13-6) ...
Can not write log, openpty() failed (/dev/pts not mounted?)
Selecting previously deselected package libxau6.
(Reading database ... 9236 files and directories currently installed.)
Unpacking libxau6 (from .../libxau6_1%3a1.0.6-2_amd64.deb) ...
Selecting previously deselected package libxdmcp6.
Unpacking libxdmcp6 (from .../libxdmcp6_1%3a1.1.0-2_amd64.deb) ...
Selecting previously deselected package libxcb1.
Unpacking libxcb1 (from .../libxcb1_1.7-3_amd64.deb) ...
Selecting previously deselected package mime-support.
Unpacking mime-support (from .../mime-support_3.51-1_all.deb) ...
Selecting previously deselected package python2.6-minimal.
Unpacking python2.6-minimal (from .../python2.6-minimal_2.6.6-10_amd64.deb) ...
Selecting previously deselected package libdb4.8.
Unpacking libdb4.8 (from .../libdb4.8_4.8.30-8_amd64.deb) ...
Selecting previously deselected package libexpat1.
Unpacking libexpat1 (from .../libexpat1_2.0.1-7_amd64.deb) ...
Selecting previously deselected package python2.6.
Unpacking python2.6 (from .../python2.6_2.6.6-10_amd64.deb) ...
Selecting previously deselected package python-minimal.
Unpacking python-minimal (from .../python-minimal_2.6.6-14_all.deb) ...
Selecting previously deselected package python.
Unpacking python (from .../python_2.6.6-14_all.deb) ...
Selecting previously deselected package python-support.
Unpacking python-support (from .../python-support_1.0.13_all.deb) ...
Selecting previously deselected package libjs-jquery.
Unpacking libjs-jquery (from .../libjs-jquery_1.6.1-1_all.deb) ...
Selecting previously deselected package libx11-data.
Unpacking libx11-data (from .../libx11-data_2%3a1.4.3-1_all.deb) ...
Selecting previously deselected package libx11-6.
Unpacking libx11-6 (from .../libx11-6_2%3a1.4.3-1_amd64.deb) ...
Selecting previously deselected package libxext6.
Unpacking libxext6 (from .../libxext6_2%3a1.3.0-1_amd64.deb) ...
Selecting previously deselected package libxinerama1.
Unpacking libxinerama1 (from .../libxinerama1_2%3a1.1.1-1_amd64.deb) ...
Selecting previously deselected package python-greenlet.
Unpacking python-greenlet (from .../python-greenlet_0.3.1-1.1+b1_amd64.deb) ...
Selecting previously deselected package python-eventlet.
Unpacking python-eventlet (from .../python-eventlet_0.9.16-1_all.deb) ...
Selecting previously deselected package python-netifaces.
Unpacking python-netifaces (from .../python-netifaces_0.5-2.1+b1_amd64.deb) ...
Selecting previously deselected package python-openssl.
Unpacking python-openssl (from .../python-openssl_0.12-1_amd64.deb) ...
Selecting previously deselected package python-pkg-resources.
Unpacking python-pkg-resources (from .../python-pkg-resources_0.6.16-1_all.deb) 
...
Selecting previously deselected package python-pastedeploy.
Unpacking python-pastedeploy (from .../python-pastedeploy_1.5.0-1_all.deb) ...
Selecting previously deselected package python-setuptools.
Unpacking python-setuptools (from .../python-setuptools_0.6.16-1_all.deb) ...
Selecting previously deselected package python-simplejson.
Unpacking python-simplejson (from .../python-simplejson_2.1.6-1_amd64.deb) ...
Selecting previously deselected package python-webob.
Unpacking python-webob (from .../python-webob_1.0.7-1_all.deb) ...
Selecting previously deselected package python-xattr.
Unpacking python-xattr (from .../python-xattr_0.6-1+b1_amd64.deb) ...
Selecting previously deselected package python-swift.
Unpacking python-swift (from .../python-swift_1.3.0-1_all.deb) ...
Selecting previously deselected package suckless-tools.
Unpacking suckless-tools (from .../suckless-tools_38-1_amd64.deb) ...
Selecting previously deselected package swift.
Unpacking swift (from .../archives/swift_1.3.0-1_all.deb) ...
dpkg: error pr

Bug#629997: psensor: fails to respond to mouse clicks

[richard]

Package: psensor
Version: 0.6.1.9-2
Severity: important

Monitoring 4 CPU's and one hard drive
updates every second, graphs 1000 sec. 

After 12 hours running memory useage is 350Mb
and CPU useage is 85-95%

Does not display numerical values - that panel 
is blank, but time, and temperatures are updated 
on the graph. There is no response to right 
mouse clicks. Temperatures are well below alarm 
settings. 

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

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

Versions of packages psensor depends on:
ii  libatk1.0-0   2.0.0-1The ATK accessibility toolkit
ii  libc6 2.13-4 Embedded GNU C Library: Shared lib
ii  libcairo2 1.10.2-6   The Cairo 2D vector graphics libra
ii  libcurl3  7.21.6-1   Multi-protocol file transfer libra
ii  libdbus-1-3   1.4.8-3simple interprocess messaging syst
ii  libdbus-glib-1-2  0.92-1 simple interprocess messaging syst
ii  libfontconfig12.8.0-2.2  generic font configuration library
ii  libfreetype6  2.4.4-1FreeType 2 font engine, shared lib
ii  libgconf2-4   2.28.1-6   GNOME configuration database syste
ii  libgdk-pixbuf2.0-02.23.3-3   GDK Pixbuf library
ii  libglib2.0-0  2.28.6-1   The GLib library of C routines
ii  libgtk2.0-0   2.24.4-3   The GTK+ graphical user interface 
ii  libjson0  0.9-1  JSON manipulation library - shared
pn  libnotify1 (no description available)
pn  libnotify1-gtk2.10 (no description available)
ii  libpango1.0-0 1.28.3-6   Layout and rendering of internatio
ii  libsensors4   1:3.3.0-2  library to read temperature/voltag
ii  psensor-common0.6.1.9-2  common files for Psensor and Psens

Versions of packages psensor recommends:
pn  hddtemp(no description available)

psensor 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#629578: libglobalhotkeys-ruby: not installable in sid

[Ralf Treinen]

Hi Vincent,

On Thu, Jun 09, 2011 at 06:01:33PM +0200, Vincent Carmona wrote:

> ruby-globalhotkeys is the new name for libglobalhotkeys-ruby. You
> should install it.
> 
> I do not known why there is 2 versions of libglobalhotkeys-ruby
> package in unstable. I need to investigate it.

OK, I didn't realise that there are two versions in sid, This happens
sometimes, typicaly when a binary package changes from one source 
package to another source package. If the old version is no longer 
needed then please file a bug report against ftp.debian.org and
ask for removal, see http://wiki.debian.org/ftpmaster_Removals.

-Ralf.



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

Bug#629996: ITP: libnet-dropbox-api-perl -- Perl module providing a dropbox API interface

[Salvatore Bonaccorso]

Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libnet-dropbox-api-perl
  Version : 1.6
  Upstream Author : Lenz Gschwendtner 
* URL : http://search.cpan.org/dist/Net-Dropbox-API/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module providing a dropbox API interface

Net::Dropbox::API is a perl interface to the Dropbox API. The Dropbox
API is a OAuth based API.



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

Bug#629995: keep ~aremove broken

[Matthew Cengia]

Package: aptitude
Version: 0.6.3-3.2
Severity: minor



This works:
mattcen@tony:tmp$ sudo aptitude unmarkauto ~i && sudo aptitude --schedule-only 
markauto ~E '~i!~M(~Rdepends:~i|~Rrecommends:~i)' && sudo aptitude keep 
$(aptitude search ~aremove -F %p)

This doesn't:
mattcen@tony:tmp$ sudo aptitude unmarkauto ~i && sudo aptitude --schedule-only 
markauto ~E '~i!~M(~Rdepends:~i|~Rrecommends:~i)' && sudo aptitude keep ~aremove

The difference in the above commands (in case it's not obvious) is the
last 'aptitude keep'. In the former I explicitly pass 'keep' the list of
packages to keep, pulled from an 'aptitude search', whereas in the
latter, I try to keep based on a search expression.

This *did* used to work on Lenny, but doesn't on Squeeze.

-- Package-specific info:
aptitude 0.6.3 compiled at Oct 16 2010 18:18:04
Compiler: g++ 4.4.5
Compiled against:
  apt version 4.10.1
  NCurses version 5.7
  libsigc++ version: 2.2.4.2
  Ept support enabled.
  Gtk+ support disabled.

Current library versions:
  NCurses version: ncurses 5.7.20100313
  cwidget version: 0.5.16
  Apt version: 4.10.1
linux-vdso.so.1 =>  (0x7fff1ef5d000)
libapt-pkg.so.4.10 => /usr/lib/libapt-pkg.so.4.10 (0x7f51b2fe4000)
libncursesw.so.5 => /lib/libncursesw.so.5 (0x7f51b2d91000)
libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x7f51b2b8b000)
libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0x7f51b28bf000)
libept.so.1 => /usr/lib/libept.so.1 (0x7f51b266b000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7f51b228a000)
libz.so.1 => /usr/lib/libz.so.1 (0x7f51b2073000)
libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x7f51b1ddc000)
libboost_iostreams.so.1.42.0 => /usr/lib/libboost_iostreams.so.1.42.0 
(0x7f51b1bc)
libpthread.so.0 => /lib/libpthread.so.0 (0x7f51b19a4000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f51b169)
libm.so.6 => /lib/libm.so.6 (0x7f51b140d000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7f51b11f7000)
libc.so.6 => /lib/libc.so.6 (0x7f51b0e96000)
libutil.so.1 => /lib/libutil.so.1 (0x7f51b0c92000)
libdl.so.2 => /lib/libdl.so.2 (0x7f51b0a8e000)
libuuid.so.1 => /lib/libuuid.so.1 (0x7f51b0889000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x7f51b0679000)
librt.so.1 => /lib/librt.so.1 (0x7f51b0471000)
/lib64/ld-linux-x86-64.so.2 (0x7f51b32fa000)
Terminal: screen.linux
$DISPLAY not set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:

aptitude linkage:

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

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

Versions of packages aptitude depends on:
ii  apt [libapt-pkg4.10]0.8.10.3 Advanced front-end for dpkg
ii  libboost-iostreams1.42. 1.42.0-4 Boost.Iostreams Library
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libcwidget3 0.5.16-3 high-level terminal interface libr
ii  libept1 1.0.4High-level library for managing De
ii  libgcc1 1:4.4.5-8GCC support library
ii  libncursesw55.7+20100313-5   shared libraries for terminal hand
ii  libsigc++-2.0-0c2a  2.2.4.2-1type-safe Signal Framework for C++
ii  libsqlite3-03.7.3-1  SQLite 3 shared library
ii  libstdc++6  4.4.5-8  The GNU Standard C++ Library v3
ii  libxapian22 1.2.3-2  Search engine library
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages aptitude recommends:
ii  apt-xapian-index  0.41   maintenance and search tools for a
pn  aptitude-doc-en | aptitude-do  (no description available)
pn  libparse-debianchangelog-perl  (no description available)
ii  sensible-utils0.0.4  Utilities for sensible alternative

Versions of packages aptitude suggests:
pn  debtags(no description available)
ii  tasksel   2.88   Tool for selecting tasks for insta

-- no debconf information

-- 
Regards,
Matthew Cengia


signature.asc
Description: Digital signature

Bug#629994: linux-image-2.6.39-1-amd64: sendfile returns early without user-visible reason

[Marc Lehmann]

Package: linux-2.6
Version: 2.6.39-1+b1
Severity: normal


In 2.6.39 (and maybe some earlier versions= of Linux, sendfile supports
file->file copies.

Unfortunately, it doesn't handle files near 2GB size correctly and returns
early. For example, here is a call that tries to copy a >3GB file:

[pid  8171] sendfile(18, 17, [0], 3569424384)= 2147479552

Linux always seems to stop copying at 0x7000 bytes, without apparent
reason (such as disk full or another error). This happens with a 64 bit
kernel btw., so this is not a 32 bit issue either.

This causes many programs to report a "short write", as this is an error
condition with similar syscalls on files (such as write(2)).

I think sendfile should either not attempt to copy files, or copy the
requested number of bytes unless an error occurs (such as disk full or a
read error). Otherwise programs always need to retry with another syscall,
to see if sendfile returned "just so" or there was an actual problem.

-- Package-specific info:
** Version:
Linux version 2.6.39-1-amd64 (Debian 2.6.39-1) 
(buildd_amd64-bra...@buildd.debian.org) (gcc version 4.4.6 (Debian 4.4.6-3) ) 
#1 SMP Tue May 24 14:34:19 UTC 2011

** Tainted: PMO (4113)
 * Proprietary module has been loaded.
 * System experienced a machine check exception.
 * Out-of-tree module has been loaded.

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

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

Versions of packages linux-image-2.6.39-1-amd64 depends on:
ii  debconf [debconf-2.0] 1.5.36.1   Debian configuration management sy
ii  initramfs-tools [linux-initra 0.99   tools for generating an initramfs
ii  linux-base3  Linux image base package
ii  module-init-tools 3.12-1 tools for managing Linux kernel mo

Versions of packages linux-image-2.6.39-1-amd64 recommends:
ii  firmware-linux-free   3  Binary firmware for various driver

Versions of packages linux-image-2.6.39-1-amd64 suggests:
ii  grub-pc 1.98+20100804-14 GRand Unified Bootloader, version 
ii  lilo1:22.8-10LInux LOader - The Classic OS load
pn  linux-doc-2.6.39   (no description available)

Versions of packages linux-image-2.6.39-1-amd64 is related to:
ii  firmware-bnx2 0.28   Binary firmware for Broadcom NetXt
pn  firmware-bnx2x (no description available)
pn  firmware-ipw2x00   (no description available)
pn  firmware-ivtv  (no description available)
pn  firmware-iwlwifi   (no description available)
pn  firmware-linux (no description available)
pn  firmware-linux-nonfree (no description available)
pn  firmware-qlogic(no description available)
pn  firmware-ralink(no description available)
pn  xen-hypervisor (no description available)

-- debconf information:
  linux-image-2.6.39-1-amd64/prerm/removing-running-kernel-2.6.39-1-amd64: true
* linux-image-2.6.39-1-amd64/postinst/missing-firmware-2.6.39-1-amd64:
  linux-image-2.6.39-1-amd64/postinst/ignoring-ramdisk:
  linux-image-2.6.39-1-amd64/postinst/depmod-error-initrd-2.6.39-1-amd64: false



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

Bug#627050: openssh-server: sftp server crashes

[Patricio Rojo]

I discover what was the problem: my .tcshrc was giving a message error
due to a missing file I wanted to source... I commented out that line
and the problem was gone...

It will be great if some info on this regard would be given by sftp
instead of dying silently.  Thanks!



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

Bug#604197: PC speaker does not work after upgrade to squeeze

[Petr Salinger]

Thanks.  Thanks to Martin we know this bug seems to have been
introduced for him in v2.6.30-rc1 (more precisely: ALSA: hda - Use
digital beep for AD codecs, 2009-02-06).  I suspect it may have been
fixed on at least some systems by v2.6.35-rc1~478^2~1^2~24^2~3 (ALSA:
hda-intel - AD1984 thinkpad - add analog beep input control,
2010-03-26).

But that is only a wild guess.  Could you test with the kernel from
testing, sid, or experimental?


It works correctly for me with kernel from testing (2.6.38-2-amd64).

Thanks.

Petr



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

Bug#629993: gnome-power-manager: script used by reportbug raises error when hal is not installed

[Julien Valroff]

Source: gnome-power-manager
Version: 2.32.0-2
Severity: minor

Hi,

Here is what I get when using `reportbug gnome-power-manager':

Gathering additional data, this may take a while...
/usr/share/gnome-power-manager/gnome-power-bugreport: 53: lshal: not found
/usr/share/gnome-power-manager/gnome-power-bugreport: 63: 
hal-find-by-capability: not found
/usr/share/gnome-power-manager/gnome-power-bugreport: 66: 
hal-find-by-capability: not found
/usr/share/gnome-power-manager/gnome-power-bugreport: 69: 
hal-find-by-capability: not found
/usr/share/gnome-power-manager/gnome-power-bugreport: 72: 
hal-find-by-capability: not found
/usr/share/gnome-power-manager/gnome-power-bugreport: 75: lshal: not found
The package bug script /usr/share/bug/gnome-power-manager/script exited with an 
error status (return code = 256). Do you still want to file a report? [y|N|q|?]?

While it doesn't prevent the bug to be reported correctly, it might mislead
users who don't have hal installed.

Making g-p-m depend on hal is not a solution, I guess the script should
simply be modified to not raise error when hal isn't installed.

Cheers,
Julien


-- Package-specific info:
Distro version:   wheezy/sid
Kernel version:   2.6.39-2-amd64
g-p-m version:2.32.0
HAL version:  System manufacturer:  missing
System version:   missing
System product:   missing
AC adapter present:   no
Battery present:  no
Laptop panel present: no
CPU scaling present:  no
Battery Information:
UPower data:
Device: /org/freedesktop/UPower/devices/line_power_ACAD
  native-path:  
/sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/ACAD
  power supply: yes
  updated:  Fri Jun 10 06:46:16 2011 (538 seconds ago)
  has history:  no
  has statistics:   no
  line-power
online: no

Device: /org/freedesktop/UPower/devices/battery_BAT1
  native-path:  
/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1
  vendor:   SANYO
  model:UM09E36
  serial:   6341
  power supply: yes
  updated:  Fri Jun 10 06:54:50 2011 (24 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   discharging
energy:  57.2871 Wh
energy-empty:0 Wh
energy-full: 58.7634 Wh
energy-full-design:  62.16 Wh
energy-rate: 8.2806 W
voltage: 12.239 V
time to empty:   6.9 hours
percentage:  97.4877%
capacity:94.5357%
technology:  lithium-ion
  History (charge):
1307681690  97.488  discharging
1307681660  97.620  discharging
1307681630  97.752  discharging
  History (rate):
1307681690  8.281   discharging
1307681660  8.636   discharging
1307681630  9.357   discharging

Daemon:
  daemon-version:  0.9.11
  can-suspend: yes
  can-hibernateyes
  on-battery:  yes
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  is-docked:   no
GNOME Power Manager Process Information:
julien2292  0.0  0.3 294720 13180 ?Sl   Jun09   0:00  
\_ gnome-power-manager
julien   15002  3.4  0.6 204904 25472 pts/2S+   06:54   0:01  | 
  \_ /usr/bin/python /usr/bin/reportbug -O --src gnome-power-manager
HAL Process Information:

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

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

Versions of packages gnome-power-manager depends on:
ii  consolekit   0.4.5-1 framework for defining and trackin
ii  dbus-x11 1.4.10-2simple interprocess messaging syst
ii  gconf2   2.32.3-2GNOME configuration database syste
ii  libbonobo2-0 2.24.3-1Bonobo CORBA interfaces library
ii  libc62.13-6  Embedded GNU C Library: Shared lib
ii  libcairo21.10.2-6The Cairo 2D vector graphics libra
ii  libcanberra-gtk0 0.28-1  Gtk+ helper for playing widget eve
ii  libcanberra0 0.28-1  a simple abstract interface for pl
ii  libdbus-1-3  1.4.10-2simple interprocess messaging syst
ii  libdbus-glib-1-2 0.94-2  simple interprocess messaging syst
ii  libgconf2-4  2.32.3-2GNOME configuration database syste
ii  libglib2.0-0 2.28.6-1The GLib library of C routines
ii  libgnome-keyring03.0.3-1 GNOME keyring services library
ii  libgtk2.0-0  2.24.4-3The GTK+ graphical user interface 
ii  libnotify1 [libnotify1-gtk2. 0.5.0-2 sends desktop notifications to a n
ii  li

Bug#629992: debian-kernel: Please include hardware patch to fix midi on M-audio Fast-Track devices

[Grant Adrian Diffey]

Package: debian-kernel
Version: linux-kernel
Severity: wishlist

Please pull commit c91d9cda558fc348205fa972c8b864f8579ef258 from linus's
current tree. which fixes Maudio-fast-track ultra midi



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

Kernel: Linux 3.0.0-rc2 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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#629991: gnome-power-manager: should (at least) recommend network-manager

[Julien Valroff]

Package: gnome-power-manager
Version: 2.32.0-2
Severity: minor

Hi,

gnome-power-manager should (at least) recommend hicolor-icon-theme as
without it, systray icons are not displayed.

Cheers,
Julien


-- Package-specific info:
Distro version:   wheezy/sid
Kernel version:   2.6.39-2-amd64
g-p-m version:2.32.0
HAL version:  System manufacturer:  missing
System version:   missing
System product:   missing
AC adapter present:   no
Battery present:  no
Laptop panel present: no
CPU scaling present:  no
Battery Information:
UPower data:
Device: /org/freedesktop/UPower/devices/line_power_ACAD
  native-path:  
/sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/ACAD
  power supply: yes
  updated:  Fri Jun 10 06:46:16 2011 (385 seconds ago)
  has history:  no
  has statistics:   no
  line-power
online: no

Device: /org/freedesktop/UPower/devices/battery_BAT1
  native-path:  
/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1
  vendor:   SANYO
  model:UM09E36
  serial:   6341
  power supply: yes
  updated:  Fri Jun 10 06:52:20 2011 (21 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   discharging
energy:  57.6867 Wh
energy-empty:0 Wh
energy-full: 58.7634 Wh
energy-full-design:  62.16 Wh
energy-rate: 8.4915 W
voltage: 12.309 V
time to empty:   6.8 hours
percentage:  98.1677%
capacity:94.5357%
technology:  lithium-ion
  History (charge):
1307681540  98.168  discharging
1307681510  98.319  discharging
1307681480  98.470  discharging
1307681450  98.602  discharging
  History (rate):
1307681540  8.492   discharging
1307681510  15.151  discharging
1307681480  8.591   discharging
1307681450  12.421  discharging

Daemon:
  daemon-version:  0.9.11
  can-suspend: yes
  can-hibernateyes
  on-battery:  yes
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  is-docked:   no
GNOME Power Manager Process Information:
julien2292  0.0  0.3 294720 13180 ?Sl   Jun09   0:00  
\_ gnome-power-manager
julien   14818  7.6  0.6 204904 25456 pts/2S+   06:52   0:01  | 
  |   \_ /usr/bin/python /usr/bin/reportbug -O gnome-power-manager
HAL Process Information:

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

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

Versions of packages gnome-power-manager depends on:
ii  consolekit   0.4.5-1 framework for defining and trackin
ii  dbus-x11 1.4.10-2simple interprocess messaging syst
ii  gconf2   2.32.3-2GNOME configuration database syste
ii  libbonobo2-0 2.24.3-1Bonobo CORBA interfaces library
ii  libc62.13-6  Embedded GNU C Library: Shared lib
ii  libcairo21.10.2-6The Cairo 2D vector graphics libra
ii  libcanberra-gtk0 0.28-1  Gtk+ helper for playing widget eve
ii  libcanberra0 0.28-1  a simple abstract interface for pl
ii  libdbus-1-3  1.4.10-2simple interprocess messaging syst
ii  libdbus-glib-1-2 0.94-2  simple interprocess messaging syst
ii  libgconf2-4  2.32.3-2GNOME configuration database syste
ii  libglib2.0-0 2.28.6-1The GLib library of C routines
ii  libgnome-keyring03.0.3-1 GNOME keyring services library
ii  libgtk2.0-0  2.24.4-3The GTK+ graphical user interface 
ii  libnotify1 [libnotify1-gtk2. 0.5.0-2 sends desktop notifications to a n
ii  libpanel-applet2-0   2.30.2-4library for GNOME Panel applets
ii  libpango1.0-01.28.3-6Layout and rendering of internatio
ii  libunique-1.0-0  1.1.6-2 Library for writing single instanc
ii  libupower-glib1  0.9.11-1+b1 abstraction for power management -
ii  libx11-6 2:1.4.3-1   X11 client-side library
ii  libxext6 2:1.3.0-1   X11 miscellaneous extension librar
ii  libxrandr2   2:1.3.1-1   X11 RandR extension library
ii  notification-daemon  0.5.0-3 daemon to displays passive pop-up 
ii  upower   0.9.11-1+b1 abstraction for power management

Versions of packages gnome-power-manager recommends:
ii  udisks1.0.2-4storage media interface

Versions of packages gnome-power-manager suggests:
ii

Bug#629990: network-manager-gnome: Should (at least) recommend hicolor-icon-theme

[Julien Valroff]

Package: network-manager-gnome
Version: 0.8.4-2
Severity: minor

Hi,

network-manager-gnome should (at least) recommend hicolor-icon-theme as
without it, systray icons are not displayed.

Cheers,
Julien

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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-x11  1.4.10-2   simple interprocess messaging syst
ii  gconf22.32.3-2   GNOME configuration database syste
ii  gnome-icon-theme  3.0.0-2GNOME Desktop icon theme
ii  libatk1.0-0   2.0.0-1The ATK accessibility toolkit
ii  libc6 2.13-6 Embedded GNU C Library: Shared lib
ii  libcairo2 1.10.2-6   The Cairo 2D vector graphics libra
ii  libdbus-1-3   1.4.10-2   simple interprocess messaging syst
ii  libdbus-glib-1-2  0.94-2 simple interprocess messaging syst
ii  libfontconfig12.8.0-2.2  generic font configuration library
ii  libfreetype6  2.4.4-1FreeType 2 font engine, shared lib
ii  libgconf2-4   2.32.3-2   GNOME configuration database syste
ii  libgdk-pixbuf2.0-02.23.3-3   GDK Pixbuf library
ii  libglib2.0-0  2.28.6-1   The GLib library of C routines
ii  libgnome-bluetooth7   2.30.0-2   GNOME Bluetooth tools - support li
ii  libgnome-keyring0 3.0.3-1GNOME keyring services library
ii  libgtk2.0-0   2.24.4-3   The GTK+ graphical user interface 
ii  libnm-glib-vpn1   0.8.4.0-2  network management framework (GLib
ii  libnm-glib2   0.8.4.0-2  network management framework (GLib
ii  libnm-util1   0.8.4.0-2  network management framework (shar
ii  libnotify1 [libnotify1-gtk2.1 0.5.0-2sends desktop notifications to a n
ii  libpango1.0-0 1.28.3-6   Layout and rendering of internatio
ii  network-manager   0.8.4.0-2  network management framework (daem
ii  policykit-1-gnome 0.101-2GNOME authentication agent for Pol

Versions of packages network-manager-gnome recommends:
pn  gnome-bluetooth(no description available)
ii  libpam-gnome-keyring [libpam- 3.0.3-2PAM module to unlock the GNOME key
ii  mobile-broadband-provider-inf 20110424-1 database of mobile broadband servi
ii  notification-daemon   0.5.0-3daemon to displays passive pop-up 

Versions of packages network-manager-gnome suggests:
pn  network-manager-openvpn-gnome  (no description available)
ii  network-manager-pptp-gnome0.8.4-1network management framework (PPTP
pn  network-manager-vpnc-gnome (no description available)

-- no debconf information

-- 
  .''`.   Julien Valroff ~  ~ 
 : :'  :  Debian Developer & Free software contributor
 `. `'`   http://www.kirya.net/
   `- 4096R/ E1D8 5796 8214 4687 E416  948C 859F EF67 258E 26B1



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

Bug#604197: PC speaker does not work after upgrade to squeeze

[Jonathan Nieder]

merge 534598 604197
found 534598 linux-2.6/2.6.32-30
quit

Hi,

Uwe Storbeck wrote:

> Same problem here, after boot the PC speaker does not work (since
> the upgrade to squeeze). Standard HP Compaq PC with ICH9 chipset.
> So no exotic hardware, if that matters.
>
> The module pcspkr is loaded after boot, but no beep or speaker
> sound at all. When I manually remove the module and reload it
> with modprobe the speaker works normal.

Thanks.  Thanks to Martin we know this bug seems to have been
introduced for him in v2.6.30-rc1 (more precisely: ALSA: hda - Use
digital beep for AD codecs, 2009-02-06).  I suspect it may have been
fixed on at least some systems by v2.6.35-rc1~478^2~1^2~24^2~3 (ALSA:
hda-intel - AD1984 thinkpad - add analog beep input control,
2010-03-26).

But that is only a wild guess.  Could you test with the kernel from
testing, sid, or experimental?



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

Bug#629989: opu: package sun-java6/6-26-0lenny1

[Torsten Werner]

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

Hi,

Oracle has updated the security baseline to 6.26 and that means we should update
the package in stable and oldstable. They plan to do such updates every 3 or 4
months from now on. I've prepared an updated package at
 based on Sylvestre's work for 
unstable.

Cheers,
Torsten



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

Bug#626640: Moreover...

[Bryce Nesbitt]

Adding to this: this script adds a twice an hour cron job, even if there 
is no webserver running at all.

This is laptop unfriendly.

/etc/cron.d/php5 should also get comments, so those of us seeing "why is 
my laptop not sleeping" can track it down.
But better yet, find a less awkward way to clean up the session files 
(or, lack of session files).  There are a few of us
that use php as a server side language without any apache/php 
involvement at all.




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

Bug#629988: Missing man pages

[Mattias Ellert]

Package: arcjobtool
Version: 0.3.0-2
Severity: minor

$ lintian arcjobtool_0.3.0-2_all.deb
W: arcjobtool: binary-without-manpage usr/bin/arcjobtool
W: arcjobtool: binary-without-manpage usr/bin/ui-cert-request



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

Bug#629984: spamd: could not create INET socket on 127.0.0.1:783 (due to /etc/cron.daily/spamassassin?)

[Bob Proulx]

Vincent Lefevre wrote:
> The problem comes from the fact that famd chooses a random port at
> startup.

Just to be clear are you saying that famd picked port 783 randomly at
startup?

> I don't know what is the policy for port selection, but either
> spamd should choose a different port until it succeeds, or (if
> ports are supposed to be fixed) this should be seen as a critical
> bug of famd, because its choice potentially breaks other packages
> (like spamassassin).

Look in /etc/services and you will find that port 783 is allocated in
Debian to spamd.  That is the port that spamc will use to contact the
spamd.  It has been coordinated.

Bob



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

Bug#629984: spamd: could not create INET socket on 127.0.0.1:783 (due to /etc/cron.daily/spamassassin?)

[Noah Meyerhans]

On Fri, Jun 10, 2011 at 03:58:45AM +0200, Vincent Lefevre wrote:
> On 2011-06-10 03:49:28 +0200, Vincent Lefevre wrote:
> > Is it a bug in spamassassin (that did a special request to famd and
> > forgot about it) or in famd (but why would it listen to port 783)?
> 
> The problem comes from the fact that famd chooses a random port at
> startup.
> 
> I don't know what is the policy for port selection, but either
> spamd should choose a different port until it succeeds, or (if
> ports are supposed to be fixed) this should be seen as a critical
> bug of famd, because its choice potentially breaks other packages
> (like spamassassin).

sh-4.1$ egrep '\s783' /etc/services 
spamd   783/tcp # spamassassin daemon

The bug is with famd.

It wouldn't make sense for spamd to choose a different port, because
clients would have no way of knowing what it is.  famd (last I knew
anyway; I haven't touched it in years) uses portmap, so it can choose an
arbitrary port.

noah



signature.asc
Description: Digital signature

Bug#629987: pulseaudio: gnome-volume.control.pulse not show "Mic rear"

[zeis]

Package: pulseaudio
Version: 0.9.21-4
Severity: important

gnome-volume-control.pulse in input show 2 connector (Mic Front - Line )
missing Mic rear.



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

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

Versions of packages pulseaudio depends on:
ii  adduser   3.112+nmu2 add and remove users and groups
ii  consolekit0.4.5-1framework for defining and trackin
ii  libasound21.0.23-4   shared library for ALSA applicatio
ii  libc6 2.13-4 Embedded GNU C Library: Shared lib
ii  libcap2   1:2.21-1   support for getting/setting POSIX.
ii  libdbus-1-3   1.4.8-3simple interprocess messaging syst
ii  libgdbm3  1.8.3-9GNU dbm database routines (runtime
ii  libice6   2:1.0.7-1  X11 Inter-Client Exchange library
ii  libltdl7  2.4-2  A system independent dlopen wrappe
ii  libpulse0 0.9.21-4   PulseAudio client libraries
ii  libsamplerate00.1.7-3Audio sample rate conversion libra
ii  libsm62:1.2.0-1  X11 Session Management library
ii  libsndfile1   1.0.24-1   Library for reading/writing audio 
ii  libspeexdsp1  1.2~rc1-1  The Speex extended runtime library
ii  libudev0  167-3  libudev shared library
ii  libx11-6  2:1.4.3-1  X11 client-side library
ii  libxtst6  2:1.2.0-1  X11 Testing -- Record extension li
ii  lsb-base  3.2-27 Linux Standard Base 3.2 init scrip
ii  udev  167-3  /dev/ and hotplug management daemo

Versions of packages pulseaudio recommends:
ii  gstreamer0.10-pulseaudio  0.10.29-2  GStreamer plugin for PulseAudio
ii  libasound2-plugins1.0.23-2   ALSA library additional plugins
ii  pulseaudio-esound-compat  0.9.21-4   PulseAudio ESD compatibility layer
ii  pulseaudio-module-x11 0.9.21-4   X11 module for PulseAudio sound se

Versions of packages pulseaudio suggests:
pn  paman  (no description available)
pn  paprefs(no description available)
pn  pavucontrol(no description available)
pn  pavumeter  (no description available)
ii  pulseaudio-utils  0.9.21-4   Command line tools for the PulseAu

-- Configuration Files:
/etc/pulse/default.pa changed [not included]

-- 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#629986: kpart-webkit: konqueror with webkit and rekonq both crashes in acid3 test at about 73/100

[Michael Tsang]

Package: kpart-webkit
Version: 0.9.6svn1180498-2
Severity: normal
Tags: lfs

1. open the browser
2. run acid3 test ( http://acid3.acidtests.org/ )
3. it crashes



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

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

Versions of packages kpart-webkit depends on:
ii  libc6  2.13-4Embedded GNU C Library: Shared lib
ii  libkdecore54:4.6.3-3 KDE Platform Core Library
ii  libkdeui5  4:4.6.3-3 KDE Platform User Interface Librar
ii  libkparts4 4:4.6.3-3 Framework for the KDE Platform Gra
ii  libkwebkit10.9.6svn1180498-2 KDE bindings for WebKit
ii  libqtcore4 4:4.7.3-1 Qt 4 core module
ii  libstdc++6 4.6.0-10  The GNU Standard C++ Library v3

kpart-webkit recommends no packages.

kpart-webkit 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#427804: bash: missing info documentation

[Sajith T S]

I had to install bash-doc package from Ubuntu as a band-aid solution
after installing wheezy, because I really need the bash info pages.
Someone someday would remedy this by creating a bash-doc-nonfree or
bash-doc-gfdl or some such package, wouldn't they?

-- 
"the lyf so short, the craft so long to lerne."
 -- Chaucer.




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

Bug#629498: binutils: ld cannot find symbols in library dependents

[Jonathan Nieder]

Philip Ashmore wrote:

> I know that libtreedb.so, or one of its dependants, exports needed symbols. 
> Whether I link
> directly or indirectly, that symbol will end up in the address space of the 
> executable.

That was never portable.  Checking the Makefile for git (which is
the example I have at hand), we find that using functions from
libcrypto requires using -lcrypto even if already passed -lssl, on:

 - Mac OS X (Apple ld)
 - Windows (MSVC)
 - Windows (GNU ld from the MinGW project)

All of those platforms use dynamic linking.

Aside from that, the usual best practice is:

 - link explicitly to every DSO providing functions you will be using
 - do not link explicitly to DSOs that are needed only as a dependency
   of functions you will be using

That way, libraries can change which libraries they link to and more
importantly versions of libraries linked to (which is after all an
implementation detail) without breaking programs that use them.  Using
--no-copy-dt-needed-entries has many purposes that as mentioned before
I don't want to get into (if you really want to raise that discussion,
you will have to motivate people --- soliciting information on the
purpose of the option on the upstream binutils mailing list in order
to write documentation might be one way).  One of the most compelling
is that it catches programs that violate the best practice mentioned
above.

But I don't think that was what you were talking about --- your
example is not about the usual case but something special.  So my
advice is still that it would be better to find another way to do what
you are trying to do.

>>  /* GNU ld script */
>>  INPUT(-llibtreedb-0.9-bare)
>>  INPUT(-lv3c-1.8)
>
> Are linker scripts portable?

No, the "implicit linker scripts" feature is specific to GNU ld.

> Can I use LD_PRELOAD to load a shlib that's a linker script to turn on 
> debugging?

Linker scripts and --no-copy-dt-needed-entries are build-time
facilities.  At run time you can still use the same LD_PRELOAD tricks
you are used to.

[...]
> Even pkg-config lists the libraries a package depends on
>
>   pkg-config --libs v3c
>
> returns -Wl,-rpath -Wl,/usr/lib -lpthread -lv3c-1.8 -luuid

That means that anyone using pkg-config to link to libtreedb won't run
into this problem, right?  You control what goes in pkg-config --libs
output (it certainly isn't supposed to list the dependencies), so this
can be a good and portable way to allow apps to conveniently link to
both libtreedb-bare and v3c when using both APIs.

But thinking about it more, I suspect that is not what you are looking
to make happen.  Instead, if I understand correctly, the intent is as
if you had two libraries of PIC code:

libtreedb-0.9-bare
libv3c-1.8

and then linked them together to make libtreedb-0.9.so and linked
libv3c-1.8 alone to make libv3c-1.8.so --- except that to save memory,
the text of libtreedb-0.9 is not supposed to duplicate libv3c.

Linking libtreedb against libv3c and populating it with some aliases
to re-export the latter's functions might be an okay way to make it
happen.  I admit I find this example a little weird --- why shield
users from the knowledge of whether they are using functions from the
libv3c API?

[...]
> Sorry If I come across as confused, maybe I don't get it.

I'm quite willing to believe there are documentation bugs lurking.
Thanks for your work.

Regards,
Jonathan



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

Bug#629592: cyrus-common-2.2: confusing/contradictory information on lenny->squeeze upgrade

[Ross Boylan]

On the minor matter of getting the update script:

On Thu, 2011-06-09 at 10:01 +0200, Ondřej Surý wrote:
> > 1. I had some trouble retrieving the file;
> > wget
> http://anonscm.debian.org/gitweb/?p=pkg-cyrus-imapd/cyrus-imapd-2.4.git;a=blob;f=debian/cyrus-upgrade-db
> >
> > got me a web page. lynx on the same URL got me the general
> repository,
> > not cyrus-upgrade-db.  I ended up navigating to  it through the tree
> > link.
> >
> > Maybe the right way to do this would be obvious if I knew git.
> 
> Just clicking on 'cyrus-upgrade-db' would do the trick. 
I didn't see the link; I got a page of the commit history of the project
apparently.  I think it was some kind of shell quoting problem; when I
said
lynx "http://anonscm."; it worked.

> Here's the
> wgetable link:
> 
> http://anonscm.debian.org/gitweb/?p=pkg-cyrus-imapd/cyrus-imapd-2.4.git;a=blob_plain;f=debian/cyrus-upgrade-db

BTW, that still is getting me a file that starts like this:


http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en-US" lang="en-US">












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

Bug#629592: cyrus-common-2.2: confusing/contradictory information on lenny->squeeze upgrade

[Ross Boylan]

On Thu, 2011-06-09 at 10:01 +0200, Ondřej Surý wrote:
> On Thu, Jun 9, 2011 at 09:10, Ross Boylan  wrote:
> > On Wed, 2011-06-08 at 10:13 +0200, Ondřej Surý wrote:
,
[Ross wrote]
> > The main problem is that the convert script says to install db4.2-util,
> > but it is not available in squeeze.  I assume it's in Lenny, but don't
> > know if the version there will work on a squeeze system.
> 
> It should work, just get libdb4.2 and db4.2-util.
> 
> Anyway the script is for squeeze->wheezy and it will work there.
> Unfortunately it's too late to fix the squeeze.
I added lenny to sources.list and was able to retrieve db4.2-util (I
didn't get libdb4.2 since I just noticed it).

Isn't there likely to be a similar issue in wheezy, in which the "old"
version (4.7) will only be available in squeeze?  If so, I think it
needs a release note warning people to install the package before they
upgrade.  And/or the cyrus package could recommend libdb4.7-util.

It looks to me as if there are still problems.  Here's what mail.info
shows when I started cyrus after running the upgrade script:

Jun  9 19:29:21 vm-migrate07 cyrus/master[16572]: process started
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: DBERROR db4: 
/var/lib/cyrus/db: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: DBERROR db4: 
/var/lib/cyrus/db/__db.001: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: DBERROR db4: 
/var/lib/cyrus/db: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: DBERROR db4: 
/var/lib/cyrus/db/__db.001: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: DBERROR: dbenv->open 
'/var/lib/cyrus/db' failed: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: DBERROR: init() on 
berkeley
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: DBERROR: writing 
/var/lib/cyrus/db/skipstamp: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: DBERROR: init() on 
skiplist
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: recovering cyrus 
databases
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: skiplist: recovered 
/var/lib/cyrus/mailboxes.db (3 records, 568 bytes) in 0 seconds
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: skiplist: recovered 
/var/lib/cyrus/annotations.db (0 records, 144 bytes) in 0 seconds
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16574]: done recovering cyrus 
databases
Jun  9 19:29:21 vm-migrate07 cyrus/cyr_expire[16575]: DBERROR db4: 
/var/lib/cyrus/db/__db.001: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/cyr_expire[16575]: DBERROR: dbenv->open 
'/var/lib/cyrus/db' failed: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/cyr_expire[16575]: DBERROR: init() on 
berkeley
Jun  9 19:29:21 vm-migrate07 cyrus/cyr_expire[16575]: DBERROR: reading 
/var/lib/cyrus/db/skipstamp, assuming the worst: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/cyr_expire[16575]: skiplist: recovered 
/var/lib/cyrus/annotations.db (0 records, 144 bytes) in 0 seconds
Jun  9 19:29:21 vm-migrate07 cyrus/cyr_expire[16575]: skiplist: recovered 
/var/lib/cyrus/mailboxes.db (3 records, 568 bytes) in 0 seconds
Jun  9 19:29:21 vm-migrate07 cyrus/cyr_expire[16575]: DBERROR db4: 
DB_AUTO_COMMIT may not be specified in non-transactional environment
Jun  9 19:29:21 vm-migrate07 cyrus/cyr_expire[16575]: DBERROR: opening 
/var/lib/cyrus/deliver.db: Invalid argument
Jun  9 19:29:21 vm-migrate07 cyrus/cyr_expire[16575]: DBERROR: opening 
/var/lib/cyrus/deliver.db: cyrusdb error
Jun  9 19:29:21 vm-migrate07 cyrus/master[16572]: process 16575 exited, status 1
Jun  9 19:29:21 vm-migrate07 cyrus/tls_prune[16576]: DBERROR db4: 
/var/lib/cyrus/db/__db.001: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/tls_prune[16576]: DBERROR: dbenv->open 
'/var/lib/cyrus/db' failed: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/tls_prune[16576]: DBERROR: init() on berkeley
Jun  9 19:29:21 vm-migrate07 cyrus/tls_prune[16576]: DBERROR: reading 
/var/lib/cyrus/db/skipstamp, assuming the worst: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/tls_prune[16576]: DBERROR db4: 
DB_AUTO_COMMIT may not be specified in non-transactional environment
Jun  9 19:29:21 vm-migrate07 cyrus/tls_prune[16576]: DBERROR: opening 
/var/lib/cyrus/tls_sessions.db: Invalid argument
Jun  9 19:29:21 vm-migrate07 cyrus/tls_prune[16576]: DBERROR: opening 
/var/lib/cyrus/tls_sessions.db: cyrusdb error
Jun  9 19:29:21 vm-migrate07 cyrus/master[16572]: process 16576 exited, status 1
Jun  9 19:29:21 vm-migrate07 cyrus/master[16572]: ready for work
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16577]: DBERROR db4: 
/var/lib/cyrus/db/__db.001: No such file or directory
Jun  9 19:29:21 vm-migrate07 cyrus/ctl_cyrusdb[16577]: DBERROR: dbenv->open 
'/var/lib/cyrus/db' failed: No such file or directory
Jun  9 19:29:21 vm-migrat

Bug#629498: binutils: ld cannot find symbols in library dependents

[Philip Ashmore]

On 09/06/11 05:53, Jonathan Nieder wrote:

Why would libtool follow the static-link model when linking to a DSO?
See.  If you disagree with the
reasoning mentioned in that bug and the bugs it is merged with, that
would be a libtool (behavior or documentation) bug.

According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=191425#10

  Yes, this is a known libtool bug.  It is trying to link your program against
  all of the dependent libraries of librrd, even though this is unnecessary,
  and indeed, strongly discouraged.

So since then, knowing what shared libraries the library you're linking to has 
become a
good thing(TM)?

If I were statically linking to libtreedb, libtool would provide all the 
archives, even the
indirect ones, through the .la file.

The point I was making about libtool following the static link model is that if 
ld behaviour
changed then libtool should be changed too, to list all shared libraries.

I know that libtreedb.so, or one of its dependants, exports needed symbols. 
Whether I link
directly or indirectly, that symbol will end up in the address space of the 
executable.

A single point of reference - change the .la file name, change the 
implementation.



If you disagree with --no-copy-dt-needed-entries being the default
behavior for ld, I don't know what to tell you.  Maybe you could
install a wrapper that passes --copy-dt-needed-entries, though that
won't help other Debian or Fedora users build your software.  The
rationale for the change is well documented elsewhere.

Maybe binutils should gain a NEWS.Debian.gz file explaining this to
help people upgrading.

As for the original use case that motivates this: perhaps making
/usr/lib/libtreedb.so a linker script would work for you.  For
example:

/* GNU ld script */
INPUT(-llibtreedb-0.9-bare)
INPUT(-lv3c-1.8)

Are linker scripts portable?

Can I use LD_PRELOAD to load a shlib that's a linker script to turn on 
debugging?
That's what the debugging versions do, by the way.


Sorry to be the bearer of bad news, and hope that helps.

Regards,
Jonathan

I'm sorry to be the one to highlight what appears to be a cognitive gap.

I'm also quite sure that I'm not the only one who writes software that links 
indirectly
to symbols, as a way of managing complexity.

Indeed the only entity this approach appears to save work for is the linker!?!

Or am I getting it wrong andnowcomplexity is a good thing(TM)?

Even pkg-config lists the libraries a package depends on

  pkg-config --libs v3c

returns -Wl,-rpath -Wl,/usr/lib -lpthread -lv3c-1.8 -luuid

How is this different? Is this wrong too?

Sorry If I come across as confused, maybe I don't get it.


Philip





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

Bug#629610: exim4: misleading (?) "failed" message after paniclog warning

[Ross Boylan]

On Thu, 2011-06-09 at 21:23 +0200, Marc Haber wrote:
> tags #629610 confirmed
> end
> 
> On Tue, Jun 07, 2011 at 09:01:10PM -0700, Ross Boylan wrote:
> > 
> > # /etc/init.d/exim4 restart
> > Stopping MTA for restart: exim4_listener.
> > Restarting MTA: exim4.
> > ALERT: exim paniclog /var/log/exim4/paniclog has non-zero size, mail system 
> > possibly broken ... failed!
> > 
> > 
> > I read the "... failed!" as meaning that the non-zero paniclog has
> > caused the restart to fail.
> 
> Affirmative. our fault. log_failure_msg has started to add the "...
> failed" in some recent versions.
Just to be sure I understand: the failure message is in error, and exim
should be functioning normally, right?

Thanks.
Ross
> 
> While we're at it, lsb's cheangelog for 3.2-17 says
> "log_{success,failure,warning}_msg suck, please don't use them for
> Debian scripts.", so we should probably re-work the init script anyway.
> 
> Greetings
> Marc
> 




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

Bug#629932: linux-image-2.6.39-2-amd64: adding physical interface to bridge crashes the kernel

[Ben Hutchings]

On Thu, 2011-06-09 at 19:44 +0200, Joerg wrote:
> Package: linux-2.6
> Version: 2.6.39-2
> Severity: normal
> 
> 
> Adding a tap-interface to a bridge works fine. But adding eth0 to the bridge
> brctl addif br0 eth0
> causes the system to crash.

Works for me.  You must provide the 'oops' message.

> With the previous kernel (2.6.29-1) this was working well.
[...]

I assume that's a typo for '2.6.39-1'.

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.


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

Bug#628641: linux-image-2.6.32-5-686: crashes when closing laptop lid (dell inspiron 300m)

[Ben Hutchings]

On Fri, 2011-06-10 at 00:41 +0200, Thibault Manlay wrote:
> Hello,
> 
> 
> I just noticed a similar issue, maybe related to this bug, on my Dell
> Studio 1555.

Sicne you say:

[...]
> I also have a kernel that I kept from squeeze
> (linux-image-2.6.32-5-686-bigmem 2.6.32-34squeeze1) on which I cannot
> reproduce the bug. It looks like it is a regression somewhere between
> versions 2.6.32 and 2.6.38.
[...]

then I really think you are seeing a different bug.

Please use 'reportbug' to send a new bug report.  Given you can
reproduce this on Linux 2.6.39, you should also report this upstream at
 under product 'DRI' and one of the 'DRM'
components (depending on which graphics chip you have).

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.


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

Bug#627640: slapos.tool.format: [debconf_rewrite] Debconf templates and debian/control review

[Arnaud Fontaine]

Hi,

Sorry  for  the  late reply.  Thank  you  so  much  for taking  care  of
translations.

The upstream recently merged slapos.slap, slapgrid and slapformat into a
single  tarball, namely  slapos.core. This  means that  I will  upload a
package soonish which will merged everything into a single package.

I will apply your patch for debian/control and debian/templates (for the
latter,  I only  have one  minor change:  replace  '_Description: SlapOS
client ID:' by '_Description: SlapOS computer ID:') in the new package.

As soon as the  package is uploaded, I will send an  email to the people
who translated debian/templates to ask for updates. Hope that's ok.

Cheers,
-- 
Arnaud Fontaine


pgp7Bof8xGCzX.pgp
Description: PGP signature

Bug#629985: initramfs-tools: encrypted rootfs doesn't work

[Christian Jaeger]

>     actually I went to a console and used "fastrandom"[1] to

[1] https://github.com/pflanze/fastrandom

(PS. I previously also sent a mail to the debian-boot mailing list on
that issue / those issues, "How to install with encrypted root?")



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

Bug#590180: Sigile Debian package

[Kan-Ru Chen]

"Benj. Mako Hill"  writes:

> Hello Kanru (and others!)
>
> Thanks everyone for your work so far to get Sigil into Debian.  I've
> noticed that it's been a few months since this bug was updated.
>
> I'm willing to put in an evening of work or two to help package
> dependencies or do other work to get this package uploaded. Do you
> have a repository where you are working? What, in particular, needs to
> be changed?

Thank you for bring this up again! I feel so bad that I cannot complete
this package quickly.

It seems I had created a collab-maint repository[1] but haven't pushed
anything yet, because of some non-free part that I don't want to put on
alioth.  My local repository was purged accidentally in my last disk
cleanup, fortunately emacs backup and notes was kept so I can rebuild
the repository and publish it this weekend.

Sigil uses so many convenience copy of libraries (three zip libraries!)
so in order to package Sigil one have to package the dependencies first.

A while ago Pino sent to me two patches that make Sigil to use system
boost and zlib library, attached for reference.

Remaining dependencies are

*** ZipArchive
 - http://www.artpol-software.com/
 - http://bugs.debian.org/614183

*** FlightCrew
 - http://code.google.com/p/flightcrew/
 - http://bugs.debian.org/602781

[1]: http://git.debian.org/?p=collab-maint/sigil.git;a=summary

Cheers,
-- 
Kanru

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -54,9 +54,18 @@
 # This disables the building of the test runner app for FlightCrew
 set( NO_TEST_EXE 1 )
 
+find_package( Boost COMPONENTS date_time filesystem program_options regex system thread )
+
 add_subdirectory( src/tidyLib )
 add_subdirectory( src/ZipArchive )
-add_subdirectory( src/BoostParts )
+if( Boost_FOUND )
+set( BOOST_LIBS ${Boost_DATE_TIME_LIBRARY} ${Boost_FILESYSTEM_LIBRARY} ${Boost_PROGRAM_OPTIONS_LIBRARY} ${Boost_REGEX_LIBRARY} ${Boost_SYSTEM_LIBRARY} ${Boost_THREAD_LIBRARY} )
+set( BOOST_INCLUDE_DIRS ${Boost_INCLUDE_DIRS} )
+else()
+add_subdirectory( src/BoostParts )
+set( BOOST_LIBS BoostParts )
+set( BOOST_INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/src/BoostParts )
+endif()
 add_subdirectory( src/Xerces )
 add_subdirectory( src/XercesExtensions )
 add_subdirectory( src/zlib )
--- a/src/FlightCrew/CMakeLists.txt
+++ b/src/FlightCrew/CMakeLists.txt
@@ -50,7 +50,7 @@
 
 # creating PCH's for MSVC and GCC on Linux
 include( ${CMAKE_SOURCE_DIR}/cmake_extras/CustomPCH.cmake )
-set( ALL_INCLUDES ${BoostParts_SOURCE_DIR}
+set( ALL_INCLUDES ${BOOST_INCLUDE_DIRS}
   ${Xerces_SOURCE_DIR}
   ${zipios_SOURCE_DIR} )
 set( GCC_PCH_TARGET gccPCH_fc )
@@ -65,7 +65,7 @@
 include_directories( ${CMAKE_CURRENT_BINARY_DIR}
  ${CMAKE_CURRENT_SOURCE_DIR}
  ../zipios 
- ../BoostParts 
+ ${BOOST_INCLUDE_DIRS} 
  ../Xerces
  ../XercesExtensions
  ../utf8-cpp
@@ -82,7 +82,7 @@
 add_library( ${PROJECT_NAME} ${SOURCES} )
 endif()
 
-target_link_libraries( ${PROJECT_NAME} zipios BoostParts XercesExtensions )
+target_link_libraries( ${PROJECT_NAME} zipios ${BOOST_LIBS} XercesExtensions )
 
 #
 
--- a/src/Sigil/CMakeLists.txt
+++ b/src/Sigil/CMakeLists.txt
@@ -281,7 +281,7 @@
 
 # creating PCH's for MSVC and GCC on Linux
 include( ${CMAKE_SOURCE_DIR}/cmake_extras/CustomPCH.cmake )
-set( ALL_INCLUDES ${BoostParts_SOURCE_DIR}
+set( ALL_INCLUDES ${BOOST_INCLUDE_DIRS}
   ${Xerces_SOURCE_DIR} 
   ${XercesExtensions_SOURCE_DIR} 
   ${ZipArchive_SOURCE_DIR}
@@ -357,7 +357,7 @@
 # and the headers for the linked-to libraries
 include_directories( ${CMAKE_CURRENT_BINARY_DIR} 
  ${CMAKE_CURRENT_SOURCE_DIR} 
- ${BoostParts_SOURCE_DIR}
+ ${BOOST_INCLUDE_DIRS}
  ${Xerces_SOURCE_DIR} 
  ${XercesExtensions_SOURCE_DIR} 
  ${ZipArchive_SOURCE_DIR}
@@ -377,7 +377,7 @@
 add_executable( ${PROJECT_NAME} WIN32 ${ALL_SOURCES} )
 endif()
 
-target_link_libraries( ${PROJECT_NAME} tidyLib ZipArchive BoostParts Xerces XercesExtensions FlightCrew ${QT_LIBRARIES} )
+target_link_libraries( ${PROJECT_NAME} tidyLib ZipArchive ${BOOST_LIBS} Xerces XercesExtensions FlightCrew ${QT_LIBRARIES} )
 
 #
 
--- a/src/XercesExtensions/CMakeLists.txt
+++ b/src/XercesExtensions/CMakeLists.txt
@@ -17,7 +17,7 @@
 # and the headers for the linked-to libraries
 include_directories( ${CMAKE_CURRENT_SOURCE_DIR}
  ../Xerces
- ../BoostParts )
+ ${BOOST_INCLUDE_DIRS} )
 
 link_directories ( ${PROJECT_BINARY_DIR}/lib ) 
 
--- a/src/zipios/CMakeLists.txt
+++ b/src/zipios/CMakeList

Bug#626091: slapos.tool.format: slapformat/bridge_note is Debconf abuse

[Arnaud Fontaine]

Hi,

Sorry for the late reply.

> Well,  that could be said  for many packages where  some action is
> often  required before it can  work. That doesn't  really push for
>  having something  interrupting the  installationto  basically say
> "there's  work left  to make package   work.  Please  look in
> README.Debian".

I think you're right. So I will just remove this note.

Cheers,
--
Arnaud Fontaine


pgpMnGbd0HFcI.pgp
Description: PGP signature

Bug#629984: spamd: could not create INET socket on 127.0.0.1:783 (due to /etc/cron.daily/spamassassin?)

[Vincent Lefevre]

On 2011-06-10 03:49:28 +0200, Vincent Lefevre wrote:
> Is it a bug in spamassassin (that did a special request to famd and
> forgot about it) or in famd (but why would it listen to port 783)?

The problem comes from the fact that famd chooses a random port at
startup.

I don't know what is the policy for port selection, but either
spamd should choose a different port until it succeeds, or (if
ports are supposed to be fixed) this should be seen as a critical
bug of famd, because its choice potentially breaks other packages
(like spamassassin).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



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

Bug#629985: initramfs-tools: encrypted rootfs doesn't work

[chris]

Package: initramfs-tools
Version: 0.98.8
Severity: important


This is what I want:

/boot   unencrypted
/usrunencrypted
/   encrypted
swapencrypted

Here's how I've tried to achieve this on a netbook, in I think the
simplest way possible (i.e. not using LVM):

- get debian-6.0.1a-i386-CD-1.iso, write it to a USB flash stick using
  unetbootin, boot the graphical installer from it

- choose "manual" in the partitioner,
 * delete all existing partitions
 * create small partition and set it up to be ext3 for /boot
 * create big partition and set it up to be ext4 for /usr
 * create big partition and set it up for crypt usage
 * create small partition and set it up for crypt usage
 * choose "set up crypt volumes" (or so),
   - say no to "overwrite with random data" (too slow for me;
 actually I went to a console and used "fastrandom"[1] to
 overwrite them)
   - give password (2*2 times, twice for each of the two encrypted
 partitions)
 * set up the big encrypted partition to be ext4 for /
 * set up the small encrypted partition to be swap

- let it install the base system; when it says "No installable kernel
  was found in the defined APT sources", go to the console, run

 # chroot /target
 # vi /etc/apt/sources.list
 (file is empty, insert sources)
 # apt-get update
 # apt-get install linux-image-686

- let the installer continue; when it says
   apt configuration problem
   An attempt to configure apt to install additional packages from
   the CD failed.
 just confirm that it should fetch things from the net
 (at that point it will replace sources.list with its own)

- let it install into the MBR; let it reboot, remove the USB flash
  stick; after letting grub boot the default entry, and after waiting
  ~30-45 seconds for the initrd to time out waiting for the root volume
  to appear, when thrown to the emergency shell, type this (I've had
  this problem on another laptop of mine where I installed Squeeze when
  it was testing, already):

 # cryptsetup luksOpen /dev/sda4 sda4_crypt
 command cryptsetup not found

Oh, it doesn't even have cryptsetup in the initrd now. Write GRML to
the USB flash stick and boot from that.

Run cryptsetup luksOpen ..., mount and then mount --bind proc / dev /
sys, mount /usr and /boot, then:

 # apt-get install busybox
 # update-initramfs -u

Installing busybox makes a warning "W: Busybox is required for
successful boot!"  from update-initramfs go away, and makes the initrd
a little bigger; but it still doesn't include cryptsetup.

I've compared /etc/initramfs-tools/* with my other system (laptop) and
they are the same, so why does update-initramfs include the crypto
stuff on my laptop (even if the password asking part doesn't work
there) but not at all on the netbook?

(I'm also wondering whether nobody ever tested installing Squeeze with
an encrypted roofs, that can't be true, right, but then why aren't the
problems I ran into known?)


Note that the info below is from my laptop, not the netbook, since I
can't boot the latter.  As mentioned it is running squeeze, too, and
uses the same setup regarding / and /usr.  As mentioned, on this
laptop update-initramfs at least does include cryptsetup (and I don't
know why), though.

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root  11M May 25 00:10 /boot/initrd.img-2.6.32-5-486
-rw-r--r-- 1 root root 9.6M Sep 24  2010 /boot/initrd.img-2.6.32-5-486.1_cj
-rw-r--r-- 1 root root 9.6M Oct  3  2010 /boot/initrd.img-2.6.32-5-486.2
-rw-r--r-- 1 root root 9.6M Oct  3  2010 /boot/initrd.img-2.6.32-5-686.1
-rw-r--r-- 1 root root 7.6M Jun 21  2010 
/boot/initrd.img-2.6.33.5-vs2.3.0.36.30.4
-rw-r--r-- 1 root root 5.3M Feb  8 23:47 /boot/initrd.img-2.6.37
-rw-r--r-- 1 root root  12M Mar 20 10:40 /boot/initrd.img-2.6.37.3
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.37.3 root=/dev/mapper/sda11plain ro

-- /proc/filesystems
ext4
ext3
squashfs
fuseblk
vfat

-- lsmod
Module  Size  Used by
iwlagn113255  0 
nls_utf8 920  0 
nls_cp437   4501  0 
vfat6455  0 
fat34446  1 vfat
ppp_deflate 2914  0 
zlib_deflate   15662  1 ppp_deflate
bsd_comp3988  0 
ppp_async   5261  0 
crc_ccitt   1047  1 ppp_async
ppp_generic15955  3 ppp_deflate,bsd_comp,ppp_async
slhc3494  1 ppp_generic
option 12918  0 
usb_wwan6147  1 option
usbserial  21120  2 option,usb_wwan
btusb   8055  0 
bluetooth  37533  1 btusb
i915  252650  2 
drm_kms_helper 19637  1 i915
drm   118430  3 i915,drm_kms_helper
i2c_algo_bit3373  1 i915
i2c_core   12989  4 i915,drm_kms_helper,drm,i2c_algo_bit
vboxnetadp  5138  0 
vboxnetflt 11916  0 
vboxdrv   125469  2 vboxnetadp,v

Bug#629984: spamd: could not create INET socket on 127.0.0.1:783 (due to /etc/cron.daily/spamassassin?)

[Vincent Lefevre]

retitle 629984 spamd: could not create INET socket on 127.0.0.1:783 (listened 
by famd)
thanks

On 2011-06-10 03:26:30 +0200, Vincent Lefevre wrote:
> It wasn't the cause: it is no longer there, and I still have the
> same problem when I want to restart spamd.

"netstat -napt" as root gives:

tcp0  0 127.0.0.1:783   0.0.0.0:*   LISTEN  
1455/famd

Is it a bug in spamassassin (that did a special request to famd and
forgot about it) or in famd (but why would it listen to port 783)?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



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

Bug#629984: spamd: could not create INET socket on 127.0.0.1:783 (due to /etc/cron.daily/spamassassin?)

[Vincent Lefevre]

retitle 629984 spamd: could not create INET socket on 127.0.0.1:783
thanks

On 2011-06-10 03:09:31 +0200, Vincent Lefevre wrote:
> I was wondering which process was the cause (spamd isn't running), and
> I saw:
> 
> root  7796  4117  0 02:52 ?00:00:00 /bin/sh 
> /etc/cron.daily/spamassassin
> 
> Something is apparently broken with it.

It wasn't the cause: it is no longer there, and I still have the
same problem when I want to restart spamd.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



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

Bug#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN

[Vincent Lefevre]

On 2011-06-10 00:05:31 +0100, Massimo Manghi wrote:
> On Thu, 9 Jun 2011 19:27:23 +0200, Vincent Lefevre wrote:
> >Actually I don't think this is the same bug. I cannot reproduce
> >this bug 629899 concerning apache2, while the bug with wwwoffle
> >has occurred every time since I upgraded to libc6 2.13.
> 
> OK. Wasn't this bug filed against apache2.2-common?

I did "reportbug apache2", but the bug was indeed files against
apache2.2-common.

> Anyway I expect every application based on apr calling
> apr_sockaddr_info_get to fail with a similar reason.

I filed a second bug against wwwoffle (which isn't based on libapr,
BTW).

[...]
> >wwwoffle may do something special, and the maintainer could reassign
> >the bug to libc6 (with a testcase) if it appears that the problem
> >comes from libc6.
> >
> >I suggest that you report a bug for the problem you get. If you can
> >reproduce it, you'll have at least more information than me...
> 
> I would file it against libc6 because my conjecture is that different
> components layered on libc6 are failing when they probably call something
> like uname or gethostname.

Perhaps, but one needs to know precisely which function is failing.
I doubt the libc6 developers know the wwwoffle internals.

I upgraded another machine (kernel and libc6), and this time, that's
spamassassin that was affected (spamassassin was not upgraded between
the two reboots). But again, I don't know whether this is related to
the problems with apache2 and wwwoffle (apparently not a hostname
problem, but still network related). Just in case:

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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



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

Bug#595298: [Pkg-oss4-maintainers] Bug#595298:

[Romain Beauxis]

Hi Remi,

I have very little time to test and package unfortunately.

However, I could include you in the team so that you can push your
changes to our repository. I'll be happy to upload them afterwards!

Romain

Le 9 juin 2011 18:36, Rémi Bernon  a écrit :
> Is there any plan to package the new upstream version?
> I've built a package locally, with the new upstream version retrieved
> with uscan and the required change in os_cmd.patch (see attached), but
> I'm probably unable to upload it as I'm not a Debian Maintainer, and I
> don't know how to provide it to the Maintainers.
> I tried mentors.debian.net, but it seems to have some issues with the
> registration.
> It's really not a big deal and this bug is really annoying for people
> who want OSS with a testing/unstable kernel.
>
> Rémi
>
> ___
> Pkg-oss4-maintainers mailing list
> pkg-oss4-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-oss4-maintainers
>



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

Bug#629984: spamd: could not create INET socket on 127.0.0.1:783 (due to /etc/cron.daily/spamassassin?)

[Vincent Lefevre]

Package: spamassassin
Version: 3.3.1-2
Severity: important

Since the last reboot (after the kernel and libc6 upgrade), I get the
following error (at boot and with a manual restart like below):

# /etc/init.d/spamassassin restart
Restarting SpamAssassin Mail Filter Daemon: No /usr/bin/perl found running; 
none killed.
defined(%hash) is deprecated at /usr/share/perl5/Mail/SpamAssassin/Dns.pm line 
757.
(Maybe you should just omit the defined()?)
Jun 10 02:58:49.398 [8305] warn: Use of uninitialized value 
$opt{"syslog-socket"} in lc at /usr/sbin/spamd line 444.
Jun 10 02:58:49.406 [8305] warn: server socket setup failed, retry 1: spamd: 
could not create INET socket on 127.0.0.1:783: Address already in use
Jun 10 02:58:50.408 [8305] warn: server socket setup failed, retry 2: spamd: 
could not create INET socket on 127.0.0.1:783: Address already in use
Jun 10 02:58:51.410 [8305] warn: server socket setup failed, retry 3: spamd: 
could not create INET socket on 127.0.0.1:783: Address already in use
Jun 10 02:58:52.412 [8305] warn: server socket setup failed, retry 4: spamd: 
could not create INET socket on 127.0.0.1:783: Address already in use
Jun 10 02:58:53.414 [8305] warn: server socket setup failed, retry 5: spamd: 
could not create INET socket on 127.0.0.1:783: Address already in use
Jun 10 02:58:54.416 [8305] warn: server socket setup failed, retry 6: spamd: 
could not create INET socket on 127.0.0.1:783: Address already in use
Jun 10 02:58:55.418 [8305] warn: server socket setup failed, retry 7: spamd: 
could not create INET socket on 127.0.0.1:783: Address already in use
Jun 10 02:58:56.420 [8305] warn: server socket setup failed, retry 8: spamd: 
could not create INET socket on 127.0.0.1:783: Address already in use
Jun 10 02:58:57.422 [8305] warn: server socket setup failed, retry 9: spamd: 
could not create INET socket on 127.0.0.1:783: Address already in use
Jun 10 02:58:58.424 [8305] error: spamd: could not create INET socket on 
127.0.0.1:783: Address already in use
spamd: could not create INET socket on 127.0.0.1:783: Address already in use

I was wondering which process was the cause (spamd isn't running), and
I saw:

root  7796  4117  0 02:52 ?00:00:00 /bin/sh 
/etc/cron.daily/spamassassin

Something is apparently broken with it.

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

Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages spamassassin depends on:
pn  libarchive-tar-perl(no description available)
ii  libdigest-sha1-perl 2.13-1+b1NIST SHA-1 message digest algorith
ii  libhtml-parser-perl 3.68-1+b1collection of modules that parse H
ii  libnet-dns-perl 0.66-2+b1Perform DNS queries from a Perl sc
ii  libnetaddr-ip-perl  4.044+dfsg-1 IP address manipulation module
ii  libsocket6-perl 0.23-1+b1Perl extensions for IPv6
ii  libsys-hostname-long-perl   1.4-2Figure out the long (fully-qualifi
ii  libwww-perl 6.02-1   simple and consistent interface to
ii  perl5.12.3-7 Larry Wall's Practical Extraction 
ii  perl-modules [libio-zlib-pe 5.12.3-7 Core Perl modules

Versions of packages spamassassin recommends:
ii  gcc   4:4.6.0-5  The GNU C compiler
ii  gnupg 1.4.11-3   GNU privacy guard - a free PGP rep
ii  libc6-dev 2.13-6 Embedded GNU C Library: Developmen
ii  libio-socket-inet6-perl   2.65-1.1   Object interface for AF_INET6 doma
ii  libmail-spf-perl  2.007-1Perl implementation of Sender Poli
ii  make  3.81-8.1   An utility for Directing compilati
ii  perl [libsys-syslog-perl] 5.12.3-7   Larry Wall's Practical Extraction 
ii  re2c  0.13.5-1   tool for generating fast C-based r
ii  spamc 3.3.1-2Client for SpamAssassin spam filte

Versions of packages spamassassin suggests:
pn  libdbi-perl(no description available)
ii  libio-compress-perl [libcompr 2.035-1bundle of IO::Compress modules
ii  libio-socket-ssl-perl 1.43-1 Perl module implementing object or
pn  libmail-dkim-perl  (no description available)
pn  libnet-ident-perl  (no description available)
ii  perl [libcompress-zlib-perl]  5.12.3-7   Larry Wall's Practical Extraction 
pn  pyzor  (no description available)
pn  razor  (no description available)

-- Configuration Files:
/etc/default/spamassassin changed:
ENABLED=1
OPTIONS="--create-prefs --max-children 5 --helper-home-dir"
PIDFILE="/var/run/spamd.pid"
NICE="--nicelevel 10"
CRON=1

Bug#629983: libc6 install aborts with "A non-dpkg owned copy of the C library was found in /lib."

[sacrificial-spam-address]

Package: libc6
Version: 2.13-6

My poor confused brain thinks "the C library" is libc-2.13.so which is NOT
in /lib (it's in /lib/i386-linux-gnu/ and /lib/i386-linux-gnu/i686/cmov/)
so the error message is not terribly useful.

The check can't be found in /var/lib/dpkg/info/libc6.preinst (from -5),
so that doesn't tell me what's going on.

I look around and find bug #629534 which looks like the issue is with
ld.so.  Looking at my system, I do indeed have an ancient /lib/ld.so
(6 March 2001) so I start a statically linked shell (for safety) and
move it to ld.so.old.

And retry the installation of the package.  Which still fails, with
the same error message.

Finally, after a few attempts, I manage to stop the dpkg while
/var/lib/dpkg/tmp.ci/preinst exists and read *that*.  It shows me that the
pattern searched for is /lib/ld*.so*, so my adding a .old suffix doesn't
work.

Now, I really shouldn't have to go to this much trouble to understand
a freaking error message.  The offending file name is readily available in $i.
How about printing THAT rather than referring vaguely to "the C library".

Thank you!



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

Bug#629867: krb5: Please enable DNS realm lookups in configure

[Alexander Wuerstlein]

On 11-06-09 20:16, Sam Hartman  wrote:
> Hi.
> 
> Current KDCs actually support a better option than DNS-based referrals.
> A KDC can issue a referral indicating what realm a host lives in.  The
> MIT and microsoft KDCs definitely support this.  I believe this was
> added to MIt in 1.8 or possible 1.7; Microsoft has always had it.
> 
> The client support has been there since 1.6 or earlier.
> 
> Is the DNS-based solution still better in your environment?

Yes.

> If so, why?

DNS is managed by the (independent) administrator of each realm, each
new host entered there would be tagged by the responsible administrator
with the appropriate realm via a _kerberos IN TXT entry. Each host needs
to be tagged because administrative domains and Kerberos realms are not
in sync with DNS (sub)domains and delegations for a lot of reasons I
don't want to go into.

Referrals on the other hand would have to be kept in sync on all realms'
KDCs manually. Each new host would need to be entered into DNS as well
as into each KDC configuration. Since DNS subdomains are not congruent
with kerberos realms, the configuration would need to name each host
specifically and assign it to a realm. While that could be automated
with some effort, it would essentially duplicate what DNS does anyways.
At least that is what I understood from the limited documentation
available on the subject, I could very well be totally wrong and I would
appreciate any advice.

In our case the (not yet implemented) scenario would look something like
this: A number of important host-realm associations would be configured
on each KDC, so that those can be discovered via referrals. Those would
also be kept in sync as far as possible across the various realms. At
the same time, new hosts and services that are created would
automatically work since the hostname in DNS is available at the same
time as its realm association. The more secure and stable association
via the KDC config can then be added later.




Ciao,

Alexander Wuerstlein.



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

Bug#629956: "fakeroot test -w /" has an exit status of 1

[Clint Adams]

On Thu, Jun 09, 2011 at 06:22:55PM -0500, Jonathan Nieder wrote:
> Makes sense.  How about something along these lines?

I'm comitting this, though I worry about the side effects of
access() returning true and then the process not being able
to access the file.



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

Bug#629978: r-base-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Dirk Eddelbuettel]

Salut Bill,

On 9 June 2011 at 23:59, Bill Allombert wrote:
| Package: r-base-dev
| Version: 2.13.0-2
| Severity: important
| 
| Hello Dirk,
| 
| There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
| As mentionned on debian-devel-announce[1], please update r-base-dev to
| Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.
| 
| The following Depends was found:
| 
| r-base-dev:Depends: libjpeg62-dev 

Done in r-base_2.13.0-3.

Thanks for the heads-up!

Dirk
 
| (Please also check the Build-Depends)
| 
| [1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html
| 
| Cheers,
| -- 
| Bill. 
| 
| Imagine a large red swirl here. 
| 
| 

-- 
Gauss once played himself in a zero-sum game and won $50.
  -- #11 at http://www.gaussfacts.com



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

Bug#629982: render_barcode_qrcode extension

[Clint Adams]

Package: inkscape
Version: 0.47.0-2

Please include the render_barcode_qrcode extension.

http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head:/share/extensions/



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

Bug#629967: libgs-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Jonas Smedegaard]

On 11-06-09 at 11:51pm, Bill Allombert wrote:
> There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
> As mentionned on debian-devel-announce[1], please update libgs-dev to
> Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

Ok.  Will have a look at that immediately.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Bug#621854: fixed in upstream xorg 1.9rc5/1.8.99.905

[Alex]

via patch Revert "dix: use the event mask of the grab for TryClientEvents."

http://cgit.freedesktop.org/xorg/xserver/patch/?id=1884db430a5680e37e94726dff46686e2218d525
http://lists.freedesktop.org/archives/xorg-announce/2010-July/001354.html

grabbutton would cause the input mask to be incorrectly applied.  this
is no longer an issue on my testing instance (xorg 1.10), but has now
cropped up on an old-stable -> stable upgrade (xorg 1.*mumble* -> 1.7)



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

Bug#629956: "fakeroot test -w /" has an exit status of 1

[Jonathan Nieder]

Clint Adams wrote:
> On Thu, Jun 09, 2011 at 04:32:48PM -0500, Jonathan Nieder wrote:

>> I can reproduce it with /usr/bin/test from coreutils 8.5-1 or $sh -c
>> 'test -w /' for various shells such as posh 0.10.  All use access(2)
>> as far as I can tell.
>> 
>> Known problem?
>
> Neither access() nor euidaccess() is wrapped.

Makes sense.  How about something along these lines?

Seems to work for "posh -c 'test -w /'", but since this doesn't wrap
euidaccess() or faccessat(), it's not enough yet for bash, dash, and
coreutils test.
---
 libfakeroot.c |   87 +
 wrapfunc.inp  |1 +
 2 files changed, 88 insertions(+), 0 deletions(-)

diff --git a/libfakeroot.c b/libfakeroot.c
index ddde1cf..d6cd757 100644
--- a/libfakeroot.c
+++ b/libfakeroot.c
@@ -94,6 +94,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef HAVE_SYS_ACL_H
 #include 
 #endif /* HAVE_SYS_ACL_H */
@@ -101,6 +102,11 @@
 #include 
 #endif /* HAVE_FTS_H */
 
+/* ST_NOEXEC is a glibc extension */
+#ifndef ST_NOEXEC
+#define ST_NOEXEC 0
+#endif
+
 #if !HAVE_DECL_SETENV
 extern int setenv (const char *name, const char *value, int replace);
 #endif
@@ -1494,6 +1500,87 @@ int setgroups(SETGROUPS_SIZE_TYPE size, const gid_t 
*list){
 return 0;
 }
 
+int access(const char *path, int amode) {
+  INT_STRUCT_STAT st;
+  struct statvfs fs_st;
+  uid_t uid;
+  gid_t gid;
+  int r;
+
+  /*
+Missing pieces:
+- should run path lookup with permissions of (uid, gid)
+- capabilities
+- POSIX acls
+- restricting write permission to an immutable file
+   */
+
+#ifdef LIBFAKEROOT_DEBUGGING
+  if (fakeroot_debug) {
+fprintf(stderr, "access path %s\n", path);
+  }
+#endif /* LIBFAKEROOT_DEBUGGING */
+  if (fakeroot_disabled || amode == F_OK)
+return next_access(path, amode);
+
+  if (amode & ~(R_OK | W_OK | X_OK)) {
+errno = EINVAL;
+return -1;
+  }
+
+  r = INT_NEXT_STAT(path, &st);
+  if (r)
+return r;
+
+  /* Read-only or noexec filesystem? */
+  if (amode & (W_OK | X_OK)) {
+r = statvfs(path, &fs_st);
+if (!r && (amode & W_OK) && (fs_st.f_flag & ST_RDONLY)) {
+  errno = EROFS;
+  return -1;
+}
+if (!r && (amode & X_OK) && (fs_st.f_flag & ST_NOEXEC)) {
+  errno = EACCES;
+  return -1;
+}
+if (r && errno != ENOSYS)
+  return -1;
+  }
+
+  uid = get_faked_uid();
+  gid = get_faked_gid();
+
+  if (uid == st.st_uid) {
+if (!((amode & R_OK) && !(st.st_mode & S_IRUSR)) &&
+!((amode & W_OK) && !(st.st_mode & S_IWUSR)) &&
+!((amode & X_OK) && !(st.st_mode & S_IXUSR)))
+  return 0;
+  } else if (gid == st.st_gid) {
+if (!((amode & R_OK) && !(st.st_mode & S_IRGRP)) &&
+!((amode & W_OK) && !(st.st_mode & S_IWGRP)) &&
+!((amode & X_OK) && !(st.st_mode & S_IXGRP)))
+  return 0;
+  } else {
+if (!((amode & R_OK) && !(st.st_mode & S_IROTH)) &&
+!((amode & W_OK) && !(st.st_mode & S_IWOTH)) &&
+!((amode & X_OK) && !(st.st_mode & S_IXOTH)))
+  return 0;
+  }
+
+  if ((amode & X_OK) && !S_ISDIR(st.st_mode) &&
+  !(st.st_mode & (S_IXUSR | S_IXGRP | S_IXOTH))) {
+errno = EACCES;
+return -1;
+  }
+
+  /* root gets CAP_DAC_OVERRIDE */
+  if (uid == 0)
+return 0;
+
+  errno = EACCES;
+  return -1;
+}
+
 int fakeroot_disable(int new)
 {
   int old = fakeroot_disabled;
diff --git a/wrapfunc.inp b/wrapfunc.inp
index dd3884e..fb9ab90 100644
--- a/wrapfunc.inp
+++ b/wrapfunc.inp
@@ -124,6 +124,7 @@ setfsgid;gid_t;(gid_t fsgid);(fsgid)
 #endif /* HAVE_SETFSGID */
 initgroups;int;(const char *user, INITGROUPS_SECOND_ARG group);(user, group)
 setgroups;int;(SETGROUPS_SIZE_TYPE size, const gid_t *list);(size, list)
+access;int;(const char *pathname, int mode);(pathname, mode)
 
 #ifdef HAVE_FSTATAT
 #ifdef HAVE_FCHMODAT
-- 
1.7.6.rc1




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

Bug#629981: ITP: libcourriel-perl -- high level email parsing and manipulation module

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcourriel-perl
  Version : 0.12
  Upstream Author : Dave Rolsky 
* URL : http://search.cpan.org/dist/Courriel/
* License : Artistic-2.0
  Programming Lang: Perl
  Description : high level email parsing and manipulation module

The Courriel class exists to provide a high level API for working with
emails, particular for processing incoming email. It is primarily a wrapper
around the other classes in the Courriel distro, especially
Courriel::Headers, Courriel::Part::Single, and Courriel::Part::Multipart. If
you need lower level information about an email, it should be available from
one of this classes.

This software is still very alpha, and the API may change without warning in
future versions.



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

Bug#629980: Subject: open-vm-source: module-assistant build failures on 2.6.39-2 kernel build system

[Bobby]

Package: open-vm-source
Version: 1:8.4.2-261024-1
Justification: fails to build from source
Severity: serious

# module-assistant auto-install open-vm -i
.
Updated infos about 1 packages
Getting source for kernel version: 2.6.39-2-amd64
Kernel headers available in /lib/modules/2.6.39-2-amd64/build
Creating symlink...
apt-get -y install build-essential
Reading package lists... Done
Building dependency tree
Reading state information... Done
build-essential is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Done!
unpack
Extracting the package tarball, /usr/src/open-vm.tar.bz2, please wait...
"/usr/share/modass/overrides/open-vm-source" build KVERS=2.6.39-2-amd64
KSRC=/lib/modules/2.6.39-2-amd64/build KDREV=2.6.39-2 kdist_image
QUILT_PATCHES=debian/patches \
quilt --quiltrc /dev/null pop -a -R || test $? = 2
No patch removed
rm -rf .pc debian/stamp-patched
dh_testdir
dh_testroot
rm -f build-stamp
rm -f config/config.guess config/config.sub
# Cleaning package
[ ! -f Makefile ] || /usr/bin/make distclean
make[1]: Entering directory `/usr/src/modules/open-vm'
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C 
modules/linux/pvscsi

clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/pvscsi'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/pvscsi'
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C 
modules/linux/vmblock

clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmblock'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmblock'
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmci
clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmci'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmci'
rm -f modules/linux/vmhgfs/Module.symvers
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C 
modules/linux/vmhgfs

clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmhgfs'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmhgfs'
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C 
modules/linux/vmmemctl

clean
Using 2.6.x kernel build system.
make[2]: Entering directory 
`/usr/src/modules/open-vm/modules/linux/vmmemctl'

rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmmemctl'
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C 
modules/linux/vmsync

clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmsync'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmsync'
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C 
modules/linux/vmxnet

clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmxnet'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmxnet'
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C 
modules/linux/vmxnet3

clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmxnet3'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmxnet3'
rm -f modules/linux/vsock/Module.symvers
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vsock
clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vsock'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vsock'
make[1]: Leaving directory `/usr/src/modules/open-vm'
dh_clean
/usr/bin/make KERNELDIR=/lib/modules/2.6.39-2-amd64/build clean
make[1]: Entering directory `/usr/src/modules/open-vm'
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C 
modules/linux/pvscsi

clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/pvscsi'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/pvscsi'
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C 
modules/linux/vmblock

clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmblock'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmblock'
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmci
clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmci'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmci'
rm -f modules/linux/vmhgfs/Module.symvers
/usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C 
modules/linux/vmhgfs

clean
Using 2.6.x kernel build system.
make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmhgfs'
rm -rf
make[2]: Leaving directory `/usr/src/modules/open-vm/mod

Bug#629899: apache2: apr_sockaddr_info_get() failed / Could not reliably determine the server's FQDN

[Massimo Manghi]

On Thu, 9 Jun 2011 19:27:23 +0200, Vincent Lefevre wrote:

On 2011-06-09 16:09:29 +0100, Massimo Manghi wrote:

On Thu, 9 Jun 2011 16:40:07 +0200, Vincent Lefevre wrote:
>On 2011-06-09 15:20:00 +0100, Massimo Manghi wrote:
>>It's probably so, because I don't see why apache2 is getting it 
right

>>after the boot is over and you have gained access to the shell.
>>That's why I thought you were using dhcp at first.
>
>Yes, I confirm a possible problem with a recent libc or kernel at
>boot time, but this isn't related to DHCP.

I have no doubt: this has nothing to do with DHCP per se. DHCP was
useful to understand that gethostname (or uname) is not working
properly.


Actually I don't think this is the same bug. I cannot reproduce
this bug 629899 concerning apache2, while the bug with wwwoffle
has occurred every time since I upgraded to libc6 2.13.


OK. Wasn't this bug filed against apache2.2-common? Anyway I expect
every application based on apr calling apr_sockaddr_info_get to fail
with a similar reason.




>and with the kernel 2.6.39-1:
>
>Sun Jun  5 22:50:14 2011: Starting HTTP cache proxy server: 
wwwoffled
>wwwoffled[5199] Warning: Failed to get name/IP address for host 
'xvii'

>[No address associated with hostname].
>Sun Jun  5 22:50:14 2011: (offline mode) done.


After I looked in the logs, I got this actually for the first time
after I upgraded to libc6 2.13.





I've reported the wwwoffle problem against wwwoffle because apache2
on the same machine doesn't have any problem:

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

wwwoffle may do something special, and the maintainer could reassign
the bug to libc6 (with a testcase) if it appears that the problem
comes from libc6.

I suggest that you report a bug for the problem you get. If you can
reproduce it, you'll have at least more information than me...


I would file it against libc6 because my conjecture is that different
components layered on libc6 are failing when they probably call 
something

like uname or gethostname.

I cannot image what apr_* and  tcsh have in common except for libc6 
when

they are unable to determine the correct hostname.
Anyway, the bug seems not to be reproducible, not in a deterministic
way at least: tonight I booted my home machine and the hostname was 
displayed

correctly. I'll keep an eye on it to see if it shows up again.

 -- Massimo




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

Bug#629956: "fakeroot test -w /" has an exit status of 1

[Clint Adams]

On Thu, Jun 09, 2011 at 04:32:48PM -0500, Jonathan Nieder wrote:
> I can reproduce it with /usr/bin/test from coreutils 8.5-1 or $sh -c
> 'test -w /' for various shells such as posh 0.10.  All use access(2)
> as far as I can tell.
> 
> Known problem?

Neither access() nor euidaccess() is wrapped.



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

Bug#629643: [Pkg-haskell-maintainers] Bug#629643: gitit: File upload bug in upstream version 0.8

[Giovanni Mascellani]

Hi Florian.

On 08/06/2011 13:39, Florian Baumann wrote:
> In the actual packaged version a bug appears by uploading files.
> You are not able to upload _any_ file to the wiki. 
> 
> Error Message from Happstack (see gitit-discuss group:
> http://groups.google.com/group/gitit-discuss/browse_thread/thread/cd673a0ea4d36093/58c9a257deee8826?hl=en#58c9a257deee8826
>  )
> 
> Server error: examplefile.txt: canonicalizePath: does not exist (No
> such file or directory) 
> 
> Bug is already fixed in upstream version 0.8.1 and 
> needs to be in debian package.

Thanks for the report. I noticed that too. Anyway I think it's better to
wait for an upload in order not to add more difficulty to the ongoing
ghc transition to testing.

In the meantime, if you want, you can find the package at:

http://poisson.phc.unipi.it/~mascellani/unstable/

Giovanni.
-- 
Giovanni Mascellani 
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org



signature.asc
Description: OpenPGP digital signature

Bug#629917: code generated for python modules fails to compile with gcc 4.6

[Torsten Landschoff]

Hi Sebastian,

On 06/09/2011 06:10 PM, Sebastian Ramacher wrote:

The code generated for python modules fails to compile with gcc 4.6. This is
due to a missing "#include". Upstream fixed this issue in [1].

Some packages FTBFS because of this (see #624982 and #625087 for example).

[1] 
http://swig.svn.sourceforge.net/viewvc/swig/trunk/Lib/std/std_common.i?r1=10424&r2=12547
Could you please try if the build works when using the swig2.0 package? 
The upstream fix as of r12547 should be included in the 2.0.4 release, 
which is the current swig2.0 version in unstable.


Greetings, Torsten




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

Bug#628641: linux-image-2.6.32-5-686: crashes when closing laptop lid (dell inspiron 300m)

[Thibault Manlay]

Hello,


I just noticed a similar issue, maybe related to this bug, on my Dell
Studio 1555.

I'm using debian/testing.

When I close and then open the lid:
- On X: the screen just shows a piece of garbled pixels whose some of
them are blinking;
- On a TTY: the console seem to go back in history (the farthest it can
I suppose).

In both cases the system does not respond and the only thing to do is to
manually turn off the laptop.

This happens on the kernel 2.6.38-5 (linux-image-2.6.38-2-686-bigmem)
and it reproducible everytime.

This happens also on the kernel 2.6.39-2 (linux-image-2.6.39-2-686-pae)
from unstable

I also have a kernel that I kept from squeeze
(linux-image-2.6.32-5-686-bigmem 2.6.32-34squeeze1) on which I cannot
reproduce the bug. It looks like it is a regression somewhere between
versions 2.6.32 and 2.6.38.

I have found a workaround to this issue: using "nolapic" in the kernel
boot options make the issue disappear. I don't know if it breaks
something else (suspend/hibernate) but I will check this later.

This is very curious because I have used 2.6.38 for a while now, and the
issue appeared today. I hadn't performed any upgrade on my laptop for
about a month.


-- 
Thibault Manlay




signature.asc
Description: OpenPGP digital signature

Bug#577785: Use debian/.poms

[Ludovic Claude]

This file is used to specify the locations of the POM files and can also
contain various options for each POM files listed there.

So your lib-java.poms file will contain:

path/to/pom.xml --java-lib --usj-name=mylibrary2

and debian/rules will contain

install/lib$(PACKAGE)-java::
mh_install

clean::
mh_clean

That's easy, isn't it?

Ludovic





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

Bug#629871: missing man pages for ecasound-iam, ecatools, ecalength

[Joel Roth]

On Thu, Jun 09, 2011 at 10:21:20AM +0200, Alessandro Ghedini wrote:
> On Wed, Jun 08, 2011 at 04:34:42PM -1000, Joel Roth wrote:
> > No result for 'man' command.  
> > 
> > According to http://packages.debian.org/sid/amd64/ecasound/filelist
> > 
> > There should be man pages in /usr/share/man/man1/
> > 
> > However removing and reinstalling the package, the man files
> > are not present.
> 
> Please note that the ecatools (as well as their manpages) have been moved 
> to the 'ecatools' package since version 2.8.0-1, to avoid a circular
> dependency between ecasound and python-ecasound.

>   $ dpkg -L ecatools | grep man1
>   /usr/share/man/man1/ecalength.1.gz
>   /usr/share/man/man1/ecatools.1.gz
>   /usr/share/man/man1/ecasound-iam.1.gz
>   /usr/share/man/man1/ecasignalview.1.gz
>   /usr/share/man/man1/ecanormalize.1.gz
>   /usr/share/man/man1/ecamonitor.1.gz
>   /usr/share/man/man1/ecafixdc.1.gz
>   /usr/share/man/man1/ecaplay.1.gz
>   /usr/share/man/man1/ecaconvert.1.gz

That's all good, however the man page for ecasound-iam,
which is necessary to use ecasound interactively, is 
in ecatools.  I think it should be moved to ecasound. 

Finally, someone trying out ecasound may be expecting the
docs and ecatools utilities. These packages are relatively
small. Could they be recommended (so they are pulled in
automatically)?  IMO they should be suggested, at least.
 
> Also, the file list on packages.d.o is quite outdated :)

Good to know, also about dpkg -L.

Thanks again for what has turned out to be a rather complex
packaging job!
 
> Cheers
> 
> -- 
> perl -E'$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'

-- 
Joel Roth

-- 
Joel Roth



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

Bug#604397: Request for TC to rule on a course of action for supporting build-arch

[Russ Allbery]

Bill Allombert  writes:

> I have proposed an alternative in the past (which did not get any
> support, though):  Decide that packages that have a Build-Depends-Indep:
> field must implement build-arch/build-indep. This is probably already
> the case.

> This has the same advantage than Build-Options: a program can check if
> dpkg-buildpackage will call build-arch just by looking at the control
> file.

This is a hack, though, that relies on the assumption that any package
with separate build-arch and build-indep targets will have additional
dependencies for build-indep.  This is not necessarily true.  For example,
building architecture-independent bearoff databases for GnuBG doesn't
require any additional packages.

> There should be a well-defined interface to know whether
> dpkg-buildpackage will call build-arch or build, that does not depend on
> a specific dpkg-buildpackage implementation.

I don't agree with this statement in the long run.  I don't see any reason
not to have a goal of having dpkg-buildpackage call build-arch
unconditionally.  The most maintainable, most easily testable, and least
complex way to implement an option in a software system is to not make it
an option.

My goal is to allow everyone developing for Debian three years from now to
not care that this debate ever happened.

> Concerning the long-term complexity: If you look at the bug log, you
> will see that developpers objected that the build-arch/build-indep split
> was unnecessary complexity for packages that would not get any benefit
> of it, so Build-Options was proposed which allowed the split to be
> optional (so only packages that get some benefit of it would have to
> implement it).

I think that the dh program and its widespread adoption has mostly made
that objection obsolete.  For those who are still listing separate targets
in debian/rules, making build-arch and build-indep just depend on build is
not generally difficult.

> (PS: I am unsure how this bug fit the purpose of the TC. There is only
> one alternative that have been implemented or even drafted at this
> stage.)

The TC is currently considering four different options, all of which are
either already implemented or fairly easy to implement in a short time
frame.  I don't think all the options have to be at the point of being
appliable patches before the TC can consider something.

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



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

Bug#629979: ITP: soap4r-ruby1.9.1 -- soap4r for ruby1.9

[Thomas Mueller]

Package: wnpp
Severity: wishlist
Owner: Thomas Mueller 


* Package name: soap4r-ruby1.9.1
  Version : 1.0.0
  Upstream Author : Hiroshi Nakamura  and many more
* URL : https://rubygems.org/gems/soap4r-ruby1.9
* License : GPL
  Programming Lang: Ruby
  Description : 

soap4r was part of ruby1.8, but removed from ruby1.9 because it is not 
compatible. 
We need soap4r for the debian tool apt-listbugs, which we'd like to migrate 
to ruby1.9.



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

Bug#604397: Request for TC to rule on a course of action for supporting build-arch

[Bill Allombert]

On Mon, Jun 06, 2011 at 01:04:59PM -0700, Russ Allbery wrote:
> Andreas Barth  writes:
> 
> > Option 1 also implies forcing debian/rules to be a Makefile, which is
> > think is sensible.
> 
> Policy already requires this.  The only package in the archive for which
> this is not already the case is "leave".
> 
> I don't like option #3 because it's something we'll be stuck with forever
> and requires packagers update both debian/rules and debian/control to
> configure things properly.  One of the reasons why I'm personally fond of
> #4 is that it reduces our long-term complexity.  #3 increases our
> long-term complexity, I think unnecessarily.

I have proposed an alternative in the past (which did not get any support, 
though):
Decide that packages that have a Build-Depends-Indep: field must implement
build-arch/build-indep. This is probably already the case.

This has the same advantage than Build-Options: a program can check if 
dpkg-buildpackage
will call build-arch just by looking at the control file.

There should be a well-defined interface to know whether dpkg-buildpackage will
call build-arch or build, that does not depend on a specific dpkg-buildpackage 
implementation. I am afraid that any makefile trickery would not be stable 
enough
for that purpose.

Concerning the long-term complexity: If you look at the bug log, you will see
that developpers objected that the build-arch/build-indep split was unnecessary
complexity for packages that would not get any benefit of it, so Build-Options 
was
proposed which allowed the split to be optional (so only packages that get some
benefit of it would have to implement it).

(PS: I am unsure how this bug fit the purpose of the TC. There is only one
alternative that have been implemented or even drafted at this stage.)

Cheers,
-- 
Bill. 

Imagine a large red swirl here.



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

Bug#628084: cdebconf: tasksel debconf does not start in d-i

[Regis Boudin]

Hi Samuel,

I believe the issue should have been fixed in git, now, thanks for
pointing to the additional bug, it helped find another similar one.

Could you check if tasksel works again with a new snapshot, to confirm
the problem is actually gone ?

Thanks,
Regis

On Fri, 2011-05-27 at 03:02 +0200, Samuel Thibault wrote:
> Package: cdebconf
> Version: 0.156~0
> Severity: important
> 
> Hello,
> 
> I've built the current git version of cdebconf and built d-i CDs, it
> seems the latest changes make tasksel's debconf not start: with 0.155,
> it does start, but with 0.156~0 pkgsel calls tasksel, tasksel starts its
> backend, which does the db_* calls, db_input and db_go, but no question
> appears at all and the return value is empty, and thus tasksel doesn't
> install anything.
> 
> Most changes in 0.156~0 are not in the udeb, except the "Implement
> handling of multiple flags in the rfc822db backend." change, maybe there
> is a small typo or something like this there. At least one difference I
> can see is that when there is no flag, "Flags:\n" is output instead of
> "Flags: \n", but maybe the bug is hiding in parse_flags too: there are a
> few odd things: 
> 
> if (!string)
> return;
> 
> Doesn't the compiler warn that a return value should be specified? It
> should be 0 here, and that might be exactly the case where tasksel
> loses, because the tasksel/first template is not preloaded, it is loaded
> by hand by the tasksel debconf backend.
> 
> Also, 
> 
> while (*wc == ' ' || *wc == '\t' || *wc == '\0')
> {
> wc++;
> }
> 
> if the string is "Flags: foo " with a trailing space, the loop will not
> stop. wc should probably be set to delim+1 (finished not being 1 assures
> us that *delim was not \0) and drop *wc == 0 from the while loop above.
> 
> Samuel
> 
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.39 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages cdebconf depends on:
> ii  debconf1.5.39Debian configuration management 
> sy
> ii  libc6  2.13-4Embedded GNU C Library: Shared 
> lib
> ii  libdebian-installer4   0.77+squeeze2 Library of common 
> debian-installer
> ii  libnewt0.520.52.11-2 Not Erik's Windowing Toolkit - 
> tex
> ii  libslang2  2.2.4-2   S-Lang programming library - 
> runti
> ii  libtextwrap1   0.1-11text-wrapping library with i18n 
> - 
> 
> cdebconf recommends no packages.
> 
> Versions of packages cdebconf suggests:
> pn  cdebconf-gtk   (no description available)
> 
> -- 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#547393: libjpeg8 transition.

[Bill Allombert]

On Thu, Jun 09, 2011 at 11:43:40PM +0200, Julien Cristau wrote:
> On Thu, Jun  9, 2011 at 23:13:03 +0200, Bill Allombert wrote:
> 
> > Given the large legacy of libjpeg62, it is probably safer to keep it.
> > Also having libjpeg62-dev an alias for libjpeg8-dev is going to be
> > confusing. I will report bug to packages that Depends on libjpeg62-dev
> > as a first step.
> > 
> Alright, thank you.

Done, 18 bugs reported, #629960 to #629978 minus #629971.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629978: r-base-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: r-base-dev
Version: 2.13.0-2
Severity: important

Hello Dirk,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update r-base-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

r-base-dev  :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629977: pslib-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: pslib-dev
Version: 0.4.3-1+b1
Severity: important

Hello Uwe,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update pslib-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

pslib-dev   :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629976: libvncserver-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libvncserver-dev
Version: 0.9.7-2+b1
Severity: important

Hello Debian QA Group,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libvncserver-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libvncserver-dev:Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629975: libspandsp-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libspandsp-dev
Version: 0.0.6~pre12-1
Severity: important

Hello Debian VoIP Team,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libspandsp-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libspandsp-dev  :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629974: libsimage-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libsimage-dev
Version: 1.7.0-1+b1
Severity: important

Hello Debian Science Team,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libsimage-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libsimage-dev   :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629973: libopenvrml-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libopenvrml-dev
Version: 0.18.8-3
Severity: important

Hello Sam,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libopenvrml-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libopenvrml-dev :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629971: X server segfault after launching isag

[Dominique Brazziel]

Package: isag
Version: 10.0.0-1
Severity: normal

As soon as I run isag from the gnome 'System Tools' menu the
X server crashes with a segfault and after a bit the gdm login screen
appears.  I am attaching the X server log which contains a small
backtrace.  I will see if I can run from gnome-terminal and
maybe get some more debugging info by altering the script.

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

Kernel: Linux 2.6.38-interactive-3-atom (SMP w/2 CPU cores; PREEMPT)
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 isag depends on:
ii  gnuplot-x11 4.4.0-1.1+b1 A command-line driven interactive 
ii  sysstat 10.0.0-1 system performance tools for Linux
ii  tk8.4 [wish]8.4.19-4 Tk toolkit for Tcl and X11, v8.4 -
ii  tk8.5 [wish]8.5.9-2  Tk toolkit for Tcl and X11, v8.5 -

isag recommends no packages.

Versions of packages isag suggests:
pn  rcs(no description available)

-- no debconf information
[   928.813] 
X.Org X Server 1.10.1
Release Date: 2011-04-15
[   928.813] X Protocol Version 11, Revision 0
[   928.813] Build Operating System: Linux 2.6.32-5-686-bigmem i686 Debian
[   928.813] Current Operating System: Linux asusb202 2.6.38-interactive-3-atom 
#2 SMP PREEMPT Mon May 9 11:20:24 EDT 2011 i686
[   928.813] Kernel command line: 
BOOT_IMAGE=/boot/vmlinuz-2.6.38-interactive-3-atom 
root=UUID=34d845d6-948f-4571-b2f4-79d2b869efeb ro apic=debug
[   928.814] Build Date: 01 May 2011  10:14:44AM
[   928.814] xorg-server 2:1.10.1-2 (Julien Cristau ) 
[   928.814] Current version of pixman: 0.21.8
[   928.814]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   928.814] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   928.814] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jun  9 17:31:44 
2011
[   928.815] (==) Using config file: "/etc/X11/xorg.conf"
[   928.815] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   928.816] (==) No Layout section.  Using the first Screen section.
[   928.816] (**) |-->Screen "Default Screen" (0)
[   928.816] (**) |   |-->Monitor "Configured Monitor"
[   928.816] (==) No device specified for screen "Default Screen".
Using the first device section listed.
[   928.816] (**) |   |-->Device "Configured Video Device"
[   928.816] (==) Automatically adding devices
[   928.816] (==) Automatically enabling devices
[   928.818] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   928.818]Entry deleted from font path.
[   928.818] (**) FontPath set to:
unix/:7100,
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
[   928.818] (==) ModulePath set to "/usr/lib/xorg/modules"
[   928.818] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   928.818] (II) Loader magic: 0x8232ac0
[   928.818] (II) Module ABI versions:
[   928.818]X.Org ANSI C Emulation: 0.4
[   928.819]X.Org Video Driver: 10.0
[   928.819]X.Org XInput driver : 12.2
[   928.819]X.Org Server Extension : 5.0
[   928.821] (--) PCI:*(0:0:2:0) 8086:27ae:1043:1252 rev 3, Mem @ 
0xfeb8/524288, 0xd000/268435456, 0xfeb4/262144, I/O @ 0xec80/8
[   928.821] (--) PCI: (0:0:2:1) 8086:27a6:1043:1252 rev 3, Mem @ 
0xfea8/524288
[   928.821] (II) Open ACPI successful (/var/run/acpid.socket)
[   928.821] (II) LoadModule: "extmod"
[   928.823] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[   928.824] (II) Module extmod: vendor="X.Org Foundation"
[   928.825]compiled for 1.10.1, module version = 1.0.0
[   928.825]Module class: X.Org Server Extension
[   928.825]ABI class: X.Org Server Extension, version 5.0
[   928.825] (II) Loading extension SELinux
[   928.825] (II) Loading extension MIT-SCREEN-SAVER
[   928.825] (II) Loading extension XFree86-VidModeExtension
[   928.825] (II) Loading extension XFree86-DGA
[   928.825] (II) Loading extension DPMS
[   928.825] (II) Loading extension XVideo
[   928.825] (II) Loading extension XVideo-MotionCompensation
[   928.825] (II) Loading extension X-Resource
[   928.825] (II) LoadModule: "dbe"
[   928.826] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[   928.826] (II) Module d

Bug#629972: libmatchbox-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libmatchbox-dev
Version: 1.9-7
Severity: important

Hello Moray,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libmatchbox-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libmatchbox-dev :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629970: libmapnik-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libmapnik-dev
Version: 0.7.1-5
Severity: important

Hello Debian GIS Project,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libmapnik-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libmapnik-dev   :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629969: libhdf5-lam-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libhdf5-lam-dev
Version: 1.8.4-patch1-2
Severity: important

Hello Debian GIS Project,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libhdf5-lam-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libhdf5-lam-dev :Depends: libjpeg62-dev 
libhdf5-mpich-dev   :Depends: libjpeg62-dev 
libhdf5-openmpi-dev :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629968: libhdf4-alt-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libhdf4-alt-dev
Version: 4.2r4-11
Severity: important

Hello Debian GIS Project,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libhdf4-alt-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libhdf4-alt-dev :Depends: libjpeg62-dev 
libhdf4-dev :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629967: libgs-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libgs-dev
Version: 9.02~dfsg-2
Severity: important

Hello Debian Printing Team,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libgs-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libgs-dev   :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629966: libgraphicsmagick1-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libgraphicsmagick1-dev
Version: 1.3.12-1+b2
Severity: important

Hello Daniel,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libgraphicsmagick1-dev 
to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libgraphicsmagick1-dev  :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629965: libgdchart-gd2-noxpm-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libgdchart-gd2-noxpm-dev
Version: 0.11.5-7
Severity: important

Hello Jonas,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update 
libgdchart-gd2-noxpm-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libgdchart-gd2-noxpm-dev:Depends: libjpeg62-dev 
libgdchart-gd2-xpm-dev  :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629964: libgdal1-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libgdal1-dev
Version: 1.7.3-4
Severity: important

Hello Debian GIS Project,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libgdal1-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libgdal1-dev:Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629963: libgd2-xpm-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libgd2-xpm-dev
Version: 2.0.36~rc1~dfsg-5.1
Severity: important

Hello GD,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libgd2-xpm-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libgd2-xpm-dev  :Depends: libjpeg62-dev 
libgd2-noxpm-dev:Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629962: libevas-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libevas-dev
Version: 1.0.0-1
Severity: important

Hello Debian Pkg-e Team,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libevas-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libevas-dev :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629961: libeet-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libeet-dev
Version: 1.4.0-2
Severity: important

Hello Debian Pkg-e Team,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libeet-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libeet-dev  :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#627101:

[Robert Keevil]

After a little more searching this looks like upstream bug 273214 (
https://bugs.kde.org/show_bug.cgi?id=273214 ).
Removing the CPU Monitor widget stops the high CPU usage for me.



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

Bug#547393: libjpeg8 transition.

[Julien Cristau]

On Thu, Jun  9, 2011 at 23:13:03 +0200, Bill Allombert wrote:

> Given the large legacy of libjpeg62, it is probably safer to keep it.
> Also having libjpeg62-dev an alias for libjpeg8-dev is going to be
> confusing. I will report bug to packages that Depends on libjpeg62-dev
> as a first step.
> 
Alright, thank you.

Cheers,
Julien



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

Bug#629960: libclaw-graphic-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libclaw-graphic-dev
Version: 1.6.1-4
Severity: important

Hello Debian Games Team,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libclaw-graphic-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libclaw-graphic-dev :Depends: libjpeg62-dev (>= 6b) 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629959: libcamlimages-ocaml-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libcamlimages-ocaml-dev
Version: 1:3.0.1-5+b5
Severity: important

Hello Debian OCaml Maintainers,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update 
libcamlimages-ocaml-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libcamlimages-ocaml-dev :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629958: libafterimage-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: libafterimage-dev
Version: 2.2.11-3
Severity: important

Hello Robert,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update libafterimage-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

libafterimage-dev   :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629957: ivtools-dev: Please Depends/Build-Depends on libjpeg-dev, not libjpeg62-dev

[Bill Allombert]

Package: ivtools-dev
Version: 1.2.8a1-4
Severity: important

Hello Barak,

There is an upcoming libjpeg transition from libjpeg62 to libjpeg8.
As mentionned on debian-devel-announce[1], please update ivtools-dev to
Depends and/or Build-Depends on libjpeg-dev instead of libjpeg62-dev.

The following Depends was found:

ivtools-dev :Depends: libjpeg62-dev 

(Please also check the Build-Depends)

[1] http://lists.debian.org/debian-devel-announce/2010/02/msg6.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#629956: "fakeroot test -w /" has an exit status of 1

[Jonathan Nieder]

Package: fakeroot
Version: 1.15.1-1

| $ fakeroot test -w /; echo $?
| 1
| $ sudo test -w /; echo $?
| 0

I would have expected the results to match.

Context: today I tried building git from source with

fakeroot debian/rules binary-arch BUILD_DOCS=0

and unfortunately a number of tests failed.  The cause is this code
fragment:

# When the tests are run as root, permission tests will report that
# things are writable when they shouldn't be.
test -w / || test_set_prereq SANITY

I can reproduce it with /usr/bin/test from coreutils 8.5-1 or $sh -c
'test -w /' for various shells such as posh 0.10.  All use access(2)
as far as I can tell.

Known problem?



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

Bug#629815: No rule to make target `/usr/lib/libdl.so'

[Andreas Tille]

On Thu, Jun 09, 2011 at 01:02:56PM +0200, Sven Joachim wrote:
> >> The problem is that libdl.so has been moved to the multiarch paths in
> >> libc6-dev 2.13-5.  You must upgrade cmake to 2.8.4+dfsg.1-3, have you
> >> done that already?
> >
> > I'm building an unstable pbuilder chroot.  It is using the cmake
> > version you are mentioning:
> >
> > $ grep cmake.2\.8 ginkgocadx_2.4.1.1-1_amd64.build 
> > Unpacking cmake (from .../cmake_2.8.4+dfsg.1-3_amd64.deb) ...
> 
> Might be worth retrying with cmake 2.8.4+dfsg.1-4, currently in
> incoming.  It has a different multiarch implementation.

$ grep cmake.2\.8 ginkgocadx_2.4.1.1-1_amd64.build
Unpacking cmake (from .../cmake_2.8.4+dfsg.1-4_amd64.deb) ...
I: new cache content cmake_2.8.4+dfsg.1-4_amd64.deb added

No change. :-((

Any further hint?

Kind regards

   Andreas.

-- 
http://fam-tille.de



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

Bug#629955: Package lirc-modules-source is not installable

[Branislav Hanáček]

Package: lirc-modules-source
Severity: important

There is no version installable with the current lirc (0.9.0~pre1-1).
There exists a varsion 0.8.3-5, but this is not installable with the
current lirc.

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

Kernel: Linux 2.6.35-zen2-20100923-1 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
sk_SK.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lirc-modules-source depends on:
ii  bzip21.0.5-6 high-quality block-sorting file co
ii  debconf [debconf-2.0]1.5.39  Debian configuration management sy
ii  debhelper8.1.6   helper programs for debian/rules
ii  debianutils  4.0.1   Miscellaneous utilities specific t
ii  module-assistant 0.11.3  tool to make module package 
creati
ii  ucf  3.0025+nmu2 Update Configuration File: preserv

lirc-modules-source recommends no packages.

Versions of packages lirc-modules-source suggests:
ii  kernel-package 12.036+nmu1   A utility for building Linux 
kerne
ii  linux-source-2.6.32 [l 2.6.32-34squeeze1 Linux kernel source for version 
2.
ii  linux-source-2.6.34.1- 1.0   Linux kernel source for version 
2.
ii  linux-source-2.6.35.4- 1.0   Linux kernel source for version 
2.
ii  linux-source-2.6.35.4- 1.0   Linux kernel source for version 
2.



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

Bug#573441: dangling symlink /usr/bin/trash4

[Sven Joachim]

Somewhat by accident, I just discovered the dangling symlink
/usr/bin/trash4 -> trash and wondered what it could have possibly been
good for.  Here's a short analysis:

Looking at commit aae2e0a2bcd3d090b in the git repository, it seems that
debian/kdebase-runtime.links has a typo and was actually meant to be a
different symlink to a different binary.  At least this way it would
have made some sense:

--8<---cut here---start->8---
diff --git a/debian/kdebase-runtime.links b/debian/kdebase-runtime.links
index d731a90..6cb2103 100644
--- a/debian/kdebase-runtime.links
+++ b/debian/kdebase-runtime.links
@@ -1,2 +1,2 @@
 #compability until we want to Break: plasma-widgets-workspace (<< 4:4.3.3), 
probably around 4:4.4 or so.
-/usr/bin/trash /usr/bin/trash4
+/usr/bin/ktrash /usr/bin/ktrash4
--8<---cut here---end--->8---

Since the right symlink was never created, and judging by the comment,
you can probably 'git rm debian/kdebase-runtime.links' instead.

Regards,
Sven



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

Bug#547393: libjpeg8 transition.

[Bill Allombert]

On Thu, Jun 09, 2011 at 10:38:37PM +0200, Julien Cristau wrote:
> Hi Bill,
> 
> sorry for the delay in getting back to you.
> 
> On Sat, Apr 30, 2011 at 16:29:17 +0200, Bill Allombert wrote:
> 
> > One issue with this transition is that a number of packages still depends 
> > on 
> > libjpeg62-dev instead of libjpeg-dev. This might cause packages to have 
> > uninstallable
> > build-dependency until they are fixed.
> > 
> I guess that depends if we need to keep building some things against
> libjpeg62.  If not, maybe libjpeg62-dev can become a dummy transitional
> package for libjpeg8-dev.  If yes, then those packages depending on
> libjpeg62-dev should have bugs filed (probably at important severity
> for now).

Given the large legacy of libjpeg62, it is probably safer to keep it.
Also having libjpeg62-dev an alias for libjpeg8-dev is going to be
confusing. I will report bug to packages that Depends on libjpeg62-dev
as a first step.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



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

Bug#560429: qtiplot: set python config folder properly

[Scott Howard]

qtiplot/qtiplot.pro

line 162

unix: pythonconfig.path = /usr/local/qtiplot

should be /usr/share/qtiplot



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

Bug#629954: Wrong path in /etc/init.d/dbus

[Rodolphe Pelloux-Prayer]

Package: dbus
Version: 1.5.2-2
Severity: grave
Tags: experimental
Justification: renders package unusable

DAEMON and UUIDGEN should be /bin/dbus-{daemon|uuidgen}

Thx
Rodolphe

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

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

Versions of packages dbus depends on:
ii  adduser  3.112+nmu2  add and remove users and groups
ii  libc62.13-5  Embedded GNU C Library: Shared lib
ii  libdbus-1-3  1.5.2-2 simple interprocess messaging syst
ii  libexpat12.0.1-7 XML parsing C library - runtime li
ii  libselinux1  2.0.98-1+b1 SELinux runtime shared libraries
ii  lsb-base 3.2-27  Linux Standard Base 3.2 init scrip

dbus recommends no packages.

Versions of packages dbus suggests:
ii  dbus-x11  1.5.2-2simple interprocess messaging syst

-- 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#629953: pu: package sun-java6/6.26-0squeeze1

[Torsten Werner]

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

Hi,

Oracle has updated the security baseline to 6.26 and that means we should update
the package in stable and oldstable. They plan to do such updates every 3 or 4
months from now on. I've prepared an updated package at
 based on Sylvestre's work for 
unstable.

Cheers,
Torsten



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

Bug#629203: nvidia-glx: gnome-shell corruption after suspend/resume

[Tony Houghton]

On Wed, 08 Jun 2011 11:07:52 +0200
Andreas Beckmann  wrote:

> On 2011-06-04 15:54, Tony Houghton wrote:
> > Package: nvidia-glx
> > Version: 275.09-1
> 
> Please retry with 275.09.04-1. This is said to fix some KDE issues,
> but eventually it helps in your case, too.
> If it does not help, please check the NVIDIA forums for a matching
> report and add additional information there or create a new report.
> The NVIDIA bug reporting instructions can be found here:
> http://www.nvnews.net/vbulletin/showthread.php?t=46678
> Please post the URL to an existing or new thread here, so that we may
> follow progress.

I still have the same problem with 275.09.04-1. I found a report on
nvnews that I think is the same bug:

http://www.nvnews.net/vbulletin/showthread.php?t=163327

Is it appropriate to use the forwarded BTS command for that URL?



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

Bug#615227: Would you cosider accepting this update to address bug 615227 in squeeze?

[Julien Cristau]

On Sat, Mar 12, 2011 at 14:43:48 +0100, Rik Theys wrote:

> Hi,
> 
> On Fri, 11 Mar 2011, Julien Cristau wrote:
> 
> >A few things:
> >- the fix should probably get a bit more exposure in unstable before we
> > accept it in stable
> >- changing the source package format in a stable update is a no-no
> 
> The package in squeeze was packaged as a "native" package. I asked on IRC in 
> #debian-release
> how to apply the patch in this case. I was told to either apply the patch to 
> the shipped "upstream" tar
> archive, or to either change the packaging.
> 
> I opted to change the packaging as this would show what has changed since the 
> original tar. I provided
> this new packaging to the DD for his convenience.
> 
> Would it have more change of being included in a stable point release if the 
> original packaging is
> kept and the patch applied to the tar?
> 
Yes.

Cheers,
Julien



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

Bug#547393: libjpeg8 transition.

[Julien Cristau]

Hi Bill,

sorry for the delay in getting back to you.

On Sat, Apr 30, 2011 at 16:29:17 +0200, Bill Allombert wrote:

> One issue with this transition is that a number of packages still depends on 
> libjpeg62-dev instead of libjpeg-dev. This might cause packages to have 
> uninstallable
> build-dependency until they are fixed.
> 
I guess that depends if we need to keep building some things against
libjpeg62.  If not, maybe libjpeg62-dev can become a dummy transitional
package for libjpeg8-dev.  If yes, then those packages depending on
libjpeg62-dev should have bugs filed (probably at important severity
for now).

Cheers,
Julien



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

Bug#626094: perl: debian/patches/fixes/processPL.diff is obsolete

[Dominic Hargreaves]

On Wed, Jun 08, 2011 at 07:14:47PM +0300, Niko Tyni wrote:
> On Tue, Jun 07, 2011 at 10:03:51PM +0100, Dominic Hargreaves wrote:
> > On Sun, May 08, 2011 at 08:10:13PM +0100, Dominic Hargreaves wrote:
> > 
> > > > At some point I think we should revert the patch, possibly with some 
> > > > test
> > > > rebuilds first to make sure no other package in the archive is relying
> > > > on our divergence. (IMO this is a bit overly defensive but easy enough
> > > > that it may be worth doing.)
> > > 
> > > Sounds good. I'll look at doing this once the 5.12 migration is
> > > completed.
> > 
> > Reverting this and rebuilding 5.12:
> > 
> > t/porting/checkcaseFAILED at 
> > test 130
> 
> > $ ../perl -I../lib porting/checkcase.t |grep -v ^ok
> > not ok 131 - lib/Version, lib/version
> > 1..11197
> > 
> > I assume that this patch has somehow become depended upon by one of
> > our other patches, maybe extutils_hacks, but I can't see why now.
> 
> I find this hard to believe,

I did too.

> and I couldn't reproduce it myself.
> 
> Is it reproducible for you after 'git clean -dfx'?

Nope. I wonder what caused this, but not enough to do lots of digging.
Note to self: always run git clean -dfx before builds!

Sorry for the noise.

Will run a rebuild against this package in the next day or two.

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