Bug#557495: Force sub-directories for both

[Andreas Tille]

On Tue, Dec 07, 2010 at 11:12:23PM +, Neil Williams wrote:
> > The fact that there is now a
> > workaround seems to decrease the presure onto this clean solution.
> 
> I'm not at all sure why the solution has to be in one or other library
> as if code including the header (none of which is in Debian currently)
> cannot be trivially modified with an #ifdef or two.

Both libraries are interfacing with a Card Terminal (CT) and we have a
package in Debian which intends to provide this API (ctapi-dev).  This
package was created to fix the bug in question you simply worked around
now.  We just have another package libopenct1-dev which provides another
ctapi.h file and which probably has the same purpose to provide a CT
interface.  The package *I* have dealt with (libctapimkt0-dev) has such
a low priority that I would rather remove it from Debian than allowing
to add even more confusion and I agreed with upstream to find a better
solution than providing its own interface.  Upstream agreed, to this in
principle but there were other issues which were not (yet) solved and
thus I removed the pending tag because it is not clear how long it might
take.

Consequently libctapimkt0-dev was removed from testing (since a long
time) and this is correct for this package.  An apropriate thing to do
would have been to reassign bug #557495 only against libctapimkt0-dev
which would enable libtowitoko-dev to stay in testing (because there
is no chance to install both packages together in testing any more).
 
> It was just a hint, no detail, no proof or way for others to test.
> 
> This bug isn't enough to prevent either package being in Squeeze -

The package libctapimkt0-dev is *not* in Squeeze!

> if
> there are other issues, please file appropriate bugs and give people a
> chance to verify and possibly fix.
> 
> If you believe this to be the case, please file the appropriate RM bug
> with the reasoning.

I have not expected that people will spend their time on fixing bugs in
packages which are not in Squeeze.  You could have saved your time if
you would have pinged me about your intend.  You have spended time to
clean up a package with very low popcon which is not intended for
Squeeze.  This is brave and I welcome your work but at least for me
there are currently more burning issues to do.  If you want me to
discuss the issue further instead of trusting me that I'm in contact
with upstream and will handle things with upstream *after* the Squeeze
release I prefer removing the package for now and adding it later again.
This would keep ftpmaster busy for two times which I also feel
unapropriate.
 
Kind regards and thanks for your work in any case

   Andreas.

-- 
http://fam-tille.de



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

Bug#603450: Is 603450 realy release critical?

[Alexander Reichle-Schmehl]

Hi release manager,

#603450 is a bug (currently with severity grave, Justification: user
security hole), as offlineimap does no ssl certificate checking.


While I agree, that this is a really important feature, which should be
fixed, I'm wondering, if that really is release critical.


There's patch floating arround, which has a major regression: It doesn't
work for users of self signed certificates.  Should this bug be seen as
of release critical severity, would you therefore at least consider
tagging it squeeze-ignore?


Best Regards,
  Alexander



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

Bug#605092: nmu patch

[Steffen Joeris]

Hi,

Please find attached the NMU patch I've uploaded for the DoS issue.

Cheers,
Steffen
diff -u collectd-4.10.1/debian/changelog collectd-4.10.1/debian/changelog
--- collectd-4.10.1/debian/changelog
+++ collectd-4.10.1/debian/changelog
@@ -1,3 +1,12 @@
+collectd (4.10.1-2.1) unstable; urgency=high
+
+  * Non-maintainer upload by the security team
+  * Fix DoS in RRD file creation (Closes: #605092)
+Fixes: CVE-2010-4336
+Thanks to Florian Forster
+
+ -- Steffen Joeris   Wed, 08 Dec 2010 17:45:50 +1100
+
 collectd (4.10.1-2) unstable; urgency=medium
 
   * debian/rules:
diff -u collectd-4.10.1/debian/patches/00list collectd-4.10.1/debian/patches/00list
--- collectd-4.10.1/debian/patches/00list
+++ collectd-4.10.1/debian/patches/00list
@@ -7 +7 @@
-
+CVE-2010-4336.dpatch
only in patch2:
unchanged:
--- collectd-4.10.1.orig/debian/patches/CVE-2010-4336.dpatch
+++ collectd-4.10.1/debian/patches/CVE-2010-4336.dpatch
@@ -0,0 +1,18 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+##
+
+...@dpatch@
+--- ../old/collectd-4.10.1/src/utils_rrdcreate.c	2010-07-09 20:01:59.0 +1000
 collectd-4.10.1/src/utils_rrdcreate.c	2010-12-08 17:41:34.0 +1100
+@@ -398,10 +398,9 @@
+   memcpy (argv + ds_num, rra_def, rra_num * sizeof (char *));
+   argv[ds_num + rra_num] = NULL;
+ 
+-  assert (vl->time > 10);
+   status = srrd_create (filename,
+   (cfg->stepsize > 0) ? cfg->stepsize : vl->interval,
+-  vl->time - 10,
++  (vl->time > 10) ? (vl->time - 10) : vl->time,
+   argc, (const char **) argv);
+ 
+   free (argv);


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

Bug#603450: Fwd: Due offlineimap absence of certificate validation issue -- Debian BTS#603450

[Alexander Reichle-Schmehl]

Hi dave!

* dave b  [101202 05:58]:

> Here have a patch!
> This obviously will break connecting to hosts which use a self-signed
> certificate.
> Perhaps some one else can fix this when they want it fixed ;) ?
> I tested using the following config:

I verified it, and your patch works:  I accepts valid ssl connections,
and rejects invalid ones.

> +self.sslobj = ssl_wrap(self.sock, self.keyfile, self.certfile, 
> cert_reqs=ssl.CERT_REQUIRED, ca_certs="/etc/ssl/certs/ca-certificates.crt")

But that looks kind of ugly, having a hardcoded path... Also, I wonder
if not self.certfile should be used for verification?

Best Regards,
  Alexander



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

Bug#606182: duplicity: Fails to restore on initial run with GPGError

[Delphine Patron]

On Wed, Dec 08, 2010 at 12:47:29PM +1000, Alexander Zangerl wrote:
> On Tue, 07 Dec 2010 09:25:03 +0100, Olivier Berger writes:

> i can't reproduce the problem here; would you please send me the output
> of a run with -v 9 and with (re-)cleaned cache?
> 

Here's at least the run with -v 5 :

# duplicity -v 5 --force --ssh-askpass 
scp://r...@x//mnt/IOMEGA_HDD/dupbackups/x /home/x/restore/
Using archive dir: /root/.cache/duplicity/a00bfabc635c2934093d231fbc26dadf
Using backup name: a00bfabc635c2934093d231fbc26dadf
Import of duplicity.backends.ftpbackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.sshbackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.cloudfilesbackend Succeeded
Import of duplicity.backends.botobackend Succeeded
Password for 'x': 
Main action: restore
PASSPHRASE variable not set, asking user.
GnuPG passphrase: 

duplicity 0.6.08b (March 11, 2010)
Args: /usr/bin/duplicity -v 5 --force --ssh-askpass 
scp://r...@x//mnt/IOMEGA_HDD/dupbackups/x /home/x/restore/
Linux x 2.6.32-5-686 #1 SMP Thu Nov 25 18:43:34 UTC 2010 i686 
/usr/bin/python 2.6.6 (r266:84292, Oct  9 2010, 11:40:09) 
[GCC 4.4.5]

Using temporary directory /tmp/duplicity-p9jsSL-tempdir
Temp has 2661462016 available, backup will use approx 34078720.
Running 'sftp  -oServerAliveInterval=15 -oServerAliveCountMax=1 r...@x' 
(attempt #1)
sftp command: 'mkdir "/mnt/IOMEGA_HDD/dupbackups/x"'
sftp command: 'cd "/mnt/IOMEGA_HDD/dupbackups/x"'
sftp command: 'ls -1'
Synchronizing remote metadata to local cache...
PASSPHRASE variable not set, asking user.
Copying duplicity-full-signatures.20101206T005609Z.sigtar to local cache.
Running 'sftp  -oServerAliveInterval=15 -oServerAliveCountMax=1 r...@x' 
(attempt #1)
sftp command: 'get 
"/mnt/IOMEGA_HDD/dupbackups/x/duplicity-full-signatures.20101206T005609Z.sigtar.gpg"
 "/tmp/duplicity-p9jsSL-tempdir/mktemp-uA0Siq-2"'
Deleting /tmp/duplicity-p9jsSL-tempdir/mktemp-uA0Siq-2
Copying duplicity-full.20100116T134814Z.manifest to local cache.
Running 'sftp  -oServerAliveInterval=15 -oServerAliveCountMax=1 r...@x' 
(attempt #1)
sftp command: 'get 
"/mnt/IOMEGA_HDD/dupbackups/x/duplicity-full.20100116T134814Z.manifest.gpg" 
"/tmp/duplicity-p9jsSL-tempdir/mktemp-p0Ukqx-3"'
Deleting /tmp/duplicity-p9jsSL-tempdir/mktemp-p0Ukqx-3
Copying duplicity-full.20100905T190548Z.manifest to local cache.
Running 'sftp  -oServerAliveInterval=15 -oServerAliveCountMax=1 r...@x' 
(attempt #1)
sftp command: 'get 
"/mnt/IOMEGA_HDD/dupbackups/x/duplicity-full.20100905T190548Z.manifest.gpg" 
"/tmp/duplicity-p9jsSL-tempdir/mktemp-hu2f4W-4"'
Deleting /tmp/duplicity-p9jsSL-tempdir/mktemp-hu2f4W-4
Copying duplicity-full.20101006T231429Z.manifest to local cache.
Running 'sftp  -oServerAliveInterval=15 -oServerAliveCountMax=1 r...@x' 
(attempt #1)
sftp command: 'get 
"/mnt/IOMEGA_HDD/dupbackups/x/duplicity-full.20101006T231429Z.manifest.gpg" 
"/tmp/duplicity-p9jsSL-tempdir/mktemp-WiIWB8-5"'
GPG error detail: Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1251, in 
with_tempdir(main)
  File "/usr/bin/duplicity", line 1244, in with_tempdir
fn()
  File "/usr/bin/duplicity", line 1145, in main
sync_archive()
  File "/usr/bin/duplicity", line 959, in sync_archive
copy_to_local(fn)
  File "/usr/bin/duplicity", line 915, in copy_to_local
globals.archive_dir.append(loc_name).name)
  File "/usr/bin/duplicity", line 841, in copy_raw
data = src_iter.next(block_size).data
  File "/usr/bin/duplicity", line 900, in next
self.fileobj.close()
  File "/usr/lib/python2.6/dist-packages/duplicity/dup_temp.py", line 210, in 
close
assert not self.fileobj.close()
  File "/usr/lib/python2.6/dist-packages/duplicity/gpg.py", line 198, in close
self.gpg_failed()
  File "/usr/lib/python2.6/dist-packages/duplicity/gpg.py", line 165, in 
gpg_failed
raise GPGError, msg
GPGError: GPG Failed, see log below:
= Begin GnuPG log =
gpg: decrypt_message failed: eof
= End GnuPG log =


GPGError: GPG Failed, see log below:
= Begin GnuPG log =
gpg: decrypt_message failed: eof
= End GnuPG log =

> from the lack of log info about backup chains it seems to me that one 
> of the manifests is damaged/empty/undecryptable, can you check their file 
> sizes 
> on the remote storage backend? (ideally run a collection-status and 
> list-current-files, too.)

You're right : the duplicity-full.20101006T231429Z.manifest.g

Bug#606145: leafpad: Saving in UTF16 encoding truncates file

[Jari Aalto]

tags 606145 + moreinfo
thanks

Alex,

Could you send your settings; output of:

locale -a

To this bug report.

Thanks,
Jari



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

Bug#606145: leafpad: Saving in UTF16 encoding truncates file

[jari]

On 2010-12-08 07:36, Tarot Osuji wrote:
| (2010/12/08 0:45), Jari Aalto wrote:
| > 
| > Hi Tarot,
| > 
| > FYI, there is new bug report concerning the UTF problems:
| > 
| >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606145
|
| Hi Jari,
| 
| Encoding feature is derived from built-in Glib's iconv feature (g_convert).
| Type 'iconv -l' on command line.
| Leafpad can use listed encoding only.

Hm, the bug reporter's "UTF16LE" seems to appear in listing:

$ iconv -l | grep -i utf16le
UTF16LE//

Does that mean, that this encoding should also be supported by leafpad?

 $ ldd /usr/bin/leafpad | grep -i libglib
 libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x7f1f149f7000)

 $ apt-cache policy leafpad
 leafpad:
Installed: 0.8.17-3

Tarot, can you suggest where to look further or if you need test files
from the bug submitter?

Jari



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

Bug#462792: RFS: failmalloc

[Jonathan Nieder]

Hi Allesandro,

Alessandro Ghedini wrote:

> * URL : http://www.nongnu.org/failmalloc
[...]
> - dget 
> http://mentors.debian.net/debian/pool/main/f/failmalloc/failmalloc_1.0-1.dsc

Since I am not a Debian Developer, I cannot upload this.  Some
comments anyway.

> Package: libfailmalloc-dev
> Description: Memory allocation failure crash-test tool (development files)
[...]
>  This package provides the development files for the failmalloc library.

Does failmalloc have a public API?  Is it meant to be linked into
programs without using the LD_PRELOAD mechanism?

If not, what good is a development library for it?

> Package: libfailmalloc0
> Description: Memory allocation failure crash-test tool

I would suggest installing it to

/usr/lib/libfailmalloc/libfailmalloc.so

.  That way, there is no temptation to link programs to it explicitly.
Unversioned since there is no reason to install multiple versions at
once.

Since you are selling it as a tool rather than a preload library
(reasonable enough), have you considered providing a

/usr/bin/failmalloc

script to do the LD_PRELOAD automatically?  See fakeroot for
inspiration.

> #!/usr/bin/make -f
> # -*- makefile -*-
> # Sample debian/rules that uses debhelper.

It's not a sample any more, is it?  I'd suggest removing the
authorship notice.

 #!/usr/bin/make -f

 %:
dh $@

is too simple to require the notice for moral reasons, I'd think.  As
legal reasons go, "without restriction" includes the ability to remove
the blurb.  Or you can copy from
/usr/share/doc/debhelper/examples/rules.tiny by the same author which
does not include that notice.

Hope that helps,
Jonathan



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

Bug#606239: custom 404 to hide info and be nice for user

[Alexander Reichle-Schmehl]

Hi!

Am 07.12.2010 19:08, schrieb Stéphane Blondon:

> - the details of the configuration are public (currently Apache/2.2.9,
> etc.). Hiding them would be lightly better (but the gain is not huge
> since there are other ways to get them).

That's a completely different topic.  Even if you have a custom 404
file, nothing prevents someone from running "curl -I
http://www.debian.org/"; or similar to still access these informations.

However, I can see the other arguments for a custom 404 page.


Best regards,
  Alexander



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

Bug#606289: 4.0.517 firmware crashes frequently on HP NC522SFP

[dann frazier]

Package: firmware-netxen
Version: 0.27
Severity: important

A user reported that the 4.0.517 crashes within seconds on this
netxen-based NIC - this is the firmware version we currently ship in
0.27. The user confirmed that 4.0.534 fixes the issue. This version
was recently accepted into the linux-firmware tree.



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

Bug#533728: Doc updated

[Oren Held]

I've checked both the 'Portable Audio Player Source' and 'Library
Source' contents, and both don't have the inaccuracies you mentioned.
They generally look OK to me.

I believe that this bug could be closed now.



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

Bug#552201: [Groff] Re: Bug#552201: groff-base: Japanese manpages are shown with too wide spaces

[Werner LEMBERG]

>> the `classes' keyword for font files, ...
> 
> What is the keyword supposed to work?  I didn't notice that since it
> is currently not used in any font file and seems not to affect the
> run-time behavior.  Perhaps a wreck of the original patch?

The `classes' keyword should help reduce the size of non-TTY font
description files of CJK fonts: Instead of thousands of lines in the
`charset' section for glyphs from the CJK range(s), you just have a
single one, something like

  classes
  [CJK]  u4E00-u9FFF

  charset
  ...
  [CJK]  1000,800,200  3  ?  ?

However, the two question marks indicate that I don't know how to
handle those fields.  Perhaps it should be something like

  [CJK]  1000,800,200  3  %d  uni%X

to programmatically derive the index value for \N'...' (field 4) and
the PS glyph name for grops (field 5), but this isn't implemented yet.

So please ignore the `classes' keyword documentation; I'll remove the
corresponding code, to be postponed for later.  Alternatively, you
might add the missing bits right now :-)

Besides that, it is an interesting question how to support Japanese
fonts for CJK characters.  In my CJK package for LaTeX, I've used
active characters to activate CJK fonts for CJK characters.  For
groff, the probably easiest method is to register, say, a Japanese
font as `special' using either `.fspecial' or `.special'.  Then any
glyph not found in the current (latin) font is taken from the fspecial
or special list.

Note that I can't remember how this has been solved in the old Debian
extension for Japanese...

> I'm now trying to extend current ja.tmac to support Chinese and Korean:
> http://ueno.fedorapeople.org/groff/make-cjk-tmac/

Very nice!


Werner



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

Bug#552985: WFM on 0.12.8-2

[Oren Held]

I cannot reproduce on 0.12.8-2 on my setup.
I've enabled crossfade of 2 seconds, changing songs (both manually and
automatic) works well, time bar seems accurate.

Oren



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

Bug#600490: Russian phonetic layout on a jp keyboard?

[Samuel Thibault]

Dima Pasechnik, le Thu 02 Dec 2010 12:26:11 +0800, a écrit :
> $ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
>  layouts = [jpjp106]
>  options = [terminate terminate:ctrl_alt_bksp,grp 
> grp:ctrl_shift_toggle,grp   grp:alt_space_toggle,grp
> grp:menu_toggle,grp grp:sclk_toggle]
>  model = toshiba_s3000
> 
> Note jp106 string in gconftool-2.

Indeed it looks suspicious.

> I do not know where it comes from (do I still have an old config file
> lying around?) and whether it is harmless.

Well, in the gconf case, the config file is the gconf database, more
precisely ~/.gconf/desktop/gnome/peripherals/keyboard. You can use the
gconftool-2 command to change it.

> The model string content there is totally random, of course, and has
> nothing to do with the real keyboard.

Samuel



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

Bug#606288: xserver-xorg-video-intel: No longer finds display; does not allow VT switch (ThinkPad X200)

[Josh Triplett]

Package: xserver-xorg-video-intel
Version: 2:2.13.0-4
Severity: important

I currently have a bleeding-edge kernel from one of the wireless
repositories installed in order to try to deal with another bug.  I
previously didn't have any problem using that kernel, but after
upgrading to the latest Intel driver, the next time I booted I no longer
had a working X.  The display went blank and stayed that way, though the
backlight stayed on.  I also could not VT switch back to a text console.

I rebooted into single-user mode, and captured the log file, included
below where Xorg.0.log would normally appear.  It looks like the intel
driver no longer decided it can drive my graphics card.  Given that the
most recent version of the driver changed the probe logic, that could
make sense.

As far as I know, I *think* this kernel I built has
KMS support; I've attached the kernel config file (produced by
"make localmodconfig"), in case it lacks something important that the
Intel driver requires.  *Something* must have gone wrong, because
if I boot into the older kernel then X comes up just fine.

In any case, if the Intel driver somehow decided that it couldn't drive
my video card because it didn't think it had modesetting, that still
shouldn't have wedged my system by refusing to fail or VT switch, or
bring up the usual dialog for when X keeps failing.

Thanks,
Josh Triplett

-- Package-specific info:
/var/lib/x11/X.roster does not exist.

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 Nov 20  2008 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1889472 Dec  1 17:16 /usr/bin/Xorg

/var/lib/x11/xorg.conf.roster does not exist.

VGA-compatible devices on PCI bus:
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 07)

/etc/X11/xorg.conf does not exist.

Kernel version (/proc/version):
Linux version 2.6.37-rc4-wl+ (j...@feather) (gcc version 4.4.5 (Debian 
4.4.5-10) ) #1 SMP Sat Dec 4 16:18:14 PST 2010

