headers
Carl Chenet | 1 Jun 2011 01:44
Gravatar

Bug#628738: debian-maintainers: Annual ping for Carl Chenet

Package: debian-maintainers
Severity: normal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

This is my annual ping.

Best regards,
Carl Chenet

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

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

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

iQIcBAEBCAAGBQJN5X1RAAoJEAJwonWM1zbivyYQAJZ9K/1d3wjS0ou2MqM+ulOl
eqK22SUo4LHHfNeEMrRog92Gshpvl4RoQbkqjuP+JCWi+h9L4mpl6l9l8DlWevIY
75V8uAuVwpSz7tozxkx0uQ6N/U5aT7im0CKCvu8aW66pwCinUrIKvGk3j0LEvX/D
+WLCR/DVeTaA/2nNIxS5eap2cKMASG8nVDfwFRWBEYP4UEGfbMEG6UIVMB1RpSFl
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Clements | 1 Jun 2011 01:07

Bug#628744: pax believes small tar files contain extraordinarily large files

Package: pax
Version: 1:20090728-1
Severity: important

The version of pax included in stable/lenny computes incredibly large sizes for
all .tar archives. Here's a transcript:

clements <at> computer:/tmp$ cd /tmp
clements <at> computer:/tmp$ cat > foo
aoesutha
clements <at> computer:/tmp$ tar cvf foo.tar foo
foo
clements <at> computer:/tmp$ ls -l foo.tar
-rw-r--r-- 1 clements clements 10240 May 31 16:02 foo.tar
clements <at> computer:/tmp$ /usr/bin/pax -v < ./foo.tar
-rw-r--r--  1 clements clements 4294967305 May 31 16:01 foo
pax: ustar vol 1, 1 files, 10240 bytes read, 13823150313071618356 bytes
written.
clements <at> computer:/tmp$

... so, pax believes that the archive contains a file foo that is massively
large, even though the actual file size is about 10 chars.

This machine is an old i686 running squeeze:

clements <at> computer:/tmp$ uname -a
Linux computer 2.6.32-5-686 #1 SMP Tue Mar 8 21:36:00 UTC 2011 i686 GNU/Linux

This makes pax unusable for .tar files, and means that the amavisd-new
mail scanner fails for all mail containing .tar files.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nobuhiro Iwamatsu | 1 Jun 2011 01:25
Gravatar

Bug#628745: libdbusmenu-qt: FTBFS: missing symbol file on some architecture

Source: libdbusmenu-qt
Version: 0.8.0-1
Justification: FTBFS
Severity: serious

Hi,

libdbusmenu-qt FTBFS on some architecure.

https://buildd.debian.org/status/package.php?p=libdbusmenu-qt

For example, on ia64:
-----
 _ZN16DBusMenuImporterD1Ev <at> Base 0.3.2
  _ZN16DBusMenuImporterD2Ev <at> Base 0.3.2
  _ZN16DBusMenuShortcut15fromKeySequenceERK12QKeySequence <at> Base 0.3.4
+ _ZN16DBusMenuShortcutD1Ev <at> Base 0.8.0-1
+ _ZN18DBusMenuLayoutItemC1ERKS_ <at> Base 0.8.0-1
  _ZN18DBusMenuLayoutItemD1Ev <at> Base 0.8.0
- _ZN18DBusMenuLayoutItemD2Ev <at> Base 0.8.0
+#MISSING: 0.8.0-1# _ZN18DBusMenuLayoutItemD2Ev <at> Base 0.8.0
  _ZNK16DBusMenuExporter10metaObjectEv <at> Base 0.3.2
  _ZNK16DBusMenuImporter10metaObjectEv <at> Base 0.3.2
  _ZNK16DBusMenuImporter4menuEv <at> Base 0.3.2
