date:20120112

Bug#655031: alien-arena: link creation from /usr/share/games/alien-arena/data1 fails; permission denied

2012-01-12 Thread Ansgar Burchardt

reopen 655031
thanks

Michael Gilbert michael.s.gilb...@gmail.com writes:
 The alien-arena wrapper script tries to make a link from /usr/share/games
 /alien-arena/data1 to $HOME/.config/alien-arena which fails.
 Creating the link by hand fails as well. It succeeds with sudo, tough.

 Your permissions on that directory structure must somehow be set as
 unwritable by your own account.  You'll have to fix that yourself.

 $ chmod a+w $HOME/.config/alien-arena

 should fix it.  If not, $HOME/.config itself isn't writable and you'll
 need to fix that similarly.

No, it looks like a bug in the wrapper script: if
$HOME/.config/alien-arena does not exist then alien-arena will be a
symlink to /usr/share/games/alien-arena/data1.  I guess this symlink
should be created inside the alien-arena directory instead, that is it
needs to mkdir -p $HOME/.config/alien-arena first.

In addition the wrapper should probably only try to do this if the
directories (the symlink) do not exist already and use set -e.

Regards,
Ansgar



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

Bug#655301: [Pkg-xen-devel] Bug#655301: Bug#655301: xcp-xapi fails to start

2012-01-12 Thread Mike McClurg

On Thu, Jan 12, 2012 at 7:21 AM, Ritesh Raj Sarraf r...@debian.org wrote:
 Setting up xcp-fe (0.5.2-3) ...
 Setting up xcp-squeezed (1.3-15) ...
 xc: error: Could not obtain handle on privileged command interface (2 =
 No such file or directory): Internal error
 Fatal error: exception Xenctrl.Error(Unable to open XC interface)
 Setting up xcp-v6d (1.3-15) ...
 Setting up xcp-storage-managers (0.1.1-2) ...
 Setting up xcp-xe (1.3-15) ...
 Setting up xcp-xapi (1.3-15) ...
 Error: Connection refused (calling connect )
 md5sum: /var/lib/xcp/templates.md5: No such file or directory
 Waiting for xapi to signal init complete

 failed to detect xapi init complete after 300s
 Setting up xcp-guest-templates (0.1-3) ...
 Setting up xcp-vncterm (0.1-2) ...


 The connection error is still there. And because of that there's a 300s
 timeout.

 This is my cleaned up environement.
 lnx200-39:~# ls /etc/x
 xcp/       xdg/       xen/       xen-tools/ xml/

 I'll look more into it.


Could you attach the fresh logs from this environment? There should be
a few hundred lines of logs in /var/log/xcp-xapi.log coming from
thread_zero, which is xapi's initialisation bit. Could you attach
that?

Mike



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

Bug#655550: gforth: see + hangs (gdb doesn't terminate)

2012-01-12 Thread Ph. Marek

Package: gforth
Version: 0.7.0+ds1-6
Severity: normal

Using gforth=0.7.0+ds1-6 and gdb=7.4-1~cvs2017.2 the see word doesn't
work for built-ins, like +. GDB just hangs, I expect it gets a bad command.



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

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

Versions of packages gforth depends on:
ii  dpkg   1.16.1.2
ii  gforth-common  0.7.0+ds1-6
ii  gforth-lib 0.7.0+ds1-6
ii  install-info   4.13a.dfsg.1-8
ii  libc6  2.13-24
ii  libffcall1 1.10+cvs20100619-2
ii  libltdl7   2.4.2-1

gforth recommends no packages.

gforth 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#654495: patchage: diff for NMU version 0.5.0+dfsg0-0.1

2012-01-12 Thread Paul Brossier


Hola Alessio!

i'm traveling at the moment, so your NMU is most welcome!

things should get better within a few weeks.

thanks, piem

On 10/01/2012 18:00, Alessio Treglia wrote:

tags 654495 + patch
tags 654495 + pending
thanks

Dear maintainer,

I've prepared an NMU for patchage (versioned as 0.5.0+dfsg0-0.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.






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

Bug#654773: cannot rebuild package