Xorg X server log files on system:
-rw-r--r-- 1 root root 32039 Jan  7  2010 /var/log/Xorg.20.log
-rw-r--r-- 1 root root  7916 May 12  2010 /var/log/Xorg.2.log
-rw-r--r-- 1 root root  7916 May 12  2010 /var/log/Xorg.5.log
-rw-r--r-- 1 root root  7916 May 12  2010 /var/log/Xorg.4.log
-rw-r--r-- 1 root root  7916 May 12  2010 /var/log/Xorg.3.log
-rw-r--r-- 1 root root 23864 Oct  6 12:06 /var/log/Xorg.1.log
-rw-r--r-- 1 root root   Dec  7 21:43 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:
[deleted in favor of Xorg.0.log.old, which shows the problem]

X.Org X Server 1.7.7
Release Date: 2010-05-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32.26-dsa-amd64 x86_64 Debian
Current Operating System: Linux feather 2.6.37-rc4-wl+ #1 SMP Sat Dec 4 
16:18:14 PST 2010 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37-rc4-wl+ 
root=UUID=a8fb9a37-fac7-4a3e-8081-fc7b347bd0b2 ro quiet
Build Date: 02 December 2010  01:10:32AM
xorg-server 2:1.7.7-10 (Julien Cristau ) 
Current version of pixman: 0.16.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec  7 21:43:42 2010
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |-->Screen "Default Screen Section" (0)
(**) |   |-->Monitor ""
(==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
Entry deleted from font path.
(WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not 
exist.
Entry deleted from font path.
(==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
(II) Loader magic: 0x7c7500
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 6.0
X.Org XInput driver : 7.0
X.Org Server Extension : 2.0
(++) using VT number 8

(--) PCI:*(0:0:2:0) 8086:2a42:17aa:20e4 Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller rev 7, Mem @ 0xf200/4194304, 
0xd000/26

Bug#606066: closed by Guido Günther (Re: [Pkg-libvirt-maintainers] Bug#606066: libvirt0: fails to define default network)

[Ian Allison]

Hi

On Mon, Dec 6, 2010 at 12:21 AM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> After installing kvm and libvirt, no default NAT-ing network is defined
> > and trying yo define it via virsh results in an error
> Please see /usr/share/doc/libvirt-bin/READM.Debian. The network is
> _defined_ but not _started_.
>  -- Guido
>

Thanks for looking at my bug, I had read the readme and tried the steps
outlined in it but it didn't work

$ virsh net-start default
  error: failed to get network 'default'
  error: Unknown failure

There is no default network defined at all. Since no-one else seems to be
having the problem I'll assume that there is something wrong with my system
rather than a bug.

Thanks,
 Ian.

Bug#603429: hylafax-server: prompting due to modified conffiles which where not modified by the user

[Giuseppe Sacco]

Hi all,
the idea behind the use of RUN_HYLAFAX=1 is that the user should be able
to enable or disable hylafax daemon. This is not easy at all, since
hylafax daemons are many processes, and the user may select to start a
few of them from inittab. BTW, if the only way to start daemons is from
init.d script, then this flag is meant to pilating hylafax activation.

This flag was not available until a few years ago. When introduced its
default value was 0 and hylafax would not start after installation. Then
(of course) a few people complained that hylafax was not starting
anymore for no apparent reason (the flag was documented only in README),
so the default value was changed to 1.

I like to idea you proposed: leave it at 1 and do not touch it anymore.
The init.d script should be changed in order to warn the user when
action is "start" and the flag is at 0, the start action should return a
0 status in order to have upgrade script working correctly, isn't it?

Bye,
Giuseppe




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

Bug#604221: hylafax-server: installation fails

[Giuseppe Sacco]

Il giorno mar, 07/12/2010 alle 18.18 +0100, gregor herrmann ha scritto:
> On Sun, 28 Nov 2010 14:26:43 +0100, gregor herrmann wrote:
[...]
> Ok, I've now prepared another patch that checks for the existence of
> /etc/mtab before using it, which should solve this bug.

I probably missed the new patch. Could you please send it again?

Thanks,
Giuseppe




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

Bug#598130: 'grub-pc' package failed to install on squeeze live beta 1

[Kartik Singhal]

My problem seems related to above.

I was trying to install Debian Squeeze Live Beta 1 amd64.

I chose the GUI install and everything ran fine upto installation of grub.
Here is what I got:

GRUB installation failed
The 'grub-pc' package failed to install into /target/. Without the GRUB boot
loader, the installed system will not boot.

I tried various methods from the Debian installer itself, like installing
grub again and continuing without grub installer but I ended up to same
point all over again. So I had to abort the installation.

Here is the relevant part of syslog at this state:


Dec  7 14:20:50 in-target: Fetched 7,516 B in 1s (5,420 B/s)
Dec  7 14:20:50 in-target: Reading package lists...
Dec  7 14:20:54 in-target:
Dec  7 14:20:55 main-menu[580]: INFO: Menu item 'grub-installer' selected
Dec  7 14:20:55 grub-installer: info: architecture: amd64/generic
Dec  7 14:21:01 grub-installer: info: Identified partition label for
/dev/sda11: msdos
Dec  7 14:21:05 grub-installer: dpkg: warning: ignoring request to remove
grub which isn't installed.
Dec  7 14:21:05 grub-installer: dpkg: warning: ignoring request to remove
grub-legacy which isn't installed.
Dec  7 14:21:07 in-target: Reading package lists...
Dec  7 14:21:11 in-target:
Dec  7 14:21:11 in-target: Building dependency tree...
Dec  7 14:21:11 in-target:
Dec  7 14:21:11 in-target: Reading state information...
Dec  7 14:21:11 in-target:
Dec  7 14:21:11 in-target: E: Unable to locate package grub-pc
Dec  7 14:21:11 grub-installer: info: Calling 'apt-install grub-pc' failed
Dec  7 14:21:31 main-menu[580]: (process:13482): File descriptor 3
(pipe:[3568]) leaked on lvdisplay invocation. Parent PID 13520: /bin/sh
Dec  7 14:21:31 main-menu[580]: (process:13482): File descriptor 4
(/dev/tty0) leaked on lvdisplay invocation. Parent PID 13520: /bin/sh
Dec  7 14:21:31 main-menu[580]: (process:13482): File descriptor 5
(/dev/tty0) leaked on lvdisplay invocation. Parent PID 13520: /bin/sh
Dec  7 14:21:31 main-menu[580]: (process:13482): File descriptor 6
(/dev/tty0) leaked on lvdisplay invocation. Parent PID 13520: /bin/sh
Dec  7 14:21:31 main-menu[580]: (process:13482):   Volume group "sda" not
found
Dec  7 14:21:31 main-menu[580]: (process:13482):   Skipping volume group sda
Dec  7 14:21:31 main-menu[580]: (process:13482): perl: warning: Setting
locale failed.
Dec  7 14:21:31 main-menu[580]: (process:13482): perl: warning: Please check
that your locale settings:
Dec  7 14:21:31 main-menu[580]: (process:13482): LANGUAGE = (unset),
Dec  7 14:21:31 main-menu[580]: (process:13482): LC_ALL = (unset),
Dec  7 14:21:31 main-menu[580]: (process:13482): LANG = "C.UTF-8"
Dec  7 14:21:31 main-menu[580]: (process:13482): are supported and
installed on your system.
Dec  7 14:21:31 main-menu[580]: (process:13482): perl: warning: Falling back
to the standard locale ("C").
Dec  7 14:21:31 main-menu[580]: (process:13482): locale: Cannot set LC_CTYPE
to default locale: No such file or directory
Dec  7 14:21:31 main-menu[580]: (process:13482): locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
Dec  7 14:21:31 main-menu[580]: (process:13482): locale: Cannot set LC_ALL
to default locale: No such file or directory
Dec  7 14:21:31 main-menu[580]: (process:13482): perl: warning: Setting
locale failed.
Dec  7 14:21:31 main-menu[580]: (process:13482): perl: warning: Please check
that your locale settings:
Dec  7 14:21:31 main-menu[580]: (process:13482): LANGUAGE = (unset),
Dec  7 14:21:31 main-menu[580]: (process:13482): LC_ALL = (unset),
Dec  7 14:21:31 main-menu[580]: (process:13482): LANG = "C.UTF-8"
Dec  7 14:21:31 main-menu[580]: (process:13482): are supported and
installed on your system.
Dec  7 14:21:31 main-menu[580]: (process:13482): perl: warning: Falling back
to the standard locale ("C").
Dec  7 14:21:31 main-menu[580]: (process:13482): locale: Cannot set LC_CTYPE
to default locale: No such file or directory
Dec  7 14:21:31 main-menu[580]: (process:13482): locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
Dec  7 14:21:31 main-menu[580]: (process:13482): locale: Cannot set LC_ALL
to default locale: No such file or directory
Dec  7 14:21:31 main-menu[580]: WARNING **: Configuring 'grub-installer'
failed with error code 1
Dec  7 14:21:31 main-menu[580]: WARNING **: Menu item 'grub-installer'
failed.
Dec  7 14:21:33 main-menu[580]: INFO: Modifying debconf priority limit from
'high' to 'medium'
Dec  7 14:21:33 debconf: Setting debconf/priority to medium
Dec  7 14:21:42 main-menu[580]: INFO: Menu item 'nobootloader' selected
Dec  7 14:21:42 main-menu[580]: INFO: Menu item 'nobootloader' succeeded but
requested to be left unconfigured.
Dec  7 14:21:44 main-menu[580]: INFO: Menu item 'nobootloader' selected
Dec  7 14:21:45 main-menu[580]: INFO: Menu item 'nobootloader' succeeded but
requested to be left unconfigured.
Dec  7 14:21:46 main-menu[580]: INFO: Menu item 'nobootloader' selected
Dec  7 14:21

Bug#605769: unknown monitor OID

[Brian May]

On 3 December 2010 21:12, Brian May  wrote:
> Package: snmpd
> Version: 5.4.3~dfsg-1
>
> Whenever I try to restart snmpd I get a list of errors (see below). I
> don't know if these errors are fatal or not.
>
> It is also says these errors occur on line 143 of snmpd.conf, which is
> "defaultMonitors yes".
>
> Seems to suggest to me that maybe the snmpd with the default
> configuration is broken without the non-free MIBs. I tried to find
> where these OIDs are referenced from but unfortunately failed.

The errors continue even after installing the MIBS using the
snmp-mibs-downloader package.

Seems like the snmpd Debian package has gone backwards since lenny,
that version works fine :-(.
-- 
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#552201: [Groff] Re: Bug#552201: groff-base: Japanese manpages are shown with too wide spaces

[Daiki Ueno]

Thanks Werner and Colin for the insightful comments.

Werner LEMBERG  writes:

> However, a very important piece is still missing: documentation!  I
> won't commit the changes otherwise.

I'm now preparing the documentation.  One question:

> the `classes' keyword for font files, ...

What is the keyword supposed to work?  I didn't notice that since it is
currently not used in any font file and seems not to affect the run-time
behavior.  Perhaps a wreck of the original patch?

> I second that; it's not necessary to do that so I'll omit these
> changes to nroff.

Good to know that man-db already has the hook to load locale macros :)

> I think that the (current) contents of ja.tmac is essentially
> universal, not restricted to Japanese.

Yes and probably CJK languages can share a single .tmac for kinsoku
processing, since the kinsoku rules for those languages are not likely
to overlap each other.

I'm now trying to extend current ja.tmac to support Chinese and Korean:
http://ueno.fedorapeople.org/groff/make-cjk-tmac/

Regards,
-- 
Daiki Ueno



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

Bug#606287: d-i manual: should add a "what is the Debian Installer" section

[Samuel Thibault]

Package: installation-guide
Version: 20100518
Severity: wishlist

- Forwarded message from Miguel Figueiredo  -

From: Miguel Figueiredo 
To: Samuel Thibault 
Subject: Re: manual - topics organization
Date: Mon, 6 Dec 2010 20:20:29 +
X-Spam-Level: 
X-Spam-Status: No, score=0.9 required=8.0 tests=BAYES_50,HTML_MESSAGE,
TVD_RCVD_SPACE_BRACKET autolearn=disabled version=3.3.1
User-Agent: KMail/1.13.5 (Linux/2.6.36-ck2+; KDE/4.4.5; i686; ; )
Message-Id: <201012062020.29621.el...@debianpt.org>

Hi Samuel,

made some minor improvements.

Thanks for your reply.

A Segunda 06 Dezembro 2010 15:23:50, você escreveu:
> Just to at least give you an answer.
> 
> Miguel Figueiredo, le Mon 29 Nov 2010 01:08:33 +, a écrit :
> > A Quarta 24 Novembro 2010 00:58:22, você escreveu:
> > 
> > [...]
> > 
> > > > on 1.x add What is the Debian Installer (purpose and scope of the
> > > > installer)
> > > 
> > > That can be useful, yes, please submit a bug (with a patch).
> > 
> > [...]
> > 
> > Care to take a look?
> 
> Care, yes, but time, not at the moment...
> 
> Samuel

-- 
Melhores cumprimentos/Best regards,

Miguel Figueiredo
http://www.DebianPT.org


What is the Debian Installer?



Debian Installer, also known as "d-i", is the software system to install 
a basic working Debian system. A wide range of hardware such as
embedded devices, laptops, desktops and server machines is supported and a
large set of free software for many purposes is offered.



The installation is conducted by answering a basic set of questions.
Also available are an expert mode that allows to control every aspect of 
the installation and an advanced feature to perform automated installations.
The installed system can be used as is or further customized.
The installation can be performed from a multitude of sources: USB,
CD/DVD/Blue Ray or the network.



The installer goes back to the boot-floppies project, and it was 
http://lists.debian.org/debian-boot/2000/06/msg00279.html";>first 
mentioned by Joey Hess in 2000 [1]. Since then the installation system 
has been continuously developed by volunteers improving and adding more 
features.



More information can be found on the http://www.debian.org/devel/debian-installer/";>Debian Installer page
, on the http://wiki.debian.org/DebianInstalle";>Wiki
 and on the http://lists.debian.org/debian-boot/";>
debian-boot mailing list.



 



- End forwarded message -

-- 
Samuel
/*
 * Oops. The kernel tried to access some bad page. We'll have to
 * terminate things with extreme prejudice.
*/
die_if_kernel("Oops", regs, error_code);
(From linux/arch/i386/mm/fault.c)  



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

Bug#606286: freetype: Freetype 2.4.4 is out with UVS Support and more

[Marc J. Driftmeyer]

Package: freetype
Version: 2.4.4
Severity: normal


CHANGES BETWEEN 2.4.3 and 2.4.4

  I. IMPORTANT BUG FIXES

- UVS support (TrueType/OpenType cmap format 14) support is fixed.
  This regression has been introduced in version 2.4.0.

  II. MISCELLANEOUS

- Detect tricky fonts (e.g. MingLiU)  by the lengths and checksums
  of Type42-persistent subtables (`cvt ', `fpgm', and `prep') when
  a TrueType font without family name is given.  The previous fix,
  introduced in 2.4.3,  was too rigorous,  causing many  subsetted
  fonts (mainly  from PDF files) displayed badly  because FreeType
  forced  rendering with  the TrueType bytecode engine  instead of
  the autohinter.

- Better support for 64bit platforms.

- More fixes to improve handling of broken fonts.




Copyright 2010 by
David Turner, Robert Wilhelm, and Werner Lemberg.

This  file  is  part  of the  FreeType  project, and may  only be  used,
modified,  and  distributed  under  the  terms of  the FreeType  project
license, LICENSE.TXT.   By continuing to use, modify, or distribute this
file you  indicate that  you have  read the  license and understand  and
accept it fully.


Local Variables:
version-control: never
coding: utf-8


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

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



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

Bug#606182: duplicity: Fails to restore on initial run with GPGError

[Alexander Zangerl]

tag 606182 + unreproducible moreinfo
thanks


On Tue, 07 Dec 2010 09:25:03 +0100, Olivier Berger writes:
>I have backups on remote server and try to restore to non-existing dir, with em
>pty ~/.cache/duplicity, and get :
>
># duplicity --force --ssh-askpass scp://r...@xx//mnt/xx/dupbackups/
>x /home/xx/restore/
>Password for 'x': 
>GnuPG passphrase: 
>Synchronizing remote metadata to local cache...
>Copying duplicity-full-signatures.20101206T005609Z.sigtar to local cache.
>Copying duplicity-full.20100116T134814Z.manifest to local cache.
>Copying duplicity-full.20100905T190548Z.manifest to local cache.
>Copying duplicity-full.20101006T231429Z.manifest to local cache.
>GPGError: GPG Failed, see log below:
>= Begin GnuPG log gpg: decrypt_message failed: eof
>= End GnuPG log 
>Thanks in advance.

i can't reproduce the problem here; would you please send me the output
of a run with -v 9 and with (re-)cleaned cache?

from the lack of log info about backup chains it seems to me that one 
of the manifests is damaged/empty/undecryptable, can you check their file sizes 
on the remote storage backend? (ideally run a collection-status and 
list-current-files, too.)

regards
az


-- 
+ Alexander Zangerl + DSA 42BD645D + (RSA 5B586291)
C++ is history repeated as tragedy. Java is history repeated as farce.
 -- Scott McKay


signature.asc
Description: Digital Signature

Bug#605878: re duplicity assertion error

[Alexander Zangerl]

tag 605878 + upstream
forwarded 605878 https://bugs.launchpad.net/duplicity/+bug/489690
thanks

that problem was reported upstream a year ago, with no cause/fix known
as of right now :/

regards
az


-- 
+ Alexander Zangerl + DSA 42BD645D + (RSA 5B586291)
Things should be as simple as possible, but not simpler. -- Albert Einstein


signature.asc
Description: Digital Signature

Bug#606285: "Error: Expected the default config" should be clearer

[jidanni]

X-debbugs-Cc: der...@glyphandcog.com
Package: xpdf
Version: 3.02-11
Severity: wishlist

Messages like
Error: Expected the default config, but wasn't able to find it, or it isn't a 
Dictionary
make it look like xpdf is talking about something in /etc, but as this
doesn't occur on some files, it must be talking about something in the
file.

Please make the error message clear so it doesn't look like a Debian bug.
The file was http://www3.nccu.edu.tw/~97154007/tscd.pdf .



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

Bug#594451: lenny->squeeze upgrade issue

[Antonio Radici]

tags 594451 +confirmed pending
thanks

On Tue, Nov 16, 2010 at 02:33:10PM +0200, Stefano Rivera wrote:
> severity 575581 important
> tags 575581 -patch
> severity 594451 serious
> tags 594451 +patch
> thanks
> 
> Russell's report, bug 575581, says:
> > Program version 4.7 doesn't match environment version 4.6
> 
> The error I saw (and Johan's patch addresses), bug 594451, is:
> > Program version 4.7 doesn't match environment version 4.8
> 
> I think 575581 is an old issue that has been superseded by 594451.
> Thus reverting the severity of 575581, and bumping 594451, as it affects
> lenny->squeeze upgrades. Not merging these bugs as they are reporting
> different symptoms.
> and then calls db4.8_upgrade.
> 
> However, I prefer Stephen's approach, as upgrading the DB in preinst
> does appear unnecessary (and is certainly currently broken). Can anyone
> who knows a little more about libberkeleydb-perl confirm that?
> 
> Patch for 594451 attached.

Hi,
sorry for the late reply but I had been busy lately.

I have committed the fix into git (collab-maint/postgrey.git) and sent a mail to
debian-release asking for their permission to upload to
testing-proposed-updates.

Once they confirm I will upload the package straight away.

Cheers
Antonio



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

Bug#606250: System map of 2.6.32-5-amd64 does not match kernel

[Ben Hutchings]

On Wed, 2010-12-08 at 00:11 +, Ben Hutchings wrote:
> On Tue, 2010-12-07 at 21:13 +0100, Jan Wielemaker wrote:
[...]
> > Looks like a trivial bug, but I cannot find a report that indicates
> > it has been filed before.  Is there a way to fix this without
> > recompiling the kernel from scratch myself?
> 
> This is a bug in procps.  It's relying on some version information which
> is only present in System.map if the kernel was configured without
> CONFIG_KALLSYMS set.

Actually this is not so clear.  The error message ps shows when you set
PS_SYSTEM_MAP is incorrect, but then ps shouldn't even need System.map
when the kernel is configured with CONFIG_KALLSYMS!

However, wchan cannot be provided when the 'omit frame pointer'
optimisation is used in the kernel.  We enable that optimisation on x86
kernels, and have done for some time.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#606283: Attaching a patch

[Alessio Treglia]

tags 606283 patch
thanks

Attaching a patch.


-- 
Alessio Treglia          | www.alessiotreglia.com
Debian Developer         | ales...@debian.org
Ubuntu Core Developer    | quadris...@ubuntu.com
0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0
diff -u muse-0.8.1a/debian/changelog muse-0.8.1a/debian/changelog
--- muse-0.8.1a/debian/changelog
+++ muse-0.8.1a/debian/changelog
@@ -1,3 +1,10 @@
+muse (0.8.1a-7.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Drop ladcca support since it's obsolete (Closes: #606283).
+
+ -- Alessio Treglia   Wed, 08 Dec 2010 01:53:03 +0100
+
 muse (0.8.1a-7) unstable; urgency=high
 
   * Added patches:
diff -u muse-0.8.1a/debian/control muse-0.8.1a/debian/control
--- muse-0.8.1a/debian/control
+++ muse-0.8.1a/debian/control
@@ -2,7 +2,7 @@
 Section: sound
 Priority: optional
 Maintainer: Daniel Kobras 
-Build-Depends: debhelper (>= 7), libqt3-mt-dev, libasound2-dev, libsndfile1-dev, libjack-dev, libfluidsynth-dev (>> 1.0.3-5), libsamplerate0-dev, liblash-dev, uuid-dev, dpatch, autotools-dev, ladcca-dev
+Build-Depends: debhelper (>= 7), libqt3-mt-dev, libasound2-dev, libsndfile1-dev, libjack-dev, libfluidsynth-dev (>> 1.0.3-5), libsamplerate0-dev, liblash-dev, uuid-dev, dpatch, autotools-dev
 Standards-Version: 3.7.3
 
 Package: muse

Bug#606278: [buildd-tools-devel] Bug#606278: aptitude resolver is completely broken in 0.60.6

[Modestas Vainius]

Hello,

On trečiadienis 08 Gruodis 2010 02:47:14 Modestas Vainius wrote:
> I guess now it wants a key. I spotted `sbuild-update --keygen` in the
> changelog and used it. Now it went much further but failed to pick up
> required build-deps from experimental (attached). Please note that sbuild
> 0.60.5 was fine with this phonon-backend-vlc dsc (get it from incoming).

Ok, the latter is because you removed a key option (that I added some time 
ago) from aptitude command line in 80f811184d7c7b06a6a5ec8d646b1eac015dffa2. 
That's:

'-o', "Aptitude::ProblemResolver::Hints::KeepDummy=reject $dummy_pkg_name 
:UNINST",

Adding it back (the patch is attached) made AptitudeResolver install required 
libphonon-dev dependencies from experimental and finally phonon-backend-vlc 
was built successfully.

P.S. But /tmp and entropy issues still need to be dealt with IMHO.


-- 
Modestas Vainius 
From 8f8894c0daaa7c172e0cba7a6068f185a7615e6e Mon Sep 17 00:00:00 2001
From: Modestas Vainius 
Date: Wed, 8 Dec 2010 03:00:39 +0200
Subject: [PATCH] Add "KeepDummy" hint back to aptitude command line.

It got removed in 80f811184d7c7b06a6a5ec8d646b1eac015dffa2. This hint is
essential for aptitude to choose a right solution when it needs to pull
additional dependencies from experimental or other non-default archives.

For more information see 95d14803e00e74aef5f6bab7e4e9cae7177423c9 when this
hint was originally introduced.
---
 lib/Sbuild/AptitudeResolver.pm |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/lib/Sbuild/AptitudeResolver.pm b/lib/Sbuild/AptitudeResolver.pm
index 4136626..9b63c4f 100644
--- a/lib/Sbuild/AptitudeResolver.pm
+++ b/lib/Sbuild/AptitudeResolver.pm
@@ -86,6 +86,7 @@ sub install_deps {
 	'--without-recommends',
 	'-o', "Aptitude::CmdLine::Ignore-Trust-Violations=$ignore_trust_violations",
 	'-o', 'Aptitude::ProblemResolver::StepScore=100',
+	'-o', "Aptitude::ProblemResolver::Hints::KeepDummy=reject $dummy_pkg_name :UNINST",
 	'-o', 'Aptitude::ProblemResolver::Keep-All-Level=55000',
 	'-o', 'Aptitude::ProblemResolver::Remove-Essential-Level=maximum',
 	'install',
-- 
1.7.2.3



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

Bug#606278: [buildd-tools-devel] Bug#606278: aptitude resolver is completely broken in 0.60.6

[Modestas Vainius]

Hello,

On trečiadienis 08 Gruodis 2010 01:58:13 Roger Leigh wrote:
> On Wed, Dec 08, 2010 at 01:38:26AM +0200, Modestas Vainius wrote:
> > aptitude resolver no longer works in 0.60.6. I suppose it has become
> > pretty important because it's the only which supports experimental
> > properly. See sample build log below.
> > 
> > dpkg-deb: failed to open package info file
> > `/tmp/resolver-nGygHK/sbuild-build-depends-core-dummy/DEBIAN/control'
> > for reading: No such file or directory Dummy package creation failed
> > Core source dependencies not satisfied; skippingNot cleaning session:
> > cloned chroot in use Keeping session:
> > debian-experimental-amd64-sbuild-5b96bbf9-3747-4053-8607-bdb68178e9e7
> 
> This is odd.  It's working fine on my system, so I wonder what's
> different?
> 
> It's clearly failing when trying to create the dummy dependency
> package.  What is the content of /tmp/resolver-nGygHK ?

/tmp/resolver-* is created on my system, but 'dpkg-deb', '--build' is run 
inside chroot session. So I guess I have to bind mount /tmp since 0.60.6 or is 
this unintentional?

When I bind-mounted /tmp, it went a bit further but now it failed with:

dpkg-deb: building package `sbuild-build-depends-core-dummy' in 
`/tmp/resolver-D4hCcH/apt_archive/sbuild-build-depends-core-dummy.deb'.
gpg: no default secret key: secret key not available
gpg: signing failed: secret key not available
Failed to sign dummy archive Release file.
Core source dependencies not satisfied; skippingNot cleaning session: cloned 
chroot in use

I guess now it wants a key. I spotted `sbuild-update --keygen` in the 
changelog and used it. Now it went much further but failed to pick up required 
build-deps from experimental (attached). Please note that sbuild 0.60.5 was 
fine with this phonon-backend-vlc dsc (get it from incoming).

This means that my setup might need even more changes now. Well, sigh. It begs 
the question why it has to be so complicated?

Another concern is that I got a message about lack of entropy once (I suppose 
from gpg) during my short testing. Now imagine buildd hanging in this state...

-- 
Modestas Vainius 
sbuild (Debian sbuild) 0.60.6 (07 Dec 2010) on mdxdesktop.lan.vainius.eu

╔══╗
║ phonon-backend-vlc 0.3.1-1 (amd64) 08 Grd 2010 02:42 ║
╚══╝

Package: phonon-backend-vlc
Version: 0.3.1-1
Source Version: 0.3.1-1
Architecture: amd64

┌──┐
│ Fetch source files   │
└──┘


Local sources
─

phonon-backend-vlc_0.3.1-1.dsc exists in .; copying to chroot

Check arch
──

dpkg-deb: building package `sbuild-build-depends-core-dummy' in 
`/tmp/resolver-DJfhmz/apt_archive/sbuild-build-depends-core-dummy.deb'.
OK
Ign file: experimental Release.gpg
Ign file:/repositories/debian/ experimental/main Translation-en
Ign file:/tmp/resolver-DJfhmz/apt_archive/ ./ Translation-en
Get:1 file: ./ Release.gpg [316 B]
Get:2 file: experimental Release [2279 B]
Ign file: experimental/main amd64 Packages
Get:3 file: ./ Release [1328 B]
Get:4 http://ftp.de.debian.org experimental Release.gpg [835 B]
Ign http://ftp.de.debian.org/debian/ experimental/main Translation-en
Ign file: ./ Sources
Ign file: ./ Packages
Get:5 http://ftp.de.debian.org experimental Release [102 kB]
Get:6 http://ftp.de.debian.org experimental/main amd64 Packages [697 kB]
Hit ftp://ftp.de.debian.org unstable Release.gpg
Get:7 ftp://ftp.de.debian.org/debian/ unstable/main Translation-en
Ign ftp://ftp.de.debian.org/debian/ unstable/main Translation-en
Hit ftp://ftp.de.debian.org unstable Release
Hit ftp://ftp.de.debian.org unstable/main Sources/DiffIndex
Hit ftp://ftp.de.debian.org unstable/main amd64 Packages/DiffIndex
Fetched 800 kB in 2s (374 kB/s)
Reading package lists...

┌──┐
│ Install core build dependencies (aptitude-based resolver)│
└──┘

Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
  libboost-iostreams1.42.0 libcwidget3 libept1 libncursesw5 libsigc++-2.0-0c2a
  libsqlite3-0 libxapian22
Suggested packages:
  tasksel debtags libcwidget-dev xapian-tools
Recommended packages:
  aptitude-doc-en aptitude-doc apt-xapian-index libparse-debianchangelog-perl
  libgpm2
The following NEW packages will be installed:
  aptitude libboost-iostreams1.42.0 libcwidget3 libept1 libncursesw5
  libsigc++-2.0-0c2a libsqlite3-0 libxapian22
0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/6345 kB of archives

Bug#606283: Please drop ladcca support

[Alessio Treglia]

Package: muse
Version: 0.8.1a-7
Severity: serious
Tags: sid squeeze

Hi!


The package 'ladcca' is orphaned [1], superseded by lash and abandoned 
upstream, so we would like to remove it from the archives in time for Squeeze 
(this is the rationale for setting this as 'serious').
In order to do that, we're asking you to remove the build-dependency on it and 
make a new upload to rebuild the package without the ladcca support.


Kind regards,

 Alessio


[1] http://bugs.debian.org/547026

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

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



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

Bug#606268: [Pkg-utopia-maintainers] Bug#606268: now ignores interfaces configured by d-i

[Michael Biebl]

On 08.12.2010 01:32, Joey Hess wrote:

> But even if that is the case, this still stands:
> 
> a. Would you really want laptops' wireless interfaces to be
>managed by ifupdown on a system with network-manager, by default?

No, but as I already mentioned imho this can only be handled half way sane in
d-i to not write out any /e/n/i configuration in the first place if
network-manager is being installed.
How would you know the configuration is from d-i and not manually added by the
administrator?
How would you handle the case where ifupdown is indeed used to configure the
wireless interface and there is no configuration for network-manager?

Commenting out the /e/n/i configuration then would kill the network connection,
which would be RC too.
Before commenting out anything in /e/n/i I need to be sure NM will be able to
bring up the device. This is really only possible to say for a interface
configuration with dhcp and nothing else.

So in a case like this I'd leave the decision to the administrator to the
system. If he wants nm to manage the interface he can do so by commenting
out/removing the configuration from /e/n/i.

That's the only safe choice I see right now.

I'm open though to a solution which addresses the above questions.

> 
> b. squeeze is heavily frozen, and it is far, far to late in the release
>cycle to be making big changes to either d-i or network-manager.
> 

I know that, but I don't know what you want to imply with that or what you want
me to reply on that.

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#606282: ksplice-objmanip depends on wrong version of libbfd

[Robert L Mathews]

Package: ksplice
Version: 0.9.9-2
Severity: normal

When using "ksplice-create", it runs for a while and eventually
errors out with:

 /usr/lib/ksplice-objmanip: error while loading shared libraries:
 libbfd-2.19.51.20090827.so: cannot open shared object file: No such
 file or directory

Indeed, ksplice-objmanip uses libbfd-2.19.51.20090827.so, preventing
me from running it manually, either:

 $ ldd /usr/lib/ksplice-objmanip
linux-gate.so.1 =>  (0xb782b000)
libbfd-2.19.51.20090827.so => not found
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb76df000)
/lib/ld-linux.so.2 (0xb782c000)

 $ /usr/lib/ksplice-objmanip
 /usr/lib/ksplice-objmanip: error while loading shared libraries:
 libbfd-2.19.51.20090827.so: cannot open shared object file:
 No such file or directory

Looking at binutils on squeeze, it has a different version of
libbfd:

 $ dpkg -L binutils | egrep libbfd
 /usr/lib/libbfd-2.20.1-system.20100303.so

So it appears that ksplice-objmanip is depending on an unavailable
version of libbfd.

The inability to run ksplice-objmanip makes ksplice not work at all,
at least on my system (I don't know if this breaks it for everyone,
so I'm marking this as a "normal" bug for now).

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

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

Versions of packages ksplice depends on:
ii  binutils  2.20.1-15  The GNU assembler, linker and bina
ii  gcc [c-compiler]  4:4.4.5-1  The GNU C compiler
ii  gcc-4.4 [c-compiler]  4.4.5-8The GNU C compiler
ii  libc6 2.11.2-7   Embedded GNU C Library: Shared lib
ii  patch 2.6-2  Apply a diff file to an original
ii  perl  5.10.1-16  Larry Wall's Practical Extraction 
ii  rsync 3.0.7-2fast remote file copy program (lik

ksplice recommends no packages.

ksplice 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#606281: Unable to launch wavesurfer

[Alessio Treglia]

Package: wavesurfer
Version: 1.8.5-2
Severity: serious
Tags: sid squeeze

Hi,

wavesurfer seems failing to run, here is the error message:

ales...@alessio-laptop:~$ /usr/bin/wavesurfer 
Error in startup script: unknown option "-troughcolor"
while executing
".dummyscrollbar cget -troughcolor"
(in namespace eval "::wavebar" script line 8)
invoked from within
"namespace eval wavebar {
 variable Info
 
 if {![info exists Info(Initialized)]} {
  scrollbar .dummyscrollbar
  button .dummybutton

  set Info(Optio..."
(file "/usr/lib/wsurf1.8/wavebar.tcl" line 12)
invoked from within
"_source /usr/lib/wsurf1.8/wavebar.tcl"
("uplevel" body line 1)
invoked from within
"uplevel _source [list $file]"
(procedure "source" line 5)
invoked from within
"source /usr/lib/wsurf1.8/wavebar.tcl"
("package ifneeded" script)
invoked from within
"package require -exact wsurf $version"
(file "/usr/bin/wavesurfer" line 2600)
ales...@alessio-laptop:~$ 


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

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

Versions of packages wavesurfer depends on:
ii  libsnack2 2.2.10-dfsg1-9 Sound extension to Tcl/Tk and Pyth
ii  tk8.4 8.4.19-4   Tk toolkit for Tcl and X11, v8.4 -

wavesurfer recommends no packages.

wavesurfer 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#605668: refcard: info for grub needs updating (regarding grub2)

[David Prévot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 07/12/2010 19:36, Simon Paillard a écrit :
> Hi Holger,

Hi,

> On Thu, Dec 02, 2010 at 11:30:17AM +0100, Holger Wansing wrote:
>> Package: refcard
>>
>> The reference card contains information about grub:
>>
>> 
>> # type: Content of: 
>> #. type: Content of: 
>> #: entries.dbk:170
>> msgid "update-grub"
>> msgstr ""
>>
>> # type: Content of: 
>> #. type: Content of: 
>> 
>> #: entries.dbk:171
>> msgid "After changing /boot/grub/menu.lst."
>> msgstr ""
>> ---
>>
>> Since grub2 is now default since Squeeze, that info is no more actual.

[...]

>> Anyway, the name of the config file in grub2 is /boot/grub/grub.cfg.
> 
> True, will change that.

Actually, the file to edit before running update-grub is
/etc/default/grub (changes in /boot/grub/grub.cfg would be lost).

Regards

David

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

iQIcBAEBCAAGBQJM/tKaAAoJELgqIXr9/gnypLIP/i5oQNXWI/QlblgSkjirK+Bg
7OQzOsNgTSc1BhS1pAndidRHVyKY4b568+LgxTsm/9OWA714JexRvveAeDtJoTyY
YhmAlaBsTqzJvouAaVkwHixi3zWmyvxR2N/KEGFj+5Xj+K7B9Z2LTSLv7AKpf6ne
Z4NdKv+jGu8LkVmDfGuGhrNmFjgiXwYhahhPg5/Y0qIITpeFoqCOwheYYFU1mM08
FAYwhLoIS/cr+mN5Ar1QwV31Q31m9jQRrFTZ96FVWcnEyVBfLLVrPTlJWkZp8oxQ
QKy24Wev1mCPsj2B9RlKnrdYHj0mmGnL3F+y33IHGiloxg/Ti3qGVHhFdVdbwIfU
nr4y2Vh8CihA78Vnu76u1xLhA5pqHgYT8yNMGOHdwRz13wVS4FG4CwPNhSBmb1BU
YKxyxJ0gzIv2/nydnJIcsj7HOrC2oifdObKFiBo9/zmw3N9TN/cNe3u4CTXHhakE
FT0pOwY5BmVDLjblyrjqq9QRo3Qn66U0XO9EvVi9eYlKY8XK8Z3+JEql51qFm97D
qeqyiHodmvL87gsM8fr0cUxU3CesggWYNUPrTRm5OpHkzGuaHETT3qcJEqEsoTpA
VPTzgSD1Gacz4qhDjwRlW8jTkIG22RXqMbOuhH2s5IuIybknsq9VMgM9b2p4pT3C
YHvyI7qwTGkm7MFAJDj9
=561F
-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#606268: [Pkg-utopia-maintainers] Bug#606268: now ignores interfaces configured by d-i

[Joey Hess]

Michael Biebl wrote:
> First, installing over wireless is certainly not the norm

Amazon is currently selling $350 laptops on which Debian can be installed
over wireless (ath9k) without even needing non-free firmware.

> open wireless networks are not that common either.

That is highly location-dependant, and not true in large regions of eg,
the United States.

Here is one statistic from http://www.wigle.net/gps/gps/main/stats/
Networks with crypto: 14,688,344 (49.8%)
Networks without crypto: 7,988,171 (27.1%)

Also, it's not as if d-i is never going to support WPA.

> And second, allow-hotplug not working on your system is afaics due to a buggy
> driver.

That may be the case -- the driver on my laptop is iwlagn,
and on a laptop with ath9k, an event does seem to be generated on boot.

But even if that is the case, this still stands:

a. Would you really want laptops' wireless interfaces to be
   managed by ifupdown on a system with network-manager, by default?

b. squeeze is heavily frozen, and it is far, far to late in the release
   cycle to be making big changes to either d-i or network-manager.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#598626: chef: [INTL:vi] Vietnamese debconf templates translation

[Luca Capello]

block 598365 by 606274
thanks

Hi there!

On Thu, 30 Sep 2010 16:20:08 +0200, Clytie Siddall wrote:
> The initial Vietnamese translation for the debconf file: 

I am preparing an NMU to fix other chef bugs for squeeze (#606274,
#604231 and #605277), thus I will include your translation as well,
here the diff WRT #598365:

--8<---cut here---start->8---
diff -u chef-0.8.16/debian/changelog chef-0.8.16/debian/changelog
--- chef-0.8.16/debian/changelog
+++ chef-0.8.16/debian/changelog
@@ -10,8 +10,9 @@
   the chef binary package Depends: on Ruby-1.8 (Closes: #606274).
   * [Debconf translation updates]
 - Japanese (Hideki Yamane) (Closes: #598365).
+- Vietnamese (Clytie Siddall) (Closes: #598626).
 
- -- Luca Capello   Wed, 08 Dec 2010 01:04:49 +0100
+ -- Luca Capello   Wed, 08 Dec 2010 01:14:15 +0100
 
 chef (0.8.16-4.1) unstable; urgency=low
 
only in patch2:
unchanged:
--- chef-0.8.16.orig/debian/po/vi.po
+++ chef-0.8.16/debian/po/vi.po
@@ -0,0 +1,80 @@
+# Vietnamese translation for Chef.
+# Copyright © 2010 Free Software Foundation, Inc.
+# This file is distributed under the same license as the chef package.
+# Clytie Siddall , 2010.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: chef 0.8.16-5\n"
+"Report-Msgid-Bugs-To: c...@packages.debian.org\n"
+"POT-Creation-Date: 2010-06-24 06:01+0200\n"
+"PO-Revision-Date: 2010-09-30 23:43+0930\n"
+"Last-Translator: Clytie Siddall \n"
+"Language-Team: Vietnamese \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=1; plural=0;\n"
+"X-Generator: LocFactoryEditor 1.8\n"
+
+#: ../chef.templates:2001
+#. Type: string
+#. Description
+msgid "Chef server URL:"
+msgstr "URL máy chủ Chef:"
+
+#: ../chef.templates:2001
+#. Type: string
+#. Description
+msgid ""
+"Please specify the full URL that clients will use to connect to the Chef "
+"server (for instance \"http://chef.example.com:4000\";)."
+msgstr "Hãy ghi rõ địa chỉ URL đầy đủ mà ứng dụng khách sẽ sử dụng để kết nối 
đến trình phục vụ Chef (v.d. « http://chef.ví_dụ.com:4000 »)."
+
+#: ../chef-solr.templates:2001
+#. Type: password
+#. Description
+msgid "Password for the AMQP user \"chef\":"
+msgstr "Mật khẩu cho người dùng AMQP « chef »:"
+
+#: ../chef-solr.templates:2001
+#. Type: password
+#. Description
+msgid ""
+"Please choose a password for the default user (named \"chef\") in the AMQP "
+"server queue, under the default RabbitMQ vhost (also \"/chef\")."
+msgstr "Hãy chọn mật khẩu cho người dùng mặc định (tên « chef ») trong hàng 
đợi trình phục vụ AMQP, dưới máy chủ ảo (vhost) RabbitMQ mặc định (cũng là « 
chef »)."
+
+#: ../chef-solr.templates:2001
+#. Type: password
+#. Description
+msgid ""
+"RabbitMQ's rabbitmqctl program, which will be used to set this password, "
+"cannot read input from a file. Instead it will be passed as a command-line "
+"argument, so the password should not include any shell meta-characters that "
+"could cause errors, such as \"!\"."
+msgstr "Chương trình rabbitmqctl của RabbitMQ, mà được dùng để lập mật khẩu 
này, không có khả năng đọc đầu vào từ một tập tin nào đó. Thay vào đó, đầu vào 
sẽ được gửi qua dưới dạng một đối số dòng lệnh, vì thế mật khẩu không nên chứa 
siêu ký tự trình bào nào có thể gây ra lỗi (v.d. « ! »)."
+
+#: ../chef-server-webui.templates:2001
+#. Type: password
+#. Description
+msgid "Temporary password for the Chef server user \"admin\":"
+msgstr "Mật khẩu tạm thời cho người dùng trình phục vụ Chef « admin »:"
+
+#: ../chef-server-webui.templates:2001
+#. Type: password
+#. Description
+msgid ""
+"Please choose a temporary password for the first time the \"admin\" user "
+"logs into the Chef server web interface. It should be changed immediately "
+"after being used."
+msgstr "Hãy chọn một mật khẩu tạm thời cho lần đầu tiên người dùng « admin » 
(quản trị) đăng nhập vào giao diện Web của trình phục vụ Chef. Mật khẩu này nên 
được thay đổi ngay lập tức sau khi được dùng."
+
+#: ../chef-server-webui.templates:2001
+#. Type: password
+#. Description
+msgid ""
+"This password must be at least six characters long. If no password is "
+"entered, a default value will be used which is displayed on the Chef server "
+"web interface home page."
+msgstr "Mật khẩu này nên có chiều dài ít nhất 6 ký tự. Bỏ trống trường này thì 
dùng một giá trị mặc định, mà được hiển thị trên trang chủ của giao diện Web 
trình phục vụ Chef."
--8<---cut here---end--->8---

Thx, bye,
Gismo / Luca


pgpJJOTl99cHn.pgp
Description: PGP signature

Bug#606278: [buildd-tools-devel] Bug#606278: Bug#606278: aptitude resolver is completely broken in 0.60.6

[Roger Leigh]

On Tue, Dec 07, 2010 at 11:58:13PM +, Roger Leigh wrote:
> On Wed, Dec 08, 2010 at 01:38:26AM +0200, Modestas Vainius wrote:
> > aptitude resolver no longer works in 0.60.6. I suppose it has become pretty
> > important because it's the only which supports experimental properly. See
> > sample build log below.
> 
> > dpkg-deb: failed to open package info file 
> > `/tmp/resolver-nGygHK/sbuild-build-depends-core-dummy/DEBIAN/control' for 
> > reading: No such file or directory
> > Dummy package creation failed
> > Core source dependencies not satisfied; skippingNot cleaning session: 
> > cloned chroot in use
> > Keeping session: 
> > debian-experimental-amd64-sbuild-5b96bbf9-3747-4053-8607-bdb68178e9e7
> 
> This is odd.  It's working fine on my system, so I wonder what's
> different?
> 
> It's clearly failing when trying to create the dummy dependency
> package.  What is the content of /tmp/resolver-nGygHK ?

Just for reference, this (attached) is the result of

  sbuild -d unstable phonon-backend-vlc_0.2.0-1

on my system.  I know it's not the experimental version, but there's
something fundamental going wrong on your system.  Do you still get
the same failure with the unstable version?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


phonon-backend-vlc_0.2.0-1_amd64.build.bz2
Description: Binary data


signature.asc
Description: Digital signature

Bug#604231: chef-solr

[Luca Capello]

block 604231 by 606274
tags 604231 + patch
thanks

Hi there!

On Mon, 06 Dec 2010 19:04:38 +0100, Mehdi Dogguy wrote:
> On 06/12/2010 18:47, Luca Capello wrote:
>> Hi there!
>>
>
> (I should have CC'ed you too... I'm sorry for that).

Np.

>> On Sat, 04 Dec 2010 19:56:14 +0100, Mehdi Dogguy wrote:
>>>
>>> These can't be updated to the latest release because of the freeze.
>>> Are you fine with removing the chef-* binary packages from the source
>>> package and keep the same upstream version? or should I add a removal
>>> hint from Squeeze for src:chef?
>>
>> Already there:
>>
>> http://bugs.debian.org/605277
>>
>> Please note that if chef-solr is being removed from squeeze, the
>> reverse dependency that impeded solr removal goes away as well:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602697#10
>>
>
> Yeah, that's why we are here :)
>
>>
>> Mehdi, is it OK if I stop to care about this bug and leave it to you?
>>
>
> As you like, I don't know what to do here, except adding a removal hint
> for chef. If you'd like to prepare an NMU that would leave the client
> only, I'd accept it. Besides, not having any reply from the maintainers
> doesn't help to decide...

While preparing the NMU below I discovered that chef FTBFS, so I also
fixed that:

--8<---cut here---start->8---
diff -u chef-0.8.16/debian/changelog chef-0.8.16/debian/changelog
--- chef-0.8.16/debian/changelog
+++ chef-0.8.16/debian/changelog
@@ -1,3 +1,16 @@
+chef (0.8.16-4.2) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * debian/control:
+- remove outdated -server* packages and chef-solr as well, with
+  maintainer's approval (Closes: #604231).
+  * debian/patches/series: update.
+  * debian/patches/chef_client_ruby18.patch:
++ fix FTBFS, use a versioned shebang for client binaries, since
+  the chef binary package Depends: on Ruby-1.8 (Closes: #606274).
+
+ -- Luca Capello   Wed, 08 Dec 2010 00:31:34 +0100
+
 chef (0.8.16-4.1) unstable; urgency=low
 
   * Non-maintainer upload to fix pending l10n issues
diff -u chef-0.8.16/debian/control chef-0.8.16/debian/control
--- chef-0.8.16/debian/control
+++ chef-0.8.16/debian/control
@@ -24,96 +24,6 @@
  This package contains the chef-client and chef-solo binaries and associated
  files.
 
-Package: chef-solr
-Architecture: all
-Depends: ${misc:Depends}, ruby1.8, rabbitmq-server (>= 1.6), 
default-jre-headless | java6-runtime-headless, libjson-ruby1.8, libchef-ruby1.8 
(= ${source:Version}), solr-jetty (>=1.4.0), libxml-ruby1.8, adduser, ucf
-Suggests: chef (= ${source:Version})
-Replaces: chef-indexer
-Conflicts: chef-indexer
-Description: system integration framework - search indexes management
- Chef is a systems integration framework and configuration management library
- written in Ruby. Chef provides a Ruby library and API that can be used to
- bring the benefits of configuration management to an entire infrastructure.
- .
- Chef can be run as a client (chef-client) to a server, or as a standalone
- tool (chef-solo). Configuration recipes are written in a pure Ruby
- domain-specific language.
- .
- The chef indexer listens to a message queue via AMQP for changes to search
- indexes. It then either creates or deletes entries in the index according
- to the information it is passed.
- .
- This package provides the chef-solr search engine which runs as a solr-jetty
- server, and chef-solr-indexer that talks to the AMQP message queue, by
- default rabbitmq-server.
-
-Package: chef-server
-Architecture: all
-Depends: ${misc:Depends}, ruby, merb-slices, libmerb-assets-ruby, 
libmerb-haml-ruby, libmerb-helpers-ruby, chef-server-api (= ${source:Version}), 
chef-solr (= ${source:Version}), thin, libjson-ruby, libchef-ruby (= 
${source:Version}), libuuidtools-ruby1.8, adduser, libjs-jquery (>= 1.3.2), ucf
-Recommends: chef (= ${source:Version})
-Suggests: nginx, apache2, rake, chef-server-webui (=${source:Version})
-Description: system integration framework - centralized server
- Chef is a systems integration framework and configuration management library
- written in Ruby. Chef provides a Ruby library and API that can be used to
- bring the benefits of configuration management to an entire infrastructure.
- .
- Chef can be run as a client (chef-client) to a server, or as a standalone
- tool (chef-solo). Configuration recipes are written in a pure Ruby
- domain-specific language.
- .
- The Chef Server is a Merb application that provides centralized storage and
- distribution for recipes stored in "cookbooks," management and authentication
- of client nodes and node data, and search indexes for that data.
- .
- The chef-server package provides a merb binary wrapper that loads up the
- chef-server-api application.
- .
- This package contains the chef-server Merb application and associated files.
-
-Package: chef-server-api
-Architecture: all
-Depends: ${misc:Depends}, ruby, merb-slices, libmerb-assets-ruby, 
libmerb-haml-ruby, libmerb-h

Bug#598365: chef: [INTL:ja] please add Japanese po-debconf template translation (ja.po)

[Luca Capello]

block 598365 by 606274
thanks

Hi there!

On Tue, 28 Sep 2010 16:21:48 +0200, Hideki Yamane wrote:
>  Here's Japanese po-debconf template translation (ja.po) file that 
>  reviewed by several Japanese Debian developers and users.
>
>  Could you apply it, please?

I am preparing an NMU to fix other chef bugs for squeeze (#606274,
#604231 and #605277), thus I will include your translation as well,
here the diff WRT #604231:

--8<---cut here---start->8---
diff -u chef-0.8.16/debian/changelog chef-0.8.16/debian/changelog
--- chef-0.8.16/debian/changelog
+++ chef-0.8.16/debian/changelog
@@ -8,8 +8,10 @@
   * debian/patches/chef_client_ruby18.patch:
 + fix FTBFS, use a versioned shebang for client binaries, since
   the chef binary package Depends: on Ruby-1.8 (Closes: #606274).
+  * [Debconf translation updates]
+- Japanese (Hideki Yamane) (Closes: #598365).
 
- -- Luca Capello   Wed, 08 Dec 2010 00:31:34 +0100
+ -- Luca Capello   Wed, 08 Dec 2010 01:04:49 +0100
 
 chef (0.8.16-4.1) unstable; urgency=low
 
only in patch2:
unchanged:
--- chef-0.8.16.orig/debian/po/ja.po
+++ chef-0.8.16/debian/po/ja.po
@@ -0,0 +1,93 @@
+# chef Debian package debconf translation for Japanese
+# Copyright (C) Joshua Timberman 
+# This file is distributed under the same license as the chef package.
+# Hideki Yamane , 2010
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: chef 0.8.16-4.1\n"
+"Report-Msgid-Bugs-To: c...@packages.debian.org\n"
+"POT-Creation-Date: 2010-06-24 06:01+0200\n"
+"PO-Revision-Date: 2010-09-16 01:10+0900\n"
+"Last-Translator: Hideki Yamane \n"
+"Language-Team: Japanese \n"
+"Language: ja\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: string
+#. Description
+#: ../chef.templates:2001
+msgid "Chef server URL:"
+msgstr "Chef サーバの URL:"
+
+#. Type: string
+#. Description
+#: ../chef.templates:2001
+msgid ""
+"Please specify the full URL that clients will use to connect to the Chef "
+"server (for instance \"http://chef.example.com:4000\";)."
+msgstr ""
+"クライアントが Chef サーバに接続するのに使う完全な URL を指定してください。"
+"(例: http://chef.example.com:4000)"
+
+#. Type: password
+#. Description
+#: ../chef-solr.templates:2001
+msgid "Password for the AMQP user \"chef\":"
+msgstr "AMQP ユーザ「chef」のパスワード:"
+
+#. Type: password
+#. Description
+#: ../chef-solr.templates:2001
+msgid ""
+"Please choose a password for the default user (named \"chef\") in the AMQP "
+"server queue, under the default RabbitMQ vhost (also \"/chef\")."
+msgstr ""
+"デフォルトの RabbitMQ 仮想ホスト (「/chef」) 配下の AMQP サーバキューの"
+"デフォルトユーザ (こちらも「chef」という名) のパスワードを指定してください。"
+
+#. Type: password
+#. Description
+#: ../chef-solr.templates:2001
+msgid ""
+"RabbitMQ's rabbitmqctl program, which will be used to set this password, "
+"cannot read input from a file. Instead it will be passed as a command-line "
+"argument, so the password should not include any shell meta-characters that "
+"could cause errors, such as \"!\"."
+msgstr ""
+"このパスワードを設定するのに使われる RabbitMQ の rabbitmqctl プログラムは、"
+"ファイルから入力の読みとりができません。代わりにコマンドラインの引数として"
+"渡されますので、パスワードは「!」のようなシェルのメタキャラクタを含んでは"
+"いけません。"
+
+#. Type: password
+#. Description
+#: ../chef-server-webui.templates:2001
+msgid "Temporary password for the Chef server user \"admin\":"
+msgstr "Chef サーバのユーザ「admin」の仮パスワード:"
+
+#. Type: password
+#. Description
+#: ../chef-server-webui.templates:2001
+msgid ""
+"Please choose a temporary password for the first time the \"admin\" user "
+"logs into the Chef server web interface. It should be changed immediately "
+"after being used."
+msgstr ""
+"「admin」ユーザが Chef サーバのウェブインターフェイスへの初回ログイン時に使う"
+"一時パスワードを指定してください。これは利用後、すぐに変更する必要があります。"
+
+#. Type: password
+#. Description
+#: ../chef-server-webui.templates:2001
+msgid ""
+"This password must be at least six characters long. If no password is "
+"entered, a default value will be used which is displayed on the Chef server "
+"web interface home page."
+msgstr ""
+"このパスワードは長さが最低 6 文字必要です。パスワードが入力されなかった場合は"
+"、Chef サーバのウェブインターフェイスのホームページ上にデフォルト値が表示され"
+"ます。"
+
--8<---cut here---end--->8---

Thx, bye,
Gismo / Luca


pgpWbDhsKwW9g.pgp
Description: PGP signature

Bug#606280: busybox-syslogd: /etc/init.d/busybox-klogd spews garbage on stderr

[Stefan Monnier]

Package: busybox-syslogd
Severity: minor

The `running' shell function in this script (also used in
/etc/init.d/busybox-syslogd) suffers from a minor race-condition that
causes it to emit irrelevant messages on stderr: the /proc/[1-9]*/stat
glob is expanded first and then passed to `cut' which then has
to open those files, but some of them will have disappeared in
the mean time.
A simple fix is to redirect stderr to /dev/null.
Maybe a better fix is to juunk this `running' function and use one of
the standard thingies like start-stop-daemon instead.


Stefan


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

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



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

Bug#606250: System map of 2.6.32-5-amd64 does not match kernel

[Ben Hutchings]

On Tue, 2010-12-07 at 21:13 +0100, Jan Wielemaker wrote:
> Package: linux-image
> Version: 2.6.32-5-amd64
> 
> Hi,  Trying to debug ocfs2 issues, I noticed that the system.map file
> doesn't match the kernel in the latest Squeeze version.

Of course it does; it would be quite hard to mess that up.

> Here are my findings:
> 
> # dpkg -S /boot/System.map-2.6.32-5-amd64 
> linux-image-2.6.32-5-amd64: /boot/System.map-2.6.32-5-amd64
> # dpkg -S /boot/vmlinuz-2.6.32-5-amd64 
> linux-image-2.6.32-5-amd64: /boot/vmlinuz-2.6.32-5-amd64
> 
> So, both come from the same package.  The (2) machines have been
> rebooted after the last kernel upgrade.  But ps -o
> pid,wchan=WIDE-WCHAN-COLUMN only gives - or ? as wchan.  Telling
> it explicitly which map to use gives:
> 
> # PS_SYSTEM_MAP=/boot/System.map-2.6.32-5-amd64 ps -o
> pid,wchan=WIDE-WCHAN-COLUMN
> Warning: /boot/System.map-2.6.32-5-amd64 has an incorrect kernel
> version.
>   PID WIDE-WCHAN-COLUMN
> 18887 -
> 
> Looks like a trivial bug, but I cannot find a report that indicates
> it has been filed before.  Is there a way to fix this without
> recompiling the kernel from scratch myself?

This is a bug in procps.  It's relying on some version information which
is only present in System.map if the kernel was configured without
CONFIG_KALLSYMS set.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#606268: [Pkg-utopia-maintainers] Bug#606268: now ignores interfaces configured by d-i

[Michael Biebl]

On 08.12.2010 00:45, Joey Hess wrote:

>> Doing a fully automated conversion would probably not be that easy and I'm 
>> not
>> convinced it would be a good idea anyways.
>>
>> And we can't simply comment out entries like the above without risking to 
>> lose
>> network connection.
> 
> Unfortunatly I don't see much of a choice, unless you want to just
> change the default to managed=true. There are probably a great many
> systems out there that have already been installed and have this
> problem.

I honestly doubt that.
First, installing over wireless is certainly not the norm, especially as WEP is
deader than dead and open wireless networks are not that common either.

And second, allow-hotplug not working on your system is afaics due to a buggy
driver.

All in all this is a rather rare combination I'd say, altough I certainly admit
it is an issue for you.

Switching to managed=true has a much wider impact which I don't want to risk at
this stage of the release.

And simply commenting out wireless configurations generated by d-i is risky too:
On systems where allow-hotplug works and ifupdown is used to configure the
interface, commenting it out will kill the network configuration.

A compromise could be, to only comment out a wireless configuration found in
/e/n/i, if we find a  corresponding (I'd use essid is the same as criteria)
network-manager configuration.

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#596732: perlmagick: BlobToImage fails for SVG

[Nelson A. de Oliveira]

Hi Thomaz!

On Mon, Nov 22, 2010 at 8:08 PM, Thomas L Marshall  wrote:
> Please disregard my previous comments re differences between sid and
> squeeze.  I have completed a more controlled test and I have found that
> on both sid and squeeze libmagickcore3-extra is necessary for processing
> SVG -> png via perlmagick BlobToImage(). I have verified the original
> error without libmagickcore3-extra and I have also verified proper and
> compatible operation with libmagickcore3-extra installed.

Very good!

> I wonder if I should have been able to able to track this down or if
> there is a way to document this SVG prerequisite to make it easier to
> find the fix?

Users upgrading from older versions should be warned with the content
of /usr/share/doc/perlmagick/NEWS.Debian.gz

But indeed, people doing a new install of perlmagick only won't easily
find libmagickcore3-extra.
I need to see if it's better to cite libmagickcore3-extra in
perlmagick (and imagemagick) description or if it's better to include
a suggests or recommends for libmagickcore3-extra (also in perlmagick,
since imagemagick already recommends libmagickcore3-extra).
Installing only perlmagick without the imagemagick package was an
option that I hadn't thought.

> Also, libmagickcore3-extra carries with it a lot of additional stuff
> that maybe I don't need (libxinerama1, libxrandr2 seem to stand out)
> just to process SVG.  I wonder if it may be possible/better to move SVG
> back to libmagickcore3 but I understand that certain CVG fonts/effects
> do extend fairly deep down the rendering path.

Then we have another "problem" here :-)
Right now it's not possible to distribute both a imagemagick package
which depends on the graphical libs and also a version that has no
dependencies on them.

If you have the imagemagick package installed, you can see at
/usr/share/doc/imagemagick/TODO.Debian that it's in our TODO list a
solution for this.

About moving the SVG codec back to libmagickcore3, we will hit the
same issue again: some users will complain "Why do I need a SVG coder
if I don't use it?"
It's a problem in balancing features and dependencies that isn't
easily solved, unfortunately.

> Again, thanks for your attention to this issue.

You are welcome ;-)

Since this issue isn't really a bug, do you agree that we can close
this bug report?

Best regards,
Nelson



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

Bug#606278: [buildd-tools-devel] Bug#606278: aptitude resolver is completely broken in 0.60.6

[Roger Leigh]

On Wed, Dec 08, 2010 at 01:38:26AM +0200, Modestas Vainius wrote:
> aptitude resolver no longer works in 0.60.6. I suppose it has become pretty
> important because it's the only which supports experimental properly. See
> sample build log below.

> dpkg-deb: failed to open package info file 
> `/tmp/resolver-nGygHK/sbuild-build-depends-core-dummy/DEBIAN/control' for 
> reading: No such file or directory
> Dummy package creation failed
> Core source dependencies not satisfied; skippingNot cleaning session: cloned 
> chroot in use
> Keeping session: 
> debian-experimental-amd64-sbuild-5b96bbf9-3747-4053-8607-bdb68178e9e7

This is odd.  It's working fine on my system, so I wonder what's
different?

It's clearly failing when trying to create the dummy dependency
package.  What is the content of /tmp/resolver-nGygHK ?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Bug#606268: [Pkg-utopia-maintainers] Bug#606268: Bug#606268: now ignores interfaces configured by d-i

[Michael Biebl]

On 08.12.2010 00:51, Joey Hess wrote:
> Michael Biebl wrote:
>> The network being taken down on upgrades from prvious 0.8.x versions under
>> certain circumstances is an issue.
>> Afaics this won't affect fresh installs though or upgrades from lenny.
> 
> This is wrong for reasons I explained in
> <20101207234147.ga3...@gnu.kitenet.net>.

As you already noted, that is a different problem.
It's not about network-manager taken the interface down, it's because of
ifupdown not bringing the device up (most likely due to a buggy driver not
generating a uevent).

-- 
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#606268: [Pkg-utopia-maintainers] Bug#606268: Bug#606268: now ignores interfaces configured by d-i

[Joey Hess]

Michael Biebl wrote:
> The network being taken down on upgrades from prvious 0.8.x versions under
> certain circumstances is an issue.
> Afaics this won't affect fresh installs though or upgrades from lenny.

This is wrong for reasons I explained in
<20101207234147.ga3...@gnu.kitenet.net>.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#604563: debhelper: Please add support for build-arch, build-indep, install-arch and install-indep sequences

[Roger Leigh]

On Tue, Dec 07, 2010 at 04:07:11PM -0400, Joey Hess wrote:
> Roger Leigh wrote:
> > I think it's more likely to be triggered now
> 
> It will happen by default now with mixed indep/arch packages.
> 
> One way to fix it is by adding a non-arch-specific configure target,
> like this:
[…]

This would be a decent way to handle things.  I've attached a patch
as a suggestion for an alternative way to approach this which doesn't
treat the build-arch and build-indep sequences specially (it doesn't
add "-a" or "-i" to the debhelper options), leaving customisation up
to the user.  This means the behaviour is the same as existing
versions by default, but the option is there to tweak the rules if
so desired.  It doesn't handle the dh_auto_install case though.

> But, that's not the only thing to run twice. The entire set of debhelper
> commands in the install and binary sequences gets run twice, with -i and
> -a switches, where before they ran once with no switches. Which is
> unnecessarily slow.

It is running the commands twice where it previously only ran them
once, and I do agree there's additional overhead here.  However, the
key difference is that the build is driven via the policy required
rules targets.  The entire purpose of the patch is to ensure that
dh doesn't skip those targets (which it currently does).

  debian/rules binary

should be directly equivalent to

  debian/rules binary-arch binary-indep

but if "debian/rules binary" runs "dh binary", it currently runs the
"binary" sequence and skips the other debian/rules targets entirely.
The tradeoff is that you're adding some overhead, but you are gaining
proper support for the standard targets, and more importantly getting
consistent build results irrespective of how you invoke things.  From
this point of view you're gaining correctness, and IMO it's worth the
small loss of speed.

> Particularly concerning is that dh_auto_install gets run twice, and unlike
> (most) building, 2 calls to make install will do 2x the work. And running
> make install twice could conceivably lead to a FTBFS too.
> 
> So I reluctantly can't apply the sequence dependencies patch in its
> current state.

I'll have a further think about this.  I think this is 90% of the way
there, and if these details can be fixed, it will be a massive
improvement.

My gut feeling is that the dh_auto_* commands are by their very nature
not intended to work on arch-only or indep-only packages, so maybe
they should be ignoring the -a and -o options and always operating
on all packages (users who need the split will have to override them
in any case in order to get useful results).  Or maybe dh should drop
the -i/-a options when invoking them automatically.  I'll give it some
more thought.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.
From 2a848025a9d6f499389d2decc9fccffbdd33b4e5 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Tue, 7 Dec 2010 23:25:01 +
Subject: [PATCH] dh: Don't treat build-arch and build-indep sequences specially

Currently, the build-arch sequence adds "-a", and build-indep adds
"-i" to the debhelper options.  This makes sense for binary and
install targets.  However, build targets are different; we don't
run any debhelper packaging commands at this point in the build where
this would make sense.  If separating architecture dependent and
independent parts of the build, we will be writing custom overrides
and/or rules in debian/rules.  If not, then the default actions will
suffice.

This change makes the build-arch and build-indep sequences behave
identically.  As a result, their behaviour is only different when
specifically requested by the user.  This means the behaviour is
identical to previous dh releases by default.  "dh build" will
run both the build-arch and build-indep sequences, but the sequence
actions will only be run the first time through.
---
 dh |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/dh b/dh
index 9031747..24db303 100755
--- a/dh
+++ b/dh
@@ -621,8 +621,7 @@ my @packag...@{$dh{dopackages}};
 # Get the options to pass to commands in the sequence.
 # Filter out options intended only for this program.
 my @options;
-if ($sequence eq 'build-arch' ||
-$sequence eq 'install-arch' ||
+if ($sequence eq 'install-arch' ||
 $sequence eq 'binary-arch') {
 	push @options, "-a";
 	# as an optimisation, remove from the list any packages
@@ -630,8 +629,7 @@ if ($sequence eq 'build-arch' ||
 	my %arch_packages = map { $_ => 1 } getpackages("arch");
 	@packages = grep { $arch_packages{$_} } @packages;
 }
-elsif ($sequence eq 'build-indep' ||
-   $sequence eq 'install-indep' ||
+elsif ($sequence eq 'install-indep' ||
$sequence eq 'binary-indep') {
 	push @options, "-i";
 	# ditto optimisation for arch indep
-- 
1.7.2.

Bug#604085: menu: su-to-root should support graphical sudo options

[Andres Salomon]

On Thu, 2 Dec 2010 22:05:35 +0100
Bill Allombert  wrote:

> On Wed, Dec 01, 2010 at 03:17:42PM -0800, Andres Salomon wrote:
> > On Wed, 1 Dec 2010 22:40:53 +0100
> > Bill Allombert  wrote:
> > 
> > Honestly, I think this should allow for an arbitrary command.  If
> > I'm not using gksudo at all, it would be nice to be able to override
> > su-to-root.  If I am using gksudo, setting something globally
> > in /etc/su-to-rootrc from a script is much easier than messing
> > around w/ gconf settings.
> 
> Unfortunately the various su tools have incompatible command line
> interfaces (which is the main reason su-to-root exist instead of
> using update-alternatives). However, /etc/su-to-rootrc is sourced by
> su-to-root, so you can add whatever bash code you want to it,
> including gksu() { gksudo "$@"; }

Ah, neat, thanks!


> 
> > At the moment, I'm having problems w/ gksu and wondering why I can't
> > just set SU_TO_ROOT_X=sudo (using passwordless sudo).  As I

(*grumble*, #605633)


> > understand it, su-to-root doesn't enforce any security, it lets the
> > backend handle it.
> 
> You cannot set SU_TO_ROOT_X to sudo, because sudo is not an X program.
> Instead you can do
> SU_TO_ROOT_X=su-to-root
> SU_TO_ROOT_SU=sudo
>
> Which will call sudo in an X terminal.
> 
> Now, I have no objection to add gksudo/kdesudo to su-to-root, but it
> would be nice if d-i would configure su-to-root to use *sudo when the
> root-passwordless option is chosen. Currently only the gconf setting
> is set.

Keep in mind some of us aren't using d-i; instead, debootstrap + image
creation.  :)

I'm not sure what the best option here is..



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

Bug#606268: [Pkg-utopia-maintainers] Bug#606268: now ignores interfaces configured by d-i

[Joey Hess]

Michael Biebl wrote:
> > Could you please clarify what exactly happened? Was this only temporary
> > immediately after the upgrade? Is the problem reproducible after a upgrade?
> 
> Reproducible after a reboot, I meant.

Yes.

> Doing a fully automated conversion would probably not be that easy and I'm not
> convinced it would be a good idea anyways.
> 
> And we can't simply comment out entries like the above without risking to lose
> network connection.

Unfortunatly I don't see much of a choice, unless you want to just
change the default to managed=true. There are probably a great many
systems out there that have already been installed and have this
problem.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#417601: closed by Julien Viard de Galbert (Re: Bug#417601: x11r6: On startup, X11 reports that my G450 is not DRI capable.)

[Dale E. Edmons]

Ah!  That bug!  That's the reason I left Debian.  When the XFree86 
switch to Xorg, Debian switched something and my G450 went from the 
fasted screaming video card to one of the worse pigs.



Dale


Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the xserver-xorg-video-mga package:

#417601: x11r6: On startup, X11 reports that my G450 is not DRI capable.

It has been closed by Julien Viard de Galbert .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Julien Viard de Galbert 
 by
replying to this email.


  




Subject:
Re: Bug#417601: x11r6: On startup, X11 reports that my G450 is not DRI 
capable.

From:
Julien Viard de Galbert 
Date:
Tue, 7 Dec 2010 17:22:13 +0100
To:
417601-d...@bugs.debian.org

To:
417601-d...@bugs.debian.org


On Tue, Dec 07, 2010 at 08:13:22AM -0800, Dale E. Edmons wrote:
  

Julien,

Close it.  I switched to Source Mage, became a developer, lost my job,  
resigned as developer, etc

I've got two finals today
Thanks for asking.

Dale



Ok, closing then.

Thank you!

  




Subject:
x11r6: On startup, X11 reports that my G450 is not DRI capable.
From:
? 
Date:
Tue, 03 Apr 2007 09:14:47 -0700
To:
Debian Bug Tracking System 

To:
Debian Bug Tracking System 


Package: x11r6
Version: X11R6
Severity: important


When using the old XFree86 X11R6 my G450 was working
in Direct Rendering (~620 fps running glxgears).
Now, glxgears runs smoothly for about 2 seconds, then
starts ``stepping'' at about one cog per second.

glxgears no longer displays frame rate.  This is a
*very* useful tool for debugging whether GL is actually
operating correctly or not.  I would estimate my
value would be at 0.1 or less--in other words, slower
than my 333MHz laptop using Mesa Indirect rendering

Old XF86Config-4 file doesn't work for xorg.conf.
System doesn't appear to be capable of using dual-monitor
yet.  X11R6 is all but unusable!

Thank you.  (I'll be happy to send any info from this
Debian and the one I'm trying to replace.  My disks are
removable and I run two matching drives.  old/new)

Dale E. Edmons
www:w
ZZ 


-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

  


--
"Any society that would give up a little liberty to gain
a little security will deserve neither and lose both."
  Benjamin Franklin 





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

Bug#606268: [Pkg-utopia-maintainers] Bug#606268: Bug#606268: now ignores interfaces configured by d-i

[Michael Biebl]

On 08.12.2010 00:19, Joey Hess wrote:
> Michael Biebl wrote:
>> Upgrading from which version?
> 
> 0.8.1-4
> 
>> I also don't understand why you say that the network is taken down.
> 
> Because it was taken down, when the postinst stopped network-manager,
> and did not come back up when the postinst started network-manager
> (because network-manager had changed to not manage it).

This is a temporary issue. Not sure yet what to do about this.

>> Are you suggesting to create a keyfile connection based on the configuration
>> from /etc/network/interfaces?
> 
> I'm suggesting that network-manager needs to deal with standard
> interfaces files as generated by d-i, and that its current code to do
> that is buggy, and that this is a release critical bug.

The network being taken down on upgrades from prvious 0.8.x versions under
certain circumstances is an issue.
Afaics this won't affect fresh installs though or upgrades from lenny.

Other than that I don't see the current code as being buggy.

Care to elaborate?

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#606268: [Pkg-utopia-maintainers] Bug#606268: now ignores interfaces configured by d-i

[Joey Hess]

Michael Biebl wrote:
> If you install a new system using d-i and a /e/n/i configuration like your's 
> is
> created, the interface will be managed by ifupdown and not network-manager.

ifup does not bring up interfaces marked as allow-hotplug unless it
gets some kind of hotplug event. That does not happen on boot with 
my pci-e wifi card.

I think it's probably a d-i bug that it seems to mark such interfaces as
allow-hotplug. However:

a. Would you really want laptops' wireless interfaces to be
   managed by ifupdown on a system with network-manager, by default?

b. squeeze is heavily frozen, and it is far, far to late in the release
   cycle to be making big changes to either d-i or network-manager.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#605732: usr/share/images/desktop-base/spacefun-grub.png too visually complex for grub's scaler

[Valessio S Brito]

Sorry, but I'm not quite know how to solve it.

Maybe having a high-resolution image. Using a script with  
"imagemagick" to cut and resize the ideal format.




Citando Yves-Alexis Perez :


On ven., 2010-12-03 at 11:08 -0400, Joey Hess wrote:

> Until grub supports svg (not sure it's a great idea either though :),
> I'm not sure we can do anything about that. Shipping an alternative for
> each and every resolution isn't really doable, so there will be some
> resize anyway.

You can use images that do not contain fine detail (in highly
contrasting colors) that degrades badly when scaled. The moreblue theme
did not have this problem to any significant degree. Removing the fine
white lines from around the swirl and removing the small-font text would
eliminate the worst part of this problem.


I'm adding Valessio to CC: in case he missed the thread on
debian-desk...@.

Regards,
--
Yves-Alexis






--
://ValessioBrito.info

Comunicação e Tecnologia

mobile: +55 71 VALESSIO




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

Bug#605668: refcard: info for grub needs updating (regarding grub2)

[Simon Paillard]

Hi Holger,

On Thu, Dec 02, 2010 at 11:30:17AM +0100, Holger Wansing wrote:
> Package: refcard
> 
> The reference card contains information about grub:
> 
> 
> # type: Content of: 
> #. type: Content of: 
> #: entries.dbk:170
> msgid "update-grub"
> msgstr ""
> 
> # type: Content of: 
> #. type: Content of: 
> #: entries.dbk:171
> msgid "After changing /boot/grub/menu.lst."
> msgstr ""
> ---
> 
> Since grub2 is now default since Squeeze, that info is no more actual.
> Change according to the situation in grub2:

> does update-grub binary still exists? Or has the functionality been
> changed? I'm not sure here.

http://packages.debian.org/search?searchon=contents&keywords=update-grub
Still exists, it builds the /boot/grub/grub.cfg from /etc//grub.d/

> Anyway, the name of the config file in grub2 is /boot/grub/grub.cfg.

True, will change that.

> And additionally to that, there is also a configuration directory
> /etc/grub.d/

Don't know whether Wolfgang (refcard author) wants to bloat the refcard with
such detail. 

-- 
Simon Paillard



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

Bug#606279: seems to think everything is a hotpluggable interface

[Joey Hess]

Package: hw-detect
Version: 1.83
Severity: normal

It's typical for netcfg to put allow-hotplug in /etc/network/interfaces
for the interface d-i was installed on IME. I get the sense that 
hw-detect.hotplug is buggy somehow:

Dec  3 16:13:37 net/hw-detect.hotplug: Detected hotpluggable network interface 
lo
Dec  3 16:13:54 net/hw-detect.hotplug: Detected hotpluggable network interface 
lo
Dec  3 16:13:54 net/hw-detect.hotplug: Detected hotpluggable network interface 
wlan0
Dec  3 16:14:42 netcfg[4454]: INFO: Detected wlan0 as a hotpluggable device
Dec  4 01:15:22 net/hw-detect.hotplug: Detected hotpluggable network interface 
wlan0
Dec  4 01:15:22 net/hw-detect.hotplug: Detected hotpluggable network interface 
lo

This can result in ifup -a not upping it on boot, and a hotplug event
never bringing it up either.

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

Kernel: Linux 2.6.32-5-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/dash

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#606278: aptitude resolver is completely broken in 0.60.6

[Modestas Vainius]

Package: libsbuild-perl
Version: 0.60.6-1
Severity: important

Hello,

aptitude resolver no longer works in 0.60.6. I suppose it has become pretty
important because it's the only which supports experimental properly. See
sample build log below.

$ sbuild --apt-update -d experimental -s -A phonon-backend-vlc_0.3.1-1.dsc
sbuild (Debian sbuild) 0.60.6 (07 Dec 2010) on mdxdesktop.lan.vainius.eu

╔══╗
║ phonon-backend-vlc 0.3.1-1 (amd64) 08 Grd 2010 01:34 ║
╚══╝

Package: phonon-backend-vlc
Version: 0.3.1-1
Source Version: 0.3.1-1
Architecture: amd64
Ign file: experimental Release.gpg
Ign file:/repositories/debian/ experimental/main Translation-en
Get:1 file: experimental Release [2279 B]
Ign file: experimental/main amd64 Packages
Get:2 http://ftp.de.debian.org experimental Release.gpg [835 B]
Ign http://ftp.de.debian.org/debian/ experimental/main Translation-en
Get:3 http://ftp.de.debian.org experimental Release [102 kB]
Hit ftp://ftp.de.debian.org unstable Release.gpg
Get:4 ftp://ftp.de.debian.org/debian/ unstable/main Translation-en
Ign ftp://ftp.de.debian.org/debian/ unstable/main Translation-en
Get:5 http://ftp.de.debian.org experimental/main amd64 Packages [697 kB]
Hit ftp://ftp.de.debian.org unstable Release
Hit ftp://ftp.de.debian.org unstable/main Sources/DiffIndex
Hit ftp://ftp.de.debian.org unstable/main amd64 Packages/DiffIndex
Fetched 800 kB in 2s (342 kB/s)
Reading package lists...

┌──┐
│ Fetch source files   │
└──┘


Local sources
─

phonon-backend-vlc_0.3.1-1.dsc exists in .; copying to chroot

Check arch
──

dpkg-deb: failed to open package info file 
`/tmp/resolver-nGygHK/sbuild-build-depends-core-dummy/DEBIAN/control' for 
reading: No such file or directory
Dummy package creation failed
Core source dependencies not satisfied; skippingNot cleaning session: cloned 
chroot in use
Keeping session: 
debian-experimental-amd64-sbuild-5b96bbf9-3747-4053-8607-bdb68178e9e7

┌──┐
│ Summary  │
└──┘

Architecture: amd64
Build-Space: 0
Build-Time: 0
Distribution: experimental
Fail-Stage: fetch-src
Install-Time: 0
Job: phonon-backend-vlc_0.3.1-1.dsc
Package: phonon-backend-vlc
Package-Time: 0
Source-Version: 0.3.1-1
Space: 0
Status: given-back
Version: 0.3.1-1

Finished at 20101208-0134
Build needed 00:00:00, 0k disc space


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

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

Versions of packages libsbuild-perl depends on:
ii  adduser   3.112+nmu2 add and remove users and groups
ii  apt   0.8.10 Advanced front-end for dpkg
ii  apt-utils 0.8.10 APT utility programs
ii  dctrl-tools   2.14.5 Command-line tools to process Debi
ii  devscripts2.10.69scripts to make the life of a Debi
ii  dpkg-dev  1.15.8.6   Debian package development tools
ii  exim4 4.72-2 metapackage to ease Exim MTA (v4) 
ii  exim4-daemon-light [mail-tran 4.72-2 lightweight Exim MTA (v4) daemon
ii  libdpkg-perl  1.15.8.6   Dpkg perl modules
ii  libfilesys-df-perl0.92-3+b1  Module to obtain filesystem disk s
ii  perl  5.10.1-16  Larry Wall's Practical Extraction 
ii  perl-modules [libio-zlib-perl 5.10.1-16  Core Perl modules
ii  schroot   1.4.15-1   Execute commands in a chroot envir

libsbuild-perl recommends no packages.

libsbuild-perl 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#606277: Please add Recommends: latex-xcolor

[Michael Tautschnig]

Package: doxygen
Version: 1.7.2-1
Severity: minor

Please add latex-xcolor to Recommends: as doxygen strictly requires xcolor.sty
for all LaTeX output. Note that this is a new requirement of 1.7.2.

Best regards,
Michael



pgpwoDBrtvnD4.pgp
Description: PGP signature

Bug#606276: COMPACT_LATEX broken in 1.7.2

[Michael Tautschnig]

Package: doxygen
Version: 1.7.2-1
Severity: important
Justification: makes other software FTBFS

With doxygen 1.7.2-1, which is currently in experimental, ppl FTBFS even with
latex-xcolor being installed (see #606233), as seen in Ubuntu and confirmed over
here:

===
Package tocloft Note: The document has section divisions.

)

! LaTeX Error: \cftchapfont undefined.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...

l.20 \renewcommand{\cftchapfont}
{%
?
! Emergency stop.
 ...

l.20 \renewcommand{\cftchapfont}
{%
!  ==> Fatal error occurred, no output PDF file produced!
===

Looking at the debdiff between 1.7.1-2 and 1.7.2-1 shows that the font change
for LaTeX builds came with several \renewcommand's. One of those is 
\cftchapfont,
the chapter font. This command is defined in tocloft.sty for document classes
with *chapters*. Now, if COMPACT_LATEX is set, LaTeX article is used as document
class, which doesn't define chapters, hence the build breaks because
\cftchapfont cannot be *re*defined.

I believe that several of the new \renewcommand's need to be emitted
conditionally only, depending on whether COMPACT_LATEX is set or not.

Best regards,
Michael



pgpsYKzau2zlO.pgp
Description: PGP signature

Bug#606275: atheist: OutContains is not implemented

[Serafeim Zanikolas]

Package: atheist
Version: 0.20100717-1
Severity: normal

Hi,

OutContains is documented but not implemented.

$ dpkg -L atheist | xargs grep -l OutContains
/usr/share/doc/atheist/html/intro.html
/usr/share/doc/atheist/html/objects.inv
/usr/share/doc/atheist/html/genindex.html

Cheers,
Serafeim



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

Bug#606268: [Pkg-utopia-maintainers] Bug#606268: now ignores interfaces configured by d-i

[Joey Hess]

Michael Biebl wrote:
> Upgrading from which version?

0.8.1-4

> I also don't understand why you say that the network is taken down.

Because it was taken down, when the postinst stopped network-manager,
and did not come back up when the postinst started network-manager
(because network-manager had changed to not manage it).

> Are you suggesting to create a keyfile connection based on the configuration
> from /etc/network/interfaces?

I'm suggesting that network-manager needs to deal with standard
interfaces files as generated by d-i, and that its current code to do
that is buggy, and that this is a release critical bug.
 
-- 
see shy jo


signature.asc
Description: Digital signature

Bug#587272: warning from defoma: "It is recommended to run defoma-app purge gs"

[Till Kamppeter]

I have fixed the problem in the Ubuntu package (8.71.dfsg.2-0ubuntu8), 
simply following the warning, adding


defoma-app purge gs

to the ghostscript.preinst script after all other defoma clean-up. Now 
the installation of this ghostscript package eliminates the defoma 
warning for all future package installations.


debdiff attached.

   Till
diff -u ghostscript-8.71.dfsg.2/debian/changelog 
ghostscript-8.71.dfsg.2/debian/changelog
--- ghostscript-8.71.dfsg.2/debian/changelog
+++ ghostscript-8.71.dfsg.2/debian/changelog
@@ -1,3 +1,11 @@
+ghostscript (8.71.dfsg.2-0ubuntu8) natty; urgency=low
+
+  * debian/ghostscript.preinst: Clean up traces of Ghostscript in defoma
+via "defoma-app purge gs", so that when updating packages which still
+use defoma no warnings get issued (Closes: #587272).
+
+ -- Till Kamppeter   Tue,  7 Dec 2010 23:59:59 +0100
+
 ghostscript (8.71.dfsg.2-0ubuntu7) maverick; urgency=low
 
   * debian/control: Updated versioned dependency of ghostscript on gsfonts,
diff -u ghostscript-8.71.dfsg.2/debian/ghostscript.preinst 
ghostscript-8.71.dfsg.2/debian/ghostscript.preinst
--- ghostscript-8.71.dfsg.2/debian/ghostscript.preinst
+++ ghostscript-8.71.dfsg.2/debian/ghostscript.preinst
@@ -31,6 +31,12 @@
 rm -f /etc/defoma/ghostscript.subst-rule~
 rm -f /var/lib/defoma/ghostscript.subst-cache
 fi
+
+   # Purge old defoma stuff to avoid warnings from defoama when updating
+   # other packages which still use defoma
+if dpkg --compare-versions "$2" lt-nl "8.71.dfsg.2-0ubuntu8"; then
+   defoma-app purge gs 2>/dev/null || true
+   fi
 ;;
 
 abort-upgrade)

Bug#606274: chef: FTBFS: Patch remove_rubygems.patch does not remove cleanly (refresh it or enforce with -f)

[Luca Capello]

Package: chef
Version: 0.8.16-4.1
Severity: serious
Tags: patch

Hi there!

=
l...@gismo:~/$ gismo-pbuilder.sh --build base-sid chef_0.8.16-4.1.dsc
[...]
dpkg-deb: building package `libchef-ruby1.8' in 
`../libchef-ruby1.8_0.8.16-4.1_all.deb'.
 dpkg-genchanges  >../chef_0.8.16-4.1_amd64.changes
dpkg-genchanges: not including original source code in upload
 fakeroot debian/rules clean
test -x debian/rules
dh_testroot
dh_clean
/usr/bin/make -f debian/rules reverse-config
make[1]: Entering directory `/tmp/buildd/chef-0.8.16'
make[1]: Nothing to be done for `reverse-config'.
make[1]: Leaving directory `/tmp/buildd/chef-0.8.16'
if [ -d "." ]; then \
  cd . && QUILT_PATCHES=/tmp/buildd/chef-0.8.16/debian/patches quilt 
--quiltrc /dev/null pop -a -R || test $? = 2 ; \
fi
Removing patch jquery_unminified.patch
Removing chef-server-webui/public/javascripts/jquery.jeditable.js
Removing chef-server-webui/public/javascripts/yetii.js
Removing chef-server-webui/public/javascripts/jquery.tools.js

Patch remove_rubygems.patch does not remove cleanly (refresh it or enforce with 
-f)
make: *** [reverse-patches] Error 1
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
E: Failed autobuilding of package
=

When you do not build the package, the patch above seems to cleanly
apply and remove, so I guess the building process modifies some files.
And indeed if I compare the patched files above with the original ones,
the diff includes more than the quilt patch:

--8<---cut here---start->8---
--- chef-0.8.16/chef/bin/chef-client 2010-12-07 21:57:20.0 +0100
+++ chef-client 2010-12-07 22:17:57.0 +0100
@@ -1,4 +1,4 @@
-#!/usr/bin/env ruby
+#! /usr/bin/ruby1.8
 #
 # ./chef-client - Run the chef client
 #
@@ -18,7 +18,6 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.

-require 'rubygems'
 $:.unshift(File.join(File.dirname(__FILE__), "..", "lib"))
 require 'chef'
 require 'chef/application/client'
--8<---cut here---end--->8---

This applies to the four chef-client binaries: chef-client, chef-solo,
knife and shef.  The build log contains the following:
=
(cd chef && /usr/bin/ruby debian-setup.rb setup)
---> bin
updating shebang: chef-client
updating shebang: shef
updating shebang: knife
updating shebang: chef-solo
<--- bin
=

What is strange is that the current chef binary package available in sid
contains the four binaries above with exactly the same shebang as the
one that causes the error, which means that the build process should
have stopped even in the past...

Actually, the same problem should happen for the -server* binaries, but
it does not, given that the shebang in these binaries is specifically
modified to ruby1.8 because the -server* binaries do not support
Ruby-1.9 yet:

  [chef-0.8.16/debian/patches/chef_solr_ruby18.patch]
  # Description: Use ruby1.8 specifically as Chef Solr/Server doesn't support
  # ruby1.9 yet.

Nevertheless, I am not a Ruby nor a chef expert, but applying the same
trick patch to the client binaries solves the FTBFS.  I am confident
this is the correct fix also because the chef binary package (which
contains the client binaries) Depends: on Ruby-1.8:

  Depends: ${misc:Depends}, ruby1.8, liberubis-ruby1.8, libjson-ruby1.8,
   libextlib-ruby1.8 (>= 0.9.13), ohai (>= 0.4.0),
   libchef-ruby1.8 (= ${source:Version}), libopenssl-ruby1.8,
   libmixlib-authentication-ruby1.8 (>= 1.1.0), ucf

--8<---cut here---start->8---
diff -u chef-0.8.16/debian/changelog chef-0.8.16/debian/changelog
--- chef-0.8.16/debian/changelog
+++ chef-0.8.16/debian/changelog
@@ -1,3 +1,13 @@
+chef (0.8.16-4.2) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * debian/patches/series: update.
+  * debian/patches/chef_client_ruby18.patch:
++ fix FTBFS, use a versioned shebang for client binaries, since
+  the chef binary package Depends: on Ruby-1.8 (Closes: #NN).
+
+ -- Luca Capello   Tue, 07 Dec 2010 23:13:49 +0100
+
 chef (0.8.16-4.1) unstable; urgency=low
 
   * Non-maintainer upload to fix pending l10n issues
diff -u chef-0.8.16/debian/patches/series chef-0.8.16/debian/patches/series
--- chef-0.8.16/debian/patches/series
+++ chef-0.8.16/debian/patches/series
@@ -4,0 +5 @@
+chef_client_ruby18.patch
only in patch2:
unchanged:
--- chef-0.8.16.orig/debian/patches/chef_client_ruby18.patch
+++ chef-0.8.16/debian/patches/chef_client_ruby18.patch
@@ -0,0 +1,34 @@
+# Description: Use ruby1.8 specifically as Chef clients do not support
+# ruby1.9 yet (Closes: #NN).
+--- chef-0.8.16.orig/chef/bin/chef-client
 chef-0.8.16/chef/bin/chef-client
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env ruby
++#!/usr/bin/ruby1.8
+ #
+ # ./chef-client - Run the chef client
+ #
+--- chef-0.8.16.orig/chef/bin/chef-solo
 chef-0.8.16/chef/bin/chef-solo
+@@ -1,4 +1,4 @@
+-#!/usr/

Bug#604231: chef-solr

[Luca Capello]

Hi there!

On Sat, 04 Dec 2010 19:56:14 +0100, Mehdi Dogguy wrote:
> Joshua Timberman  wrote:
> > We (Opscode, upstream maintainers of Chef) are fine with removal
> > of the following chef packages from Debian Squeeze:

I would have preferred to be cc:ed by Joshua in his first reply, given
that I work on chef/solr bugs during the Bern BSP
 and I guess Joshua's
acknowledgement of removal is because of:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602697#35
  http://bugs.debian.org/605277

> > chef-server
> > chef-server-api
> > chef-server-webui
> > chef-solr
> > 
> > The client packages should remain, and should be updated to the
> > latest release (0.9.12):
> > 
> > chef
> > libchef-ruby
> > libchef-ruby1.8
> > 
> 
> These can't be updated to the latest release because of the freeze.
> Are you fine with removing the chef-* binary packages from the source
> package and keep the same upstream version? or should I add a removal
> hint from Squeeze for src:chef?

Already there:

  http://bugs.debian.org/605277

Please note that if chef-solr is being removed from squeeze, the
reverse dependency that impeded solr removal goes away as well:

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

> > I do have updated packaging in the Debian Ruby Extras team repository
> > for these packages.
> > 
> 
> Where can I find the packaging? (where is the repository?)

I guess

  http://wiki.opscode.com/display/chef/Package+Installation+on+Debian+and+Ubuntu

Mehdi, is it OK if I stop to care about this bug and leave it to you?

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#436466: dash: Please optimise single command given to -c to exec it

[Jilles Tjoelker]

Drake Wilson wrote:
> - Point out that full tail execution optimization is not as
>   localized as the "anything without shell meta-stuff" that some
>   people think it is, and that partial tail execution optimization
>   can lead to subtle problems if not done carefully.  Cf. a vaguely
>   similar case where I was attempting to use an XSI shell builtin
>   (which I was willing to rely on on the target system) as a single
>   command in a series of commands in a makefile, and GNU Make
>   decided that it didn't look enough like a shell thing and could be
>   "optimized" into an exec, which naturally hosed the command.  Of
>   course, the case of doing exec transformation _in_ the shell is
>   not as bad as that.

I think the gmake problem is caused by a non-compliance to POSIX in the
operating system, possibly combined with an overzealous skipping of the
shell by gmake. It is rather different from the fork/exec problem with
sh -c.

POSIX requires that all standard utilities except special builtins be
available via the exec functions and the utilities that can invoke
user-specified other utilities (env, find, nice, nohup, time, xargs).

In SUSv4, the special builtins are . (dot), : (colon), break, continue,
eval, exec, exit, export, readonly, return, set, shift, times, trap and
unset; none of these are under the XSI option. An implementation is not
required to provide them as external programs (and there seems no point
in doing so). Gmake must know about these and not try to exec them
itself.

Other builtins that do not exist as external programs yet need to be
provided. An easy way is to link a shell script like the below to
/usr/bin/alias, /usr/bin/bg, /usr/bin/cd, /usr/bin/command, etc.:

#!/bin/sh
command -p ${0##*/} "$@"

The 'command -p' serves to avoid looping when the PATH is set to a value
like /usr/bin:%builtin which is an undocumented way to prefer
/usr/bin/FOO to a builtin command FOO. The 'command' utility itself is
not subject to this because dash implements the POSIX requirement that
various (usually builtin) utilities such as 'command' cannot be
overridden via PATH (but unlike the special builtins can be overridden
with a function).

Regarding sh -c optimization, I am in favour of this. Uselessly waiting
'sh -c' processes annoy me. I made the change for FreeBSD 8.0 sh, which
is very similar to dash. The SVN changeset is r194128. The change
appears to work for dash as well.

-- 
Jilles Tjoelker



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

Bug#599903: (no subject)

[Rupert Swarbrick]

Hi,

I tried to write this below the reopen email, but it seems that was the
wrong thing to do. Hopefully, the following text will appear on the bug
report now:

I'm not sure this fixes the problem in all cases. I had a stale 
/etc/common-lisp/source-registry.conf.d/common-lisp-controller-userdir.conf
with the wrong contents.

Since this isn't the config file used since a commit in February (I
think, looking at the git log), this doesn't get wiped by the fixed
version. Then it still causes the error.

Hope this makes sense,

Rupert



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

Bug#558343: Pulseaudio bug

[Emilio Pozuelo Monfort]

reassign 558343 pulseaudio
forcemerge 558343 606271
fixed 558343 0.9.22-1
thanks

On 07/12/10 22:57, Oren Held wrote:

This bug originates in pulseaudio bug #606271

Reported and fixed in upstream (Pulseaudio 0.9.22):
http://pulseaudio.org/ticket/752


Thanks, reassigning and merging.

Cheers,
Emilio



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

Bug#557495: Force sub-directories for both

[Neil Williams]

On Tue, 7 Dec 2010 23:47:47 +0100
Andreas Tille  wrote:

> Hi Neil,
> 
> thanks for your effort in solving this.
> 
> On Tue, Dec 07, 2010 at 09:44:17PM +, Neil Williams wrote:
> > As no other solution has actually been uploaded, I propose that the
> > two packages involved should both be changed to use sub-directories
> > just like the one other library containing the relevant file. Hence,
> > splitting this bug report into two to allow two uploads.
> > 
> > It's fairly trivial to adapt relevant code to use a subdirectory,
> > with surrounding #ifdef where appropriate.
> > ...
> > I'll make the upload to delayed/2 tonight. (This bug has been
> > hanging around without a resolution for long enough.)
> 
> Probably you missed my remark when I deleted the pending tag [1].

No, I saw that. The two files *are* different, albeit still similar,
hence every reason to have *both* files in different locations. There
isn't necessarily a need for a common interface within the packages -
just as long as any code including these headers can uniquely identify
the *right* header consistently and reproducibly.

> While in principle no real harm is done by your solution it would have
> been IMHO perfectly correct to not fix the bug until both projects
> really issued a reasonable common header file which would be
> technically the best solution. 

Really? If the files are different but can be used in similar ways that
argues for separation, not integration IMHO.

> The fact that there is now a
> workaround seems to decrease the presure onto this clean solution.

I'm not at all sure why the solution has to be in one or other library
as if code including the header (none of which is in Debian currently)
cannot be trivially modified with an #ifdef or two.

>  I
> wonder whether you simply was hunting for open bugs or whether you
> really need one of those libraries.  If it would be libctapimkt I
> hope you did not missed my hint that there are other issues which
> bring the package into a state which makes it unfit for release.

It was just a hint, no detail, no proof or way for others to test.

This bug isn't enough to prevent either package being in Squeeze - if
there are other issues, please file appropriate bugs and give people a
chance to verify and possibly fix.

If you believe this to be the case, please file the appropriate RM bug
with the reasoning.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpPIZQ0argdl.pgp
Description: PGP signature

Bug#544112: Fixed?

[Paul Tagliamonte]

Hello, Ulrich,

Hummm, fantastic! I'm going to close the bug :)

Thanks so much for helping us make Fluxbox better :)

-Paul

On Tue, Dec 7, 2010 at 5:38 PM, Ulrich Eckhardt  wrote:
> Hi!
>
> I recently noticed that the problem seems to be gone.
>
> I then downloaded and installed fluxbox_1.1.1+dfsg2-1_powerpc.deb, restarted
> fluxbox, and the problem reappeared, so that version is affected.
>
> Installing fluxbox_1.1.1+git20100908.df2f51b-2_powerpc.deb again, the effect
> is gone again, so something in between must have fixed the issue. Note that I
> picked this package directly from the FTP server, APT doesn't seem to know
> about it.
>
> Cheers!
>
> Uli
>
>
>
>



-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq



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

Bug#606273: libsoup2.4-1: libsoup prefers IPv4

[Yves-Alexis Perez]

Package: libsoup2.4-1
Version: 2.30.2-1
Severity: important
Tags: ipv6

Hey,

it seems that libsoup prevents me from having correct IPv6 access. I
have a working IPv6 setup, but none of my browser will use it because
they are all webkit (and thus libsoup) based. A quick way to reproduce
is to go to www.kame.net with midori, epiphany or chromium. The famous
“dancing turtle” isn't dancing.

I've tried the test programs in libsoup sources and it indeed seems that
IPv4 is preferred:

cor...@hidalgo: getent hosts www.kame.net
2001:200:dff:fff1:216:3eff:feb1:44d7 orange.kame.net www.kame.net
cor...@hidalgo: ./dns www.kame.net
Name:www.kame.net
Address: 203.178.141.194

I think it's a fairly important issue, considering IPv6 is a release
goal and IPv4 is likely to fade away during Squeeze life time.

Regards,
-- 
Yves-Alexis


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

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

Versions of packages libsoup2.4-1 depends on:
ii  libc6   2.11.2-7 Embedded GNU C Library: Shared lib
ii  libgcrypt11 1.4.5-2  LGPL Crypto library - runtime libr
ii  libglib2.0-02.27.3-1 The GLib library of C routines
ii  libgnutls26 2.10.2-1 the GNU TLS library - runtime libr
ii  libxml2 2.7.8.dfsg-1 GNOME XML library
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

libsoup2.4-1 recommends no packages.

libsoup2.4-1 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#606272: FTBFS [hppa]: check_threads: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.

[dann frazier]

Source: toonloop
Version: 2.0.0-1
Severity: important
User: debian-h...@lists.debian.org
Usertags: hppa
X-Debbugs-CC: debian-h...@lists.debian.org

toonloop fails to build on hppa. Complete build logs are available here:
  https://buildd.debian.org/pkg.cgi?pkg=toonloop

>From the most recent build attempt:
[...]
make[3]: Entering directory 
`/build/buildd-toonloop_2.0.0-1-hppa-0fTU05/toonloop-2.0.0/tests'
PASS: check_looper
Clip created
Adding image 999
Writehead: 999
NUmber of frames: 1
Removing image
Writehead: 4213728080
NUmber of frames: 0
Clip destroyed
PASS: check_classes
main: startup
check_threads: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion 
`mutex->__data.__owner == 0' failed.
/bin/bash: line 5:  4589 Aborted ${dir}$tst
FAIL: check_threads
PASS: check_bool
creating directory
creating symlink
Success!
remove directory tree
PASS: check_symlinks
Item:0
Item:1
Item:2
PASS: check_containers
PASS: check_statesaving
PASS: check_signals
=
1 of 8 tests failed
Please report to supp...@toonloop.com
=
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory 
`/build/buildd-toonloop_2.0.0-1-hppa-0fTU05/toonloop-2.0.0/tests'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory 
`/build/buildd-toonloop_2.0.0-1-hppa-0fTU05/toonloop-2.0.0/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory 
`/build/buildd-toonloop_2.0.0-1-hppa-0fTU05/toonloop-2.0.0'
make: *** [debian/stamp-makefile-check] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2



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

Bug#606268: [Pkg-utopia-maintainers] Bug#606268: now ignores interfaces configured by d-i

[Michael Biebl]

On 07.12.2010 23:44, Michael Biebl wrote:

> Could you please clarify what exactly happened? Was this only temporary
> immediately after the upgrade? Is the problem reproducible after a upgrade?

Reproducible after a reboot, I meant.

>> One approach would be for for /usr/lib/NetworkManager/ifblacklist_migrate.sh
>> to convert stanzas containing any of these lines which d-i can include:
>>
>>  wireless-mode managed
>>  wireless-essid *
>>  wireless-key1 *
>>  hostname *
> 
> Are you suggesting to create a keyfile connection based on the configuration
> from /etc/network/interfaces?
> 
> Currently we don't do any conversion at all. We simply comment out any dhcp
> iface configuration without any additional option.

Doing a fully automated conversion would probably not be that easy and I'm not
convinced it would be a good idea anyways.

And we can't simply comment out entries like the above without risking to lose
network connection.

> If you install a new system using d-i and a /e/n/i configuration like your's 
> is
> created, the interface will be managed by ifupdown and not network-manager.
> 
> Or are you suggesting that NM still tries to take over the interface even if 
> is
> configured in /e/n/i?

Let me be more clear here: I fail to see the problem. Where do you think is
network-manager not behaving as expected?

Isn't this more a d-i problem, that it shouldn't write any /e/n/i configuration
at all if network-manager is being installed?

Trying to fix up such setups later in network-manager is brittle and we only do
it in the most common and simplest case.

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#604215: libpam-rsa: installation fails

[Julien Cristau]

On Tue, Dec  7, 2010 at 12:52:07 +0100, Julien Cristau wrote:

> + if ! [ -f "$pam_rsa_conf" ]; then
> + cat > "$pam_rsa_conf" << EOF
> +# Configuration file for libpam-rsa
> +# Please read pam_rsa (8) for further instructions
> +
> +EOF

I guess there's an argument for only doing this on initial install or
reconfigure, to allow the admin to remove the file entirely and not have
it restored at each upgrade.  Probably not a big deal either way,
though.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#572990: freeciv: FTBFS with binutils-gold

[Jacob Nevins]

The upstream fix for this bug has just been released in Freeciv 2.2.4.

(The conditions where this bug bites are:
1. Socket option IPV6_V6ONLY defaults to on (as in Linux with
   net.ipv6.bindv6only=1);
2. "localhost" resolves to 127.0.0.1 but not ::1.

This caused the server to accept IPv6 connections, and the client to
only attempt to connect to 127.0.0.1 as "localhost".)



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

Bug#564864: Pulseaudio bug

[Oren Held]

This bug originates in pulseaudio bug #606271

Reported and fixed in upstream (Pulseaudio 0.9.22):
http://pulseaudio.org/ticket/752

Bug#558343: Pulseaudio bug

[Oren Held]

This bug originates in pulseaudio bug #606271

Reported and fixed in upstream (Pulseaudio 0.9.22):
http://pulseaudio.org/ticket/752

Bug#604215: libpam-rsa: installation fails

[Agustin Martin]

2010/12/7 Julien Cristau :
> On Tue, Dec  7, 2010 at 12:12:29 +0100, Agustin Martin wrote:
>>
>> I have been playing about parsing config file and seed values in
>> config. It is a whitespace separated file with an unquoted string. I
>> want some validation, but my tests still do not deal with the unquoted
>> string, needs to refresh my awk here.
>>
> How about something like the following (untested)?

Hi, Julien,

Thanks again.  I was playing in parallel with something like

--- 8< ---
...
db_get libpam-rsa/no_configuration
if [ "$RET" = "false" ]
then
# If present, parse config file and feed debconf database with its values
pam_rsa_conf="/etc/security/pam_rsa.conf"
pam_rsa_keys="pubkey_dir privkey_dir privkey_name_hash pam_prompt
log_auth_result"
if [ -f $pam_rsa_conf ]; then
for keyname in $pam_rsa_keys; do
keyvalue=$(grep -e "^$keyname " $pam_rsa_conf | sed 's/^'$keyname' 
*//')
if [ -n "$keyvalue" ]; then
db_set "libpam-rsa/$keyname $keyvalue"
fi
done
fi
...
--- 8< ---

for the config file.

Need to look more carefully at the postinst code, could not do that
yet. I like the idea of using an intermediate file, that may even
allow to preserve sysadmin comments

This is requiring more time than initially expected, but I hope to
have a new NMU candidate this week.

Cheers,

-- 
Agustin



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

Bug#596527: gnome-help crash

[Emilio Pozuelo Monfort]

reassign 596527 yelp
tags 596527 unreproducible
thanks

On 02/12/10 15:42, ctineo wrote:

when execute gnome-help ghelp:///usr/share/gnome/help/network-admin/es/network-
admin.xml Or any app with help button many windows open and freeze computer.
this error:
(gnome-help:30720): Gtk-CRITICAL **: gtk_toolbar_insert: assertion
`GTK_IS_TOOL_ITEM (item)' failed

(gnome-help:30720): Gtk-CRITICAL **: gtk_tool_button_new: assertion
`icon_widget == NULL || GTK_IS_MISC (icon_widget)' failed

(gnome-help:30720): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(gnome-help:30720): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion
`G_TYPE_CHECK_INSTANCE (instance)' failed

(gnome-help:30720): Gtk-CRITICAL **: gtk_toolbar_insert: assertion
`GTK_IS_TOOL_ITEM (item)' failed


I get the same warnings but yelp shows up (just one window) and everything works 
normally.




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

Bug#554411: freeciv: FTBFS with binutils-gold

[Jacob Nevins]

In May, I wrote:
> A patch has been committed upstream which is intended to deal with this
> (as of r17431), [...]

For the avoidance of doubt: this patch went in between the 2.2.0 and
2.2.1 releases, so Debian now has it.



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

Bug#582767: lintian: if Package format 3.0 is in use report warning for quilt in Depebds:

[Niels Thykier]

tags 582767 + patch
thanks

Hi

I have created a patch that implements this check with a small test case for it.

~Niels
From 0bd1d202b0f46598eff33cd8d522161c1e5f37ff Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Tue, 7 Dec 2010 23:48:52 +0100
Subject: [PATCH] Added check for unneeded build-dep on quilt when building a 3.0 (quilt) package,
  including a test case for it.

---
 checks/patch-systems   |3 +++
 checks/patch-systems.desc  |8 
 .../debian/debian/README.source|1 +
 .../debian/debian/control.in   |   15 +++
 .../debian/debian/source/format|1 +
 t/tests/patch-systems-quilt-source/desc|7 +++
 t/tests/patch-systems-quilt-source/tags|1 +
 t/tests/patch-systems-quilt-source/upstream/README |1 +
 8 files changed, 37 insertions(+), 0 deletions(-)
 create mode 100644 t/tests/patch-systems-quilt-source/debian/debian/README.source
 create mode 100644 t/tests/patch-systems-quilt-source/debian/debian/control.in
 create mode 100644 t/tests/patch-systems-quilt-source/debian/debian/source/format
 create mode 100644 t/tests/patch-systems-quilt-source/desc
 create mode 100644 t/tests/patch-systems-quilt-source/tags
 create mode 100644 t/tests/patch-systems-quilt-source/upstream/README

diff --git a/checks/patch-systems b/checks/patch-systems
index 9934d46..73337e9 100644
--- a/checks/patch-systems
+++ b/checks/patch-systems
@@ -118,6 +118,9 @@ sub run {
 	#- quilt
 	if ($build_deps->implies("quilt") or $quilt_format) {
 		$uses_patch_system++;
+		if($quilt_format && $build_deps->implies("quilt")){
+		tag "unneeded-build-dep-on-quilt";
+		}
 		#check for a debian/patches file:
 		if (! -r "debfiles/patches/series") {
 			tag "quilt-build-dep-but-no-series-file" unless $quilt_format;
diff --git a/checks/patch-systems.desc b/checks/patch-systems.desc
index d77749b..f04a9bd 100644
--- a/checks/patch-systems.desc
+++ b/checks/patch-systems.desc
@@ -160,3 +160,11 @@ Info: This package build-depends on a patch system such as dpatch or
  referring to /usr/share/doc/quilt/README.source.  Similarly, you
  can refer to /usr/share/doc/dpatch/README.source.gz for dpatch.
 Ref: policy 4.14
+
+Tag: unneeded-build-dep-on-quilt
+Severity: normal
+Certainty: certain
+Info: This package build-depends on quilt, which is not required since
+ dpkg-source will apply patches at unpack time for 3.0 (quilt) source
+ packages.
+
diff --git a/t/tests/patch-systems-quilt-source/debian/debian/README.source b/t/tests/patch-systems-quilt-source/debian/debian/README.source
new file mode 100644
index 000..17250a4
--- /dev/null
+++ b/t/tests/patch-systems-quilt-source/debian/debian/README.source
@@ -0,0 +1 @@
+This package uses quilt.  See /usr/share/doc/quilt/README.source.
diff --git a/t/tests/patch-systems-quilt-source/debian/debian/control.in b/t/tests/patch-systems-quilt-source/debian/debian/control.in
new file mode 100644
index 000..5f56ffb
--- /dev/null
+++ b/t/tests/patch-systems-quilt-source/debian/debian/control.in
@@ -0,0 +1,15 @@
+Source: {$srcpkg}
+Priority: extra
+Section: devel
+Maintainer: {$author}
+Standards-Version: {$standards_version}
+Build-Depends: quilt, debhelper (>= 7)
+
+Package: {$srcpkg}
+Architecture: {$architecture}
+Depends: $\{shlib:Depends\}, $\{misc:Depends\}
+Description: {$description}
+ This is a test package designed to exercise some feature or tag of
+ Lintian.  It is part of the Lintian test suite and may do very odd
+ things.  It should not be installed like a regular package.  It may
+ be an empty package.
diff --git a/t/tests/patch-systems-quilt-source/debian/debian/source/format b/t/tests/patch-systems-quilt-source/debian/debian/source/format
new file mode 100644
index 000..163aaf8
--- /dev/null
+++ b/t/tests/patch-systems-quilt-source/debian/debian/source/format
@@ -0,0 +1 @@
+3.0 (quilt)
diff --git a/t/tests/patch-systems-quilt-source/desc b/t/tests/patch-systems-quilt-source/desc
new file mode 100644
index 000..d9f6dd1
--- /dev/null
+++ b/t/tests/patch-systems-quilt-source/desc
@@ -0,0 +1,7 @@
+Testname: patch-systems-quilt-source
+Sequence: 6000
+Type: non-native
+Version: 1.0-1
+Description: Test for quilt patches which do not have accompanying descriptions
+Test-For: unneeded-build-dep-on-quilt
+References: Debian Bug #582767
diff --git a/t/tests/patch-systems-quilt-source/tags b/t/tests/patch-systems-quilt-source/tags
new file mode 100644
index 000..856b0e2
--- /dev/null
+++ b/t/tests/patch-systems-quilt-source/tags
@@ -0,0 +1 @@
+W: patch-systems-quilt-source source: unneeded-build-dep-on-quilt
diff --git a/t/tests/patch-systems-quilt-source/upstream/README b/t/tests/patch-systems-quilt-source/upstream/README
new file mode 100644
index 000..e845566
--- /dev/null
+++ b/t/tests/patch-systems-quilt-source/upstream/README
@@ -0,0 +1 @@
+README
-- 
1.7.2.3

Bug#606271: When IPv6 is off, pulseaudio hangs for 5 secs on pa_context_connect

[Oren Held]

Package: pulseaudio
Version: 0.9.21-3+b1
Severity: important

This problem was reported several times as an application bug (#558343,
#564864), but it's in fact a Pulseaudio bug, which was already found &
fixed in upstream, 0.9.22:
- ticket: http://pulseaudio.org/ticket/752
- patch: http://pulseaudio.org/attachment/ticket/752/pulseaudio.patch

I believe that we should backport the patch to squeeze (patch looks
simple enough).

Additional reports from other projects:
- http://bugs.freedesktop.org/show_bug.cgi?id=25742
- https://bugzilla.mozilla.org/show_bug.cgi?id=533470
- https://bugzilla.redhat.com/show_bug.cgi?id=546956

Regards

Oren

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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.112+nmu2  add and remove users and groups
ii  consolekit   0.4.3-2 framework for defining and
trackin
ii  libasound2   1.0.23-2.1  shared library for ALSA
applicatio
ii  libc62.11.2-7Embedded GNU C Library:
Shared lib
ii  libcap2  1:2.19-3support for getting/setting
POSIX.
ii  libdbus-1-3  1.2.24-3simple interprocess
messaging syst
ii  libgdbm3 1.8.3-9 GNU dbm database routines
(runtime
ii  libice6  2:1.0.7-1   X11 Inter-Client Exchange
library
ii  libltdl7 2.2.6b-2A system independent dlopen
wrappe
ii  libpulse00.9.21-3+b1 PulseAudio client libraries
ii  libsamplerate0   0.1.7-3 Audio sample rate
conversion libra
ii  libsm6   2:1.2.0-1   X11 Session Management library
ii  libsndfile1  1.0.23-1Library for reading/writing
audio ii  libspeexdsp1 1.2~rc1-1   The Speex extended
runtime library
ii  libudev0 164-2   libudev shared library
ii  libx11-6 2:1.3.3-4   X11 client-side library
ii  libxtst6 2:1.2.0-1   X11 Testing -- Record
extension li
ii  lsb-base 3.2-26  Linux Standard Base 3.2
init scrip
ii  udev 164-2   /dev/ and hotplug
management daemo

Versions of packages pulseaudio recommends:
ii  gstreamer0.10-pulseaudio 0.10.24-1   GStreamer plugin for PulseAudio
ii  libasound2-plugins   1.0.23-1+b1 ALSA library additional plugins
ii  pulseaudio-esound-compat 0.9.21-3+b1 PulseAudio ESD
compatibility layer
ii  pulseaudio-module-x110.9.21-3+b1 X11 module for PulseAudio
sound se

Versions of packages pulseaudio suggests:
ii  paman0.9.4-1 PulseAudio Manager
ii  paprefs  0.9.9-2 PulseAudio Preferences
ii  pavucontrol  0.9.9-1 PulseAudio Volume Control
ii  pavumeter0.9.3-1 PulseAudio Volume Meter
ii  pulseaudio-utils 0.9.21-3+b1 Command line tools for the
PulseAu

-- 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#557495: Force sub-directories for both

[Andreas Tille]

Hi Neil,

thanks for your effort in solving this.

On Tue, Dec 07, 2010 at 09:44:17PM +, Neil Williams wrote:
> As no other solution has actually been uploaded, I propose that the two
> packages involved should both be changed to use sub-directories just
> like the one other library containing the relevant file. Hence,
> splitting this bug report into two to allow two uploads.
> 
> It's fairly trivial to adapt relevant code to use a subdirectory, with
> surrounding #ifdef where appropriate.
> ...
> I'll make the upload to delayed/2 tonight. (This bug has been hanging around 
> without a resolution for long enough.)

Probably you missed my remark when I deleted the pending tag [1].
While in principle no real harm is done by your solution it would have
been IMHO perfectly correct to not fix the bug until both projects
really issued a reasonable common header file which would be technically
the best solution.  The fact that there is now a workaround seems to
decrease the presure onto this clean solution.  I wonder whether you
simply was hunting for open bugs or whether you really need one of
those libraries.  If it would be libctapimkt I hope you did not missed
my hint that there are other issues which bring the package into a
state which makes it unfit for release.

Kind regards

  Andreas.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=81;bug=557495

-- 
http://fam-tille.de



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

Bug#606270: lintian: commit 894daa630bdf (most likely) caused test regressions

[Niels Thykier]

Package: lintian
Version: 2.4.4

test output:
...
Running test distribution-ubuntu-native 1.0... building... testing... FAILED:
--- t/tests/distribution-ubuntu-native/tags 2010-08-03
15:05:07.354069756 +0200
+++ debian/tests/tags.distribution-ubuntu-native2010-12-07
23:21:50.378531654 +0100
@@ -0,0 +1 @@
+E: distribution-ubuntu-native_1.0_i386 changes:
bad-distribution-in-changes-file jaunty
...
Running test nmu-ubuntu-native 1.0... building... testing... FAILED:
--- t/tests/nmu-ubuntu-native/tags  2010-08-03 15:05:07.775100644 +0200
+++ debian/tests/tags.nmu-ubuntu-native 2010-12-07 23:38:15.819550625 +0100
@@ -0,0 +1,3 @@
+E: nmu-ubuntu-native_1.0_i386 changes: bad-distribution-in-changes-file jaunty
+W: nmu-ubuntu-native source: changelog-should-mention-nmu
+W: nmu-ubuntu-native source: source-nmu-has-incorrect-version-number 1.0
...

I strongly suspect that this commit[1] broke these tests when the
commit did not update the tests to reflect current valid Ubuntu code
names.

~Niels

[1] 
http://git.debian.org/?p=lintian/lintian.git;a=commit;h=894daa630bdf88e59ff3683857d1d808be2d3c1b



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

Bug#606268: [Pkg-utopia-maintainers] Bug#606268: now ignores interfaces configured by d-i

[Michael Biebl]

On 07.12.2010 23:21, Joey Hess wrote:
> Package: network-manager
> Version: 0.8.1-6
> Severity: serious
> Tags: d-i
> 
> On upgrading to this version network manager stopped managing
> my wireless interface and my laptop's network was taken down.

Upgrading from which version?

> /etc/network/interfaces contains a standard stanza as setup by d-i
> for a wireless interface:
> 
> # The primary network interface
> allow-hotplug wlan0
> iface wlan0 inet dhcp
> # wireless-* options are implemented by the wireless-tools package
> wireless-mode managed
>   wireless-essid any
> 
> /etc/NetworkManager/NetworkManager.conf contained managed=false. Setting
> managed=true works around the problem.
> 
> Unfortunatly the /etc/network/interfaces munger introduced to fix
> #530024 was not a sufficient fix. It doesn't munge the above stanza at all
> when I run it by hand, due to the wireless-mode and wireless-essid lines.
> 
> So, bug #569215 has basically been all that has been keeping wireless
> and some other networks managed by network-manager on newly installed
> and upgraded systems, for the past 6+ months..

I think you will agree though that if you have a configuration like yours for
wlan0 in /etc/network/interfaces and managed=false, then network-manager should
not manage it? The previous behaviour was simply a bug.

I also don't understand why you say that the network is taken down.
If the device is being marked unmanaged, NM should not touch it at all and as
you configured the interface in /e/n/i it should be brought up by ifupdown
during boot.

Could you please clarify what exactly happened? Was this only temporary
immediately after the upgrade? Is the problem reproducible after a upgrade?

> 
> One approach would be for for /usr/lib/NetworkManager/ifblacklist_migrate.sh
> to convert stanzas containing any of these lines which d-i can include:
> 
>   wireless-mode managed
>   wireless-essid *
>   wireless-key1 *
>   hostname *

Are you suggesting to create a keyfile connection based on the configuration
from /etc/network/interfaces?

Currently we don't do any conversion at all. We simply comment out any dhcp
iface configuration without any additional option.

If you install a new system using d-i and a /e/n/i configuration like your's is
created, the interface will be managed by ifupdown and not network-manager.

Or are you suggesting that NM still tries to take over the interface even if is
configured in /e/n/i?

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#605292: [pkg-mono-group] Bug#605292: mono-gac: lenny to squeeze upgraded system problems with monobasic system installation

[Jochen]

Hello Mirco,
fast answer

(1) dpkg -i libmono0-dbg mono-runtime-dbg
#   FAILED so i do
(2) aptitude install libmono0-dbg mono-runtime-dbg
Die folgenden NEUEN Pakete werden zusätzlich installiert:
  libmono-corlib2.0-cil{a} libmono-i18n-west2.0-cil{a} 
libmono-posix2.0-cil{a} libmono-security2.0-cil{a} 
libmono-system2.0-cil{a} libmono0{a}

  mono-2.0-gac{a} mono-gac{a} mono-runtime{a}
Die folgenden teilweise installierten Pakete werden konfiguriert:
  libmono0-dbg mono-runtime-dbg
# installation works

calling: "gacutil -l"

** (/usr/lib/mono/2.0/gacutil.exe:9876): WARNING **: Thread (nil) may 
have been prematurely finalized


** (/usr/lib/mono/2.0/gacutil.exe:9876): WARNING **: Thread (nil) may 
have been prematurely finalized


** (/usr/lib/mono/2.0/gacutil.exe:9876): WARNING **: Thread (nil) may 
have been prematurely finalized


** (/usr/lib/mono/2.0/gacutil.exe:9876): WARNING **: Thread (nil) may 
have been prematurely finalized

Speicherzugriffsfehler

fails

Information about shm
mount | grep sh
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,size=512)

# after reading this i changed  /etc/default/tmpfs from "SHM_SIZE=512" 
to "SHM_SIZE=" (fresh default installtions does not have there any value)

# i have to wait for the next reboot tomorrow to see the changes

"ls -l /dev/shm" before the command "gacutil -l"
insgesamt 2
-r 1 jochen jochen 67108904  2. Dez 22:43 pulse-shm-1651979569
-r 1 jochen jochen 67108904  2. Dez 22:43 pulse-shm-2238754634


"ls -l /dev/shm/" after calling "gacutil -l"
insgesamt 4
-rw-r- 1 root   root   4096  7. Dez 23:29 mono.9897
-rw-r- 1 root   root  83976  7. Dez 23:29 
mono-shared-0-shared_data-camelot-Linux-x86_64-328-12-0

-r 1 jochen jochen 67108904  2. Dez 22:43 pulse-shm-1651979569
-r 1 jochen jochen 67108904  2. Dez 22:43 pulse-shm-2238754634

greatings and thx for help
i will test everything
jochen

ps i will look for you in the irc or via mail


Am 07.12.2010 23:11, schrieb Mirco Bauer:

reassign 605292 mono-runtime
retitle 605292 /usr/bin/mono segfaults in mono_shared_area
forcemerge 605292 589707
thanks

Hi,

in this report are 2 independent issues, one leads to the other.

The postinst maintainer script of mono-gac fails to configure because
/usr/bin/gacutil crashes in /usr/bin/mono which is the mono runtime,
thus I am reassigning and retitling.

This crash is a very serious issue as it basically prevents you from
running any tool or application that uses the mono runtime. At the same
time it will leave your package management system (apt/dpkg) in a very
bad state behind.

To get a better picture where exactly the issue pops up, please install
the debug symbols of mono by using:
apt-get install libmono0-dbg mono-runtime-dbg

If that fails to install, try it using dpkg -i

Then run "gacutil -l" which should segfault but hopefully this time with
source line information.

As the stacktrace looks like the issue is related to shared memory which
is kept in /dev/shm, please make sure it is correctly mounted and
possibly shows some files in that location.

I would really like to get this issue solved in time for squeeze, but I
am unable to reproduce it, so I need your help to track it down.

PS: If you are still able to reproduce this issue it would probably help
if you could join me on IRC in the #debian-cli channel found on the OFTC
network.

   





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

Bug#606269: mailman: Mailman should allow users to set the secure flag on cookies

[Daniel Kahn Gillmor]

Package: mailman
Severity: normal
Tags: patch

Mailman offers a web interface that relies heavily on cookies.

If the web interface is used via https, those cookies should have the
secure flag set.

Attached is a patch which allows system administrators to indicate
manually whether they would like the secure flag to be set or not.

Feel free to forward upstream, if that would be useful.

 --dkg

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.36-trunk-686 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -ru mailman-2.1.13.orig/Mailman/Defaults.py.in mailman-2.1.13/Mailman/Defaults.py.in
--- mailman-2.1.13.orig/Mailman/Defaults.py.in	2010-12-07 16:54:35.0 -0500
+++ mailman-2.1.13/Mailman/Defaults.py.in	2010-12-07 17:22:02.0 -0500
@@ -362,6 +362,9 @@
 # publically available?
 PUBLIC_MBOX = No
 
+# set the secure flag on all cookies?  Only enable this if your web
+# interface is always accessed via https.
+SECURE_COOKIES = No
 
 
 #
diff -ru mailman-2.1.13.orig/Mailman/SecurityManager.py mailman-2.1.13/Mailman/SecurityManager.py
--- mailman-2.1.13.orig/Mailman/SecurityManager.py	2009-12-22 13:00:43.0 -0500
+++ mailman-2.1.13/Mailman/SecurityManager.py	2010-12-07 17:24:59.0 -0500
@@ -250,6 +250,8 @@
 # We use session cookies, so don't set `expires' or `max-age' keys.
 # Set the RFC 2109 required header.
 c[key]['version'] = 1
+if mm_cfg.SECURE_COOKIES:
+c[key]['secure'] = 'yes'
 return c
 
 def ZapCookie(self, authcontext, user=None):

Bug#544112: Fixed?

[Ulrich Eckhardt]

Hi!

I recently noticed that the problem seems to be gone.

I then downloaded and installed fluxbox_1.1.1+dfsg2-1_powerpc.deb, restarted 
fluxbox, and the problem reappeared, so that version is affected.

Installing fluxbox_1.1.1+git20100908.df2f51b-2_powerpc.deb again, the effect 
is gone again, so something in between must have fixed the issue. Note that I 
picked this package directly from the FTP server, APT doesn't seem to know 
about it.

Cheers!

Uli



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

Bug#606260: Amendment to bug report

[Bob Kline]

I wrote that the installed documentation lists 
schoenf...@in-medias-res.com as the "administrator" of the package, 
where I meant to write "... as the maintainer "


--
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com




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

Bug#606258: unblock: distcc/3.1-3.2

[Adam D. Barratt]

On Tue, 2010-12-07 at 22:25 +0100, Moritz Muehlenhoff wrote:
> Please unblock package distcc. It fixes another of the yet CVE-less
> PYTHONPATH issues.

Looking at the diff, either the original code is more broken than the
general case, or it's intentionally adding an empty entry to PYTHONPATH.
It seems an odd choice, but part of me does wonder if it was
intentional.

-  "PYTHONPATH='$pythonpath::$PYTHONPATH' " \
+  "PYTHONPATH='$pythonpath${PYTHONPATH:+:$PYTHONPATH}' " \

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#605292: [pkg-mono-group] Bug#605292: mono-gac: lenny to squeeze upgraded system problems with monobasic system installation

[Mirco Bauer]

reassign 605292 mono-runtime
retitle 605292 /usr/bin/mono segfaults in mono_shared_area
forcemerge 605292 589707
thanks

Hi,

in this report are 2 independent issues, one leads to the other.

The postinst maintainer script of mono-gac fails to configure because
/usr/bin/gacutil crashes in /usr/bin/mono which is the mono runtime,
thus I am reassigning and retitling.

This crash is a very serious issue as it basically prevents you from
running any tool or application that uses the mono runtime. At the same
time it will leave your package management system (apt/dpkg) in a very
bad state behind.

To get a better picture where exactly the issue pops up, please install
the debug symbols of mono by using:
apt-get install libmono0-dbg mono-runtime-dbg

If that fails to install, try it using dpkg -i

Then run "gacutil -l" which should segfault but hopefully this time with
source line information.

As the stacktrace looks like the issue is related to shared memory which
is kept in /dev/shm, please make sure it is correctly mounted and
possibly shows some files in that location.

I would really like to get this issue solved in time for squeeze, but I
am unable to reproduce it, so I need your help to track it down.

PS: If you are still able to reproduce this issue it would probably help
if you could join me on IRC in the #debian-cli channel found on the OFTC
network.

-- 
Regards,

Mirco 'meebey' Bauer

PGP-Key ID: 0xEEF946C8

FOSS Developermee...@meebey.net  http://www.meebey.net/
PEAR Developermee...@php.net http://pear.php.net/
Debian Developer  mee...@debian.org  http://www.debian.org/



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

Bug#587668: Fwd: Bug#587668: The Debian open logo with "Debian" is not compliant to the Debian policy

[Ulrich Hansen]

On 07.12.2010 22:11, Arthur Machlas wrote:

Is there a problem with choosing a different font, and keeping the word Debian?


No there isn't. This solves the DFSG problem. It is done for instance 
in spacefun-splash.svg. I didn't keep the word Debian in 
spacefun-grub-widescreen.png as it has been already deleted in 
spacefun-grub.png and the splashy pictures and I thought the changes 
should be consistent.


In some other pictures I just used the swirl and didn't change the 
font of the word Debian. Because I think that Debian users are used to 
see the word Debian in the official Poppl Laudation Condensed font 
(for instance on debian.org). So using a different font might look 
unofficial and like a "fake" to them.


The swirl on the other hand is our official symbol and is well known 
to our users. So I think it could be a good idea to use the swirl more 
often and the word Debian less often in the artwork included in Debian.


Of course this could be changed, if everybody wants that.



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

Bug#606268: now ignores interfaces configured by d-i

[Joey Hess]

Package: network-manager
Version: 0.8.1-6
Severity: serious
Tags: d-i

On upgrading to this version network manager stopped managing
my wireless interface and my laptop's network was taken down.

/etc/network/interfaces contains a standard stanza as setup by d-i
for a wireless interface:

# The primary network interface
allow-hotplug wlan0
iface wlan0 inet dhcp
# wireless-* options are implemented by the wireless-tools package
wireless-mode managed
wireless-essid any

/etc/NetworkManager/NetworkManager.conf contained managed=false. Setting
managed=true works around the problem.

Unfortunatly the /etc/network/interfaces munger introduced to fix
#530024 was not a sufficient fix. It doesn't munge the above stanza at all
when I run it by hand, due to the wireless-mode and wireless-essid lines.

So, bug #569215 has basically been all that has been keeping wireless
and some other networks managed by network-manager on newly installed
and upgraded systems, for the past 6+ months..

One approach would be for for /usr/lib/NetworkManager/ifblacklist_migrate.sh
to convert stanzas containing any of these lines which d-i can include:

wireless-mode managed
wireless-essid *
wireless-key1 *
hostname *

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

Kernel: Linux 2.6.32-5-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/dash

Versions of packages network-manager depends on:
ii  adduser  3.112+nmu2  add and remove users and groups
ii  dbus 1.2.24-3simple interprocess messaging syst
ii  isc-dhcp-client  4.1.1-P1-15 ISC DHCP client
ii  libc62.11.2-7Embedded GNU C Library: Shared lib
ii  libdbus-1-3  1.2.24-3simple interprocess messaging syst
ii  libdbus-glib-1-2 0.88-2  simple interprocess messaging syst
ii  libgcrypt11  1.4.5-2 LGPL Crypto library - runtime libr
ii  libglib2.0-0 2.24.2-1The GLib library of C routines
ii  libgnutls26  2.8.6-1 the GNU TLS library - runtime libr
ii  libgudev-1.0-0   164-2   GObject-based wrapper library for 
ii  libnl1   1.1-6   library for dealing with netlink s
ii  libnm-glib2  0.8.1-6 network management framework (GLib
ii  libnm-util1  0.8.1-6 network management framework (shar
ii  libpolkit-gobject-1-00.96-4  PolicyKit Authorization API
ii  libuuid1 2.17.2-3.3  Universally Unique ID library
ii  lsb-base 3.2-26  Linux Standard Base 3.2 init scrip
ii  udev 164-2   /dev/ and hotplug management daemo
ii  wpasupplicant0.6.10-2.1  client support for WPA and WPA2 (I

Versions of packages network-manager recommends:
ii  dns 2.55-2+b1A small caching DNS proxy and DHCP
ii  ipt 1.4.10-1 administration tools for packet fi
ii  mod 0.4+git.20100624t180933.6e79d15-1+b1 D-Bus service for managing modems
ii  pol 0.96-4   framework for managing administrat
ii  ppp 2.4.5-4  Point-to-Point Protocol (PPP) - da

Versions of packages network-manager suggests:
ii  avahi-autoipd 0.6.27-3   Avahi IPv4LL network address confi

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

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#603292: [php-maint] Bug#603292: libapache2-mod-php5: PHP5 does not round correctly

[Bob Proulx]

Ondřej Surý wrote:
> thanks for comprehensive explanation. Would you be willing to put this
> information to f.e. http://wiki.debian.org/PHP/Rounding and link it
> from http://wiki.debian.org/PHP (or just in
> http://wiki.debian.org/PHP/Rounding), so it doesn't disappear when
> this bug is archived?

Done.  I captured this discussion here in:

  http://wiki.debian.org/PHP/Rounding

And linked it to the main http://wiki.debian.org/PHP page.

Bob



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

Bug#606267: manual page lists --mapfile, real option is --map-file

[Jim Paris]

Package: tftpd-hpa
Version: 5.0-18
Severity: minor

The manpage lists "-m" as "--mapfile", but it's really "--map-file" in
the source.

-jim

-- System Information:
Debian Release: 5.0.6
  APT prefers testing
  APT policy: (200, 'testing'), (150, 'stable'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages tftpd-hpa depends on:
ii  adduser   3.110  add and remove users and groups
ii  debconf [debconf-2.0] 1.5.35 Debian configuration management sy
ii  libc6 2.11.2-2   Embedded GNU C Library: Shared lib
ii  libwrap0  7.6.q-16   Wietse Venema's TCP wrappers libra

tftpd-hpa recommends no packages.

Versions of packages tftpd-hpa suggests:
ii  syslinux-common2:4.02+dfsg-3 collection of boot loaders (common

-- debconf information:
* tftpd-hpa/address: 0.0.0.0:69
* tftpd-hpa/directory: /srv/tftp
* tftpd-hpa/username: tftp
* tftpd-hpa/options: --secure -m /etc/tftp.map
* tftpd-hpa/use_inetd: true



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

Bug#606071: refcard: [INTL:sk] Slovak po-debconf translation

[helix84]

On Tue, Dec 7, 2010 at 22:43, Simon Paillard  wrote:
> Indeed, however, I don't know how we could make it appear in the po file..

So I tried what works with programming languages - putting a comment
before the string. Tried both DocBook's  and XML's
. Neither worked. It's probably not implemented for DocBook if
I'm reading this right:
/usr/share/perl5/Locale/Po4a/Docbook.pm

Regards,
~~helix84



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

Bug#599556: procps: sysctl is using deprecated sysctl(syscall) net.ipv6.neigh.default.retrans_time

[Craig Small]

On Tue, Nov 30, 2010 at 10:43:13AM +0100, Hilmar Preusse wrote:
> On 08.10.10 Alexandre Cavalcante Alencar (alexandre.alen...@gmail.com) wrote:
> I do see that same problem when calling "sysctl -p /etc/sysctl.conf"
> on the command line.  The message appears in /var/log/messages.  Here
> is my sysctl.conf:
sysctl -a will cause this to happen as it lists all options, including
ones that should not be used. I'm not exactly sure how its supposed to
know it's an old key.

Are you certain you are getting the message with 
 sysctl -p /etc/sysctl.conf?

stracing the command I see it doesn't go near those sysctl keys.

 - Craig
-- 
Craig Small VK2XLZhttp://www.enc.com.au/   csmall at : enc.com.au
Debian GNU/Linux  http://www.debian.org/   csmall at : debian.org
GPG fingerprint:   1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5



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

Bug#606266: ditaa: Please use virtual Packages as Dependencies

[Michael Gebetsroither]

Package: ditaa
Version: 0.9+ds1-2
Severity: normal

Hi,

Please change the hard-dependency on openjdk-6-jdk to a
dependency to the provided virtual packages of openjdk-6-jdk.

Package: openjdk-6-jdk
Provides: java-compiler, java-sdk, java2-sdk, java5-sdk, java6-sdk

michael

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

Kernel: Linux 2.6.36-trunk-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



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

Bug#605909: linux-image-2.6.32-5-amd64: Kernel freeze when running on Lenovo x100e laptop (trace included)

[Anton Martchukov]

On Sat, Dec 04, 2010 at 05:21:30PM +, Ben Hutchings wrote:
> I am inclined to suspect the fglrx driver.  Please try to reproduce this
> without that driver loaded.

Good news. This problem does not exists in kernel 2.6.36 from the
debian package linux-image-2.6.36-trunk-amd64 in experimental.

Tried with both open source radeon driver and fglrx (package
version 1:10-11-1 from experimental either).

I also noted that thinkpad_acpi module in 2.6.36 kernel does
have acpi support for Lenovo x100e laptop and this may be
the reason why it is working there.

-- 
Anton Martchukov   http://www.martchukov.com
0xFC4FBF28  96BC 3DAB 231A 7FCC 4F49  D783 9A69 65C1 FC4F BF28


signature.asc
Description: Digital signature

Bug#570223: This problem is reproducible on Debian live (Squeeze) daily build 20101206

[Anton Zinoviev]

On Mon, Dec 06, 2010 at 09:18:19PM +0800, Steven Shiau wrote:
> 
> How to reproduce:
> 1. Download 
> http://live.debian.net/cdimage/daily-builds/squeeze/20101206-1/i386/iso-hybrid/debian-live-squeeze-i386-standard.iso
> 2. Boot it
> ...

I can confirm this.  In order to convert the 8-bit keymaps to unicode 
the scripts of console-data do some some "magic" with dumpkeys that I 
don't fully understand.  I don't know whether the bug belongs to the 
package owning dumpkeys (kbd or console-tools) or to the kernel.

On my machine I can reproduce the bug of dumpkeys in the following way:

# dumpkeys | grep 
compose '`' 'A' to U+ffc0
compose '`' 'a' to U+ffe0
...
... more lines of this form

Here the kernel and/or dumpkeys generate 32-bit unicode numbers that are 
not supported by loadkeys.  I don't known whether this behaviour of 
dumpkeys+kernel is on purpose or it is a bug.

Anton Zinoviev




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