Bug#509624: lintian should check for wrong image size

[Patrick Matthäi]

> Hi,
>
> On Tuesday 23 December 2008 15:38:38 Patrick Matthäi wrote:
> [...]
>>
>> I am maintaining tork and we found out, that the images (e.g.
>> ./usr/share/apps/tork/icons/hicolor/22x22/*) are finaly not 22x22.
>>
>> In OpenSUSE such packages will be rejected (from the osuse packaging), I
>> think it will be a good idea to check images for their size if they are
>> in dirs like hicolor/22x22, 48x48 etc.
>
> What's the side effect of using those icons? a bit of over head because
> they
> are re-sized? or are they are used as-is?

It has not got a real negative side effect, but it is unclean and also
does not fit the size from the dir where they are.
Maybe there was also a packaging etc. error where 22x22 images are
installed to 48x48.

>
> Would severity: minor be enough? or would severity: normal fit better?
>

Would be okay.





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

Bug#514741: evince: full screen navigation in documents created by LaTeX-Beamer requires two scrolling actions

[Josselin Mouette]

Le mercredi 11 février 2009 à 21:32 -0500, Denis Laxalde a écrit :
> Josselin Mouette a écrit :
> > I can reproduce this with evince 2.22, but not with evince 2.24 from
> > experimental. Could you confirm?
> 
> No, I tried with evince 2.24 from experimental on Sid (x86) and the 
> problem is the same.

Then there must be something else necessary to reproduce the bug, maybe
the screen resolution.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Bug#514943: network-manager: wired connection remains with wireless associated and no cable

[Drew Parsons]

On Thu, 2009-02-12 at 07:57 +0100, Michael Biebl wrote:

> What driver do you use?
> What does nm-tool say for eth0, is carrier detect supported?
> 

Driver for eth0 is e1000e,  Carrier Detect:  yes

The wlan0 driver is iwlagn.


> You might also check the syslog .

syslog says before the new kernel, nm would bring eth0 up at home, and
then deactivate it:

Jan 31 21:47:50 pug NetworkManager:   Waking up...
Jan 31 21:47:50 pug NetworkManager:   (eth0): now managed
Jan 31 21:47:50 pug NetworkManager:   (eth0): device state change:
1 -> 2
Jan 31 21:47:50 pug NetworkManager:   (eth0): bringing up device.
Jan 31 21:47:50 pug kernel: [31790.172718] ADDRCONF(NETDEV_UP): eth0:
link is not ready
Jan 31 21:47:50 pug NetworkManager:   (eth0): preparing device.
Jan 31 21:47:50 pug NetworkManager:   (eth0): deactivating device
(reason: 2).
Jan 31 21:47:50 pug NetworkManager:   (wlan0): now managed
Jan 31 21:47:50 pug NetworkManager:   (wlan0): device state
change: 1 -> 2
Jan 31 21:47:50 pug NetworkManager:   (wlan0): bringing up device.
...
Jan 31 21:50:09 pug NetworkManager:   (wlan0): preparing device.
Jan 31 21:50:09 pug NetworkManager:   (wlan0): deactivating device
(reason: 2).
Jan 31 21:50:09 pug kernel: [31929.475088] ADDRCONF(NETDEV_UP): wlan0:
link is not ready
Jan 31 21:50:09 pug kernel: [31929.488461] wlan0: authenticate with AP 

Does "reason 2" means "no cable"?  Nothing more was said about eth0.  It
continued from "wlan0: authenticate with AP" and the wireless interface
got established.


With the new kernel, syslog starts reporting the same, including
"(eth0): deactivating device (reason: 2)".  But then a second later it
continues on saying:

Feb 12 00:35:14 pug NetworkManager:   (wlan0): preparing device.
Feb 12 00:35:14 pug NetworkManager:   (wlan0): deactivating device
(reason: 2).
Feb 12 00:35:14 pug kernel: [ 8875.187423] ADDRCONF(NETDEV_UP): wlan0:
link is not ready
Feb 12 00:35:14 pug NetworkManager:   (eth0): carrier now ON
(device state 2)
Feb 12 00:35:14 pug NetworkManager:   (eth0): device state change:
2 -> 3
Feb 12 00:35:14 pug NetworkManager:   (wlan0): device state
change: 2 -> 3
Feb 12 00:35:14 pug NetworkManager:   Activation (eth0) starting
connection 'ANU wired'
Feb 12 00:35:14 pug NetworkManager:   (eth0): device state change:
3 -> 4
Feb 12 00:35:14 pug NetworkManager:   Activation (eth0) Stage 1 of
5 (Device Prepare) scheduled...
...
Feb 12 00:35:15 pug NetworkManager:   (eth0): device state change:
7 -> 8
Feb 12 00:35:15 pug NetworkManager:   (eth0): writing resolv.conf
to /sbin/resolvconf
Feb 12 00:35:27 pug NetworkManager:   Policy set (eth0) as default
for routing and DNS.


These eth0 entries are new. I guess "(eth0): carrier now ON" is the
start of the trouble.  Only after this do I get to the "wlan0:
authenticate with AP" step.  There are also some new wlan0 steps between
"set (eth0) as default" and "authenticate with AP", including:

Feb 12 00:35:27 pug NetworkManager:   Activation (eth0)
successful, device activated.
Feb 12 00:35:27 pug NetworkManager:   Activation (eth0) Stage 5 of
5 (IP Configure Commit) complete.
Feb 12 00:35:27 pug NetworkManager:   (wlan0): supplicant
interface state change: 1 -> 2.
Feb 12 00:35:29 pug NetworkManager:   Activation (wlan0) starting
connection 'myAP'
Feb 12 00:35:29 pug NetworkManager:   (wlan0): device state
change: 3 -> 4
Feb 12 00:35:29 pug NetworkManager:   Activation (wlan0) Stage 1
of 5 (Device Prepare) scheduled...


Is that enough detail or do you need full logs?

Drew





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

Bug#505089: alsa-utils: "asoundconf set-default-card" does not work

[Lionel Elie Mamane]

tags 505089 +patch
thanks

On Thu, Feb 12, 2009 at 10:09:34AM +1100, Paul TBBle Hampson wrote:

> Just came across this, and from [1] it turns out the fix is to
> remove the exclamation mark in front of the "defaults.pcm.card" in
> the generated file.

No, the reference you give does more than just remove the exclamation
mark. It also refers to the card by number and not by name, which is
not useful to someone that does not have root access to the machine
and cannot fix which card is which number.

When just removing the exclamation mark, I get the following
.asoundrc.asoundconf

# ALSA library configuration file managed by asoundconf(1).
#
# MANUAL CHANGES TO THIS FILE WILL BE OVERWRITTEN!
#
# Manual changes to the ALSA library configuration should be implemented
# by editing the ~/.asoundrc file, not by editing this file.
defaults.pcm.card CK804
defaults.ctl.card CK804
defaults.pcm.device 0
defaults.pcm.subdevice -1

which gives this error:

ALSA lib conf.c:976:(parse_value) card is not a string
ALSA lib conf.c:1589:(snd_config_load1) 
/home/master/.asoundrc.asoundconf:8:0:Invalid argument
ALSA lib conf.c:2850:(snd_config_hook_load) /home/master/.asoundrc may be old 
or corrupted: consider to remove or fix it
ALSA lib conf.c:2714:(snd_config_hooks_call) function snd_config_hook_load 
returned error: Invalid argument
ALSA lib conf.c:3079:(snd_config_update_r) hooks failed, removing configuration



But I have _finally_ figured it out! Removing the exclamation mark
_and_ applying this patch to /usr/share/alsa/alsa.conf does the trick.

--- alsa.conf.bak   2009-02-12 08:06:25.458031089 +0100
+++ alsa.conf   2009-02-12 08:08:59.074231990 +0100
@@ -58,8 +58,8 @@
 # show extended name hints
 defaults.namehint.extended off
 #
-defaults.ctl.card 0
-defaults.pcm.card 0
+defaults.ctl.card "0"
+defaults.pcm.card "0"
 defaults.pcm.device 0
 defaults.pcm.subdevice -1
 defaults.pcm.nonblock 1


Here are patches.

-- 
Lionel
diff --recursive -N -u alsa-lib-1.0.18/debian/changelog alsa-lib-1.0.18.505089/debian/changelog
--- alsa-lib-1.0.18/debian/changelog	2009-02-12 08:24:16.0 +0100
+++ alsa-lib-1.0.18.505089/debian/changelog	2009-02-12 08:14:55.257031809 +0100
@@ -1,3 +1,9 @@
+alsa-lib (1.0.18-1.0) experimental; urgency=low
+
+  * Allow defaults.{ctl,pcm}.card to be a string
+
+ --
+
 alsa-lib (1.0.18-1) experimental; urgency=low
 
   * New upstream release.
diff --recursive -N -u alsa-lib-1.0.18/debian/patches/named_defaults alsa-lib-1.0.18.505089/debian/patches/named_defaults
--- alsa-lib-1.0.18/debian/patches/named_defaults	1970-01-01 01:00:00.0 +0100
+++ alsa-lib-1.0.18.505089/debian/patches/named_defaults	2009-02-12 08:21:07.306033058 +0100
@@ -0,0 +1,15 @@
+Index: alsa-lib-1.0.18/src/conf/alsa.conf
+===
+--- alsa-lib-1.0.18.orig/src/conf/alsa.conf	2009-02-12 08:19:56.197033159 +0100
 alsa-lib-1.0.18/src/conf/alsa.conf	2009-02-12 08:20:14.915281547 +0100
+@@ -58,8 +58,8 @@
+ # show extended name hints
+ defaults.namehint.extended off
+ #
+-defaults.ctl.card 0
+-defaults.pcm.card 0
++defaults.ctl.card "0"
++defaults.pcm.card "0"
+ defaults.pcm.device 0
+ defaults.pcm.subdevice -1
+ defaults.pcm.nonblock 1
diff --recursive -N -u alsa-lib-1.0.18/debian/patches/series alsa-lib-1.0.18.505089/debian/patches/series
--- alsa-lib-1.0.18/debian/patches/series	2009-02-12 08:24:16.0 +0100
+++ alsa-lib-1.0.18.505089/debian/patches/series	2009-02-12 08:19:50.217032117 +0100
@@ -1,3 +1,4 @@
 relibtoolise.patch
 add-maintainer-mode.patch
 configure_cross_compile.patch
+named_defaults
diff --recursive -u alsa-utils-1.0.18/debian/asoundconf alsa-utils-1.0.18.505089/debian/asoundconf
--- alsa-utils-1.0.18/debian/asoundconf	2009-02-12 08:29:51.0 +0100
+++ alsa-utils-1.0.18.505089/debian/asoundconf	2009-02-12 08:32:04.753031103 +0100
@@ -340,9 +340,9 @@
 	sep = re.compile(r'[ ]')
 	r = re.compile('^defaults.pcm.card')
 	s = re.compile('^defaults.ctl.card')
-	## !defaults.pcm.card and defaults.ctl.card should lead
+	## defaults.pcm.card and defaults.ctl.card should lead
 	## the user's custom asoundrc.
-	if set('!defaults.pcm.card', card) and \
+	if set('defaults.pcm.card', card) and \
 	   set('defaults.ctl.card', card):
 	for i in clist:
 		(j, k) = sep.split(i)
diff --recursive -u alsa-utils-1.0.18/debian/changelog alsa-utils-1.0.18.505089/debian/changelog
--- alsa-utils-1.0.18/debian/changelog	2009-02-12 08:29:51.0 +0100
+++ alsa-utils-1.0.18.505089/debian/changelog	2009-02-12 08:34:00.873031419 +0100
@@ -1,3 +1,9 @@
+alsa-utils (1.0.18-1.0) experimental; urgency=low
+
+  * asoundconf set-default-card: no "!" (closes: #505089)
+
+ --
+
 alsa-utils (1.0.18-1) experimental; urgency=low
 
   * New upstream release.

Bug#514906: console-data: please add new french dvorak 'bépo' layout

[Christian Perrier]

Quoting Frédéric Boiteux (fboit...@free.fr):


>   'ANSI' => 'ANSI-dvorak',
>   'Dvorak German' => 'dvorak-de',
>   'Dvorak French' => 'dvorak-fr',
> + 'Dvorak French Bepo' => 'fr-dvorak-bepo',
> + 'Dvorak French Bepo (UTF8)' => 'fr-dvorak-bepo-utf8',
>   'Dvorak Russian' => 'dvorak-ru',
>   'With French and Spanish accents' => 'pc-dvorak-latin1',
>   'Dvorak Classic' => 'dvorak-classic',


Any reasone for the naming to be inconsistent with other dvorak
flavours?

Why not "dvorak-bepo-fr"?

Or, if "bépo" is something specific to French, "dvorak-fr-bepo"




signature.asc
Description: Digital signature

Bug#514889: "On battery power, so skipping file system check" when in AC power

[Virgo Pärna]

> Hi Virgo,
> 
> This is completly and utterly wrong. You dont describe any problem, just a 
> mere note. If this were an error, the severity would be minor.

It is a problem, because it never does filesystem check - even after
crash, when it is necessary. And the message says, that it skips the
check because it is running on battery power, when it is not running on
battery power but in AC power.

> 
>> >When starting my Acer laptop on AC power, it reports:
>> > "On battery power, so skipping file system check".
> 
> And as this is a feature, I'm closing this bug.
> 

It is a feature, that the system reports, that it is running on
battery, when it is not running on battery?

-- 
Virgo Pärna
virgo.pa...@mail.ee




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

Bug#504880: Disambiguate "installed" for packages

[Raphael Hertzog]

On Wed, 11 Feb 2009, Russ Allbery wrote:
> Is the reason why you can't rely on configured for the prerm case the same
> reason why you can't rely on it for the postinst case: because of breaking
> circular dependencies and choosing one package to deconfigure first?  It

No, I believe it's a design choice to be able to unpack all packages in a
first batch and then configure them all in a second one (like apt does).

> I'm a little concerned that this sounds like an implicit encouragement to
> use Pre-Depends more because you can rely on it, and I don't think we want
> to do that.  I'm not entirely sure how to avoid that, though, and in

We don't want that, feel free to reword that part to frighten people that
would like to use it just because that sentence says you can rely on it.
:)

> What happens if there are circular Pre-Depends?  Does dpkg just give up at
> that point and throw a fatal error?

I don't know.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



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

Bug#514951: [checks/binaries] check the output of strings for typos and mistakes

[Raphael Geissert]

Package: lintian
Version: 2.2.5
Severity: wishlist
Tags: patch
Blocks: 318104

Hi,

Attached mbox contains patches adding a collection script to gather the output 
of the 'strings' command on the ELF binaries of a package, and spell checks 
its output. The collection script is also needed to implement the check for 
statically linking to zlib, within others.

The spell checking part should better go in together with a spell checking 
function that performs better with large texts.
The elf-index file was originally being generated so that it could be possible 
to iterate over the elf files without having to look for them in the 
file-info index. Maybe it should die if nobody finds a use for it.

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


lintian-binaries_spelling.mbox
Description: application/mbox


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

Bug#514943: [Pkg-utopia-maintainers] Bug#514943: network-manager: wired connection remains with wireless associated and no cable

[Michael Biebl]

Drew Parsons schrieb:
> Package: network-manager
> Version: 0.7.0-1
> Severity: normal
> 
> A change in network-manager behaviour appears to have been triggered
> by the 2.6.28 linux kernel.
> 
> Up till now, I've had network-manager automatically connect to and
> switch between wired and wireless networks.  At work I insert the
> cable, and my wired connection is set up.  I take my laptop home, and
> it finds my wireless network, the wired connection is switched off.
> 
> Now all of a sudden I've found that when I get home, the wired
> connection is still on, even though no cable is inserted to the
> ethernet jack.  At the same time the wireless network is still found
> and set up.  But because nm has already set up the eth0 interface, the
> gateway and dns (/etc/resolve.conf) is not rewritten. wlan0 is routed
> to the local network only, the gateway is still set to the eth0
> address.  So I can't connect properly to the external internet from
> home.  
> 
> The only way I know to work around the problem is to switch off
> "Connects automatically" in the nm configuration entry for the wired
> network.  This makes it less convenient at work, where previously I
> just had to plug in the cable for nm to set up the connection.
> 
> As far as I can tell the only change I've made to cause this new
> behaviour is to install a 2.6.28 kernel (well, bind9-host also got
> upgraded over the weekend along with associated libraries).
> 

What driver do you use?
What does nm-tool say for eth0, is carrier detect supported?

You might also check the syslog .

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#514950: hylafax-server: start script not reaaly "syncing directories": modems deleted in /etc/hylafax persists

[Sebastian Niehaus]

Package: hylafax-server
Version: 2:4.4.4-10.1
Severity: normal


I deleted a modem from /etc/hylafax/ 
rm /etc/hylafax/config.ttyACM0 

This change is not synced to /var/spool/hylafax/etc/, I 
needed to remove the configuration file at this directory
as well. 

Sorry, not enough knowledge to patch the init script 



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

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

Versions of packages hylafax-server depends on:
ii  adduser3.110 add and remove users and groups
ii  bsd-mailx [mailx]  8.1.2-0.20071201cvs-3 A simple mail user agent
ii  debconf [debconf-2 1.5.24Debian configuration management sy
ii  ghostscript8.62.dfsg.1-3.2lenny0 The GPL Ghostscript PostScript/PDF
ii  ghostscript-x [gs] 8.62.dfsg.1-3.2lenny0 The GPL Ghostscript PostScript/PDF
ii  hylafax-client 2:4.4.4-10.1  Flexible client/server fax softwar
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  libgcc11:4.3.2-1.1   GCC support library
ii  libpam0g   1.0.1-5   Pluggable Authentication Modules l
ii  libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii  libtiff-tools  3.8.2-11  TIFF manipulation and conversion t
ii  libtiff4   3.8.2-11  Tag Image File Format (TIFF) libra
ii  lsb-base   3.2-20Linux Standard Base 3.2 init scrip
ii  mailx  1:20071201-3  Transitional package for mailx ren
ii  psmisc 22.6-1Utilities that use the proc filesy
ii  sed4.1.5-6   The GNU sed stream editor
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

hylafax-server recommends no packages.

Versions of packages hylafax-server suggests:
pn  mgetty (no description available)
pn  psrip  (no description available)

-- debconf-show failed



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

Bug#513589: dpkg: Fehler beim Bearbeiten von rsyslog-mysql (--configure)

[Michael Biebl]

clone 513589 -1
reassign -1 dbconfig-common
retitle -1 dbconfig-common does not set configuration variables
found -1 1.8.39
thanks

sean finney schrieb:
>  
>>> Creating config file /etc/dbconfig-common/rsyslog-mysql.conf with new 
>>> version
>>> Have had a look at:
>>> server:/var/www# cat /etc/rsyslog.d/mysql.conf
>>> ### Configuration file for rsyslog-mysql
>>> ### Changes are preserved
>>>
>>> $ModLoad ommysql
>>> *.* :ommysql:localhost,,,
> 
> what should it be?  are the resp host/db/port/user values different from
> the contents of /etc/dbconfig-common/rsyslog-mysql.conf?

The template looks like:
*.* :ommysql:_DBC_DBSERVER_,_DBC_DBNAME_,_DBC_DBUSER_,_DBC_DBPASS_

>> This is imho a dbconfig-common bug now. If everything is working correctly,
>> dbconfig-common should automatically setup your db and create a working
>> configuration. Apparently it doesn't do that on your system.
>> I would like to keep this bug closed, but we could clone this one, reopen and
>> reassign it to dbconfig-common, as you already have submitted valuable log 
>> files
>> which are helpful. Sean, would you be ok with that?
> 
> i guess, though we may need to go back and forth on this a few times if
> we can't find the problem right away.

I've reassigned the bug now.
Christian, maybe you can provide the missing information, sean is
requesting.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#514818: lenny-backports not a recognised distribution

[Adam D. Barratt]

On Wed, 2009-02-11 at 10:08 +, Adam D. Barratt wrote:
> martin f krafft wrote, Wednesday, February 11, 2009 9:21 AM
> > I suggest to also include the fix to --bpo. I'll gladly review the diff.
> 
> I've already uploaded the version that Marc approved. I can prepare a 
> further update if desired; diff attached, in any case.

fwiw, the patch I committed for unstable is a little more complicated as
it ensures that running --bpo on an existing etch backport doesn't
suddenly turn it into a lenny backport.

Regards,

Adam



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

Bug#514549: belarusian translation for inkscape 0.46

[Wolfram Quester]

Hi!

> 
> Hello! I'm a current translator of Inkscape into Belarusian. Translation 
> for 0.46 version was made after its release, so Debian's package hasn't it
> (at least my version, my Lenny snapshot is outdated). So if you include 
> attached po into package all belarusian users of Debian will be very thankful.

Thanks for the info and the patch, I'll include ist in the next upload of the
package. I don't know however, if it will make it into lenny.

With best wishes,

Wolfi


signature.asc
Description: Digital signature

Bug#509624: [checks/files] check icons for an incorrect size

[Raphael Geissert]

tag 509624 patch
thanks

Whatever the final severity is, attached  patch implements it. Right now I'm 
lacking good arguments for the tag description, so it needs to be improved.

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


lintian-icons.mbox
Description: application/mbox


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

Bug#514737: libpdf-reuse-perl: wrong declaration of PDF::Reuse::findFont

[Niko Tyni]

On Tue, Feb 10, 2009 at 03:32:31PM +0100, Andreas Faust wrote:
> Package: libpdf-reuse-perl
> Severity: grave
> Justification: renders package unusable
> 
> Too many arguments for PDF::Reuse::findFont at /usr/share/perl5/PDF/Reuse.pm 
> line 197, near "$nyFont)"
> BEGIN not safe after errors--compilation aborted at 
> /usr/share/perl5/PDF/Reuse.pm line 744.
> Compilation failed in require at (eval 312) line 36.
> BEGIN failed--compilation aborted at (eval 312) line 36.
> 
> "sub PDF::Reuse::findFont()" is wrong, as it implies "no arguments"
> 
> it should be "sub PDF::Reuse::findFont"   

Hi,

while I see the wrong prototype on Reuse.pm:744, I can't reproduce this
error. Could you please provide a test case or something like that?

For example, this works for me and visits the problematic code:

# perl -MPDF::Reuse -e 'prFile("test.pdf"); prFont(q/Times-Roman/); prText(100, 
500, qq/Hello World\n/); prEnd()'
-- 
Niko Tyni   nt...@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#474590: [frontend] add a parsable reason for overrides and optionally require it

[Russ Allbery]

Raphael Geissert  writes:

> The implementation of #512901 is still a bit tricky because the comments
> need to be made available next to the overridden tags when
> --show-overrides is used so that reporting/harness sees them. Russ or
> anyone else: is there any suggestion on what letter to use to indicate
> that they are comments? "C"?  another possibility would be to print them
> as "N" with some sort of format that harness could identify and parse.
>
> Suggestions? Comments?

I think using N: with some special marker is the best idea, but that's
only a tentative opinion and I could be convinced otherwise.

The rest of your idea seems quite sound to me.

-- 
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#514948: /sys - parameters not set on startup

[Armin Fuerst]

Package: sysfsutils
Version: 2.1.0-5

During startup of the system, I want to set the scaling governor to
performance. After installing sysfsutils I modified /etc/sysfs.conf
to contain only the line:
devices/system/cpu/cpu0/cpufreq/scaling_governor = performance
(beside the default comments). When I enter
"/etc/init.d/sysfsutils start", the scaling governor is changed
properly. After a reboot of the system, the scaling governor is
again "ondemand". Following links to /etc/init.d/sysfsutils exist:
/etc/rc2.d/S20sysfsutils
/etc/rc3.d/S20sysfsutils
/etc/rc4.d/S20sysfsutils
/etc/rc5.d/S20sysfsutils

I can't find any entry with sysfs in /var/log/* (besides the
package installation) nor in dmesg.




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

Bug#474590: [frontend] add a parsable reason for overrides and optionally require it

[Raphael Geissert]

block 512901 with 474590
thanks

Hi all,

After thinking for a while about how to implement 474590 I think an approach 
like the one propposed in 512901 would be the best. This is based on two 
points:
* First, comment lines are already supported: adding something on the same 
line as the tag would break old lintians, and we don't want that. Introducing 
some other sort of comment lines would have the same effect.
* Second, I don't remember seeing any override file with comments where the 
comments were below the tag line.

My proposed parsing would then be:
# Comment explaining why the below tag is overridden
T: package: tag [extra [...]]
# Explanation for the following overrides, this comment
# should be re-used for the same tags, as duplicating the same information
# over and over again is useless. But it shouldn't be re-used for "bar-tag",
# nor any other tag other than "foo-tag"
T: package: foo-tag [extra [...]]
T: package: foo-tag [extra [...]]
T: package: bar-tag [extra [...]]

In order to properly implement/integrate #512901 maybe we should ask Jordà 
Polo to help us a bit, unless somebody wants to play with the reporting 
scripts :).

The implementation of #512901 is still a bit tricky because the comments need 
to be made available next to the overridden tags when --show-overrides is 
used so that reporting/harness sees them. Russ or anyone else: is there any 
suggestion on what letter to use to indicate that they are comments? "C"? 
another possibility would be to print them as "N" with some sort of format 
that harness could identify and parse.

Suggestions? Comments?

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


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

Bug#514945: gstreamer0.10: FTBFS: Bad bison version check

[Sebastian Dröge]

Am Mittwoch, den 11.02.2009, 20:05 -0800 schrieb Daniel Schepler:
> Package: gstreamer0.10
> Version: 0.10.20-1
> Severity: serious
> 
> From my pbuilder build log:
> 
> ...
> checking for perl... /usr/bin/perl
> checking for bison... /usr/bin/bison
> checking bison version 2.4.1 >= 1.875... Argument "^B^D^A" isn't numeric in 
> numeric lt (<) at - line 1.
> configure: error: no
> make: *** [config.status] Error 1
> dpkg-buildpackage: failure: debian/rules build gave error exit status 2

Could you give the output of bison --version?

Also this is most likely fixed upstream already and in experimental in
0.10.22.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#279591: Bug #279591 (man page)

[Laurent Guignard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

While i had an overview of the mutt source package, i saw some lintian
errors on mutt.man file.
I made a patch to solve that i saw in the BTS [1].

For my next work, i will focus my attention on lintian errors before
anything.
I downloaded debian directory from git and mutt-1.5.19 from the upstream
web site. Is it the correct method to apply for working on mutt package ?
Is there anywhere to get informations about the package management
(version used to build from sources, freeze of package, and so on...).


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

- --
Laurent Guignard, Registered as user #301590 with the Linux Counter
Site : http://www.famille-guignard.org
Blog : http://blog.famille-guignard.org
Projet : http://sicontact.sourceforge.net
GULL de Villefranche sur Saône : http://www.cagull.org




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJk7UUjcKpXFc/7oYRAljcAJ98BNEqbRr8ws5mw5QvZhwFyOw9EACeK4YL
ZMgW9bfJVn32DzmSzftSoQ4=
=DiDL
-END PGP SIGNATURE-
diff -Nadru mutt-1.5.18/doc/mutt.man trunk/doc/mutt.man
--- mutt-1.5.18/doc/mutt.man	2008-01-30 05:26:50.0 +0100
+++ trunk/doc/mutt.man	2009-02-06 13:39:24.0 +0100
@@ -23,36 +23,36 @@
 .SH SYNOPSIS
 .PP
 .B mutt
-[-nRyzZ] 
-[-e \fIcmd\fP] [-F \fIfile\fP] [-m \fItype\fP] [-f \fIfile\fP]
+[\-nRyzZ] 
+[\-e \fIcmd\fP] [\-F \fIfile\fP] [\-m \fItype\fP] [\-f \fIfile\fP]
 .PP
 .B mutt 
-[-nx] 
-[-e \fIcmd\fP] 
-[-F \fIfile\fP]
-[-H \fIfile\fP]
-[-i \fIfile\fP]
-[-s \fIsubj\fP]
-[-b \fIaddr\fP]
-[-c \fIaddr\fP]
+[\-nx] 
+[\-e \fIcmd\fP] 
+[\-F \fIfile\fP]
+[\-H \fIfile\fP]
+[\-i \fIfile\fP]
+[\-s \fIsubj\fP]
+[\-b \fIaddr\fP]
+[\-c \fIaddr\fP]
 [\-a \fIfile\fP [...]]
 [\-\-]
 \fIaddr\fP [...]
 .PP
 .B mutt
-[-n] [-e \fIcmd\fP] [-F \fIfile\fP] -p
+[\-n] [\-e \fIcmd\fP] [\-F \fIfile\fP] \-p
 .PP
 .B mutt
-[-n] [-e \fIcmd\fP] [-F \fIfile\fP] -A \fIalias\fP
+[\-n] [\-e \fIcmd\fP] [\-F \fIfile\fP] \-A \fIalias\fP
 .PP
 .B mutt
-[-n] [-e \fIcmd\fP] [-F \fIfile\fP] -Q \fIquery\fP
+[\-n] [\-e \fIcmd\fP] [\-F \fIfile\fP] \-Q \fIquery\fP
 .PP
 .B mutt 
--v[v]
+\-v[v]
 .PP
 .B mutt 
--D
+\-D
 .SH DESCRIPTION
 .PP
 Mutt is a small but very powerful text based program for reading and sending electronic
@@ -60,63 +60,63 @@
 OpenPGP, and a threaded sorting mode.
 .SH OPTIONS
 .PP
-.IP "-A \fIalias\fP"
+.IP "\-A \fIalias\fP"
 An expanded version of the given alias is passed to stdout.
-.IP "-a \fIfile\fP [...]"
+.IP "\-a \fIfile\fP [...]"
 Attach a file to your message using MIME.
 To attach multiple files, separating filenames and recipient addresses with
 "\-\-" is mandatory, e.g. \fBmutt \-a img.jpg *.png \-\- addr1 addr2\fP.
-.IP "-b \fIaddress\fP"
-Specify a blind-carbon-copy (BCC) recipient
-.IP "-c \fIaddress\fP"
+.IP "\-b \fIaddress\fP"
+Specify a blind\-carbon\-copy (BCC) recipient
+.IP "\-c \fIaddress\fP"
 Specify a carbon-copy (CC) recipient
-.IP "-d \fIlevel\fp"
+.IP "\-d \fIlevel\fp"
 If mutt was complied with +DEBUG log debugging output to ~/.muttdebug0.
-\fILevel\fP can range from 1-5 and effects verbosity. A value of 2 is
+\fILevel\fP can range from 1\-5 and effects verbosity. A value of 2 is
 recommended.
-.IP "-D"
+.IP "\-D"
 Print the value of all configuration options to stdout.
-.IP "-e \fIcommand\fP"
+.IP "\-e \fIcommand\fP"
 Specify a configuration command to be run after processing of initialization
 files.
-.IP "-f \fImailbox\fP"
+.IP "\-f \fImailbox\fP"
 Specify which mailbox to load.
-.IP "-F \fImuttrc\fP"
+.IP "\-F \fImuttrc\fP"
 Specify an initialization file to read instead of ~/.muttrc
-.IP "-h"
+.IP "\-h"
 Display help.
-.IP "-H \fIdraft\fP"
+.IP "\-H \fIdraft\fP"
 Specify a draft file which contains header and body to use to send a
 message.
-.IP "-i \fIinclude\fP"
+.IP "\-i \fIinclude\fP"
 Specify a file to include into the body of a message.
-.IP "-m \fItype\fP   "
+.IP "\-m \fItype\fP   "
 specify a default mailbox type
-.IP "-n"
+.IP "\-n"
 Causes Mutt to bypass the system configuration file.
-.IP "-p"
+.IP "\-p"
 Resume a postponed message.
-.IP "-Q \fIquery\fP"
+.IP "\-Q \fIquery\fP"
 Query a configuration variables value.  The query is executed after
 all configuration files have been parsed, and any commands given on
 the command line have been executed.
-.IP "-R"
-Open a mailbox in \fIread-only\fP mode.
-.IP "-s \fIsubject\fP"
+.IP "\-R"
+Open a mailbox in \fIread\-only\fP mode.
+.IP "\-s \fIsubject\fP"
 Specify the subject of the message.
-.IP "-v"
-Display the Mutt version number and compile-time definitions.
-.IP "-vv"
+.IP "\-v"
+Display the Mutt version number and compile\-time definitions.
+.IP "\-vv"
 Display license and copyright information.
-.IP "-x"
+.IP "\-x"
 Emulate the mailx compose mode.
-.IP "-y"
+.IP "\-y"
 Start Mutt with a listing of all mailboxes specified by the \fImailboxes\fP
 command.
-.IP "-z"
-When used with -f, causes Mutt no

Bug#504880: Disambiguate "installed" for packages

[Russ Allbery]

Raphael Hertzog  writes:

> Please find a proposed patch in attachment. Feel free to reword/improve
> if needed.

Is the reason why you can't rely on configured for the prerm case the same
reason why you can't rely on it for the postinst case: because of breaking
circular dependencies and choosing one package to deconfigure first?  It
just seems conceptually odd to use Pre-Depends for a dependency for a
removal script.

I'm a little concerned that this sounds like an implicit encouragement to
use Pre-Depends more because you can rely on it, and I don't think we want
to do that.  I'm not entirely sure how to avoid that, though, and in
context there are other warnings against using Pre-Depends.  What we
really want to do is actively discourage circular dependencies, since in
the absence of circular dependencies, Depends works as expected and you
can rely on packages being configured for postinst and prerm dependencies.

What happens if there are circular Pre-Depends?  Does dpkg just give up at
that point and throw a fatal error?

-- 
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#509624: lintian should check for wrong image size

[Raphael Geissert]

Hi,

On Tuesday 23 December 2008 15:38:38 Patrick Matthäi wrote:
[...]
>
> I am maintaining tork and we found out, that the images (e.g.
> ./usr/share/apps/tork/icons/hicolor/22x22/*) are finaly not 22x22.
>
> In OpenSUSE such packages will be rejected (from the osuse packaging), I
> think it will be a good idea to check images for their size if they are
> in dirs like hicolor/22x22, 48x48 etc.

What's the side effect of using those icons? a bit of over head because they 
are re-sized? or are they are used as-is?

Would severity: minor be enough? or would severity: normal fit better?

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



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

Bug#310563: (no subject)

[Robert Gerlach]

Please see http://bugzilla.padl.com/show_bug.cgi?id=388



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

Bug#514919: Removing support for uploads to multiple distributions

[Russ Allbery]

"Adam D. Barratt"  writes:

> The Policy section detailing the "Distribution" field in .changes files
> specifies that the field may contain a space-separated list of
> distributions. Whilst this is technically accurate, the feature has been
> deprecated since the "testing" distribution became an official part of
> the archive and is, imho, obsolete; the use case of uploading the same
> package to unstable and the frozen-stable-to-be as a single upload no
> longer applies.
>
> I discussed this with a couple of members of the ftpteam on IRC earlier
> today, and they were both in favour of removing support for the feature
> from dak. One of them had a dig through the archives and discovered that
> there have been no multiple-distribution uploads since 2004; even then
> there was only the one upload in that year, with the grand total of
> three in 2003.

This looks good to me in general.

The only concern that I have is that there are other archive maintenance
packages besides dak and some of them explicitly list multiple-
distribution upload support as a feature (reprepro, for instance).  Policy
is specifically intended to describe the requirements for packages that
are part of Debian, where dak matters the most, but this is specifically a
description of the *.changes *syntax*.  I'm a little unsure as to whether
we should make multiple distributions a syntax error, when other tools
support it, or instead just say that it's allowed in the syntax but the
Debian archive doesn't support it.

-- 
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#514938: alternatively...

[Kees Cook]

Attached is a gross alternative to depending on bash...

-- 
Kees Cook@debian.org
--- mkinitramfs~	2009-02-11 17:18:41.0 -0800
+++ mkinitramfs	2009-02-11 20:13:16.0 -0800
@@ -296,7 +296,24 @@
 fi
 
 [ "${verbose}" = y ] && echo "Building cpio ${outfile} initramfs"
-(cd "${DESTDIR}" && find . | cpio --quiet --dereference -o -H newc | gzip >"${outfile}") || exit 1
+(
+# work around lack of "set -o pipefail" for the following pipe:
+# cd "${DESTDIR}" && find . | cpio --quiet --dereference -o -H newc | gzip >"${outfile}"
+exec 3>&1
+eval `
+# http://cfaj.freeshell.org/shell/cus-faq-2.html
+exec 4>&1 >&3 3>&-
+{
+cd "${DESTDIR}" && find . 4>&-; echo "ec1=$?;" >&4
+} | {
+cpio --quiet --dereference -o -H newc 4>&-; echo "ec2=$?;" >&4
+} | gzip >"${outfile}"
+echo "ec3=$?;" >&4
+`
+if [ "$ec1" -ne 0 ]; then exit "$ec1"; fi
+if [ "$ec2" -ne 0 ]; then exit "$ec2"; fi
+if [ "$ec3" -ne 0 ]; then exit "$ec3"; fi
+) || exit $?
 
 if [ -s "${__TMPCPIOGZ}" ]; then
 	cat "${__TMPCPIOGZ}" >>"${outfile}" || exit 1

Bug#514947: libplrpc-perl: FTBFS: Missing Build-Depends

[Daniel Schepler]

Package: libplrpc-perl
Version: 0.2020-1
Severity: serious

From my pbuilder build log:

...
# Add here commands to compile the package.
/usr/bin/perl Makefile.PL INSTALLDIRS=vendor
Checking for Sys::Syslog ... ok
Checking if your kit is complete...
Looks good
Warning: prerequisite Net::Daemon 0.13 not found.
Writing Makefile for RPC::PlServer
/usr/bin/make OPTIMIZE="-O2 -g -Wall"
make[1]: Entering directory `/tmp/buildd/libplrpc-perl-0.2020'
perldoc -t lib/RPC/PlServer.pm >README
You need to install the perl-doc package to use this program.
make[1]: *** [README] Error 1
make[1]: Leaving directory `/tmp/buildd/libplrpc-perl-0.2020'
make: *** [build-stamp] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
-- 
Daniel Schepler




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

Bug#471408: ITA: jabber -- An instant messaging server using the Jabber/XMPP protocol

[miguel]

retitle 471408 ITA: jabber -- An instant messaging server using the Jabber/XMPP 
protocol
owner 471408 Miguel Landaeta 
thanks



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

Bug#514945: gstreamer0.10: FTBFS: Bad bison version check

[Daniel Schepler]

Package: gstreamer0.10
Version: 0.10.20-1
Severity: serious

From my pbuilder build log:

...
checking for perl... /usr/bin/perl
checking for bison... /usr/bin/bison
checking bison version 2.4.1 >= 1.875... Argument "^B^D^A" isn't numeric in 
numeric lt (<) at - line 1.
configure: error: no
make: *** [config.status] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
-- 
Daniel Schepler




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

Bug#514946: ghc6: ghci segfaults on powerpc

[Shyamal Prasad]

Package: ghc6
Version: 6.10.1+dfsg1-6
Severity: important
Tags: experimental

shya...@turtle:~$ dpkg-architecture -qDEB_HOST_ARCH
powerpc
shya...@turtle:~$ uname -r
2.6.26-1-powerpc
shya...@turtle:~$ ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
Segmentation fault
shya...@turtle:~$

Please note that ghc6 6.8.2-dfsg1.1 in testing can be used to build a
registerised ghc on this machine that will actually start ghci (and
work properly as far as I know). So this is not the same bug as
#365497 and is a different regression problem.

Specifically I can verify #365497 is fixed in 6.8.2 if I build a
registerised ghc from the source package and try to reproduce it :

shya...@turtle:/tmp$ cat test.hs
module Bug where

data Test = Const Integer deriving (Show)
shya...@turtle:/tmp$ ghci test.hs
GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
[1 of 1] Compiling Bug  ( test.hs, interpreted )
Ok, modules loaded: Bug.
*Bug> Const 1
Const 1
*Bug>

So that one was fixed a while ago but 6.8.2 was just never built
registerised on powerpc...

Cheers!
Shyamal

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (600, 'testing'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.26-1-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages ghc6 depends on:
ii  gcc  4:4.3.2-2   The GNU C compiler
ii  libc62.7-18  GNU C Library: Shared libraries
ii  libedit-dev  2.11~20080614-1 BSD editline and history libraries
ii  libedit2 2.11~20080614-1 BSD editline and history libraries
ii  libffi-dev   3.0.7-1 Foreign Function Interface library
ii  libffi5  3.0.7-1 Foreign Function Interface library
ii  libgmp3-dev  2:4.2.2+dfsg-3  Multiprecision arithmetic library 
ii  libgmp3c22:4.2.2+dfsg-3  Multiprecision arithmetic library
ii  libncurses5  5.7+20081213-1  shared libraries for terminal hand
ii  perl [perl5] 5.10.0-19   Larry Wall's Practical Extraction 

ghc6 recommends no packages.

Versions of packages ghc6 suggests:
pn  ghc6-doc   (no description available)
pn  ghc6-prof  (no description available)
pn  haskell-doc(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#514941: RFP: libtest-prereq-perl -- check if Makefile.PL has the right pre-requisites

[Rene Mayorga]

block 514390 by 514941
thanks

On Wed, Feb 11, 2009 at 09:07:49PM -0500, Jonathan Yu wrote:
> Hi:

Hi Jonathan,

> 
> I don't know if you can really skip modules in the Perl core, since
> which modules are included in Perl core vary based on your Perl
> distribution.

IMHO, Module::CoreList can be helpfully here, since Module::CoreList is 
part of the main perl distribution and already contains info of the
modules that suppose to be on the Perl core distribution.

> But I guess this is more of something to bring up with b d foy

Indeed, can be tricky to just assume that all people distribute
Perl core as it supposed to be distributed(like Module::CoreList think).
but there are some more tests involved.

> I'd be interested to see how many people really use this module "in the wild".

actually I'm packaging this as a Dependency for Test-Apocalypse (ITP #514390)
so, there are people already using this module :)

Cheers.
-- 
Rene Mauricio Mayorga   |  jabber: rmayo...@jabber.org
http://rmayorga.org |  
--
08B6 58AB A691 DD56 C30B  8D37 8040 19FA A209 C305


signature.asc
Description: Digital signature

Bug#514841: [Pkg-bluetooth-maintainers] Bug#514841: gnome-bluetooth: gnome-obex-send doesn't send a file correctly if the filename contains non-ASCII characters.

[Morita Sho]

Thanks for your quick reply.

On 02/12/2009 12:06 AM, Filippo Giunchedi wrote:
> out of curiosity: does this work sending with bluetooth-applet (package
> bluez-gnome) ?

I'm not sure but bluetooth-applet/bluez-gnome package does not use libbtctl
library, therefore modifying libbtctl does not affect bluez-gnome
functionality.

To confirm my guess above, I have tested to check if sending with
bluetooth-applet works or not with a non-ASCII filename by the
following instruction:

Right-click on the bluetooth-applet then click "Send File...", select a file
named "β.txt" and send it to my mobile phone, hcidump outputs the following:

< ACL data: handle 38 flags 0x02 dlen 55
L2CAP(d): cid 0x0041 len 51 [psm 3]
  RFCOMM(d): UIH: cr 1 dlci 2 pf 0 ilen 47 fcs 0x9a
OBEX: Put cmd(f): len 47
Name (0x01) = Unicode length 12
: 03 b2 00 2e 00 74 00 78  00 74 00 00  .t.x.t..

The character 'β' seems to be correctly translated to "03 B2". So that I think
there is no Unicode conversion problems in sending with bluetooth-applet.

Let me know if you need more information.


Thanks,

-- 
Morita Sho 



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

Bug#511185: Lincense of Crypt-Twofish CPAN module

[Abhijit Menon-Sen]

Hi Damyan.

I apologise for the delayed response.

At 2009-01-08 13:28:53 +0200, d...@debian.org wrote:
>
> My question is, is the license that is mentioned above the same one
> that is used by Perl?

Yes, it is.

> If it is, it would be nice to change the license statement [...]

You're right, I'll do that.

-- ams



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

Bug#285888: Always a pleasure never a problem. Leslie

[leslie27]

Sent via BlackBerry from T-Mobile



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

Bug#285888: Info received (How are you and what are you doing inmy hometown? Leslie MOntaNaro)

[leslie27]

Call me 727 2511770 Leslie
--Original Message--
From: Debian Bug Tracking System
Sender: 
To: lesli...@tmo.blackberry.net
ReplyTo: DR deejay Delbert Nixon
Sent: Feb 11, 2009 9:57 PM
Subject: Bug#285888: Info received (How are you and what are you doing inmy 
hometown? Leslie MOntaNaro)


Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian CD-ROM Team 

If you wish to submit further information on this problem, please
send it to 285...@bugs.debian.org, as before.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.


-- 
285888: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285888
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


Sent via BlackBerry from T-Mobile

Bug#285888: How are you and what are you doing in my hometown? Leslie MOntaNaro

[leslie27]

Sent via BlackBerry from T-Mobile



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

Bug#514849: tested with bare Etch amd64 on the same hardware

[Vsevolod Sipakov]

Hi!

I tested opensync-plugin-irmc 0.19 - it works:

Installed Etch with debootstrap inside Lenny.
msynctool with the same configs just works (inside chroot):
---
r...@vs-work:/root/.opensync/group1# msynctool --sync yy
Synchronizing group "yy"
Member 1 of type file-sync just connected
Member 2 of type irmc-sync just connected
All clients connected or error
Member 1 of type file-sync just sent all changes
Received an entry 00010001 with data of size 8 from member 2. 
Changetype ADDED
Received an entry 00010003 with data of size 8 from member 2. 
Changetype ADDED

<...skipped...>
Sent an entry 0002011C of size 40 to member 1. Changetype ADDED
Sent an entry 0002006F of size 40 to member 1. Changetype ADDED
Member 1 of type file-sync committed all changes.
All clients have written
Member 1 of type file-sync just disconnected
Member 2 of type irmc-sync just disconnected
All clients have disconnected
The sync was successful
-
I can send vCal entries to maintainer if it will help (but I really 
doubt it :-)


opensync-plugin-irmc from Experimental cannot be installed: 
libopensync1exp3 is missing


Is there anybody else using opensync irmc plugin? :-)

Best regards,
 Vsevolod Sipakov


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#514741: evince: full screen navigation in documents created by LaTeX-Beamer requires two scrolling actions

[Denis Laxalde]

Josselin Mouette a écrit :

I can reproduce this with evince 2.22, but not with evince 2.24 from
experimental. Could you confirm?



No, I tried with evince 2.24 from experimental on Sid (x86) and the 
problem is the same.





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

Bug#514944: expr: false negatives (expr match)

[Trent W. Buck]

Package: coreutils
Version: 6.10-6
Severity: normal
File: /usr/bin/expr

In the following transcript, the second invocation of expr should exit
successfully.

13:22 <\amethyst> hm, yeah, GNU expr is buggy
13:22 <\amethyst> # expr fooar : 'foob*ar'; echo $?
13:22  \amethyst: 5
13:22  \amethyst: 0
13:22 <\amethyst> # expr fooar : 'foo\(b\)*ar'; echo $?
13:22  \amethyst:
13:22  \amethyst: 1
13:23 <\amethyst> # expr foobar : 'foo\(b\)*ar'; echo $?
13:23  \amethyst: b
13:23  \amethyst: 0

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

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

Versions of packages coreutils depends on:
ii  libacl1   2.2.47-2   Access control list shared library
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libselinux1   2.0.65-5   SELinux shared libraries

coreutils recommends no packages.

coreutils 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#510323: mozilla-noscript: Me Too - Unable to Enable an Object by Clicking It

[Dave Allen Barker Jr]

Package: mozilla-noscript
Version: 1.6.9.3-1
Followup-For: Bug #510323


Me too.

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

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

Versions of packages mozilla-noscript depends on:
ii  iceweasel 3.0.6-1lightweight web browser based on M

mozilla-noscript recommends no packages.

mozilla-noscript 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#514941: RFP: libtest-prereq-perl -- check if Makefile.PL has the right pre-requisites

[Jonathan Yu]

Hi:

I don't know if you can really skip modules in the Perl core, since
which modules are included in Perl core vary based on your Perl
distribution.

But I guess this is more of something to bring up with b d foy

I'd be interested to see how many people really use this module "in the wild".

Cheers,

Jonathan

On Wed, Feb 11, 2009 at 8:40 PM, Rene Mayorga  wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name: libtest-prereq-perl
>  Version : 1.036
>  Upstream Author : brian d foy 
> * URL : http://search.cpan.org/dist/Test-Prereq/
> * License : GPL/Artistic
>  Programming Lang: Perl
>  Description : check if Makefile.PL has the right pre-requisites
>
>  Test::Prerq examines the modules looking on blib/lib/,
>  blib/script, and the test files t/*  (and test.pl).
>  then figures out which modules they use, skips the modules that are
>  in the Perl core, and compares the remaining list of modules to
>  those in the PREREQ_PM section of Makefile.PL.
>
>
> This package will be maintained under the Debian Perl Group umbrella
>
> --
> Rene Mauricio Mayorga   |  jabber: rmayo...@jabber.org
> http://rmayorga.org |
> --
> 08B6 58AB A691 DD56 C30B  8D37 8040 19FA A209 C305
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJk34JgEAZ+qIJwwURAmDZAJ9U9eDibmLyny0n0KmXbmzWuN5FagCfSLW0
> SD6CsTRP8+4fQKZx1699AIw=
> =WrEI
> -END PGP SIGNATURE-
>
>



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

Bug#514179: CVE-2009-0413: possible XSS issue

[Vincent Bernat]

OoO Pendant le journal télévisé du mercredi 11 février 2009, vers 20:20,
Holger Levsen  disait :

>> The future 0.2stable will need more  work (even for lenny) since it uses
>> mdb.

> hmpf. 0.2 stable is not really future (as you'll know), but current. So I 
> expect 0.2alpha to also have important issues which are fixed in 0.2.x in the 
> short or long run, so no real gain IMHO...

Well, it does not have this XSS issue, so it is an improvement over 0.1.1.
-- 
die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs);
2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c


pgpuWDBirYDDt.pgp
Description: PGP signature

Bug#514941: Acknowledgement (RFP: libtest-prereq-perl -- check if Makefile.PL has the right pre-requisites)

[Rene Mayorga]

# errr, I actually mean ITP, retitling this bug...
retitle 514941 ITP: libtest-prereq-perl -- check if Makefile.PL has the right 
pre-requisites
thanks

-- 
Rene Mauricio Mayorga   |  jabber: rmayo...@jabber.org
http://rmayorga.org |  
--
08B6 58AB A691 DD56 C30B  8D37 8040 19FA A209 C305


signature.asc
Description: Digital signature

Bug#514942: svn-buildpackage: lists wrong .changes (and .debs) when building source-only

[Evgeni Golov]

X-Debbugs-Cc: k...@debian.org
Package: svn-buildpackage
Version: 0.6.23
Severity: normal

I've just had a build of pokerth first with binaries, later without (-S).
The second call produced the following output from svn-bp:
dpkg-buildpackage: source only upload (original source is included)
build command was successful; binaries are in 
/home/zhenech/debian/pkg-games/packages/build-area/. The changes file is:
 
/home/zhenech/debian/pkg-games/packages/build-area/pokerth_0.6.3-2-1_i386.changes
Binary packages:
 
/home/zhenech/debian/pkg-games/packages/build-area/pokerth-data_0.6.3-2-1_all.deb
 /home/zhenech/debian/pkg-games/packages/build-area/pokerth_0.6.3-2-1_i386.deb 
/home/zhenech/debian/pkg-games/packages/build-area/pokerth-server_0.6.3-2-1_i386.deb

But I built source only, so it is _source.changes and no binary packages at 
all.

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

Kernel: Linux 2.6.28-x31-1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages svn-buildpackage depends on:
ii  devscripts  2.10.45  scripts to make the life of a Debi
ii  file4.26-2   Determines file type using "magic"
ii  libsvn-perl 1.5.1dfsg1-2 Perl bindings for Subversion
ii  liburi-perl 1.37+dfsg-1  Manipulates and accesses URI strin
ii  perl5.10.0-19Larry Wall's Practical Extraction 
ii  subversion  1.5.1dfsg1-2 Advanced version control system
ii  unp 1.0.15   unpack (almost) everything with on
ii  wget1.11.4-2 retrieves files from the web

svn-buildpackage recommends no packages.

svn-buildpackage suggests no packages.

-- no debconf information


-- 
Bruce Schneier Fact Number 102:
The birthday referred to in the 'Birthday Attack' is Bruce Schneier's.


pgpqU3d6irvGB.pgp
Description: PGP signature

Bug#514943: network-manager: wired connection remains with wireless associated and no cable

[Drew Parsons]

Package: network-manager
Version: 0.7.0-1
Severity: normal

A change in network-manager behaviour appears to have been triggered
by the 2.6.28 linux kernel.

Up till now, I've had network-manager automatically connect to and
switch between wired and wireless networks.  At work I insert the
cable, and my wired connection is set up.  I take my laptop home, and
it finds my wireless network, the wired connection is switched off.

Now all of a sudden I've found that when I get home, the wired
connection is still on, even though no cable is inserted to the
ethernet jack.  At the same time the wireless network is still found
and set up.  But because nm has already set up the eth0 interface, the
gateway and dns (/etc/resolve.conf) is not rewritten. wlan0 is routed
to the local network only, the gateway is still set to the eth0
address.  So I can't connect properly to the external internet from
home.  

The only way I know to work around the problem is to switch off
"Connects automatically" in the nm configuration entry for the wired
network.  This makes it less convenient at work, where previously I
just had to plug in the cable for nm to set up the connection.

As far as I can tell the only change I've made to cause this new
behaviour is to install a 2.6.28 kernel (well, bind9-host also got
upgraded over the weekend along with associated libraries).

Thanks,
Drew

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

Kernel: Linux 2.6.28.4 (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 network-manager depends on:
ii  adduser3.110 add and remove users and groups
ii  dbus   1.2.1-5   simple interprocess messaging syst
ii  hal0.5.11-8  Hardware Abstraction Layer
ii  ifupdown   0.6.8+nmu1high level tools to configure netw
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  libdbus-1-31.2.1-5   simple interprocess messaging syst
ii  libdbus-glib-1-2   0.76-1simple interprocess messaging syst
ii  libgcrypt111.4.1-2   LGPL Crypto library - runtime libr
ii  libglib2.0-0   2.16.6-1  The GLib library of C routines
ii  libgnutls262.4.2-6   the GNU TLS library - runtime libr
ii  libgpg-error0  1.4-2 library for common error values an
ii  libhal10.5.11-8  Hardware Abstraction Layer - share
ii  libnl1 1.1-3 library for dealing with netlink s
ii  libnm-glib00.7.0-1   network management framework (GLib
ii  libnm-util10.7.0-1   network management framework (shar
ii  libpolkit-dbus20.9-2 library for accessing PolicyKit vi
ii  libpolkit2 0.9-2 library for accessing PolicyKit
ii  libtasn1-3 1.5-1 Manage ASN.1 structures (runtime)
ii  libuuid1   1.41.3-1  universally unique id library
ii  lsb-base   3.2-20Linux Standard Base 3.2 init scrip
ii  wpasupplicant  0.6.5-2   client support for WPA and WPA2 (I
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

Versions of packages network-manager recommends:
ii  network-manager-gnome  0.7.0-1   network management framework (GNOM
ii  policykit  0.9-2 framework for managing administrat
ii  ppp2.4.4rel-10.1 Point-to-Point Protocol (PPP) - da

Versions of packages network-manager suggests:
ii  avahi-autoipd 0.6.23-4   Avahi IPv4LL network address confi

-- 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#514940: Typo in alsaconf

[Thomas Bliesener]

Package: alsa-utils
Version: 1.0.16-2
Severity: minor
Tags: patch

--- /tmp/alsaconf   2009-02-11 19:41:06.583057786 -0600
+++ /tmp/alsaconf_new   2009-02-11 19:41:14.295068869 -0600
@@ -462,7 +462,7 @@
 
   Please notice, that sound configuration with this script
   is not needed if you are running testing/sid with an up
-  to date kernel and your sound device is a suopported PCI
+  to date kernel and your sound device is a supported PCI
   one. In that case *udev* is predestinated to load your
   driver ;)
   But any way, you can finish this procedure with a working



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

Bug#513535: Online Google Promo 2009

[CLAIMS ANNIVERSARY PROMO]

Your E-mail has Won in our End Of Year Online Anniversary
Promotion.SEND WINNING DETAILS:Computer Generated Profile
Numbers (CGPN):7-22-71-00-66-12,Ticket number:00869575733664
Serial numbers:/BTD/8070447706/06 Lucky
numbers:12-12-23-35-40-41(12)To:Mr.Francis Henson
Email:fhenso...@mybestmail.com Thanks For Using Google.




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

Bug#514941: RFP: libtest-prereq-perl -- check if Makefile.PL has the right pre-requisites

[Rene Mayorga]

Package: wnpp
Severity: wishlist

* Package name: libtest-prereq-perl
  Version : 1.036
  Upstream Author : brian d foy 
* URL : http://search.cpan.org/dist/Test-Prereq/
* License : GPL/Artistic
  Programming Lang: Perl
  Description : check if Makefile.PL has the right pre-requisites

 Test::Prerq examines the modules looking on blib/lib/,
 blib/script, and the test files t/*  (and test.pl). 
 then figures out which modules they use, skips the modules that are
 in the Perl core, and compares the remaining list of modules to
 those in the PREREQ_PM section of Makefile.PL.


This package will be maintained under the Debian Perl Group umbrella

-- 
Rene Mauricio Mayorga   |  jabber: rmayo...@jabber.org
http://rmayorga.org |  
--
08B6 58AB A691 DD56 C30B  8D37 8040 19FA A209 C305


signature.asc
Description: Digital signature

Bug#514939: iceweasel: right-click searching does not select the appropriate engine in fullscreen

[Luís Picciochi Oliveira]

Package: iceweasel
Version: 3.0.5-1
Severity: normal


  When one selects some text and right-clicks somewhere in the page, the 
currently selected search engine will be used for the search option. 
However, when in fullscreen mode (by pressing F11), the first 
search engine in the list will always be used, regardless of which is 
currently selected.
  The only way to use the currently selected search engine while in 
fullscreen is to make the toolbar visible, by moving the mouse pointer 
to the top of the screen. In this case, the currently selected engine 
will be used to search when right clicking when have some selected text.

  I believe the currently selected search engine should be the one to 
use when using the right-click search feature, whether the toolbar is 
currently visible in fullscreen mode or not.

Regards,
  Luís Picciochi

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

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

Versions of packages iceweasel depends on:
ii  debianutils  2.30Miscellaneous utilities specific t
ii  fontconfig   2.6.0-3 generic font configuration library
ii  libc62.7-18  GNU C Library: Shared libraries
ii  libgcc1  1:4.3.2-1.1 GCC support library
ii  libglib2.0-0 2.18.3-1The GLib library of C routines
ii  libgtk2.0-0  2.14.5-1The GTK+ graphical user interface 
ii  libnspr4-0d  4.7.1-4 NetScape Portable Runtime Library
ii  libstdc++6   4.3.2-1.1   The GNU Standard C++ Library v3
ii  procps   1:3.2.7-11  /proc file system utilities
ii  psmisc   22.6-1  Utilities that use the proc filesy
ii  xulrunner-1.91.9.0.5-1   XUL + XPCOM application runner

iceweasel recommends no packages.

Versions of packages iceweasel suggests:
pn  latex-xft-fonts(no description available)
ii  libkrb53  1.6.dfsg.4~beta1-5 MIT Kerberos runtime libraries
pn  mozplugger (no description available)
pn  ttf-mathematica4.1 (no description available)
pn  xfonts-mathml  (no description available)
pn  xprint (no description available)
ii  xulrunner-1.9-gnome-s 1.9.0.5-1  Support for GNOME in xulrunner app

-- 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#514807: Regression in libgnutls security update

[Daniel Kahn Gillmor]

On 02/11/2009 06:05 PM, Florian Weimer wrote:
> I think it is somewhat debatable if this also applies to the root CA
> container, where the X.509 structure is just use as a transport for
> key material.  The RSA-MD5 signature does not hurt there, and the DN
> doesn't really matter, either.  The risk I see is that someone adds a
> v1 *server* certificate to the trusted list, without realizing that it
> will act as a *CA* certificate in this place.

if the trusted certificate list were simply a "root CA container", then
i'd agree with you that V1 certificates are acceptable there.  But
that's not how the list is treated (or has ever been treated, to my
knowledge) in GnuTLS.

I think your last sentence makes it clear what the risks are.  GnuTLS
declares that the trusted certificate list is for holding *any type of*
trusted certificate.  If a given trusted certificate is a server
(end-entity) cert, then the remote party will be validated if it offers
that exact certificate (and if its name matches, and it can prove
possession of the corresponding secret key, presumably).  If a given
trusted certificate is a CA cert, then any certificate chain where the
end entity certificate matches the name of the remote party, and which
is rooted in the trusted CA cert will be accepted.

These are two different ways to use the trusted certificate list, and
they are distinguished by the *type* of certificate added to the list.
IIUC, Nikos' post indicates that there is no way to distinguish a V1 CA
certificate from an end-entity certificate.  So adding one to any
trusted store is inherently a risky activity, particularly if you're
adding a certificate that you expect to be an end-entity instead of a
CA.  GnuTLS has no way of knowing what the user's intent is here.

One option, of course, is to change the interface of GnuTLS to cleanly
separate out trusted peer certificates from trusted CA certificates in
the API.  This would permit users to specify how they intend to use a
given V1 cert.  Of course, this would also require an API change,
potentially an soname bump, etc.  In the absence of such a change, i
think it's safer to strongly deprecate V1 certificates (as has been
documented for years, if not enforcced), and let applications which
choose to treat the trusted certificate list solely as a CA store
specify so explicitly with GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT.

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature

Bug#514938: find/cpio exit codes ignored while building initramfs

[Kees Cook]

Package: initramfs-tools
Version: 0.92o
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jaunty ubuntu-patch

The final stage of mkinitramfs that builds the image does not verify the
exit codes of find or cpio:

(cd "${DESTDIR}" && find . | cpio --quiet --dereference -o -H newc | gzip 
>"${outfile}") || exit 1

Once bug 514936 is solved, this will be even more important, since cpio
will actually return errors.  In bash, there is support for checking more
than just the final pipe command's exit code via the "pipefail" option.

Attached patch adds this behavior, and make sure the script uses bash (to
avoid future dash/bash migration issues).

Current behavior:

$ find /fail | cpio --quiet --dereference -o -H newc | gzip > /tmp/archive.gz
find: `/fail': No such file or directory
$ echo $?
0

Desired behavior:

$ set -o pipefail
$ find /fail | cpio --quiet --dereference -o -H newc | gzip > /tmp/archive.gz
find: `/fail': No such file or directory
$ echo $?
1


Also, I would recommend adding "-e" to the shell to catch single-command
failures during execution, though that's out of scope for this particular
bug.

Thanks!

-Kees

-- 
Kees Cook@debian.org
--- mkinitramfs~	2009-02-11 17:18:41.0 -0800
+++ mkinitramfs	2009-02-11 17:19:40.0 -0800
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 umask 0022
 export PATH='/usr/bin:/sbin:/bin'
@@ -296,6 +296,7 @@
 fi
 
 [ "${verbose}" = y ] && echo "Building cpio ${outfile} initramfs"
+set -o pipefail
 (cd "${DESTDIR}" && find . | cpio --quiet --dereference -o -H newc | gzip >"${outfile}") || exit 1
 
 if [ -s "${__TMPCPIOGZ}" ]; then

Bug#514147: linux-image-2.6.26-1-686: lenny gets sometimes stuck while booting in system

[dann frazier]

On Thu, Feb 12, 2009 at 02:09:29AM +0100, Bastian Blank wrote:
> tags 514147 moreinfo
> thanks
> 
> On Wed, Feb 04, 2009 at 07:25:02PM +0100, clue wrote:
> > ** Tainted: P (1)
> 
> We can't and won't support binary-only crap.
> 
> Please reproduce without.

Assuming you can reproduce without, it'd be helpful to try and capture
backtraces of the running processes. Alt+SysRQ+t will do this. If it
works, it will produce a lot of output, so I'd suggest hooking up a
serial console if you have one.

-- 
dann frazier




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

Bug#514937: It would be nice if dhclient-script would block zlob.dnschanger

[Boran Car]

Package: dhcp3-client
Version: 3.1.1-6

A certain trojan exists which mimics the functionality of a DHCP server 
by pointing computers who receive this false DHCP information to an 
unsafe DNS server (in most cases 85.255.x.x). This DNS server helps 
spread infection on Windows machines. Although Linux is safe, it still 
gets the 85.255.x.x DNS server address which is blocked on most routers 
today, therefore blocking an internet connection. Please find attached a 
patch I have created for blocking this blacklisted DNS server. I hope it 
will evolve into a more advanced blacklisted DNS server blocker.


I am using Debian GNU/Linux 5.0 Lenny.


dhclient_script-blacklist_85.255.x.x.patch.gz
Description: GNU Zip compressed data

Bug#514903: ITP: pymca -- Python toolkit and application for X-ray fluorescence analysis

[Chris Walker]

Teemu Ikonen  writes:

> 
> * Package name: pymca

[snip]

I've added it to the science-physics task. 
> 
> Prelimary packages will be soon at the Debian Science repository
> at git.debian.org.
> 

When it is, if you let me know I'll add that information to the task too. 

Chris




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

Bug#514147: linux-image-2.6.26-1-686: lenny gets sometimes stuck while booting in system

[Bastian Blank]

tags 514147 moreinfo
thanks

On Wed, Feb 04, 2009 at 07:25:02PM +0100, clue wrote:
> ** Tainted: P (1)

We can't and won't support binary-only crap.

Please reproduce without.

Bastian

-- 
Men of peace usually are [brave].
-- Spock, "The Savage Curtain", stardate 5906.5



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

Bug#508432: [libnet-pcap-perl] Fwknop fails with a segmentation fault on i386

[Sébastien Aperghis-Tramoni]

Gunnar Wolf a écrit :


Hi,


Hello,


Any news on this bug? Last action says you needed two days... two
weeks ago.


My fault as well. I haven't answered Franck yet.

Franck, I never saw warnings such as the ones you sent me, even with - 
Wall. I'll check again the different CPAN Testers FAIL reports, but  
last time I did, I saw no such warnings. Which version of gcc, Perl,  
libpcap and Net::Pcap are you using? I'll try tomorrow to compile  
Fwknop on my Linux station at work and see if I can reproduce this.



--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.




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

Bug#514833: linux-image-2.6.18-6-686: sundance network driver get timeout on a DFE-580TX when this kernel is installed

[Bastian Blank]

On Wed, Feb 11, 2009 at 07:13:41PM +0100, Benoit Mortier wrote:
> Le Wednesday 11 February 2009 11:47:45 maximilian attems, vous avez 
> écrit :
> > On Wed, Feb 11, 2009 at 10:56:25AM +0100, Benoit Mortier wrote:
> > > Package: linux-image-2.6.18-6-686
> > > Version: 2.6.18.dfsg.1-24
> > > Severity: grave
> > > Justification: causes non-serious data loss
> >
> > inflated severity, stop doing this.
> 
> Sorry but this is not inflated, those 4 port card are mainly used in 
> router and firewall, and this breakage have big consequences.

You justified it with data loss. This can't happen as ethernet is not
reliable anyway and the upper protocols have to deal with this.

The second justification would be: is broken for everyone. This is also
not true.

Anything is else up to the maintainer.

Bastian

-- 
"... freedom ... is a worship word..."
"It is our worship word too."
-- Cloud William and Kirk, "The Omega Glory", stardate unknown



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

Bug#512589: fw_setenv: Cannot malloc -131072 bytes: Cannot allocate memory

[Luca Capello]

Hi Timo!

On Thu, 12 Feb 2009 01:44:57 +0100, Timo Juhani Lindfors wrote:
> Luca Capello  writes:
>> I packaged that version (available at [2]) and indeed it works.  Timo,
>> can you confirm it, please?
>
> $ sudo fw_printenv
> Too few good blocks within range

/usr/share/doc/uboot-envtools/README:

  DEVICEx_ENVSECTORS defines the number of sectors that may be used for
  this environment instance. On NAND this is used to limit the range
  within which bad blocks are skipped, on NOR it is not used.

This means that (/usr/share/doc/uboot-envtools/fw_env.config):

--8<---cut here---start->8---
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundand
# environment sector is assumed present.
# Notice, that the "Number of sectors" is ignored on NOR.

# MTD device name   Device offset   Env. size   Flash sector size   
Number of sectors
/dev/mtd2   0x  00040002
2
--8<---cut here---end--->8---

Thx, bye,
Gismo / Luca


pgpXr634loujV.pgp
Description: PGP signature

Bug#514936: cpio does not use error codes on exit

[Kees Cook]

Package: cpio
Version: 2.9-14
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jaunty ubuntu-patch

It seems that cpio does not actually use the error codes it sets while
running, and always exits with 0.  This will break anything that expects
cpio to fail if it encounter problems (like, say, mkinitramfs).

All the error handling code is in paxlib, which includes the "pax_exit()"
function.  src/main.c's main should call pax_exit, not "exit (0)" like it
currently does.

Example:

$ cd /tmp/busticated
$ ls -lR
.:
total 4
drwxr-xr-x 2 kees kees 4096 Feb 12 00:27 sbin

./sbin:
total 0
lrwxrwxrwx 1 kees kees 20 Feb 12 00:27 no-such-binary -> /sbin/no-such-binary

What current happens with failures:

$ find . | cpio -L -o > /tmp/archive.cpio
cpio: ./sbin/no-such-binary: No such file or directory
1 block
$ echo $?
0

I would expect this instead:

$ find . | cpio -L -o > /tmp/archive.cpio
cpio: ./sbin/no-such-binary: No such file or directory
1 block
$ echo $?
2


Attached trivial patch changes the behavior...

-Kees

-- 
Kees Cook@debian.org
diff -u cpio-2.9/src/main.c cpio-2.9/src/main.c
--- cpio-2.9/src/main.c
+++ cpio-2.9/src/main.c
@@ -801,3 +801,3 @@
 
-  exit (0);
+  pax_exit ();
 }

Bug#512589: fw_setenv: Cannot malloc -131072 bytes: Cannot allocate memory

[Timo Juhani Lindfors]

Luca Capello  writes:
> I packaged that version (available at [2]) and indeed it works.  Timo,
> can you confirm it, please?

$ sudo fw_printenv
Too few good blocks within range

$ cat /etc/fw_env.config
# Configuration file for fw_(printenv/saveenv) utility.

# MTD device name   Device offset   Env. size   Flash sector size
/dev/mtd2   0x  00040002

$ dpkg -l uboot-envtools
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version  
Description
+++---
ii  uboot-envtools   20080909-1~gismo.1   
read/modify the environment for the bootloader U-Boot




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

Bug#512589: fw_setenv: Cannot malloc -131072 bytes: Cannot allocate memory

[Luca Capello]

tags 512589 + fixed-upstream
thanks

Hi there!

On Thu, 12 Feb 2009 00:38:41 +0100, Luca Capello wrote:
> On Thu, 22 Jan 2009 01:29:04 +0100, Timo Juhani Lindfors wrote:
>> I tried to add mem=127M boot option on openmoko neo freerunner but
>> fw_setenv seems to fail mysteriously:
[...]
> It would be good to test if a more recent version still generates
> this.

I am quite sure that this bug was an uptream one fixed by commit [1]:

  commit 5608692104efa8d56df803dc79ea41ac3607eee5
  Author: Guennadi Liakhovetski 
  Date:   Thu Sep 4 13:01:49 2008 +0200

  fw_env: add NAND support

  Add support for environment in NAND with automatic NOR / NAND
  recognition,
  including unaligned environment, bad-block skipping, redundant
  environment
  copy.

  Signed-off-by: Guennadi Liakhovetski 

I packaged that version (available at [2]) and indeed it works.  Timo,
can you confirm it, please?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 
http://git.denx.de/?p=u-boot.git;a=commit;h=5608692104efa8d56df803dc79ea41ac3607eee5
[2] http://people.debian.org/~gismo/tmp/uboot-envtools/


pgp35wCiETnvU.pgp
Description: PGP signature

Bug#513516: (no subject)

[Jan Engelhardt]

The kernel wants '\0' for algo, only pattern may be a 
non-'\0'-terminated string of up to 128 chars. Turns out iptables
calculates the ->patlen incorrectly. Will submit fix upstream, thanks.



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

Bug#514935: openoffice.org-calc: Power regressions are wrong.

[Kurt Roeckx]

Package: openoffice.org-calc
Version: 1:2.4.1-17

Hi,

I was trying to do a power regression in a chart, and the results are completly 
wrong.

It's a gamma curve, so the formula should be in the form of y = x^gamma, and 
the result I
have are very close to a gamma curve.  But the regression curve it's showing me
doesn't fit at all, and has a power that's clearly wrong.

Trying to fit it manually, I get a curve in that looks very close.  It's a 
gamma curve
near 2.3, so I should get something like 1 * x^2.3, but instead I get 0.68 * 
x^1.61.

If I generate the gamma curve myself, so with very small errors, and let it do
the regression on that, I do get the correct result.


Kurt




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

Bug#514934: miro: Alternate dependency on python-gnome2-extras-dev

[Iain Lane]

Package: miro
Version: 2.0-1ubuntu1
Severity: wishlist

Hi,

(Thanks for getting miro 2.0 out so swiftly; works great)

I was wondering if you could do Ubuntu a favour in your next upload.
Currently our miro package includes the following change to the
dependencies of miro:

- python-gtkmozembed (>= 2.19.1),
+ python-gnome2-extras (>= 2.19.1),

This is because we do not have the python-gtkmozembed package in Ubuntu.
I was wondering if it would be possible for you to provide an alternate
dependency of the form:

python-gtkmozembed (>= 2.19.1) | python-gnome2-extras (>= 2.19.1)

This change will allow us to get into sync (the other delta, dropping
the democracyplayer-data transitional package), can be dropped to make
this happen. Then we will be in the happy state where we can pull new
miro releases straight from Debian unmodified (and, at some points in
our release cycle, automatically).

Thank you for considering this request.

Iain

-- System Information:
Debian Release: lenny/sid
  APT prefers intrepid-updates
  APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500, 
'intrepid-proposed'), (500, 'intrepid-backports'), (500, 'intrepid')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.27-7-generic (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages miro depends on:
ii  libatk 1.24.0-0ubuntu1   The ATK accessibility toolkit
ii  libboo 1.34.1-11ubuntu1  set of date-time libraries based o
ii  libboo 1.34.1-11ubuntu1  filesystem operations (portable pa
ii  libboo 1.34.1-11ubuntu1  Boost.Python Library
ii  libboo 1.34.1-11ubuntu1  portable C++ multi-threading
ii  libc6  2.8~20080505-0ubuntu9 GNU C Library: Shared libraries
ii  libcai 1.8.0-0ubuntu1.1  The Cairo 2D vector graphics libra
ii  libfon 2.6.0-1ubuntu4generic font configuration library
ii  libfre 2.3.7-2ubuntu1FreeType 2 font engine, shared lib
ii  libgcc 1:4.3.2-1ubuntu12 GCC support library
ii  libgli 2.18.2-0ubuntu2   The GLib library of C routines
ii  libgtk 2.14.4-0ubuntu2   The GTK+ graphical user interface 
ii  libnsp 4.7.1+1.9-0ubuntu4NetScape Portable Runtime Library
ii  libpan 1.22.2-0ubuntu1   Layout and rendering of internatio
ii  libssl 0.9.8g-10.1ubuntu2.1  SSL shared libraries
ii  libstd 4.3.2-1ubuntu12   The GNU Standard C++ Library v3
ii  libx11 2:1.1.5-2ubuntu1.1X11 client-side library
ii  libxin 1.1.15-0ubuntu3.1intrepid1the xine video/media player librar
ii  libxin 1.1.15-0ubuntu3.1intrepid1the xine video/media player librar
ii  libxin 1.1.15-0ubuntu3.1intrepid1X desktop video output plugins for
ii  miro-d 2.0-1ubuntu1  GTK+ based RSS video aggregator da
ii  python 2.5.2-1ubuntu1An interactive high-level object-o
ii  python 0.82.4-2  simple interprocess messaging syst
ii  python 2.13.0-0ubuntu8   GTK+ bindings: Glade support
ii  python 2.22.3-0ubuntu1   Python bindings for the GNOME desk
ii  python 2.19.1-0ubuntu11  Python bindings for the GNOME desk
ii  python 2.13.0-0ubuntu8   Python bindings for the GTK+ widge
ii  python 2.4.1-1   Python interface to SQLite 3
ii  python 0.8.4 automated rebuilding support for P
ii  xulrun 1.9.0.6+nobinonly-0ubuntu0.8.10.1 XUL + XPCOM application runner
ii  zlib1g 1:1.2.3.3.dfsg-12ubuntu1  compression library - runtime

miro recommends 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#514877: locale-gen fails on ltsp-build-client

[Vagrant Cascadian]

reassign 514877 ltsp-server
thanks

On Wed, Feb 11, 2009 at 06:10:56PM +0200, Lars Noodén wrote:
> When trying to build an i386 ltsp on an AMD64,

what version of ltsp packages do you have installed:

  COLUMNS=200 dpkg -l 'ltsp*' | awk '/^ii/{print $2" "$3}'

> locale-gen seems to be missing from the ltsp build directory, the result
> is an error:
> 
>   # time ltsp-build-client --arch i386 --dist etch \
>   --mirror http://ftp.fi.debian.org/debian/
> 
>   I: Configuring tasksel...
>   I: Base system installed successfully.
>   chroot: cannot run command `locale-gen': No such file
>   or directory
>   error: LTSP client installation ended abnormally

this seems odd, as the code tests for the presence of locale-gen before running
it (since 2007-05-19, at least):

  if [ -f $ROOT/etc/locale.gen ] && [ -x $ROOT/usr/sbin/locale-gen ] ; then
  DEBIAN_FRONTEND=noninteractive DEBIAN_PRIORITY=critical LC_ALL=C chroot 
$ROOT /usr/sbin/locale-gen
  fi
 
> Linux mini 2.6.24-23-generic #1 SMP Thu Nov 27 18:13:46 UTC 2008 x86_64
> GNU/Linux

what version of Debian are you running? 

thanks!

live well,
  vagrant

p.s. in the future, please consider using the "reportbug" tool to help
get some of this information automatically.



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

Bug#514913: [Pkg-kde-extras] Bug#514913: digikam: crashes in image restoration tool

[Mark Purcell]

Wolfram,

Thanks for your bug reports.

I'll forward them upstream and see what they can come up with.

Mark




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

Bug#512047: (no subject)

[Jan Engelhardt]

I cannot reproduce this with any of

iptables 1.4.1.1
iptables 1.4.2
iptables 1.4.3-rc1

Hence tagging as fixed-upstream.



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

Bug#513122: gimp stuck querying plugin xsane, cannot start

[jidanni]

JB> See if you can find which backend is reponsible
JB> for the hang, by setting SANE_DEBUG_DLL to something like 128.

$ SANE_DEBUG_DLL=128 gimp
...
[dll] sane_exit: calling backend `agfafocus's exit function
[dll] sane_exit: calling backend `abaton's exit function
[dll] sane_exit: calling backend `net's exit function

At which point it hangs and I have to C-c C-c

gimp: terminated: Interrupt
(xsane:8568): LibGimp-WARNING **: xsane: gimp_flush(): error: Broken pipe

I hope that helps you find out what the problem is and if I will ever
be able to use gimp again.



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

Bug#463189: It has been restarted

[Alex Dănilă]

Work was started on a new and even more interesting version of 
Timevault, using rdiff and KDE technologies.

https://launchpad.net/timevaultng
I'd really love to see one of these two Timevaults in Debian.



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

Bug#514914: coreutils: date -s STRING does not accept localized format

[Michael Stone]

On Thu, Feb 12, 2009 at 12:11:39AM +0100, you wrote:

Natural for US citizens. Not so natural for others.


It's not natural for anyone. It's kinda-sorta, then doesn't do what you 
expect.



If locale based input parsing is doomed then the next logical solution
is using a common format, and ISO 8601 is fine in this case, but then it
should also be documented well! The manpage only talks about possible
*output* formats ( and only mentions --rfc-2822 and --rfc-3339 there).

From user's perspective, even one single *complete* example of date and
time setting somewhere on top of the manpage or in the --help output
would help a lot, but there is nothing. Just a short reference to some
"STRING".


Because, as I said, it isn't "a string". It's designed to take things 
like "last thursday" or "fortnight tuesday". The info docs hint at the 
complexity necessary for the documentation.



Which manpage? date(1) on my system says:

date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]]

So it looks like it should accept "-s 02112332" (for February 11th,
23:12). But it doesn't!


Note the lack of the "-s" in the quoted line. :-)

Mike Stone



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

Bug#514926: rolo: UTF-8 is broken

[Rafael Laboissiere]

package rolo
clone 514926 -1
retitle -1 rolo: Columns displayed wrongly in UTF-8
severity -1 normal
thanks

* Carsten Hey  [2009-02-11 23:36]:

> Package: rolo
> Severity: important
> 
> UTF-8 in rolo is broken, lines including UTF-8 are simply not displayed.
> 
> Build-depending on libncursesw5-dev and linking against menuw and formw
> (libncursesw5) instead of menu and form (libncurses5) fixes this partly.

Thanks for this bug report and for the suggestion on using libncursesw5-dev.
I already committed a fixed version of the package to SVN and will upload it
soon.

> I'd be happy when you would at least link against menuw and formw, feel
> free to set the severity of this bug to minor when the linking has been
> done but correctly displaying the columns has not yet been implemented.

This bug report will be closed when the new version will be uploaded.  I am
cloning it to a new bug report about the specific issue of column display,
which will be fixed later, eventually.

-- 
Rafael



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

Bug#512589: fw_setenv: Cannot malloc -131072 bytes: Cannot allocate memory

[Luca Capello]

user pkg-fso-ma...@lists.alioth.debian.org
usertags 512589 + config-uboot
thanks

Hi there!

For Timo: it seems you forgot to cc: the pkg-fso-maint mailing list.
For everyone: please keep the pkg-fso-maing mailing list list cc:ed.

On Thu, 22 Jan 2009 01:29:04 +0100, Timo Juhani Lindfors wrote:
> I tried to add mem=127M boot option on openmoko neo freerunner but
> fw_setenv seems to fail mysteriously:

FWIW, the very same error happens on my FR as well:
=
debian-gta02:~# free
 total   used   free sharedbuffers cached
Mem:120808  90196  30612  0   3748  39068
-/+ buffers/cache:  47380  73428
Swap:0  0  0

debian-gta02:~# fw_printenv | grep quiet
quiet=1

debian-gta02:~# fw_setenv quiet 0
Unlocking flash...
Done
Cannot malloc -131072 bytes: Cannot allocate memory
Error: can't write fw_env to flash

debian-gta02:~# fw_printenv | grep quiet
quiet=1

debian-gta02:~#
=

It would be good to test if a more recent version still generates this.

Thx, bye,
Gismo / Luca


pgpDU8Nqj2NLi.pgp
Description: PGP signature

Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main

[Steve McIntyre]

On Thu, Feb 12, 2009 at 12:14:02AM +0100, Frans Pop wrote:
>On Wednesday 11 February 2009, Steve McIntyre wrote:
>> In fact, simply looking at the lenny RC2 images you can see that
>> sources are in alphabetical order. We may as well simply not do
>> anything in the $(TASKDIR): target for a source-only build and save
>> the processing time. Agreed?
>
>I don't know. I'd have to check in detail why tasks get ignored (for which 
>I'm not motivated)

Because source-only discs do nothing with the tasks at all.

>and IMO this is the wrong time to be making such changes
>anyway. You're not going to get any real testing or feedback anymore
>before the release.

Understood. I'm looking into this now to help fix the bugs Enrico
raised, which I'm told are causing real problems for CDD users. From
review of the code, I'm quite certain it's not going to affect us for
our builds, but it should make a big difference for others.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"




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

Bug#514639: ITP: frei0r -- a minimalistic plugin API for video effects

[Luca Bigliardi]

On Wed, Feb 11, 2009 at 08:51 AM, Stefano Zacchiroli wrote:

> > You can follow the changes here:
> > http://git.dyne.org/index.cgi?url=frei0r/log/&h=debian
> 
> Any reason for the project for not being hosted on the git repo of
> collab-maint?

Along with the author we keep the debian stuff in a separate branch of
upstream git repository. It's the same approach we're using for other dyne
projects like freej and hasciicam.


luca

-- 
Beware of programmers who carry screwdrivers.
-- Leonard Brandwein

http://shammash.homelinux.org/ - http://www.artha.org/ - http://www.yue.it/



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

Bug#514456: Fwd: Bug#514456: imagemagick: Encoding photos to slideshow very slow

[Bastien ROUCARIES]

-- Forwarded message --
From: Michael Pavletich 
Date: Wed, Feb 11, 2009 at 11:42 PM
Subject: Re: Bug#514456: imagemagick: Encoding photos to slideshow very slow
To: Bastien ROUCARIES 


OK, thanks for that, I didn't know about the debugging shell.

Please see the attached txt file. I had to run it through 2x to get
the results, but I changed the duration and transition times and
limited it to a single image, so please take that into consideration
should you need to.

First run gave me the ending section, I interrupted the second run to
get the initial section, then I combined the 2 so you can see the
start and the finish without all the repetitive stuff in the middle as
each frame was processed.

Mike P
mich...@mikepav:~/Pictures/Toy_Library/Sand&Water$ sh -x /usr/bin/images2mpg -f 
DVD -n PAL -S 420mpeg2 -d 2 -t 2 -c 00 -o test.avi -i ./*.jpg   
   + trap CleanUp 2
+ VIDEO_FORMAT=XVCD
+ VIDEO_TYPE=PAL
+ PPMTOY4M_CHROMA_OPT='-S 420mpeg2'
+ VERBOSE=0
+ IMAGEDURATION=10
+ TRANSITIONENABLE=0
+ TRANSITIONDURATION=0
+ TEMPORARYFOLDER=
+ IMBINFOLDER=/usr/bin
+ MJPEGTBINFOLDER=/usr/bin
+ WITHGUI=0
+ CPT_IMG_FILE=0
+ '[' 16 == 0 ']'
+ test 16 -gt 0
+ OPTIONMESSAGE=-f
+ case $1 in
+ shift
+ '[' -z DVD ']'
+ VIDEO_FORMAT=DVD
+ shift
+ test 14 -gt 0
+ OPTIONMESSAGE=-n
+ case $1 in
+ shift
+ '[' -z PAL ']'
+ VIDEO_TYPE=PAL
+ shift
+ test 12 -gt 0
+ OPTIONMESSAGE=-S
+ case $1 in
+ shift
+ '[' -z 420mpeg2 ']'
+ PPMTOY4M_CHROMA_OPT='-S 420mpeg2'
+ shift
+ test 10 -gt 0
+ OPTIONMESSAGE=-d
+ case $1 in
+ shift
+ '[' -z 2 ']'
+ IMAGEDURATION=2
+ '[' 0 = 1 ']'
+ shift
+ test 8 -gt 0
+ OPTIONMESSAGE=-t
+ case $1 in
+ shift
+ '[' -z 2 ']'
+ '[' 1 = 1 ']'
+ DISSOLVEVALUEINC=2
+ TRANSITIONENABLE=1
+ shift
+ test 6 -gt 0
+ OPTIONMESSAGE=-c
+ case $1 in
+ shift
+ '[' -z 00 ']'
+ BACKGROUNDCOLOR=00
+ shift
+ test 4 -gt 0
+ OPTIONMESSAGE=-o
+ case $1 in
+ OLD_IFS='
'
+ IFS='"'
+ shift
+ '[' -z test.avi ']'
+ OUTPUT_MPEG_FILE=test.avi
+ IFS='
'
+ shift
+ test 2 -gt 0
+ OPTIONMESSAGE=-i
+ case $1 in
+ OLD_IFS='
'
+ IFS='"'
+ shift
+ '[' ./SW006_Little_Tikes_Water_Slide.jpg ']'
+ INPUT_IMAGE_FILES[CPT_IMG_FILE]=./SW006_Little_Tikes_Water_Slide.jpg
++ echo 1
+ CPT_IMG_FILE=1
+ shift
+ '[' ']'
+ IFS='
'
+ shift
+ test 0 -gt 0
+ '[' 0 = 1 ']'
+ '[' -z /usr/bin ']'
+ MONTAGE_BIN=/usr/bin/montage
+ COMPOSITE_BIN=/usr/bin/composite
+ CONVERT_BIN=/usr/bin/convert
+ IDENTIFY_BIN=/usr/bin/identify
+ '[' '!' -e /usr/bin/montage ']'
+ '[' '!' -e /usr/bin/composite ']'
+ '[' '!' -e /usr/bin/convert ']'
+ '[' '!' -e /usr/bin/identify ']'
+ '[' -z /usr/bin ']'
+ PPMTOY4M_BIN=/usr/bin/ppmtoy4m
+ YUVSCALER_BIN=/usr/bin/yuvscaler
+ MPEG2ENC_BIN=/usr/bin/mpeg2enc
+ MP2ENC_BIN=/usr/bin/mp2enc
+ OGG_BIN=/usr/bin/ogg123
+ MP3_BIN=/usr/bin/mpg123
+ MPLEX_BIN=/usr/bin/mplex
+ '[' '!' -e /usr/bin/ppmtoy4m ']'
+ '[' '!' -e /usr/bin/yuvscaler ']'
+ '[' '!' -e /usr/bin/mpeg2enc ']'
+ '[' '!' -e /usr/bin/mp2enc ']'
+ '[' '!' -e /usr/bin/ogg123 ']'
+ '[' '!' -e /usr/bin/mpg123 ']'
+ '[' '!' -e /usr/bin/mplex ']'
+ '[' 1 = 0 ']'
+ '[' 0 = 0 ']'
+ echo -e 

+ echo -e '\nNumber of image file(s)   :  1.'

Number of image file(s)   :  1.
+ echo -e 'Processing sequence :'
Processing sequence :
+ CPT=1
+ test 1 -gt 0
++ echo 0
+ INPUT_FILE_NAME=./SW006_Little_Tikes_Water_Slide.jpg
+ '[' 0 = 0 ']'
+ echo -e ./SW006_Little_Tikes_Water_Slide.jpg
./SW006_Little_Tikes_Water_Slide.jpg
+ '[' -s ./SW006_Little_Tikes_Water_Slide.jpg ']'
++ echo 0
+ CPT=0
+ test 0 -gt 0
++ date +%s
+ DATE_DEBUT=1234391383
+ '[' -z '' ']'
+ TMPFILENAME=1234391383
+ case $VIDEO_TYPE in
+ VIDEO_TYPE_LETTER=p
+ IMAGES_SEC=25
+ IMAGES_SEC_FORMAT=25:1
+ case $VIDEO_FORMAT in
+ VIDEO_FORMAT_NUMBER=8
+ '[' PAL = NTSC ']'
+ VIDEO_FORMAT=SIZE_720x576
+ BIT_RATE=8000
+ BUFFER_SIZE=230
+ VIDEOFORMAT_MESSAGE=DVD
+ AUDIO_WAVE_CONVERSION='-b 224 -r 48000 -s'
+ case $VERBOSE in
+ VERBOSITY=none
+ '[' -z '' ']'
+ '[' -z 00 ']'
+ MASK=1234391383.black.tmp.png
++ /usr/bin/convert xc:#00 -resize '768x576!' 1234391383.black.tmp.png
+ RET=
++ echo 50
+ NBFRAMEIMAGE=50
+ '[' 1 = 1 ']'
++ echo 50
+ NBFRAMETRANSITION=50
++ echo 2
+ TRANSITIONDURATION=2
++ echo 150
+ NBFRAMETOTAL=150
++ echo 6
+ TOTALDURATION=6
+ WARNINGTOTALDURATION=
+ '[' 0 = 1 ']'
+ '[' 0 = 0 ']'
+ echo -e 'Video format  : '\''DVD'\''.'
Video format  : 'DVD'.
+ echo -e 'Video type: '\''PAL'\''.'
Video type: 'PAL'.
+ '[' '' ']'
+ '[' '' ']'
+ echo -e 'Frames per second : '\''25'\''.'
Frames per second : '25'.
+ echo -e 'Image duration:  2 s.'
Image duration:  2 s.
+ echo -e 'Total video sequence duration :  6 s .'
Total video sequence duration :  6 s .
+ '[' 1 = 1 ']'
+ echo -e 'Transition frames :  50.'
Transition frames :  50.
+ echo -e 

Bug#514578: LDAP STARTTLS is broken

[Brian May]

Simon Josefsson wrote:

Can you provide more details what "works" and "not work" actually means
for you?  Output from gnutls-cli with -d 4711 and --print-cert helps.
The original failure in this bug report is the intended and documented
behaviour, so if you really are seeing the same problem, the problem is
with your cert chains.
  


Unfortunately no. The configuration that didn't work, now works, and I 
don't know what I did to change do that. I will list the steps though:


  1. upgrade client from etch to lenny
  2. note ldap is broken because certificate is not trusted
  3. hours of debugging, including adding both root and intermediate
 class 3 certificate to trusted chain
  4. upgrade libgnutls26 from 2.4.2-5 to 2.4.2-6
  5. It works!
  6. Upgrade openldap server to Lenny.
  7. Upgrade another client to lenny. It is using libgnutls26 2.4.2-5.
  8. It works!
  9. Downgrade libgnutls26 on first client to 2.4.2-5
 10. It still works!

Something must have changed, but I don't know what.

Maybe step 6 might be significant? I can't see any evidence to proof 
this - it seems unlikely. I might be wrong...


I will let you know if I encounter the problem again.

Just in case I also downgraded libgnutls26 to 2.4.2-4, and it still works.

--
Brian May 




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

Bug#514932: seems to "forget" passing xslt options to xsltproc

[W. Martin Borgert]

Package: dblatex
Version: 0.2.9-3
Severity: important
Tags: patch

I have the impression, that dblatex calls xsltproc without user
options and that the patch helps. Could you please comment?

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

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dblatex depends on:
ii  docbook-xml   4.5-6  standard XML documentation system,
ii  python2.5.2-3An interactive high-level object-o
ii  python-apt0.7.7.1+nmu1   Python interface to libapt-pkg
ii  python-support0.8.4  automated rebuilding support for P
ii  texlive   2007.dfsg.1-5  TeX Live: A decent selection of th
ii  texlive-extra-utils   2007.dfsg.2-4  TeX Live: TeX auxiliary programs
ii  texlive-lang-cyrillic 2007.dfsg.4-1  TeX Live: Cyrillic
ii  texlive-latex-extra   2007.dfsg.15-1 TeX Live: LaTeX supplementary pack
ii  texlive-math-extra2007.dfsg.15-1 TeX Live: Advanced math typesettin
ii  texlive-xetex 2007.dfsg.2-4  TeX Live: XeTeX macros
ii  xsltproc  1.1.24-2   XSLT command line processor

Versions of packages dblatex recommends:
ii  libxml2-utils  2.6.32.dfsg-5 XML utilities

Versions of packages dblatex suggests:
ii  docbook4.5-4 standard SGML representation syste
ii  evince-gtk [pdf-vi 2.22.2-4~lenny1   Document (postscript, pdf) viewer 
ii  ghostscript8.62.dfsg.1-3.2lenny0 The GPL Ghostscript PostScript/PDF
ii  graphicsmagick-ima 1.1.11-3.2image processing tools providing I
ii  latex-cjk-all  4.7.0+git20080122-1   installs all LaTeX CJK packages
ii  lmodern1.010x-5  scalable PostScript and OpenType f
ii  opensp 1.5.2-6   OpenJade group's SGML parsing tool
pn  transfig   (no description available)
ii  xpdf-reader [pdf-v 3.02-1.4  Portable Document Format (PDF) sui

-- no debconf information
--- /usr/share/dblatex/lib/dbtexmf/core/dbtex.py2008-08-18 
13:30:07.0 +0200
+++ /root/etch/usr/share/dblatex/lib/dbtexmf/core/dbtex.py  2009-02-12 
00:13:55.0 +0100
@@ -174,7 +174,7 @@
 param = {"current.dir": self.inputdir}
 self.xsltproc.use_catalogs = 0
 self.xsltproc.run(self.xsllist, self.input,
-  self.listings, params=param)
+  self.listings, opts=self.xslopts, params=param)
 else:
 self.log.info("No external file support")
 f = file(self.listings, "w")

Bug#514854: DM application for Evgeni Golov

[Cyril Brulebois]

Cyril Brulebois  (15/12/2008):
> I've reviewed several of Evgeni's packages (but not necessarily
> uploaded them because away from my key at that moment or so), and I've
> been very happy with his packaging. A little remark here or there, or
> rather questions about this or that choice to make sure it was on
> purpose, and I've been happy with the answers.
> 
> Moreover, I really enjoy Evgeni as channel mate on
> #debian-{games,xfce}, so the social part is OK for me too. :)

Hi,

that was some time ago, and I've NM-processed Evgeni in the meanwhile,
so here's a formal DM advocacy message, quoting the relevant bits from
my AM report, which can be viewed at [1]:
| 3. Philosophy and Procedures:
| =
| 
|   Evgeni has a good understanding of Debian's philosophy and procedures
|   and answered all my questions (be it template questions; patched
|   template questions, thanks to Bernd; or any additional questions)
|   about the social contract, DFSG, BTS, etc. in a good way.
| 
|   Evgeni also committed to uphold the SC and DFSG in his Debian work and
|   accepts the DMUP.
| 
| 
| 4. Tasks and Skills:
| 
| 
|   The technical side of Debian is well known to Evgeni. He maintains a
|   bunch of packages, be it within the Games Team, the Xfce Team, or by
|   himself. His packages were in a good shape already. T&S questions,
|   including binutils tips and tricks weren't a problem at all. Finally,
|   Evgeni jumped into several RC bugs, providing with patches, and even
|   preparing some NMUs; during this process, he shown a particular
|   attention to details, trying hard not to break anything, and knowing
|   how to interact with the release team.
| 
| 
| 5. Recommendation:
| ==
| 
|   I wholeheartedly recommend to accept Evgeni as a Debian Developer, and
|   look forward to seeing him become (officially) one of my peers, which
|   I consider done already.

 1. http://lists.debian.org/debian-newmaint/2009/02/msg0.html

While I'd like him to be a DD ASAP, I'd also appreciate if he could take
care of uploading his packages on his own, that'd mean less work for
me. :)

Please make him a DM, TIA.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main

[Steve McIntyre]

On Thu, Feb 12, 2009 at 12:10:56AM +0100, Frans Pop wrote:
>On Wednesday 11 February 2009, Steve McIntyre wrote:
>> >Bad IMO. It means:
>> >- m-a image may be different when built with "i386 amd64" than when
>> > built with "amd64 i386"; this is even more true for "i386 powerpc"
>> > versus "powerpc i386"; IMO the order in which arches are listed
>> > should not change the resulting image
>>
>> It's always likely to, though: imagine if we don't have the space for
>> the two different-arch versions of the last package in the image. The
>> order that we add things is likely going to affect which one is missed
>> out.
>
>That's an edge case. I'm talking about packages going missing completely 
>because they are e.g. available for i386, but not for powerpc. Which 
>means that if you run update_tasks based on powerpc the packages just 
>won't be there on the early CDs.

Oh, sure.

>As I've mentioned before in this thread the only correct solution is to 
>somehow run update_tasks for each arch and merge them. But that will only 
>result in a really stable list if the merge is effectively done 
>line-by-line (a package that is listed 5th for a task for the second arch 
>should not end up below a package that is listed 200th for the same task 
>for the first arch, or even worse after the packages for all tasks for 
>the first arch).

I think I already cope with that, actually: I saw this problem coming
when I started doing multi-arch CDs. If you look at the code in
tools/merge_package_lists you'll see how that works.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"




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

Bug#514931: calendarserver: iCal.app can't connect with README.Debian Kerberos config

[Arthur P Prokosch]

Package: calendarserver
Version: 1.2.dfsg-8
Severity: minor

The packaged README.Debian, under "Enabling SPNEGO/Kerberos", implies that 
adding a key with a service principal name of HTTP/@ to a keytab 
is sufficient to enable Kerberos negotiation with CalDAV clients.

When a system is configured as README.Debian describes, iCal.app (after 
prompting the user to obtain Kerberos credentials if none are precent) returns 
"Login Failed: Your password was rejected by the server  for the login 
." and /var/log/caldavd/error.log will report "Authentication failed: 
Authentication System Failure: Unspecified GSS failure. Minor code may provide 
more information (No principal in keytab matches desired name)".

I have been able to solve this problem by:
1. Adding a key to the keytab (/etc/krb5.keytab, unless patched as described in 
http://trac.calendarserver.org/ticket/314) with a service principal name of 
http/@, and
2. Changing the ServicePrincipal in caldavd.plist to a lowercase "http/"
In this configuration, iCal.app connects seamlessly, and access by iceowl, 
icedove with the iceowl-extension, and other clients is not adversely affected.

I believe README.Debian should be updated with the above information.

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

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages calendarserver depends on:
ii  adduser 3.110add and remove users and groups
ii  lsb-base3.2-20   Linux Standard Base 3.2 init scrip
ii  python  2.5.2-3  An interactive high-level object-o
ii  python-central  0.6.8register and build utility for Pyt
ii  python-dateutil 1.4.1-2  powerful extensions to the standar
ii  python-kerberos 1.0+svn2455-1A GSSAPI interface module for Pyth
ii  python-openssl  0.7-2Python wrapper around the OpenSSL 
ii  python-pysqlite22.4.1-1  Python interface to SQLite 3
ii  python-twisted-calendar 0.2.0.svn19773-5 Twisted components for Apple's Cal
ii  python-vobject  0.6.0-1  parse iCalendar and VCards in Pyth
ii  python-xattr0.4-4module for manipulating filesystem
ii  python-xml  0.8.4-10.1   XML tools for Python
ii  ssl-cert1.0.23   simple debconf wrapper for OpenSSL

calendarserver recommends no packages.

Versions of packages calendarserver suggests:
pn  python-pydirector  (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#514930: aptitude full-upgrade ignores preferences

[Uwe Storbeck]

Package: aptitude
Version: 0.4.11.11-1~lenny1
Severity: important

Hi

I have set preferences for lenny (750) and sid (650) in /etc/apt/preferences
and no default release in /etc/apt/apt.conf.
aptitude ignores these preferences and tries to upgrade packages to the
unstable version. Even when I increase the priority for lenny to a value
above 1000 (which should force a downgrade of the package when it's
installed with a higher version) aptitude tries to do the opposite:

  # apt-cache policy libcaca0 
  libcaca0:
Installed: 0.99.beta14-1
Candidate: 0.99.beta14-1
Version table:
   0.99.beta16-1 0
  650 http://http.us.debian.org sid/main Packages
   *** 0.99.beta14-1 0
 1750 http://http.us.debian.org lenny/main Packages
  100 /var/lib/dpkg/status

  # aptitude full-upgrade
  [..]
  The following packages have unmet dependencies:
  [..]
  The following actions will resolve these dependencies:
  [..]
  Upgrade the following packages:
  libcaca0 [0.99.beta14-1 (testing, now) -> 0.99.beta16-1 (unstable)]
  libcucul0 [0.99.beta14-1 (testing, now) -> 0.99.beta16-1 (unstable)]

This shouldn't happen and makes apt preferences quite useless.

Regards

Uwe

-- Package-specific info:
aptitude 0.4.11.11 compiled at Dec  5 2008 02:43:34
Compiler: g++ 4.3.2
Compiled against:
  apt version 4.6.0
  NCurses version 5.6
  libsigc++ version: 2.0.18
  Ept support enabled.

Current library versions:
  NCurses version: ncurses 5.7.20081213
  cwidget version: 0.5.12
  Apt version: 4.6.0
linux-gate.so.1 =>  (0xe000)
libapt-pkg-libc6.7-6.so.4.6 => /usr/lib/libapt-pkg-libc6.7-6.so.4.6 
(0xb7ef6000)
libncursesw.so.5 => /lib/libncursesw.so.5 (0xb7eb8000)
libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0xb7eb1000)
libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0xb7ded000)
libept.so.0 => /usr/lib/libept.so.0 (0xb7d2c000)
libxapian.so.15 => /usr/lib/libxapian.so.15 (0xb7bd6000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7bc1000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7ba8000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7ab9000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7a93000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7a86000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb792b000)
libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7927000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7922000)
/lib/ld-linux.so.2 (0xb7fd3000)
Terminal: xterm
$DISPLAY is set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:

aptitude linkage:

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (1750, 'testing'), (650, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages aptitude depends on:
ii  apt [libapt-pkg-libc6. 0.7.20.2  Advanced front-end for dpkg
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  libcwidget30.5.12-4  high-level terminal interface libr
ii  libept00.5.22High-level library for managing De
ii  libgcc11:4.3.2-1.1   GCC support library
ii  libncursesw5   5.7+20081213-1shared libraries for terminal hand
ii  libsigc++-2.0-0c2a 2.0.18-2  type-safe Signal Framework for C++
ii  libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii  libxapian151.0.7-4   Search engine library
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

Versions of packages aptitude recommends:
ii  aptitude-doc-en [apti 0.4.11.11-1~lenny1 English manual for aptitude, a ter
ii  libparse-debianchange 1.1.1-2parse Debian changelogs and output

-- 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#514800: inputlirc: missing init dependency on lirc?

[Guus Sliepen]

On Wed, Feb 11, 2009 at 12:02:45AM +0100, Jaap Eldering wrote:

> I recently upgraded my desktop to Lenny and installed the insserv 
> dependency based init package. I'm pretty sure that since then my remote 
> stopped working correctly: it did send signals, but it didn't seem to 
> read/use the .lircrc config file anymore. Restarting lirc and then 
> inputlirc solves the problem and restores the original behaviour.
> 
> So it seems that /etc/init.d/inputlirc is missing a boot-time depencency 
> on lirc, but I'm not completely sure that it not an error in 
> configuration from my side.

Inputlirc does not depend at all on lirc. However, I guess that you are using
the init script from the lirc package to automatically start irexec. I cannot
specify in the LSB header of the inputlirc init script that the lirc init
script should start after it. The only thing you can do is to add Should-Start:
inputlirc to /etc/init.d/lirc's header.

Does that solve your problem?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#505089: alsa-utils: "asoundconf set-default-card" does not work

[Paul TBBle Hampson]

Just came across this, and from [1] it turns out the fix is
to remove the exclamation mark in front of the "defaults.pcm.card"
in the generated file.

So this bug would be quite quick and easy to fix, it turns out.

From [2]: The exclamation mark causes the parameter and all its
sub-parameters to be removed before it is created anew. (So don't ever
write something like "!pcm..." — this would presumably erase all
definitions in the pcm interface.)

So it's blowing away the contents of "defaults", which blows away the
default dmix configuration. The default dmix configuration uses
defaults.pcm to choose where to output, so the exclamation mark isn't
needed.

[1] http://forums.debian.net/viewtopic.php?t=22325
[2] http://www.volkerschatz.com/noise/alsa.html

-- 
Paul "TBBle" Hampson, paul.hamp...@pobox.com

Shorter .sig for a more eco-friendly paperless office.


pgppo4eYsoX0u.pgp
Description: PGP signature

Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main

[Frans Pop]

On Wednesday 11 February 2009, Steve McIntyre wrote:
> In fact, simply looking at the lenny RC2 images you can see that
> sources are in alphabetical order. We may as well simply not do
> anything in the $(TASKDIR): target for a source-only build and save
> the processing time. Agreed?

I don't know. I'd have to check in detail why tasks get ignored (for which 
I'm not motivated) and IMO this is the wrong time to be making such 
changes anyway. You're not going to get any real testing or feedback 
anymore before the release.



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

Bug#514914: coreutils: date -s STRING does not accept localized format

[Eduard Bloch]

#include 
* Michael Stone [Wed, Feb 11 2009, 05:12:01PM]:
> severity 514914 wishlist
> tags 514914 wontfix
>
> On Wed, Feb 11, 2009 at 09:57:51PM +0100, Eduard Bloch wrote:
>> See subject, setting the date is a popular source
>> of confusion for non-US citizens. This problem is especially PITA
>> because the string expected for -s is not documented well in the
>> manpage. Just assuming that it's the same format as the one from date's
>> output ends up in the missery shown in the log below. And when I try to
>> use the popular middle-european format, it fails too, see #211508 for
>> details.
>
> date's parser has all sort of issues, and there is no "expected string"  
> as it tries to be a natural language parser. My main inclination would  

Natural for US citizens. Not so natural for others.

> be to drop the natural language parsing entirely, as it has never really  
> worked. Unfortunately, debian's date would then be incompatible with  
> everyone else's. I don't see a realistic solution. Maybe you can  
> convince upstream to drop natural language parsing and replace it with  

Feel free to forward my mail to the upstream, I'm not sure about the
appropriate contact address in Debian's documentation.

> some structured format. I doubt that will go far upstream, either,  
> because of compatibility issues. Maybe an entirely new option with a  
> rational syntax? All it needs is someone to write it...
>
> FYI, ISO 8601 format mostly works (except that you can't use the T to  
> separate date and time):
>
>> date -d '2009-01-01 14:55'
> Thu Jan  1 14:55:00 EST 2009

If locale based input parsing is doomed then the next logical solution
is using a common format, and ISO 8601 is fine in this case, but then it
should also be documented well! The manpage only talks about possible
*output* formats ( and only mentions --rfc-2822 and --rfc-3339 there).

>From user's perspective, even one single *complete* example of date and
time setting somewhere on top of the manpage or in the --help output
would help a lot, but there is nothing. Just a short reference to some
"STRING".

And the only documentation for that "STRING" can be found in the GNU
info docs, but a) that requires the info reader program on the system
and b) the hint needs to be found in the manpage which is looong. And a)
and b) can be really complicated when you are setting up a machine in
the wild having not much time and no internet connection.

> Note that to set the time you don't need to mess with -s at all, you can 
> "simply" use 
>> date 010114552009
> as described in the man page.

Which manpage? date(1) on my system says:

date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]]

So it looks like it should accept "-s 02112332" (for February 11th,
23:12). But it doesn't!

Regards,
Eduard.

-- 
Der liebt nicht, der die Fehler des Geliebten nicht für Tugenden 
hält.
-- Goethe, Maximen und Reflektionen, Nr. 645



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

Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main

[Frans Pop]

On Wednesday 11 February 2009, Steve McIntyre wrote:
> >Bad IMO. It means:
> >- m-a image may be different when built with "i386 amd64" than when
> > built with "amd64 i386"; this is even more true for "i386 powerpc"
> > versus "powerpc i386"; IMO the order in which arches are listed
> > should not change the resulting image
>
> It's always likely to, though: imagine if we don't have the space for
> the two different-arch versions of the last package in the image. The
> order that we add things is likely going to affect which one is missed
> out.

That's an edge case. I'm talking about packages going missing completely 
because they are e.g. available for i386, but not for powerpc. Which 
means that if you run update_tasks based on powerpc the packages just 
won't be there on the early CDs.

As I've mentioned before in this thread the only correct solution is to 
somehow run update_tasks for each arch and merge them. But that will only 
result in a really stable list if the merge is effectively done 
line-by-line (a package that is listed 5th for a task for the second arch 
should not end up below a package that is listed 200th for the same task 
for the first arch, or even worse after the packages for all tasks for 
the first arch).

The problem is not trivially solvable and because of that I'd prefer to 
use a logic that is at least predictable and gives the best result for 
our primary architectures.



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

Bug#514929: python-geoip: New upstream version 1.2.4 available

[Pascal Volk]

Package: python-geoip
Version: 1.2.1-2+b1
Severity: wishlist

MaxMind has released version 1.2.4 of the python wrapper to GeoIP. In the  
ChangeLog are some improvements and fixes mentioned since version 1.2.1.


Regards,
Pascal

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

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

Versions of packages python-geoip depends on:
ii  libc6   2.7-18   GNU C Library: Shared libraries
ii  libgeoip1   1.4.5.dfsg-3 A non-DNS IP-to-country resolver l
ii  python  2.5.2-3  An interactive high-level object-o
ii  python-support  0.8.4automated rebuilding support for P

python-geoip recommends no packages.

python-geoip 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#514807: Regression in libgnutls security update

[Florian Weimer]

* Simon Josefsson:

> What can be done here is to produce better documentation, perhaps in
> release notes.  People must be aware that trusting X.509 certificate
> chains containing RSA-MD5 signatures or V1 CAs is insecure.

I think it is somewhat debatable if this also applies to the root CA
container, where the X.509 structure is just use as a transport for
key material.  The RSA-MD5 signature does not hurt there, and the DN
doesn't really matter, either.  The risk I see is that someone adds a
v1 *server* certificate to the trusted list, without realizing that it
will act as a *CA* certificate in this place.



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

Bug#514520: bmpx: Hangs when trying to play music

[William Pitcock]

On Sun, 2009-02-08 at 11:46 +, Bradley Smith wrote:
> Package: bmpx
> Version: 0.40.14-1
> Severity: grave
> Justification: renders package unusable
> 
> When trying to play a music file, either with the gui, or when using
> bmp-play-files-2.0, bmpx simply hangs. I suspect this is related to bug
> #462585, since I am also using LVM, and too suffer from that bug.
> 
> Looking at the other bugs against this package, I question whether this
> should be released in lenny.

I concur, it probably should not. Especially considering that upstream
has abandoned this codebase. As such, I am not touching the severity of
this bug.

William



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

Bug#514807: Regression in libgnutls security update

[Florian Weimer]

* Edward Allcutt:

> I believe this is a significant regression in stable because at least
> one widely used CA (godaddy) still issues certificates with a chain
> ending in a v1 root (ValiCert Class 2).

Are we talking about this certificate?

Certificate:
Data:
Version: 1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert 
Class 2 Policy Validation Authority, 
CN=http://www.valicert.com//emailaddress=i...@valicert.com
Validity
Not Before: Jun 26 00:19:54 1999 GMT
Not After : Jun 26 00:19:54 2019 GMT
Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert 
Class 2 Policy Validation Authority, 
CN=http://www.valicert.com//emailaddress=i...@valicert.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:ce:3a:71:ca:e5:ab:c8:59:92:55:d7:ab:d8:74:
0e:f9:ee:d9:f6:55:47:59:65:47:0e:05:55:dc:eb:
98:36:3c:5c:53:5d:d3:30:cf:38:ec:bd:41:89:ed:
25:42:09:24:6b:0a:5e:b3:7c:dd:52:2d:4c:e6:d4:
d6:7d:5a:59:a9:65:d4:49:13:2d:24:4d:1c:50:6f:
b5:c1:85:54:3b:fe:71:e4:d3:5c:42:f9:80:e0:91:
1a:0a:5b:39:36:67:f3:3f:55:7c:1b:3f:b4:5f:64:
73:34:e3:b4:12:bf:87:64:f8:da:12:ff:37:27:c1:
b3:43:bb:ef:7b:6e:2e:69:f7
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
3b:7f:50:6f:6f:50:94:99:49:62:38:38:1f:4b:f8:a5:c8:3e:
a7:82:81:f6:2b:c7:e8:c5:ce:e8:3a:10:82:cb:18:00:8e:4d:
bd:a8:58:7f:a1:79:00:b5:bb:e9:8d:af:41:d9:0f:34:ee:21:
81:19:a0:32:49:28:f4:c4:8e:56:d5:52:33:fd:50:d5:7e:99:
6c:03:e4:c9:4c:fc:cb:6c:ab:66:b3:4a:21:8c:e5:b5:0c:32:
3e:10:b2:cc:6c:a1:dc:9a:98:4c:02:5b:f3:ce:b9:9e:a5:72:
0e:4a:b7:3f:3c:e6:16:68:f8:be:ed:74:4c:bc:5b:d5:62:1f:
43:dd

It's not just a X.509v1 certificate.  It's ten years old, it's just
1024 bits, and ValiCert does not exist anymore as an organization
(thus the DN is invalid).

So while I understand that there is a problem (and we knew that there
was a trade-off to be made when releasing the update), I think this
particular root certificate is a bad example if you want to make a
point.

Simon, could we make the harmless variant (X.509v1 certificate set as
trusted is accepted as a root CA, but intermediate X.509v1
certificates aren't accepted) the default in etch?

> Godaddy appears to have a newer v3 root but I don't know how widely
> deployed this is. It is not in the etch ca-certificates package for
> example.

Which root are you referring to?



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

Bug#514928: gedit-latex-plugin: Does not clean up .pyc files on upgrade

[Sam Morris]

Package: gedit-latex-plugin
Version: 0.2rc1-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

When upgrading the plugin:

(Reading database ... 326806 files and directories currently installed.)
Preparing to replace gedit-latex-plugin 0.1.3.2-2 (using 
.../gedit-latex-plugin_0.2rc1-1_all.deb) ...
Unpacking replacement gedit-latex-plugin ...
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/builder': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/bibtex': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/listings': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/archive': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/latex': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/autocomplete': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/snippets': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/document': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/ipc': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/graphics': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/quickedit': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/symbols': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/tabular': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin/toolbar': Directory not empty
dpkg: warning - unable to delete old directory 
`/usr/lib/gedit-2/plugins/LaTeXPlugin': Directory not empty
Setting up gedit-latex-plugin (0.2rc1-1) ...

The /usr/lib/gedit-2/plugins/LaTeXPlugin directory was left behind, full of 
.pyc files.

- -- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (510, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gedit-latex-plugin depends on:
ii  gedit2.22.3-1+lenny1 official text editor of the GNOME 
ii  python-dbus  0.82.4-2simple interprocess messaging syst
ii  rubber   1.1-2.2 an automated system for building L

Versions of packages gedit-latex-plugin recommends:
ii  texlive2007.dfsg.1-5 TeX Live: A decent selection of th

gedit-latex-plugin suggests no packages.

- -- no debconf information

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

iEYEARECAAYFAkmTV0oACgkQshl/216gEHhXyQCg8G2M6rx6fW/vwGMKkLRA8WA/
IuEAoKzmSjbAlYKnl75D5Cj86iwfj9np
=kbQ/
-END PGP SIGNATURE-



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

Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main

[Steve McIntyre]

On Wed, Feb 11, 2009 at 10:49:06PM +, Steve McIntyre wrote:
>On Wed, Feb 11, 2009 at 11:29:13PM +0100, Frans Pop wrote:
>
>>- source only set will have packages in in a completely different order
>>  from the corresponding binary set
>
>Personally, I don't care in the slightest. In fact, I'd be surprised
>if the tasks affect the source builds at all right now... For
>source-only sets, I normally expect them to just be in alphabetical
>order. Testing that now.

In fact, simply looking at the lenny RC2 images you can see that
sources are in alphabetical order. We may as well simply not do
anything in the $(TASKDIR): target for a source-only build and save
the processing time. Agreed?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll




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

Bug#514711: [INTL:es] Spanish po-debconf translation

[Javier Fernández-Sanguino Peña]

On Wed, Feb 11, 2009 at 11:07:36PM +0100, Martin Michlmayr wrote:
> CCing debian-l10n-span...@lists.debian.org so whoever maintains this
> web page can update it.

The web page is maintained automatically by a translation robot. It does not
(yet) have the feature to purge inexistant packages. We will try to do a
review and purge some, but translators are expected to check if the
translations are relevant before submitting a bug report.

Regards

Javier


signature.asc
Description: Digital signature

Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main

[Steve McIntyre]

Moot points here, as I'm looking into going with Jonathan's latest
patchset anyway.

On Wed, Feb 11, 2009 at 11:29:13PM +0100, Frans Pop wrote:
>On Wednesday 11 February 2009, Steve McIntyre wrote:
>> In fact, I'd say the simplest answer would be to pick the first named
>> arch. If we're doing source-only then don't run update_tasks at
>> all. How does that sound?
>
>Bad IMO. It means:
>- m-a image may be different when built with "i386 amd64" than when built
>  with "amd64 i386"; this is even more true for "i386 powerpc" versus
>  "powerpc i386"; IMO the order in which arches are listed should not
>  change the resulting image

It's always likely to, though: imagine if we don't have the space for
the two different-arch versions of the last package in the image. The
order that we add things is likely going to affect which one is missed
out.

>- source only set will have packages in in a completely different order
>  from the corresponding binary set

Personally, I don't care in the slightest. In fact, I'd be surprised
if the tasks affect the source builds at all right now... For
source-only sets, I normally expect them to just be in alphabetical
order. Testing that now.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane




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

Bug#514927: ITP: sugar-help-activity -- Documentation application for the Sugar suite

[Luke Faraone]

Package: wnpp
Severity: wishlist


* Package name : sugar-help-activity
Version : 9
Upstream Author : Seth Woodworth , Brian Jordan <
br...@laptop.org>
* URL : http://wiki.laptop.org/go/Help_(activity)
* License : GPLv2+
Description : The Help activity provides a quick interface to help
documentation. It currently launches a browser and displays html documents
describing how to use the Sugar interface.


-- 
Luke Faraone
http://luke.faraone.cc

Bug#514741: evince: full screen navigation in documents created by LaTeX-Beamer requires two scrolling actions

[Josselin Mouette]

Le mardi 10 février 2009 à 09:52 -0500, Denis Laxalde a écrit :
> Package: evince
> Version: 2.22.2-4~lenny1
> Severity: normal
> 
> When viewing documents created by LaTeX Beamer (see for example [1]) in
> full screen mode, one has to press the arrow keys (or scroll the mouse wheel) 
> twice to navigate to next or previous pages.
> I haven't noticed this in other documents (created by TeX or not).
> 
> [1] http://latex-beamer.sourceforge.net/beamerexample1.pdf

I can reproduce this with evince 2.22, but not with evince 2.24 from
experimental. Could you confirm?

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Bug#514921: [Pkg-gpe-maintainers] Processed: reassign 514921 to libmimedir0, libmimedir-gnome0-dev

[Barry deFreese]

Neil Williams wrote:

On Wed, 11 Feb 2009 21:51:03 +
ow...@bugs.debian.org (Debian Bug Tracking System) wrote:

  

Processing commands for cont...@bugs.debian.org:



reassign 514921 libmimedir0,libmimedir-gnome0-dev
  

Bug#514921: libmimedir0: tries to overwrite file owned by libmimedir-gnome0-dev
Bug reassigned from package `libmimedir0' to 
`libmimedir0,libmimedir-gnome0-dev'.




Barry, your upload of libmimedir 0.5.1-1 introduced the relevant file
into libmimedir0 when it does not exist in Lenny:

http://packages.debian.org/lenny/amd64/libmimedir0/filelist
/usr/lib/libmimedir.so.0
/usr/lib/libmimedir.so.0.0.0
/usr/share/doc/libmimedir0/README
/usr/share/doc/libmimedir0/changelog.Debian.gz
/usr/share/doc/libmimedir0/changelog.gz
/usr/share/doc/libmimedir0/copyright

http://packages.debian.org/sid/amd64/libmimedir0/filelist
/usr/lib/libmimedir.a
/usr/lib/libmimedir.so.0
/usr/lib/libmimedir.so.0.0.0
/usr/share/doc/libmimedir0/README
/usr/share/doc/libmimedir0/changelog.Debian.gz
/usr/share/doc/libmimedir0/changelog.gz
/usr/share/doc/libmimedir0/copyright

Why was this file introduced? I don't see that this is a bug in
libmimedir-gnome0-dev, it appears to be a bug in libmimedir0,
specifically libmimedir0 (0.5.1-1) - there's nothing I can see in the
changelog to explain this addition.

There should be no .a file in the library package and there wasn't one
in the -dev in Lenny either (for whatever reason).

Now, whether libmimedir-gnome0-dev should contain /usr/lib/libmimedir.a
and not something like /usr/lib/libmimedir-gnome.a is a different
question. Moray?

IMHO it's far less troublesome for the two -dev packages to conflict.

$ apt-cache rdepends libmimedir0
libmimedir0
Reverse Depends:
  python-rra
  librra0
  librra-tools
  libmimedir-dev

$ apt-cache rdepends libmimedir-gnome0.4
libmimedir-gnome0.4
Reverse Depends:
  libmimedir-gnome0-dev
  libgpevtype1
  gpe-contacts
  gpe-calendar
  gpe-bluetooth

The only extra dependency of the -gnome version is libglib2.0-0 -
python-rra already depends on libglib2.0-0 via a dependency on
libdbus-glib, in turn via http://packages.debian.org/sid/libsynce0, and
http://packages.debian.org/sid/librra0 also depends on libsynce0.

Maybe the best thing would be:

1. Remove /usr/lib/libmimedir.a from libmimedir0 asap.
2. Migrate librra0 and reverse dependencies to libmimedir-gnome0.4
after Lenny
3. Remove the orphaned libmimedir0

Doing that means that the "problem" of /usr/lib/libmimedir.a in
libmimedir-gnome0-dev goes away completely.

  


That was my fault.  For some reason I added the .a file to 
libmime0.install.  I'll re-upload a version immediate without the .a file.


Sorry about that.

Barry deFreese
Debian QA



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

Bug#514925: release-notes: Typo 'begginning'

[Javier Fernández-Sanguino Peña]

Package: release-notes
Severity: normal

I've found a typo while translating the upgrading.dbk file, it uses
'beggining' instead of 'beginning'. Patch attached.

Regards

Javier
--- upgrading.dbk.old   2009-02-11 23:33:27.0 +0100
+++ upgrading.dbk   2009-02-11 23:33:40.0 +0100
@@ -59,7 +59,7 @@
 you upgrade to and test an &oldreleasename;
 2.6.18 or 2.6.24 kernel or a
 custom kernel of at least version 2.6.18 before
-beggining the upgrade process.
+beginning the upgrade process.
   
 
 

Bug#514926: rolo: UTF-8 is broken

[Carsten Hey]

Package: rolo
Severity: important

Hi,

UTF-8 in rolo is broken, lines including UTF-8 are simply not displayed.

Build-depending on libncursesw5-dev and linking against menuw and formw
(libncursesw5) instead of menu and form (libncurses5) fixes this partly.

The following example shows what would be displayed after linking against menuw
and formw when one decorates entry 26 of the example file with umlauts. As you
can see, the beginning of the columns is messed up. This example is when entry
26 is selected, if it is not selected the telephone number is displayed
correctly but the other columns look still like in this example.

  25 Thomson  Nigeln...@yahoos.com  
+420-2607-1234-123
- 26 Träcy   Richürd d...@watch.cöm+1-555-222-0001   
  27 Winter   Alex a...@winter.com+1-413-545-2911

Fixing this probably requires something like g_utf8_strlen(str, -1), which is
included in glib but can easily be reimplemented, to be used instead of strlen
(or whatever rolo uses for detecting the number of characters of the string).
Alternatively mbstowcs(NULL, str, 0) should also work but I did not use this to
determine the number of characters of strings until now, so I can't be sure.

Correctly displaying columns when using double wide characters (e.g. タ) will
not work when g_utf8_strlen(str, -1) or mbstowcs(NULL, str, 0) is used since
they return the number of characters instead of the number of columns needed to
display a string.  Maybe you find a sane way to fix get the number of columns
needed, e.g. by combining mbstowcs() and wcswidth().  I don't consider the wide
character support to be a part of this bug report.

I'd be happy when you would at least link against menuw and formw, feel free to
set the severity of this bug to minor when the linking has been done but
correctly displaying the columns has not yet been implemented.


Regards
Carsten



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

Bug#514237: debian-cd: Support non-i386 mirrors, and support D-I modules in non-main

[Frans Pop]

On Wednesday 11 February 2009, Steve McIntyre wrote:
> In fact, I'd say the simplest answer would be to pick the first named
> arch. If we're doing source-only then don't run update_tasks at
> all. How does that sound?

Bad IMO. It means:
- m-a image may be different when built with "i386 amd64" than when built
  with "amd64 i386"; this is even more true for "i386 powerpc" versus
  "powerpc i386"; IMO the order in which arches are listed should not
  change the resulting image
- source only set will have packages in in a completely different order
  from the corresponding binary set



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

Bug#514921: [Pkg-gpe-maintainers] Processed: reassign 514921 to libmimedir0, libmimedir-gnome0-dev

[Neil Williams]

On Wed, 11 Feb 2009 21:51:03 +
ow...@bugs.debian.org (Debian Bug Tracking System) wrote:

> Processing commands for cont...@bugs.debian.org:
> 
> > reassign 514921 libmimedir0,libmimedir-gnome0-dev
> Bug#514921: libmimedir0: tries to overwrite file owned by 
> libmimedir-gnome0-dev
> Bug reassigned from package `libmimedir0' to 
> `libmimedir0,libmimedir-gnome0-dev'.
> 

Barry, your upload of libmimedir 0.5.1-1 introduced the relevant file
into libmimedir0 when it does not exist in Lenny:

http://packages.debian.org/lenny/amd64/libmimedir0/filelist
/usr/lib/libmimedir.so.0
/usr/lib/libmimedir.so.0.0.0
/usr/share/doc/libmimedir0/README
/usr/share/doc/libmimedir0/changelog.Debian.gz
/usr/share/doc/libmimedir0/changelog.gz
/usr/share/doc/libmimedir0/copyright

http://packages.debian.org/sid/amd64/libmimedir0/filelist
/usr/lib/libmimedir.a
/usr/lib/libmimedir.so.0
/usr/lib/libmimedir.so.0.0.0
/usr/share/doc/libmimedir0/README
/usr/share/doc/libmimedir0/changelog.Debian.gz
/usr/share/doc/libmimedir0/changelog.gz
/usr/share/doc/libmimedir0/copyright

Why was this file introduced? I don't see that this is a bug in
libmimedir-gnome0-dev, it appears to be a bug in libmimedir0,
specifically libmimedir0 (0.5.1-1) - there's nothing I can see in the
changelog to explain this addition.

There should be no .a file in the library package and there wasn't one
in the -dev in Lenny either (for whatever reason).

Now, whether libmimedir-gnome0-dev should contain /usr/lib/libmimedir.a
and not something like /usr/lib/libmimedir-gnome.a is a different
question. Moray?

IMHO it's far less troublesome for the two -dev packages to conflict.

$ apt-cache rdepends libmimedir0
libmimedir0
Reverse Depends:
  python-rra
  librra0
  librra-tools
  libmimedir-dev

$ apt-cache rdepends libmimedir-gnome0.4
libmimedir-gnome0.4
Reverse Depends:
  libmimedir-gnome0-dev
  libgpevtype1
  gpe-contacts
  gpe-calendar
  gpe-bluetooth

The only extra dependency of the -gnome version is libglib2.0-0 -
python-rra already depends on libglib2.0-0 via a dependency on
libdbus-glib, in turn via http://packages.debian.org/sid/libsynce0, and
http://packages.debian.org/sid/librra0 also depends on libsynce0.

Maybe the best thing would be:

1. Remove /usr/lib/libmimedir.a from libmimedir0 asap.
2. Migrate librra0 and reverse dependencies to libmimedir-gnome0.4
after Lenny
3. Remove the orphaned libmimedir0

Doing that means that the "problem" of /usr/lib/libmimedir.a in
libmimedir-gnome0-dev goes away completely.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpbOI2Oc88nN.pgp
Description: PGP signature