2012-01-12 Thread Colin Watson

On Thu, Jan 05, 2012 at 04:40:32PM +, Ian Jackson wrote:
 After preparing and testing (ad hoc) the resulting patch I wanted to
 make a fixed package to install on my system.  So I edited
 debian/changelog and tried dpkg-buildpackage -us -uc -rfakeroot and
 got this error message:
 
   dpkg-source: info: use the '3.0 (quilt)' format to have separate and
 documented changes to upstream files, see dpkg-source(1)

trn4 = 4.0-test77-1 does in fact use the 3.0 (quilt) format.  It may
well be that the source package rearrangements involved in converting to
this have made this bug go away.

   dpkg-source: unrepresentable changes to source
 
 A full transcript is below, and also my shell history.  The other
 shells and the emacs did nothing but run gdb and edit files.

That said, I can't seem to reproduce this based on your shell history.
It's somewhat as if the Makefile has been removed at some point without
actually cleaning up, thus leaving binary crud behind in your tree, but
I can't see what would do that.

Do you still have the broken tree lying around?  If you could tar it up
and send it to me then I could take a look.

Thanks,

-- 
Colin Watson   [cjwat...@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#579640: cron complains about missing lost+found dirs

2012-01-12 Thread Andrew Chittenden

Package: cron
Version: 3.0pl1-120
Followup-For: Bug #579640

Since installing autofs5, all active automounts have been complained
about. For example, when /home/andyc and /var/chroot/ia32/home/andyc
have been automounted:

/etc/cron.daily/standard:

Some local file systems lack a lost+found directory. This means if the
file system is damaged and needs to be repaired, fsck will not have
anywhere to put stray files for recovery. You should consider creating
a lost+found directory with mklost+found(8).

The following lost+found directories were not available:

/home/andyc/lost+found
/var/chroot/ia32/home/andyc/lost+found

-- Package-specific info:
--- EDITOR:
not set

--- /usr/bin/editor:
/usr/bin/vim.basic

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 34048 Sep 18 22:21 /usr/bin/crontab

--- /var/spool/cron:
drwxr-xr-x 5 root root 4096 May 17  2011 /var/spool/cron

--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Jun 27  2011 /var/spool/cron/crontabs

--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Nov 25 08:36 /etc/cron.d

--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Jan  9 14:31 /etc/cron.daily

--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Sep 22 08:24 /etc/cron.hourly

--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Sep 22 08:24 /etc/cron.monthly

--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Jan  3 12:45 /etc/cron.weekly


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

Kernel: Linux 3.1.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cron depends on:
ii  adduser 3.113
ii  debianutils 4.1
ii  dpkg1.16.1.2
ii  libc6   2.13-24
ii  libpam-runtime  1.1.3-6
ii  libpam0g1.1.3-6
ii  libselinux1 2.1.0-4
ii  lsb-base3.2-28

Versions of packages cron recommends:
ii  exim4  4.77-1
ii  exim4-daemon-light [mail-transport-agent]  4.77-1+b1

Versions of packages cron suggests:
ii  anacron2.3-14
ii  checksecurity  none
ii  logrotate  3.8.1-1

Versions of packages cron is related to:
pn  libnss-ldap   none
pn  libnss-ldapd  none
pn  libpam-ldap   none
pn  libpam-mount  none
pn  nis   3.17-32
pn  nscd  none

-- 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#649937: usb: timeouts trying to mount thumb drive, device descriptor read/64, error -60

2012-01-12 Thread Gabriel VLASIU

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 11 Jan 2012, Jonathan Nieder wrote:

 Does the device actually have manufacturer 1, product 2, serial number 3?
Whats what the log said, so yes (assuming the kernel report is correct).

 What do you get with lsusb -v with it plugged in to an unaffected system?
See attached file lsusb-v-k3.1.8-2.f16.x86_64.txt.

 How about on an affected system?
See attached file lsusb-v_k3.2.0-rc7-sparc64.txt.

 I assume you had plugged the same device in back into the same port?
I used the same port when moved to others when back to original port.

 Does the misbehavior happen for arbitrary USB devices, or just this
 one thumb drive?  (E.g., if you have any old USB 1.0 devices, can you
 reproduce this with it?)
Well This is what I did this morning:

1. Reboot.
2. Insert thumb drive in first usb port. Run 'lsusb -v'
3. Removed thumb drive.
4. Inserted an old logitech wireless mouse (the receiver) in another usb 
   port (I think is an usb 1.1 device). Kernel reported this:

Jan 12 09:50:00 mailq kernel: [  399.868318] usb 2-1: USB disconnect, device 
number 2
Jan 12 09:50:18 mailq kernel: [  417.819643] usb 2-2: new low-speed USB device 
number 3 using ohci_hcd
Jan 12 09:50:18 mailq kernel: [  418.011698] usb 2-2: New USB device found, 
idVendor=046d, idProduct=c501
Jan 12 09:50:18 mailq kernel: [  418.011734] usb 2-2: New USB device strings: 
Mfr=1, Product=2, SerialNumber=0
Jan 12 09:50:18 mailq kernel: [  418.011766] usb 2-2: Product: USB Receiver
Jan 12 09:50:18 mailq kernel: [  418.011790] usb 2-2: Manufacturer: Logitech

5. Removed the usb mouse receiver. Inserted the usb mouse receiver again 
   in same port. No reaction from kernel.
6. Trying to run lsusb -v. lsusb freeze (ctrl-c/ctrl-z/kill don't work). 
7. Waiting for a while... See attached file messages-20120112
8. Reboot.

 Was this a regression?  (I.e., if you know of any older kernel version that
 is not affected, that would be useful.)
I tested with kernel 3.x as requested in one of the previous e-mails. 
However, 2.6.32-5-sparc64 behave almost the same. thumb drive is 
detected also fist time. Errors second/third time, etc. Still, after 
several remove / inserts the thumb drive is recognized again (I only 
tried this procedure once).


Sincerely,
Gabriel

- -- 

// Gabriel VLASIU
//
// OpenGPG-KeyID  : 0xE684206E
// OpenGPG-Fingerprint: 0C3D 9F8B 725D E243 CB3C 8428 796A DB1F E684 206E
// OpenGPG-URL: http://www.vlasiu.net/public.key


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

iEYEARECAAYFAk8OnEsACgkQeWrbH+aEIG6SGwCfdylzFD2DlSqasqyH/FwZRFo/
7RAAnAvWvJaBQFHBrJKzyhKq45niXch8
=KOWE
-END PGP SIGNATURE-Jan 12 09:47:13 mailq kernel: [  232.467738] usb 2-1: new full-speed USB device 
number 2 using ohci_hcd
Jan 12 09:47:13 mailq kernel: [  232.660665] usb 2-1: New USB device found, 
idVendor=1005, idProduct=b113
Jan 12 09:47:13 mailq kernel: [  232.660702] usb 2-1: New USB device strings: 
Mfr=1, Product=2, SerialNumber=3
Jan 12 09:47:13 mailq kernel: [  232.660735] usb 2-1: Product: USB FLASH DRIVE
Jan 12 09:47:13 mailq kernel: [  232.660759] usb 2-1: Manufacturer: 
Jan 12 09:47:13 mailq kernel: [  232.660783] usb 2-1: SerialNumber: 
07AB061376562D50
Jan 12 09:47:13 mailq kernel: [  232.763199] usbcore: registered new interface 
driver uas
Jan 12 09:47:13 mailq kernel: [  232.791937] Initializing USB Mass Storage 
driver...
Jan 12 09:47:13 mailq kernel: [  232.792605] scsi2 : usb-storage 2-1:1.0
Jan 12 09:47:13 mailq kernel: [  232.793608] usbcore: registered new interface 
driver usb-storage
Jan 12 09:47:13 mailq kernel: [  232.793637] USB Mass Storage support 
registered.
Jan 12 09:47:14 mailq kernel: [  233.894699] scsi 2:0:0:0: Direct-Access
  USB FLASH DRIVE  PMAP PQ: 0 ANSI: 0 CCS
Jan 12 09:47:14 mailq kernel: [  233.901935] sd 2:0:0:0: Attached scsi generic 
sg3 type 0
Jan 12 09:47:14 mailq kernel: [  234.418563] sd 2:0:0:0: [sdc] 7834944 512-byte 
logical blocks: (4.01 GB/3.73 GiB)
Jan 12 09:47:15 mailq kernel: [  234.425533] sd 2:0:0:0: [sdc] Write Protect is 
off
Jan 12 09:47:15 mailq kernel: [  234.432542] sd 2:0:0:0: [sdc] No Caching mode 
page present
Jan 12 09:47:15 mailq kernel: [  234.432916] sd 2:0:0:0: [sdc] Assuming drive 
cache: write through
Jan 12 09:47:15 mailq kernel: [  234.469527] sd 2:0:0:0: [sdc] No Caching mode 
page present
Jan 12 09:47:15 mailq kernel: [  234.469975] sd 2:0:0:0: [sdc] Assuming drive 
cache: write through
Jan 12 09:47:15 mailq kernel: [  234.491634]  sdc: sdc1
Jan 12 09:47:15 mailq kernel: [  234.524568] sd 2:0:0:0: [sdc] No Caching mode 
page present
Jan 12 09:47:15 mailq kernel: [  234.524907] sd 2:0:0:0: [sdc] Assuming drive 
cache: write through
Jan 12 09:47:15 mailq kernel: [  234.525244] sd 2:0:0:0: [sdc] Attached SCSI 
removable disk
Jan 12 09:49:39 mailq kernel: [  379.379777] FAT-fs (sdc1): utf8 is not a 
recommended IO charset for FAT filesystems, filesystem will be case sensitive

Bug#655547: closed by Mark Brown broo...@debian.org (Re: Bug#655547: pam_unix.so needs nis option)

2012-01-12 Thread Harald Dunkel

Hi Mark,

Its not about editing the file, but about adding the nis
option to the pam_unix.so line using the documented
configuration interface (pam-auth-update).

I can understand that you hesitate to touch the complex
pam configuration scheme, but surely common-password is
_not_ a critical system configuration file. It is just
the default scheme for changing passwords.

On openSUSE and RedHat this is not an issue. How comes
that it is on Debian?


Regards

Harri



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

Bug#653205: [Pkg-acpi-devel] Bug#653205: acpi-support: screen is dark without backlight after resume.

2012-01-12 Thread Michael Meskes

Hi,

 The screen is light with backlight when changing LOCK_SCREEN.
 
 0.138-10
   LOCK_SCREEN=true  : NG
   LOCK_SCREEN=false : OK
 
 0.138-9
   LOCK_SCREEN=true  : OK
   LOCK_SCREEN=false : OK

I checked all possible setups on my system and they all work. Which kernel do 
you have? Does it still happen with the latest 3.1 kernel from sid? 

Also what happens of you change the setting of DISPLAY_DPMS in 
/etc/default/acpi-support? 

There were some problems in -9 that may have resulted in this part of the code 
not being executed at all. So maybe that fix made another problem visible.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL



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

Bug#655551: [l10n/zh_CN] nvidia-support: Updated Simplified Chinese translation

2012-01-12 Thread Aron Xu

Package: nvidia-support
Severity: wishlist
Tags: l10n,patch

Attached is my updated version of Simplified Chinese translation.

--
Regards,
Aron Xu
# Chinese translations for nvidia-support package
# nvidia-support 软件包的简体中文翻译.
# Copyright (C) 2011 Free Software Foundation, Inc.
# This file is distributed under the same license as the nvidia-support package.
# Aron Xu happyaron...@gmail.com, 2011.
#
msgid
msgstr
Project-Id-Version: nvidia-support debconf\n
Report-Msgid-Bugs-To: nvidia-supp...@packages.debian.org\n
POT-Creation-Date: 2011-11-10 17:17+0100\n
PO-Revision-Date: 2012-01-12 17:04+0800\n
Last-Translator: Aron Xu happyaron...@gmail.com\n
Language-Team: Chinese (simplified) i18n...@googlegroups.com\n
Language: zh_CN\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n

#. Type: boolean
#. Description
#: ../nvidia-installer-cleanup.templates:1001
msgid Run 'nvidia-installer --uninstall'?
msgstr 运行“nvidia-installer --uninstall”吗？

#. Type: boolean
#. Description
#: ../nvidia-installer-cleanup.templates:1001
msgid
The 'nvidia-installer' program was found on your system. This is probably
left over from an earlier installation of the non-free NVIDIA graphics
driver, installed using the NVIDIA *.run file directly. This installation
is incompatible with the Debian packages. To install the Debian packages
safely, it is therefore neccessary to undo the changes performed by 'nvidia-
installer'.
msgstr
您的系统中存在“nvidia-installer”程序。这可能是由于您之前使用 NVIDIA *.run 文
件直接安装而遗留的文件，而它与即将要安装 Debian 软件包不相容。要安全地安装这
个 Debian 软件包，您需要先还原“nvidia-installer”所做的一切修改。

#. Type: boolean
#. Description
#: ../nvidia-installer-cleanup.templates:2001
msgid Delete 'nvidia-installer' files?
msgstr 删除“nvidia-installer”文件？

#. Type: boolean
#. Description
#: ../nvidia-installer-cleanup.templates:2001
msgid
Some files from the 'nvidia-installer' still remain on your system. These
probably come from an earlier installation of the non-free NVIDIA graphics
driver using the *.run file directly. Running the uninstallation procedure
may have failed and left these behind. These files conflict with the
packages providing the non-free NVIDIA graphics driver and must be removed
before the package installation can continue.
msgstr
“nvidia-installer”中的某些文件可能仍存在于您的系统中。这可能是由于您之前使用
NVIDIA *.run 文件直接安装而遗留的文件。此后的卸载操作可能出现了失败。这些文件
与提供非自由 NVIDIA 图形驱动的软件包冲突，继续前必须删除。

#. Type: boolean
#. Description
#: ../nvidia-installer-cleanup.templates:3001
msgid Remove conflicting library files?
msgstr 删除冲突的库文件？

#. Type: boolean
#. Description
#: ../nvidia-installer-cleanup.templates:3001
msgid
The following libraries were found on your system and conflict with the
current installation of the NVIDIA graphics drivers:
msgstr 您系统中的以下库文件与即将安装的 NVIDIA 图形驱动冲突：

#. Type: boolean
#. Description
#: ../nvidia-installer-cleanup.templates:3001
msgid
These libraries are most likely remnants of an old installation using the
nvidia-installer and do not belong to any package managed by dpkg. It
should be safe to delete them.
msgstr
这些库文件像是 nvidia-installer 安装时残存的旧文件，它们未被 dpkg 所收录管
理。删除他们应当是安全的。

#. Type: note
#. Description
#. Translators, do not translate the substitution variables (${new-version},
#. ${running-version}) and the command 'rmmod nvidia'.
#: ../nvidia-support.templates:3001
msgid
The nvidia driver that is being installed (version ${new-version}) does not
match the nvidia kernel module currently loaded (version ${running-version}).
msgstr
当前安装的 Nvidia 驱动(${new-version})和当前加载的模块(${running-version})版
本不匹配。

#. Type: note
#. Description
#. Translators, do not translate the substitution variables (${new-version},
#. ${running-version}) and the command 'rmmod nvidia'.
#: ../nvidia-support.templates:3001
msgid
The easiest way to 'fix' this is to reboot the machine once the installation
has finished. You can also stop the X server (usually by stopping the login
manager, e.g. gdm3, kdm or xdm), manually unload the module (rmmod nvidia)
and restart the X server.
msgstr
解决这个问题的最简单方法是在安装完成后重新启动计算机。除此之外，您也可以手工
关闭 X (一般是关闭登录管理器，如 gdm3、kdm 和 xdm)后卸载正在使用的模块(rmmod
nvidia) 并重启 X。

#. Type: note
#. Description
#: ../nvidia-support.templates:4001
msgid Conflicting nouveau kernel module loaded
msgstr 有冲突的 nouveau 内核模块正在运行

1 2 3 4 >

1 - 100 of 355 matches

Mail list logo