dh_makeshlibs: dpkg-gensymbols -plibdbusmenu-qt2
-Idebian/libdbusmenu-qt2.symbols -Pdebian/libdbusmenu-qt2 returned
exit code 1
make[1]: *** [override_dh_makeshlibs] Error 1
make[1]: Leaving directory
`/build/buildd-libdbusmenu-qt_0.8.0-1-ia64-ZLURqH/libdbusmenu-qt-0.8.0'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alberto Garcia | 1 Jun 2011 01:25
Favicon
Gravatar

Bug#628746: ITP: opense-basic -- Free software ROM for the Sinclair ZX Spectrum

Package: wnpp
Severity: wishlist
Owner: Alberto Garcia <agarcia <at> igalia.com>

* Package name    : opense-basic
  Version         : 3.03
  Upstream Author : Andrew Owen
* URL             : http://sourceforge.net/projects/sebasic/
* License         : GPL
  Programming Lang: Assembler (Z80)
  Description     : Free software ROM for the Sinclair ZX Spectrum

OpenSE BASIC is a free software implementation of Sinclair BASIC
including many improvements over the original, while retaining a high
level of compatibility.

Its purpose is to be a free replacement ROM for the ZX Spectrum /
Timex Sinclair for use with emulators or real machines, but note that
it cannot replace 48 BASIC in computers with 32K or 64K ROMs (that
includes Spectrum 128/+2/+2A/+3).

Some of the highlights are:

 * Overall fastest version of Sinclair BASIC - fully optimized for
   speed.
 * Fastest and most user friendly editor - with additional editing
   commands.
 * AY support including pseudo-interrupt driven sound.
 * ULAplus support including a default palette and new commands.
 * 8-bit character set support including printing characters 24-31.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Estevo Paz Freire | 1 Jun 2011 01:43

Bug#628747: Compile error at install virtualbox-ose-guest-dkms

Package: virtualbox-ose-guest-dkms
Version: 4.0.4-dfsg-2
Severity: grave
Tags: sid
Justification: renders package unusable

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

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

Versions of packages virtualbox-ose-guest-dkms depends on:
ii  dkms                          2.1.1.2-6  Dynamic Kernel Module Support Fram

virtualbox-ose-guest-dkms recommends no packages.

virtualbox-ose-guest-dkms suggests no packages.

-- no debconf information

shinji:~# tail /var/lib/dkms/virtualbox-ose-guest/4.0.4/build/make.log
/var/lib/dkms/virtualbox-ose-guest/4.0.4/build/vboxsf/vfsmod.c:461: error: implicit
declaration of function ‘get_sb_nodev’
/var/lib/dkms/virtualbox-ose-guest/4.0.4/build/vboxsf/vfsmod.c: At top level:
/var/lib/dkms/virtualbox-ose-guest/4.0.4/build/vboxsf/vfsmod.c:469: error: unknown field
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert McQueen | 1 Jun 2011 02:18
Picon
Favicon

Bug#628749: libebook should depend on newer e-d-s somehow

Package: libebook1.2-10
Version: 3.0.0-1

In 3.0.0-1 libebook needs the evolution-data-server that provides the
org.gnome.evolution.dataserver.AddressBook0 service, but in 2.32.x e-d-s
provides the old org.gnome.evolution.dataserver.AddressBook service. I
had libebook 3.0.0-1 installed after installing some apps from
experimental, but my evolution-data-server was still 2.32.x, so none of
my apps could find contacts until I downgraded libebook again. For a
smooth GNOME 2 -> 3 migration, libebook should express some dependency
on the e-d-s that it works with.

Regards,
Rob
Permalink | Reply | 0 comments |
headers
Uwe Hermann | 1 Jun 2011 02:23
Picon
Favicon
Gravatar

Bug#627800: miro: New Upstream (4.0)

On Sat, May 28, 2011 at 10:14:00PM +0200, Jan Hauke Rahm wrote:
> On Tue, May 24, 2011 at 06:36:19PM +0200, Daniel Baumann wrote:
> > it would be nice if you could upgrade to version 4.0.
> 
> I'd like to second this. Uwe, are you by any chance working on this
> already?

Yep, working on it.

Uwe.
--

-- 
http://hermann-uwe.de     | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org
Permalink | Reply | 1 comment |
headers
Ryo Furue | 1 Jun 2011 01:30
Favicon

Bug#628742: Acknowledgement (xdvik-ja: cannot display kanji)

I was able to solve the problem.

1) I found that 

  $ fc-match serif:lang=ja
  lohit_ta.ttf: "Lohit Tamil" "Regular"
  $

The Tamil fonts are included in "ttf-tamil-fonts", which was pulled
in by "ttf-indic-fonts" as a dependency.

2) So I purged the Indic fonts:

  # aptitude --purge-unused purge ttf-tamil-fonts ttf-indic-fonts

3) Now, xdvi-ja started to report this error:

  $ xdvi-ja tmp
  FreeType2: Open Font Error (/usr/share/fonts/truetype/ttf-tamil-fonts/lohit_ta.ttf).  Error code =
1 

4) So I updated:

  # update-vfontmap

  Then xdvi-ja started to work!

5) Finally, I installed the Indic fonts again:

  # aptitude install ttf-indic-fonts
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ismael | 1 Jun 2011 02:43
Picon

Bug#628750: udev: takes too long to detect and configure mouse (steelseries XAI)

Package: udev
Version: 169-1
Severity: normal

Udev is taking around 15 secs to detect and configure my mouse. If you take a
look at my bootchart, you see a big hole: http://i.imgur.com/whbA8.png . That
hole is caused by udev trying to figure out my Steelseries XAI mouse. This (
http://imgur.com/7tSVP.png ) is the same bootchart with the mouse unplugged.
You can see that when I plug it, a modprobe runs and takes about 15 seconds. I
don't see any weird module loaded for the mouse afterwards (hid, usbhid and
that's it), so the modprobe is pointless (?).

Here's the dmesg output (at loglevel 9) after booting my PC without the mouse
and pluggin it in:

[   30.892447] SysRq : Changing Loglevel
[   30.896441] Loglevel set to 9
[   42.700013] usb 5-1: new full speed USB device number 2 using uhci_hcd
[   42.877032] usb 5-1: New USB device found, idVendor=1038, idProduct=1360
[   42.886016] usb 5-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=2
[   42.894967] usb 5-1: Product: SteelSeries Gaming Device
[   42.903794] usb 5-1: Manufacturer: Ruling Technologies Sdn. Bhd.
[   42.912457] usb 5-1: SerialNumber: SteelSeries Gaming Device
[   48.032209] input: Ruling Technologies Sdn. Bhd. SteelSeries Gaming Device
as /devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0/input/input4
[   48.051405] generic-usb 0003:1038:1360.0001: input,hidraw0: USB HID v1.00
Mouse [Ruling Technologies Sdn. Bhd. SteelSeries Gaming     Device] on
usb-0000:00:1d.3-1/input0
[   53.080105] input: Ruling Technologies Sdn. Bhd. SteelSeries Gaming Device
(Continue reading)

Permalink | Reply | 3 comments |
headers
Scott Schaefer | 1 Jun 2011 03:24

Bug#595119: piuparts: modular way to add new tests?

On 05/31/2011 03:31 AM, Timo Juhani Lindfors wrote:
> Hi,
>
> Scott Schaefer<saschaefer <at> neurodiverse.org>  writes:
>    
>>  From reading your report and your patch, I believe you can achieve
>> this with the "custom scripting" interface
>> (/usr/share/doc/piuparts/README.html or
>> http://piuparts.debian.org/doc/README.html#_custom_scripts_with_piuparts).
>> While perhaps not ideal, this interface provides a 'modular way to add
>> new tests'.
>>      
> Looks good indeed but is this only for my private tests? How do I get my
> tests to run on piuparts.debian.org?
>
>    
Hm ... Well, that is a very good question.  And, I understand what you 
are trying to do is outside the scope of what can be expected of 
"private tests".  Unfortunately, I am afraid your question raises a 
large number of issues, well beyond a scope I feel qualified to comment 
on (other than to note they exist) ...

Given what I have read, and reviewing list of wishlist bugs, I am 
reasonably certain a "framework for securely executing plugins" will be 
a big part of any future discussion re "piuparts 2.0".

Until then, the only alternatives I see are to revise/include your patch 
and/or to provide some way to provide for "package-specific" scriptdir.  
The latter is extremely problematic in master/slave setup, since the 
scripts would have to either exist at the slave, or some means of
(Continue reading)

Permalink | Reply | 3 comments |

Gmane