headers
Dmitrijs Ledkovs | 1 Feb 2010 01:02
Picon
Gravatar

Bug#567746: dh_xulrunner missed dependency in xiphos

reassign 567746 xulrunner-dev 1.9.1.6-1
retitle 567746 "dh_xulrunner missed dependency in xiphos"
thanks

 <at> David Thompson I believe it's a bug in dh_xulrunner cause it was
suppose to generate dependencies. aptitude did everything right.

Here we go. dh_xulrunner did not detect xulrunner dependency in xiphos
as you can see from all the current xiphos build-logs / binaries in
testing/unstable.

Rebuilding locally also shows that xulrunner dependency is not added
to the substitute vars.

I couldn't quite understand how dh_xulrunner works, but I can
successfully grep xiphos binary for all the terms dh_xulrunner is
looking for. So I'm puzzled as to why it didn't add the dependency.

Is something wrong with the way i use dh_xulrunner? Or did I hit a
corner-case of dh_xulrunner?

Shall I make another upload of xiphos and explicitly add
"xulrunner-1.9.1" to depends? (I thought we were suppose to avoid that
with dh_xulrunner)

With best regards,

Dmitrijs Ledkovs.

On 31 January 2010 16:08, david thompson <thompdump <at> gmail.com> wrote:
(Continue reading)

Permalink | Reply | 7 comments |
headers
Arnaud Fontaine | 1 Feb 2010 01:00
Picon
Favicon

Bug#567696: emms: diff for NMU version 3.0-5.1

Hi,

I have already  prepared a package with a patch for  #567696 too. I will
upload it tomorrow. Hope that's ok.

Regards,
Arnaud Fontaine
Permalink | Reply | 0 comments |
headers
martin f krafft | 1 Feb 2010 01:05
Picon
Favicon

Bug#562031: unbound: Add support resolvconf for

retitle 562031 tell resolvconf about unbound on localhost
thanks

also sprach Ondřej Surý <ondrej <at> sury.org> [2010.01.07.0534 +1300]:
> add '[ "X$RESOLVCONF" != "Xno" ] &&' here and set RESOLVCONF=yes
> (or no) to /etc/default/unbound
> 
> I think, you don't have to cover all the cases, just the most
> simple one.

I don't think this proposal is a good idea at all. First, unbound
may not be running on 127.0.0.1/::1, and second, what you propose is
a trivial change that the admin can make in /etc/network/interfaces.
I don't think the package should do that, since it's
a policy decision.

I suggest instead to add a note to the README that unbound can be
top-inserted as a resolver by adding

  iface lo inet loopback
    …
    dns-nameservers ::1

to the lo stanza in /etc/network/interfaces and bringing down/up lo.
Alternatively, after adding it, you can

  echo nameserver ::1 > /etc/resolvconf/run/interface/lo.inet
  resolvconf -u

to avoid having to bring the iface down.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexander Holmes | 1 Feb 2010 01:07

Bug#567618: Unable to boot after upgrade.

I was also unable to boot and used a similar method to Geoff to fix the
problem, i.e. upon booting I received

GRUB loading.
Welcome to GRUB!

error: the symbol 'grub_env_find' not found.
Entering rescue mode...
grub rescue>

however then was able to fix the problem by chrooting into my system
from a live cd and then apt-get remove ing the grub-pc package, then
installing it again, rather than using the squeeze package.

--
Alex Holmes
Permalink | Reply | 0 comments |
headers
Michael Gibbs | 1 Feb 2010 01:22
Picon

Bug#567890: fluxbox: Setting keymap in startup script does not work

Package: fluxbox
Version: 1.1.1-6
Severity: normal

I have the line 'xmodmap /home/michael/.xmodmaprc' in the appropriate part of 
my ~/.fluxbox/startup but when I start fluxbox, my keymap is not altered as per
 that file.

When I run 'xmodmap /home/michael/.xmodmaprc' after fluxbox has already started
 up, my keymap changes appropriately.

This behaviour has only started recently, either with a fluxbox update or a 
xorg update.

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

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

Versions of packages fluxbox depends on:
ii  libc6                   2.10.2-2         GNU C Library: Shared libraries
ii  libfontconfig1          2.8.0-2          generic font configuration library
ii  libfreetype6            2.3.11-1         FreeType 2 font engine, shared lib
ii  libgcc1                 1:4.4.2-9        GCC support library
ii  libice6                 2:1.0.6-1        X11 Inter-Client Exchange library
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wade Richards | 1 Feb 2010 01:25

Bug#372207: Agree that the FHS violation is serious

I also keep a read-only root (including /etc) partition, to minimize the 
chances of accidental file corruption.  I also want to use LVM snapshots 
for my backups, to ensure that they are internally consistent.  Both of 
these seem like reasonable and sensible things.

However, in order to create the snapshots I'm going to use in my 
backup,  I need to re-mount my root partition as writable.  It doesn't 
seem reasonable to me that I need to write to my root partition merely 
to back it up.

I'm not an expert on LVM, but shouldn't tools like pvscan, vgscan, 
vgdisplay, lvscan, lvdisplay, etc. be enough to regain access to your 
/var directory if it is lost?  The metadata is also stored directly in 
the disk structures, is it not?   It will probably be slow, but if I'm 
recovering from a disaster, I don't mind waiting for a while.
Permalink | Reply | 1 comment |
headers
Américo Monteiro | 1 Feb 2010 01:31
X-Face
Picon

Bug#567891: guarddog: [INTL:pt] Updated Portuguese translation for package messages

Package: guarddog
Version: 2.6.0-2.1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for guarddog messages.
Translator: Américo Monteiro <a_monteiro at netcabo.pt>
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team <traduz at debianpt.org>.

--

-- 
Best regards,
Américo Monteiro
Attachment (pt.po): text/x-gettext-translation, 28 KiB
Permalink | Reply | 0 comments |
headers
Norman Rasmussen | 1 Feb 2010 01:38
Favicon

Bug#567892: randomsound: should be able to specify command line (parameters to pass) to arecord

Package: randomsound
Version: 0.2-5
Severity: normal

The hardcoded options that randomsound passes to arecord are a complete failure on my server (default
sound device doesn't support recording in mono).  It should be possible to pass the complete command line
to exec arecord with to randomsound.

What about adding a -r or -R param that specifies the complete command line to exec to get random data?

eg:
randomsound -r 'arecord -c 2 -f S16_LE -r 48000 -t raw -D hw:2'

-- System Information:
Debian Release: squeeze/sid
  APT prefers stable
  APT policy: (750, 'stable'), (700, 'testing'), (600, 'unstable'), (550, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core)
Locale: LANG=en_ZA, LC_CTYPE=en_ZA (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages randomsound depends on:
ii  alsa-utils                    1.0.21-1   ALSA utilities
ii  libc6                         2.10.2-2   GNU C Library: Shared libraries

randomsound recommends no packages.

randomsound suggests no packages.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Edmonds | 1 Feb 2010 01:38
Picon
Favicon

Bug#567879: Please add resolvconf integration

martin f krafft wrote:
> also sprach Robert Edmonds <edmonds <at> debian.org> [2010.02.01.1207 +1300]:
> > can you please explain exactly what this does and how it relates to
> > #562031?
> 
> My script supplements #562031, which talks only about how to teach
> the system to ask localhost (or whereever unbound listens). The way
> I do this is by adding
> 
>   dns-nameservers ::1
> 
> to the 'lo' stanza in /etc/network/interfaces.
> 
> My script then simply makes sure that unbound knows what the DNS IPs
> obtained by e.g. DHCP are, so that it can forward queries
> recursively, rather than iteratively resolving them.

hm, i see.

> > > ++# Resolvconf integration ++# If you have the resolvconf
> > > package installed, you can uncomment the ++# following to let
> > > unbound forward queries to the DNS resolvers discovered by ++#
> > > resolvconf (e.g. from DHCP or static entries in
> > > /etc/network/interfaces). ++# include:
> > > "/var/cache/unbound/resolvconf_resolvers.conf"
> > 
> > i'm confused.  unbound is already a full service resolver.
> > doesn't this configure unbound to just act like a stub resolver by
> > forwarding all its queries to another full service resolver?  why
> > not just set that resolver address in /etc/resolv.conf?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bill Brelsford | 1 Feb 2010 01:25

Bug#565236: mutt: "reply-hook . set realname=foo" is executed too late

On Sun Jan 31 2010 at 06:25 PM +0000, Antonio Radici wrote:
> tag 565236 +unreproducible moreinfo
> notfound 565236 1.5.20-6
> thanks
> 
> On Wed, Jan 13, 2010 at 05:36:42PM -0800, Bill Brelsford wrote:
> > Package: mutt
> > Version: 1.5.20-5
> > Severity: normal
> > 
> > After the commands
> > 
> > 	set realname=bar
> > 	reply-hook . set realname=foo
> > 
> > replying to a message generates a From: line with name "bar" rather
> > than "foo".  The From: address is apparently set before the
> > reply-hook is executed.  ($realname is then correctly left as "foo".)
> 
> Hi,
> I cannot reproduce this with mutt 1.5.20-6, this is what I did:
> 
> shell$ cat .muttrc-realname
> set realname=bar
> reply-hook . set realname=foo
> 
> shell$ mutt -F .muttrc-realname
> 
> then I reply to a message and the realname is correctly set to "foo".
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane