Bug#239816: bug#16134: libparted Atari partition table support
Philip, On 12/17/2013 2:17 PM, Thorsten Glaser wrote: I thought so too, but it turns out that the Atari IDE interface is literally wired “the wrong way”, so you do need to bswap the entire disc – not just partition table or filesystem metadata – but also user data – before exchanging it between any other sy‐ stem with IDE and an Atari. Don’t mind that detail. Oh wow. That's some serous dain bramage... Yep, that's seriously borked up. Someone traded sanity and portability for speed (originally these machines did have a 16 MHz 68030 only). Can't have been delusions to be the only game in town at that stage (the Amigas and Macs already had 040 processors in use by that time), so it's even more amazing. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732451: cryptsetup can't find blkid binary when launched in a dropbear shell
Package: cryptsetup Version: 2:1.4.3-4 Severity: normal Dear Maintainer, In order to decrypt partitions on boot via SSH, I installed dropbear and busybox, following the instructions at the following URL. http://blog.nguyenvq.com/blog/2011/09/13/remote-unlocking-luks-encrypted-lvm-using-dropbear-ssh-in-ubuntu/ After launching the 'cryptsetup' script from within the shell provided by dropbear SSH, I received the following error message, and the boot partition was not mounted: -sh: blkid: not found The 'cryptsetup' script calls 'blkid' without a full directory qualifier, but if I change the script to reference '/sbin/blkid' specifically, the instructions work as expected, and my boot partition is mounted properly. My recommendation is to provide an absolute path for the location of the 'blkid' binary in the 'cryptsetup' script. Please note the information provided below is from Debian testing (as of 2013-12-18) 64-bit, running in a VirtualBox VM. Thanks. Colin Wetherbee -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/enctest-root ro initrd=/install/initrd.gz quiet -- /etc/crypttab sda5_crypt UUID=28f66d54-dbd6-42b9-b502-520e83d62aad none luks -- /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # file system mount point type options dump pass /dev/mapper/enctest-root / ext4errors=remount-ro 0 1 # /boot was on /dev/sda1 during installation UUID=c3d0b197-f8d1-4a16-91be-6136e1a305a0 /boot ext2defaults 0 2 /dev/mapper/enctest-swap_1 noneswapsw 0 0 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 -- lsmod Module Size Used by ppdev 12763 0 bnep 17567 2 lp 17149 0 rfcomm 33700 0 bluetooth 119455 10 rfcomm,bnep rfkill 19012 2 bluetooth uinput 17440 1 nfsd 216170 2 nfs 308313 0 nfs_acl12511 2 nfs,nfsd auth_rpcgss37143 2 nfs,nfsd fscache36739 1 nfs lockd 67306 2 nfs,nfsd sunrpc173730 6 lockd,auth_rpcgss,nfs_acl,nfs,nfsd ext2 59231 1 loop 22641 0 snd_intel8x0 30903 0 snd_ac97_codec106942 1 snd_intel8x0 snd_pcm68083 2 snd_ac97_codec,snd_intel8x0 snd_page_alloc 13003 2 snd_pcm,snd_intel8x0 parport_pc 22364 0 snd_timer 22917 1 snd_pcm parport31858 3 parport_pc,lp,ppdev i2c_piix4 12536 0 psmouse69265 0 ac 12624 0 i2c_core 23876 1 i2c_piix4 evdev 17562 4 joydev 17266 0 pcspkr 12579 0 serio_raw 12931 0 battery13146 0 power_supply 13475 2 battery,ac snd52889 4 snd_timer,snd_pcm,snd_ac97_codec,snd_intel8x0 soundcore 13065 1 snd processor 28157 0 button 12937 0 ac97_bus 12510 1 snd_ac97_codec thermal_sys18040 1 processor ext4 350763 1 crc16 12343 2 ext4,bluetooth jbd2 62115 1 ext4 mbcache13114 2 ext4,ext2 cryptd 14517 0 aes_x86_64 16843 12 aes_generic33026 1 aes_x86_64 xts12645 6 gf128mul 13048 1 xts uhci_hcd 26865 0 dm_crypt 22586 1 dm_mod 63645 10 dm_crypt usbhid 36418 0 hid81328 1 usbhid sg 25874 0 sr_mod 21899 0 sd_mod 36136 3 cdrom 35401 1 sr_mod crc_t10dif 12348 1 sd_mod ata_generic12479 0 ahci 24997 2 ohci_hcd 26563 0 libahci22860 1 ahci ehci_hcd 40215 0 ata_piix 29535 0 usbcore 128741 5 ehci_hcd,ohci_hcd,usbhid,uhci_hcd e1000 86156 0 usb_common 12354 1 usbcore libata140630 4 ata_piix,libahci,ahci,ata_generic scsi_mod 162269 4 libata,sd_mod,sr_mod,sg -- System Information: Debian Release: 7.2 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 cryptsetup depends on: ii cryptsetup-bin
Bug#732452: icecast2: Icecast 2.3.2 doesn't list all mount points
Package: icecast2 Version: 2.3.2-9+deb7u2 Severity: normal Dear Maintainer, I have installed icecast2 on a Debian Wheezy server, which is used to 'proxy' some streams to the internal network. This all works fine. However, it seems that I cannot list all the mount points that are configured on this server. Only mount points which have been used at least once are shown. I have several relay configurations like this: relay serverhostname of source/server port8000/port mount/radio/mount local-mount/radio/local-mount relay-shoutcast-metadata1/relay-shoutcast-metadata on-demand1/on-demand /relay These relay mount points do just work fine. This problem is also described here: http://comments.gmane.org/gmane.comp.audio.icecast.general/8710 Icecast2 revision 15122 should have fixed this problem, see http://lists.xiph.org/pipermail/commits/2008-July/013869.html I tried to fix it by editing some xsl files (removing conditionals), but that didn't seem to fix it. -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-4-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/dash Versions of packages icecast2 depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii libc6 2.13-38 ii libcurl3-gnutls7.26.0-1+wheezy6 ii libogg01.3.0-4 ii libspeex1 1.2~rc1-7 ii libtheora0 1.1.1+dfsg.1-3.1 ii libvorbis0a1.3.2-1.3 ii libxml22.8.0+dfsg1-7+nmu2 ii libxslt1.1 1.1.26-14.1 icecast2 recommends no packages. Versions of packages icecast2 suggests: pn ices2 none -- Configuration Files: /etc/default/icecast2 changed [not included] - Enabled the daemon /etc/icecast2/admin/listmounts.xsl changed [not included] - Tried some fixes showing all mount points /etc/icecast2/icecast.xml changed [not included] - Changed passwords and added relay configuration /etc/icecast2/web/status.xsl changed [not included] - Tried some fixes showing all mount points -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732453: bluez: New upstream release 5.12
Package: bluez Version: 4.101-4 Severity: normal Dear Maintainer, It is possile to have bluez 5.12 in unstable ? Christian -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.12.5 (SMP w/8 CPU cores; PREEMPT) 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 bluez depends on: ii dbus 1.6.18-2 ii kmod 9-3 ii libc6 2.17-97 ii libdbus-1-3 1.6.18-2 ii libglib2.0-0 2.36.4-1 ii libreadline6 6.2+dfsg-0.1 ii libudev1 204-5 ii libusb-0.1-4 2:0.1.12-23.3 ii lsb-base 4.1+Debian12 ii python-dbus 1.2.0-2+b1 ii python-gi 3.10.2-1 ii udev 204-5 bluez recommends no packages. bluez suggests no packages. -- Configuration Files: /etc/bluetooth/main.conf changed [not included] /etc/bluetooth/rfcomm.conf changed [not included] /etc/default/bluetooth changed [not included] -- 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#732454: amarok: Amarok ampache plugin configuration error
Package: amarok Version: 2.8.0-2 Severity: important When configuring ampache plugin, (host, user and password), checking the connection succeeds. Once the configuration is saved, when I restart amarok, I have an Authentication failed error showing up. When I check ampache logs, I can see that the password used to connect is not the same as the one used when testing the connection during the configuration (the password is not displayed in plain text in the logs). I have to enter again the password in the configuration box to discard this error message when I start Amarok. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.10-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages amarok depends on: ii amarok-common 2.8.0-2 ii amarok-utils 2.8.0-2 ii kde-runtime 4:4.11.3-1 ii libaio1 0.3.109-4 ii libavcodec54 6:9.10-1 ii libavformat54 6:9.10-1 ii libavutil52 6:9.10-1 ii libc6 2.17-97 ii libcurl3-gnutls 7.33.0-1 ii libgcrypt11 1.5.3-2 ii libgdk-pixbuf2.0-02.28.2-1+b1 ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libglib2.0-0 2.36.4-1 ii libgpod4 0.8.3-1.1 ii libkcmutils4 4:4.11.3-2 ii libkdecore5 4:4.11.3-2 ii libkdeui5 4:4.11.3-2 ii libkdewebkit5 4:4.11.3-2 ii libkdnssd44:4.11.3-2 ii libkfile4 4:4.11.3-2 ii libkio5 4:4.11.3-2 ii libknewstuff3-4 4:4.11.3-2 ii liblastfm11.0.8-2 ii libloudmouth1-0 1.4.3-10 ii libmtp9 1.1.6-20-g1b9f164-1 ii libmysqlclient18 5.5.33+dfsg-1 ii libnepomukcore4 4:4.11.3-1 ii libofa0 0.9.3-5 ii libphonon44:4.7.0.0-2 ii libplasma34:4.11.3-2 ii libqjson0 0.8.1-3 ii libqt4-dbus 4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-network4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-opengl 4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-script 4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-sql4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-svg4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-xml4:4.8.5+git192-g085f851+dfsg-2 ii libqtcore44:4.8.5+git192-g085f851+dfsg-2 ii libqtgui4 4:4.8.5+git192-g085f851+dfsg-2 ii libqtscript4-core 0.2.0-1 ii libqtscript4-gui 0.2.0-1 ii libqtscript4-network 0.2.0-1 ii libqtscript4-sql 0.2.0-1 ii libqtscript4-uitools 0.2.0-1 ii libqtscript4-xml 0.2.0-1 ii libqtwebkit4 2.2.1-7 ii libsolid4 4:4.11.3-2 ii libsoprano4 2.9.4+dfsg-1 ii libstdc++64.8.2-1 ii libthreadweaver4 4:4.11.3-2 ii libx11-6 2:1.6.2-1 ii libxml2 2.9.1+dfsg1-3 ii phonon4:4.7.0.0-2 ii zlib1g1:1.2.8.dfsg-1 Versions of packages amarok recommends: pn clamznone pn kio-audiocd none Versions of packages amarok suggests: pn amarok-doc none ii libqt4-sql-mysql 4:4.8.5+git192-g085f851+dfsg-2 pn libqt4-sql-psqlnone ii libqt4-sql-sqlite 4:4.8.5+git192-g085f851+dfsg-2 pn moodbarnone Versions of packages amarok-common depends on: ii perl 5.18.1-5 amarok-common recommends no packages. Versions of packages amarok is related to: ii phonon-backend-gstreamer [phonon-backend] 4:4.7.0.0-1 ii phonon-backend-vlc [phonon-backend]0.7.0-1 -- 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#732387: [Openstack-devel] Bug#732387: Adds user ceilometer to group nova and libvirt on every upgrade
Hi Gaudenz, First of all, thanks for taking the time to send bug reports. I'm very happy to see that OpenStack gets more and more traction within the Debian community. On 12/17/2013 10:20 PM, Gaudenz Steinlin wrote: But this is actually not respecting local admin configurations. If an administrator decides (for whatever reason) that the ceilometer user should not be part of these groups Well, if an admin decides this, then Ceilometer will not work anymore. That admin might as well just remove ceilometer-common... this decision is reverted on every package upgrade. This violates Debian Policy section 10.7.3 which states that local modifications must be preserved. The user should only be added to these groups on first install. On upgrades the group membership should not be changed. The section 10.7.3 that you mention is under the chapter Configuration files and has nothing to do with managing Unix user and groups. Also, removing the unconditionality of the unix user/group management would make this particular maintainer script not idempotent anymore, which is a path that is very dangerous to take. Also, I fail to see where else in the policy manual it is written that a package cannot impose a particular user to be inside a specific group. Please point to the correct policy manual section if you still think this is wrong. Whatever your reply will be, I don't think this bug deserves a severity serious (to quote the release team: not all policy violation are RC bugs), so I'm downgrading the severity. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732421: python-zc.buildout: requires setuptools=0.7 which is not in wheezy
Buildout itself does not require a newer version of setuptools, 0.6c11 is
enough. But the init command bootstraps a new buildout by downloading the
newest version of distribute and this fails. This started happening when
setuptools/distribute merged and setuptools 0.7 was released.
buildout init only creates an empty buildout.cfg file. It's not very useful.
The recommended way is to write the buildout.cfg, create a virtualenv and
bootstrap a self-contained buildout:
virtualenv sandbox
wget http://downloads.buildout.org/1/bootstrap.py
python bootstrap.py
bin/buildout
I never use the system buildout.
2013/12/17 Ryan Nowakowski r...@keyingredient.com
Package: python-zc.buildout
Version: 1.5.2-1
Severity: normal
It seems that buildout 1.5.2 requires setuptools=0.7 which is not is
wheezy:
tubaman@cuisine:~/myproj$ buildout2.7 init
Creating '/home/tubaman/myproj/buildout.cfg'.
Creating directory '/home/tubaman/myproj/bin'.
Creating directory '/home/tubaman/myproj/parts'.
Creating directory '/home/tubaman/myproj/eggs'.
Creating directory '/home/tubaman/myproj/develop-eggs'.
Getting distribution for 'distribute'.
warning: install_lib: 'build/lib.linux-x86_64-2.7' does not exist -- no
Python modules to install
Got distribute 0.7.3.
Getting distribution for 'zc.buildout'.
Got zc.buildout 2.2.1.
While:
Bootstrapping.
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/zc/buildout/buildout.py, line
1805, in main
getattr(buildout, command)(args)
File /usr/lib/python2.7/dist-packages/zc/buildout/buildout.py, line
393, in bootstrap
ws.require('zc.buildout')
File /usr/lib/python2.7/dist-packages/pkg_resources.py, line 686, in
require
needed = self.resolve(parse_requirements(requirements))
File /usr/lib/python2.7/dist-packages/pkg_resources.py, line 584, in
resolve
raise DistributionNotFound(req)
DistributionNotFound: setuptools=0.7
tubaman@cuisine:~/myproj$
-- System Information:
Debian Release: 7.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 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 python-zc.buildout depends on:
ii python2.7.3-4+deb7u1
ii python-pkg-resources 0.6.24-1
ii python2.6 2.6.8-1.1
ii python2.7 2.7.3-6
python-zc.buildout recommends no packages.
python-zc.buildout suggests no packages.
-- no debconf information
___
pkg-zope-developers mailing list
pkg-zope-develop...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-zope-developers
--
Gediminas
Bug#715410: amarok: Same problem with 2.8.0
Package: amarok Version: 2.8.0-2 Followup-For: Bug #715410 I have the same problem with this version (2.8.0-2). It used to work, but now no collection is displayed in the ampache part. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.10-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages amarok depends on: ii amarok-common 2.8.0-2 ii amarok-utils 2.8.0-2 ii kde-runtime 4:4.11.3-1 ii libaio1 0.3.109-4 ii libavcodec54 6:9.10-1 ii libavformat54 6:9.10-1 ii libavutil52 6:9.10-1 ii libc6 2.17-97 ii libcurl3-gnutls 7.33.0-1 ii libgcrypt11 1.5.3-2 ii libgdk-pixbuf2.0-02.28.2-1+b1 ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libglib2.0-0 2.36.4-1 ii libgpod4 0.8.3-1.1 ii libkcmutils4 4:4.11.3-2 ii libkdecore5 4:4.11.3-2 ii libkdeui5 4:4.11.3-2 ii libkdewebkit5 4:4.11.3-2 ii libkdnssd44:4.11.3-2 ii libkfile4 4:4.11.3-2 ii libkio5 4:4.11.3-2 ii libknewstuff3-4 4:4.11.3-2 ii liblastfm11.0.8-2 ii libloudmouth1-0 1.4.3-10 ii libmtp9 1.1.6-20-g1b9f164-1 ii libmysqlclient18 5.5.33+dfsg-1 ii libnepomukcore4 4:4.11.3-1 ii libofa0 0.9.3-5 ii libphonon44:4.7.0.0-2 ii libplasma34:4.11.3-2 ii libqjson0 0.8.1-3 ii libqt4-dbus 4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-network4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-opengl 4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-script 4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-sql4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-svg4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-xml4:4.8.5+git192-g085f851+dfsg-2 ii libqtcore44:4.8.5+git192-g085f851+dfsg-2 ii libqtgui4 4:4.8.5+git192-g085f851+dfsg-2 ii libqtscript4-core 0.2.0-1 ii libqtscript4-gui 0.2.0-1 ii libqtscript4-network 0.2.0-1 ii libqtscript4-sql 0.2.0-1 ii libqtscript4-uitools 0.2.0-1 ii libqtscript4-xml 0.2.0-1 ii libqtwebkit4 2.2.1-7 ii libsolid4 4:4.11.3-2 ii libsoprano4 2.9.4+dfsg-1 ii libstdc++64.8.2-1 ii libthreadweaver4 4:4.11.3-2 ii libx11-6 2:1.6.2-1 ii libxml2 2.9.1+dfsg1-3 ii phonon4:4.7.0.0-2 ii zlib1g1:1.2.8.dfsg-1 Versions of packages amarok recommends: pn clamznone pn kio-audiocd none Versions of packages amarok suggests: pn amarok-doc none ii libqt4-sql-mysql 4:4.8.5+git192-g085f851+dfsg-2 pn libqt4-sql-psqlnone ii libqt4-sql-sqlite 4:4.8.5+git192-g085f851+dfsg-2 pn moodbarnone Versions of packages amarok-common depends on: ii perl 5.18.1-5 amarok-common recommends no packages. Versions of packages amarok is related to: ii phonon-backend-gstreamer [phonon-backend] 4:4.7.0.0-1 ii phonon-backend-vlc [phonon-backend]0.7.0-1 -- 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#732455: nsd: French debconf templates translation
Package: nsd Version: 4.0.0-5 Severity: wishlist Tags: patch l10n Hi, Please find attached the french debconf templates translation, proofread by the debian-l10n-french mailing list contributors. This file should be put as debian/po/fr.po in your package build tree. -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-0.bpo.2-amd64 (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 # Translation of nsd debconf template to French # Copyright (C) 2013 # This file is distributed under the same license as the nsd package. # Steve Petruzzello dl...@bluewin.ch, 2013. # msgid msgstr Project-Id-Version: nsd\n Report-Msgid-Bugs-To: n...@packages.debian.org\n POT-Creation-Date: 2013-12-13 06:20+0100\n PO-Revision-Date: 2013-12-14 12:00+0100\n Last-Translator: Steve Petruzzello dl...@bluewin.ch\n Language-Team: French debian-l10n-fre...@lists.debian.org\n Language: \n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n #. Type: note #. Description #: ../templates:2001 msgid Configuration directory for NSD changed msgstr Déplacement du répertoire de configuration de NSD #. Type: note #. Description #: ../templates:2001 msgid NSD 4 has changed the configuration directory from /etc/nsd3 to /etc/nsd. msgstr Le répertoire de configuration de NSD 4 a été déplacé de /etc/nsd3 à /etc/ nsd. #. Type: note #. Description #: ../templates:2001 msgid The old configuration file (/etc/nsd3/nsd.conf) will be moved to /etc/nsd/ nsd.conf. However, other configuration files in /etc/nsd3 will not be moved, so you need to check and move your configuration snippets and zone files yourself. msgstr L'ancien fichier de configuration (/etc/nsd3/nsd.conf) sera déplacé vers / etc/nsd/nsd.conf. Toutefois, les autres fichiers de configuration présents dans /etc/nsd3 ne seront pas déplacés ; vous devrez donc vérifier et déplacer vos bribes de configuration et vos fichiers de zone vous-même.
Bug#732118: xserver-xorg-video-nvidia: Could you please add xorg-video-abi-15 support
On 12/18/2013 08:28 AM, Eric Valette wrote: On 18/12/2013 01:19, Andreas Beckmann wrote: On 2013-12-14 12:37, Eric Valette wrote: As far as I know nvidia has added Xorg 1.15 support on all it's branch now (including the legacy 175.x, 304.x, ...). I would like to test Xorg 1.15 from experimental. AFAIK 331.xx does not yet support Xorg 1.15 - but you can use the driver from sid. While I agree I cannot find explicit mention of it, I would be surprised that all their stable version has support while their beta version does not. Will test myself by changing control file then. Checked nvidia developper zone and you are right. Strange! -- eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732393: tinc: strange memory error reported to syslog
On Wed, Dec 18, 2013 at 06:02:14AM +0100, Petter Reinholdtsen wrote: On the other hand, one doesn't expect much memory to be allocated due to such calls, and if that would fail you would expect tinc itself to quickly fail afterwards. Well, my tincd process have failed a few times, as in disappeared without a trace. Did not find anything in the log explaining what happened. Ok, that could be the result of tinc running out of memory. Also, I wouldn't expect an amd64 to run out of memory from tinc. Can you check whether memory really is tight? And are you using tinc's mlock feature? Memory isn't tight, I got 250 MiB free on the machine, according to top. I'm using the default, where --mlock is used as a command line option. This is the command line according to ps -ef: /usr/sbin/tincd -n dugnadsnett.no -o Interface vpn -d1 --mlock --user=nobody Ah, it might be related to bug #690685: when running as a non-root user, the process limits might prevent tinc from allocating all the locked memory it needs. There is a patch available as well. Could you try it out and see if that helps? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690685 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=tinc-set-shell-limit.diff;att=1;bug=690685 After applying the patch, add the following to /etc/defaults/tinc: LIMITS=-l unlimited I'll apply the patch to the version in unstable in any case. -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Bug#732456: xen-tools: Please support operation on systems without xend installed
Package: xen-tools Version: 4.3.1-1 Severity: normal Dear Maintainer, Running on a system which contains Xen (xl) but not xend results in: 2013-12-18 02:23:56 Z executing ssh ... root@10.80.229.109 xen-create-image \ --dhcp --mac 5a:36:0e:b9:00:09 \ --memory 512Mb --swap 1000Mb \ --dist squeeze \ --mirror http://10.80.16.196/debian \ --hostname debian.guest.osstest \ --lvm marilith-n5 --force \ --kernel /boot/vmlinuz-3.12.0+ \ --genpass 0 --password xenroot \ --initrd /boot/initrd.img-3.12.0+ \ --arch armhf Failed to read /etc/xen/xend-config.sxp: No such file or directory2013-12-18 02:23:57 Z runvar store: debian_cfgpath=/etc/xen/debian.guest.osstest.cfg 2013-12-18 02:23:57 Z runvar store: debian_swap_lv=debian.guest.osstest-swap + rc=0 (full log is currently at http://www.chiark.greenend.org.uk/~xensrcts/logs/22457/test-armhf-armhf-xl/7.ts-debian-install.log but will likely expire, so also attached). Upstream Xen has made Xen a configure time option which defaults to off which will release with Xen 4.4 in the new year. Also the new ARM port will not include xend even as an option (the above log is actually from the ARM test because the test infrastructure currently forces xend on for x86). BTW apart from this issue xen-tools seems to work perfectly fine on armhf. This was observed on Wheezy but by inspection the version in Sid (4.4-1) appears to still have this issue. I also observed a few secondary issues: The callers of fail() appear for the most part to expect the final \n to be appended to the log but logprint() does not do so (the callers of logprint appear to get this right and pass \n themselves where necessary). The overall xen-create-image command appears to succeed despite erroring out early (no domain is actually created). If xend is installed then the warning/advice to add a network-script setting to xend-config.sxp is contrary to both upstream Xen and the Debian Xen maintainer's advice, which is to use /etc/network/interfaces to configure host level networking, see /usr/share/doc/xen-utils-4.1/README.Debian and http://wiki.xen.org/wiki/HostConfiguration/Networking. Under xl this is the only possible way to configure networking. FYI the xl equivalent of xend-config.sxp:(vif-script FOO) is /etc/xen/xl.conf:vif.default.script = FOO. Note that it is also valid with both xl and xm to include the script in per-vif configuration string. Thanks, Ian. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/4 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 xen-tools depends on: ii cdebootstrap 0.5.10 ii debootstrap 1.0.53 ii libconfig-inifiles-perl 2.82-1 ii libdata-validate-domain-perl 0.10-1 ii libdata-validate-ip-perl 0.20-1 ii libdata-validate-uri-perl 0.06-1 ii libfile-slurp-perl.19-2 ii libfile-which-perl1.09-1 ii libterm-ui-perl 0.36-1 ii libtext-template-perl 1.45-2 ii openssh-client1:6.2p2-6 ii perl 5.18.1-4 ii perl-modules 5.18.1-4 Versions of packages xen-tools recommends: ii libexpect-perl 1.21-1 ii rinse2.0.1-1 ii xen-hypervisor-4.1-amd64 [xen-hypervisor-amd64] 4.1.4-4 ii xen-utils-4.1 [xen-utils]4.1.4-4 Versions of packages xen-tools suggests: pn btrfs-toolsnone pn cfengine2 none ii reiserfsprogs 1:3.6.21-1 ii xfsprogs 3.1.9 -- no debconf information + OSSTEST_JOB=test-armhf-armhf-xl + export OSSTEST_JOB + ./ts-debian-install 2013-12-18 02:23:41 Z starting 22457.test-armhf-armhf-xl 2013-12-18 02:23:41 Z setting all_hostflags=arch-armhf,arch-xen-armhf,suite-wheezy,purpose-test 2013-12-18 02:23:41 Z setting arch=armhf 2013-12-18 02:23:41 Z setting buildjob=build-armhf 2013-12-18 02:23:41 Z setting console=hvc0 2013-12-18 02:23:41 Z setting debian_arch=armhf 2013-12-18 02:23:41 Z setting debian_kernkind=pvops 2013-12-18 02:23:41 Z setting host=marilith-n5 2013-12-18 02:23:41 Z setting host_suite=wheezy 2013-12-18 02:23:41 Z setting kernbuildjob=build-armhf-pvops 2013-12-18 02:23:41 Z setting kernkind=pvops 2013-12-18 02:23:41 Z setting toolstack=xl 2013-12-18 02:23:41 Z setting xenbuildjob=build-armhf 2013-12-18 02:23:41 Z setting xen_kernel_path=/boot/vmlinuz-3.12.0+ 2013-12-18 02:23:41 Z setting xen_kernel_ver=3.12.0+ 2013-12-18 02:23:41 Z serial method xenuse marilith-n5: 2013-12-18 02:23:41 Z serial method http marilith-n5: http://conserver.uk.xensource.com/consoles/ marilith-n5.txt*
Bug#732457: ceilometer-common: unowned directories after purge: /var/lib/ceilometer/{, cache/}, /var/log/ceilometer/
Package: ceilometer-common Version: 2013.2.1-1 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned directories on the system after purge, which is a violation of policy 6.8: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. The maintainer scripts create (and later remove) a file in that directory. Manual directory removal may be not appropriate as this directory is shared between several packages. If the package would ship this as an empty directory, dpkg would take care of the creation and removal (if it's empty). From the attached log (scroll to the bottom...): 2m5.0s ERROR: FAIL: Package purging left files on system: /var/lib/ceilometer/ not owned /var/lib/ceilometer/cache/ not owned /var/log/ceilometer/ not owned cheers, Andreas ceilometer-common_2013.2.1-1.log.gz Description: GNU Zip compressed data
Bug#732281: [Debian-med-packaging] Bug#732281: soapdenovo: Please update package information or drop this package
On 12/16/2013 11:25 AM, Andreas Tille wrote: Package: soapdenovo Severity: normal Hi Olivier, I stumbled upon soapdenovo since on one hand there seems to be a watch file that for whatever reason reports a new version if you look at http://blends.debian.org/med/tasks/bio#soapdenovo (even if I have no idea why since the d/watch in SVN reports nothing). On the other hand I realised that soapdenovo2 was missing from our tasks files (and was just added). When I inspected the homepage[1] I stumbled upon the information Please note that the old version of SOAPdenovo is out of maintainance now, if you want to achieve the old version of SOAPdenovo, please contact us (xi...@genomics.cn or bgi-s...@googlegroups.com). For me this does not necessarily mean that we should drop the package if there might be some users (popcon tells only one) but if we should keep this package we should definitely update the information in the package description + README.Debian. hi, we should not drop it. Many users may still use it at least for scripts compatibility. I switched to soapdenovo2 package due to those incompatibilities. I will however update the description and README Olivier Kind regards Andreas. [1] http://soap.genomics.org.cn/soapdenovo.html#down2 -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732222: Bug#732222: imagej: does not see present JAVA
On 12/16/2013 01:47 PM, Martin Weiser wrote: Andreas Tille píše v Po 16. 12. 2013 v 13:33 +0100: Hi Martin, On Mon, Dec 16, 2013 at 12:55:33PM +0100, Martin Weiser wrote: Dear friends, maybe there is something else involved (should I open another bug?), as Olivier's workaround helps only partially: me@here:~$ export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-i386 me@here:~$ echo $JAVA_HOME /usr/lib/jvm/java-1.7.0-openjdk-i386 me@here:~$ imagej Open other images in this ImageJ panel as follows: imagej -p 1 image1 [image2 ... imageN] Exception in thread main java.awt.HeadlessException at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:207) at java.awt.Window.init(Window.java:535) at java.awt.Frame.init(Frame.java:420) at ij.ImageJ.init(ImageJ.java:129) at ij.ImageJ.main(ImageJ.java:597) Any advice? Once again: thank you for your patience. You may be running an application that requires a graphical mode in non graphical environment. There is an option in java to run in headless mode (when no graphics are available): java -Djava.awt.headless=true Please update the imagej script to try this. this however only works when original code manage this correctly. Olivier Please try the script: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/imagej/trunk/debian/imagej.sh?view=markup which is the usual wrapper around imagej with a patch that should properly select the JAVA_HOME. It would be nice to know whether this would help or not. Kind regards Andreas. Hi Andreas, unfortunately, the same behaviour occurs: louskacek@zouzel:~$ chmod 777 imagej.sh louskacek@zouzel:~$ ./imagej.sh Open other images in this ImageJ panel as follows: imagej -p 1 image1 [image2 ... imageN] Exception in thread main java.awt.HeadlessException at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:207) at java.awt.Window.init(Window.java:535) at java.awt.Frame.init(Frame.java:420) at ij.ImageJ.init(ImageJ.java:129) at ij.ImageJ.main(ImageJ.java:597) Any advice? Best, Martin. -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#732458: powertop bug
Subject: powertop: Powertop crashes on battery Package: powertop Version: 2.0-0.3 Severity: important Dear Maintainer, * What led up to the situation? When I launch sudo powertop or powertop (as root), it crashes with this output: terminate called after throwing an instance of 'std::ios_base::failure' what(): basic_filebuf::underflow error reading the file * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? Powertop is useless when laptop is on battery * What outcome did you expect instead? I read that next versions of powertop fix this bug, but I think that the aim of Debian Stable is to work well without upgrading packages -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-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 powertop depends on: ii libc6 2.13-38 ii libgcc1 1:4.7.2-5 ii libncursesw5 5.9-10 ii libnl-3-200 3.2.7-4 ii libnl-genl-3-200 3.2.7-4 ii libpci3 1:3.1.9-6 ii libstdc++6 4.7.2-5 ii libtinfo5 5.9-10 ii zlib1g 1:1.2.7.dfsg-13 powertop recommends no packages. Versions of packages powertop suggests: ii cpufrequtils 008-1 ii laptop-mode-tools 1.61-2 -- no debconf information
Bug#732459: php-apc: unowned files after purge (policy 6.8, 10.8): /usr/share/doc/php-apc/php5-apcu
Package: php-apc Version: 4.0.2-2 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8 (or 10.8): http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. From the attached log (scroll to the bottom...): 0m32.8s ERROR: FAIL: Package purging left files on system: /usr/share/doc/php-apc/owned by: php-apc /usr/share/doc/php-apc/php5-apcu - php5-apcu not owned This looks like like a buggy directory-to-symlink conversion. Please take a look at dpkg-maintscript-helper dir_to_symlink (available since dpkg 1.17.5) for a proper solution. cheers, Andreas php-apc_4.0.2-2.log.gz Description: GNU Zip compressed data
Bug#732460: imvirt: Unexpected output from lspci parsing bug
Package: imvirt Version: 0.9.6-1 Severity: normal Dear Maintainer, I'm getting the following error when running imvirt on one of our servers: host ~ # imvirt Unexpected output from lspci: 00:1a.0 USB controller Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 -r05 -p20 Intel Corporation Apple MacBookPro8,2 [Core i7, 15\, 2011] Unexpected output from lspci: 00:1d.0 USB controller Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 -r05 -p20 Intel Corporation Apple MacBookPro8,2 [Core i7, 15\, 2011] Unexpected output from lspci: 00:1f.3 SMBus Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller -r05 Intel Corporation Apple MacBookPro8,2 [Core i7, 15\, 2011] Physical Apparently the regex in /usr/share/perl5/ImVirt/Utils/pcidevs.pm doesn't cope with the quoted in Apple MacBookPro8,2 [Core i7, 15\, 2011] in the lspci output: host ~ # lspci -m 00:00.0 Host bridge Intel Corporation Xeon E3-1200 Processor Family DRAM Controller -r09 Intel Corporation Device 2010 00:19.0 Ethernet controller Intel Corporation 82579LM Gigabit Network Connection -r05 Intel Corporation Device 3578 00:1a.0 USB controller Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 -r05 -p20 Intel Corporation Apple MacBookPro8,2 [Core i7, 15\, 2011] 00:1c.0 PCI bridge Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 -rb5 00:1c.4 PCI bridge Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 -rb5 00:1c.5 PCI bridge Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 -rb5 00:1d.0 USB controller Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 -r05 -p20 Intel Corporation Apple MacBookPro8,2 [Core i7, 15\, 2011] 00:1e.0 PCI bridge Intel Corporation 82801 PCI Bridge -ra5 -p01 00:1f.0 ISA bridge Intel Corporation C204 Chipset Family LPC Controller -r05 Intel Corporation Device 7270 00:1f.2 SATA controller Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller -r05 -p01 Intel Corporation Device 7270 00:1f.3 SMBus Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller -r05 Intel Corporation Apple MacBookPro8,2 [Core i7, 15\, 2011] 02:00.0 Ethernet controller Intel Corporation 82574L Gigabit Network Connection Intel Corporation Device 3578 03:00.0 VGA compatible controller Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) -r07 Intel Corporation Device 0102 (The server is not a MacBook btw, but that's probably a different bug report for the pciutils package :) -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages imvirt depends on: ii dpkg1.16.12 ii libimvirt-perl 0.9.6-1 ii perl5.14.2-21+deb7u1 imvirt recommends no packages. imvirt 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#710275: postgresql-9.1: Needs restart on libc upgrade
Control: reassign -1 postgresql-9.3 Control: severity -1 normal Re: Matthew Gabeler-Lee 2013-05-29 20130529141948.11588.33904.report...@cheetah.fastcat.org Package: postgresql-9.1 Version: 9.1.9-1 Severity: important When upgrading libc6, it appears that postgresql is one of the services that needs to be restarted for authentication to work properly. After updating libc6 from 2.13 to 2.17 (testing), I was unable to authenticate to my databases until I restarted postgresql. After a restart, all was fine. Hi Matthew, a late followup here: which kind of authentication do you have configured there? I'd assume the problem only affects pam. (I'm downgrading the bug to normal because pam is not the default configuration.) Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732393: tinc: strange memory error reported to syslog
[Guus Sliepen] Ok, that could be the result of tinc running out of memory. Right. Ah, it might be related to bug #690685: when running as a non-root user, the process limits might prevent tinc from allocating all the locked memory it needs. There is a patch available as well. Could you try it out and see if that helps? It will not help, as I start tinc using ifup based on setup in /etc/network/interfaces, and not using /etc/init.d/tinc. I added 'ulimit -l 1024' in /etc/default/tinc instead to see if it help. Not quite sure what is a good value. Will try unlimited if 1024 is too small. :) -- Vennlig hilsen Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732461: needrestart: fails to install, remove, and install again
Package: needrestart Version: 0.4-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install, remove (but not purge), and install again. Before the second installation the package is in config-files-remaining state. The configuration is remaining from the last version that was successfully configured - which is the same version that is going to be installed again. Like a plain failure on initial install this makes the package too buggy for a release, thus the severity. From the attached log (scroll to the bottom...): 0m22.3s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpwc6DQn', 'apt-get', '-y', 'install', 'needrestart=0.4-1'] 0m22.8s DUMP: Reading package lists... Building dependency tree... Reading state information... The following NEW packages will be installed: needrestart debconf: delaying package configuration, since apt-utils is not installed 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/10.9 kB of archives. After this operation, 124 kB of additional disk space will be used. /bin/bash: /usr/lib/needrestart/dpkg-status: No such file or directory Selecting previously unselected package needrestart. (Reading database ... 8301 files and directories currently installed.) Preparing to unpack .../needrestart_0.4-1_all.deb ... E: Sub-process /usr/bin/dpkg exited unexpectedly 0m22.8s ERROR: Command failed (status=100): ['chroot', '/tmp/piupartss/tmpwc6DQn', 'apt-get', '-y', 'install', 'needrestart=0.4-1'] cheers, Andreas needrestart_0.4-1.log.gz Description: GNU Zip compressed data
Bug#732387: [Openstack-devel] Bug#732387: Adds user ceilometer to group nova and libvirt on every upgrade
Thomas Goirand z...@debian.org writes: Hi Gaudenz, First of all, thanks for taking the time to send bug reports. I'm very happy to see that OpenStack gets more and more traction within the Debian community. On 12/17/2013 10:20 PM, Gaudenz Steinlin wrote: But this is actually not respecting local admin configurations. If an administrator decides (for whatever reason) that the ceilometer user should not be part of these groups Well, if an admin decides this, then Ceilometer will not work anymore. That admin might as well just remove ceilometer-common... Well, it won't work anymore without configuration changes to other packages sure. But it's very well possible to configure libvirt to use another group too. this decision is reverted on every package upgrade. This violates Debian Policy section 10.7.3 which states that local modifications must be preserved. The user should only be added to these groups on first install. On upgrades the group membership should not be changed. The section 10.7.3 that you mention is under the chapter Configuration files and has nothing to do with managing Unix user and groups. As these changes ultimately end up in /etc/group I would say that this policy section applies. It does not matter if you change the file directly or with a tool. But I agree that the question if users and group are configuration is a bit a grey area. As you can't lock the user database anyway this won't prevent (mis)configuration either. IMO you should at least add a check like the following before adding the group: id -Gn ceilometer | grep -qE (^| )nova( |$) || adduser ceilometer nova id -Gn ceilometer | grep -qE (^| )libvirt( |$) || adduser ceilometer libvirt This is only a quick example to show the intention. Feel free to improve it. Also, removing the unconditionality of the unix user/group management would make this particular maintainer script not idempotent anymore, which is a path that is very dangerous to take. I don't understand what you mean here. Indempotence means that you can call the postinst several times with the SAME arguments and this will not have any undesired side effects (like creating something on every call that is only needed once). I don't see how this is affected by the proposal to only add the user to these groups on fresh installs as the arguments to the postinst differ from fresh installs to upgrades. If the postinst script fails, it will be called with the same arguments on retries, so a condition checking for a fresh install will still execute. Also, I fail to see where else in the policy manual it is written that a package cannot impose a particular user to be inside a specific group. Please point to the correct policy manual section if you still think this is wrong. I agree that we are lacking clear policy on user management in maintainer scripts. This is a problem as every package does his own thing. But nothing we can fix in ceilometer. Whatever your reply will be, I don't think this bug deserves a severity serious (to quote the release team: not all policy violation are RC bugs), so I'm downgrading the severity. I'm fine with that. I don't think the severity matters much as long as bugs get fixed. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ pgp6D6Si8GfOK.pgp Description: PGP signature
Bug#732462: munin-node: unowned directories after purge: /var/lib/munin-node/plugin-state/{munin, nobody, root}/
Package: munin-node Version: 2.0.19-2 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned directories on the system after purge, which is a violation of policy 6.8: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. The maintainer scripts create (and later remove) a file in that directory. Manual directory removal may be not appropriate as this directory is shared between several packages. If the package would ship this as an empty directory, dpkg would take care of the creation and removal (if it's empty). From the attached log (scroll to the bottom...): 0m32.7s ERROR: FAIL: Package purging left files on system: /var/lib/munin-node/plugin-state/munin/not owned /var/lib/munin-node/plugin-state/nobody/ not owned /var/lib/munin-node/plugin-state/root/ not owned cheers, Andreas munin-node_2.0.19-2.log.gz Description: GNU Zip compressed data
Bug#731357: opu: package librsvg/2.26.3-2
block 731357 by 732144 reassign 732144 src:librsvg 2.26.3-1+deb6u1 severity 732144 grave tags 732144 confirmed thanks Hi, I'm afraid that a regression has been discovered in the patch for oldstable (i.e. wheezy is not affected). Some applications using librsvg or its command line interface might get an error from rsvg when trying to open a file without passing it as a URI, or when the svg file tries to include a file without a URI. I'm already working on a fix, but there's still one case (relative paths) that I haven't managed to find a solution for. Will keep you posted. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732393: tinc: strange memory error reported to syslog
On Wed, Dec 18, 2013 at 10:50:15AM +0100, Petter Reinholdtsen wrote: Ah, it might be related to bug #690685: when running as a non-root user, the process limits might prevent tinc from allocating all the locked memory it needs. There is a patch available as well. Could you try it out and see if that helps? It will not help, as I start tinc using ifup based on setup in /etc/network/interfaces, and not using /etc/init.d/tinc. I added 'ulimit -l 1024' in /etc/default/tinc instead to see if it help. Oh, you're right, the patch doesn't cover ifup. Putting the ulimit command in /etc/default/tinc should work. The package in experimental does it right though :) -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Bug#732463: python-virtualenv: virtualenv --system-site-packages fails on easy_install /usr/share/python-virtualenv/pip-1.1.debian1.tar.gz
Package: python-virtualenv
Version: 1.7.1.2-2
Severity: normal
I've tried installing a virtualenv with --system-site-packages on wheezy, and
got :
$ virtualenv -v --system-site-packages env
Creating env/lib/python2.7
Symlinking Python bootstrap modules
Symlinking env/lib/python2.7/lib-dynload
Symlinking env/lib/python2.7/os.py
Ignoring built-in bootstrap module: posix
Symlinking env/lib/python2.7/posixpath.py
Cannot import bootstrap module: nt
Symlinking env/lib/python2.7/ntpath.py
Symlinking env/lib/python2.7/genericpath.py
Symlinking env/lib/python2.7/fnmatch.py
Symlinking env/lib/python2.7/locale.py
Symlinking env/lib/python2.7/encodings
Symlinking env/lib/python2.7/codecs.py
Symlinking env/lib/python2.7/stat.py
Symlinking env/lib/python2.7/UserDict.py
Symlinking env/lib/python2.7/copy_reg.py
Symlinking env/lib/python2.7/types.py
Symlinking env/lib/python2.7/re.py
Symlinking env/lib/python2.7/sre.py
Symlinking env/lib/python2.7/sre_parse.py
Symlinking env/lib/python2.7/sre_constants.py
Symlinking env/lib/python2.7/sre_compile.py
Ignoring built-in bootstrap module: zlib
Symlinking env/lib/python2.7/warnings.py
Symlinking env/lib/python2.7/linecache.py
Symlinking env/lib/python2.7/_abcoll.py
Symlinking env/lib/python2.7/abc.py
Symlinking env/lib/python2.7/_weakrefset.py
Creating env/lib/python2.7/site-packages
Writing env/lib/python2.7/site.py
Writing env/lib/python2.7/orig-prefix.txt
Creating env/bin
New python executable in env/bin/python
Changed mode of env/bin/python to 0755
Testing executable with env/bin/python -c
import sys
prefix = sys.prefix
if sys.version_info[0] == 3:
prefix = prefix.encode('utf8')
if hasattr(sys.stdout, 'detach'):
sys.stdout = sys.stdout.detach()
elif hasattr(sys.stdout, 'buffer'):
sys.stdout = sys.stdout.buffer
sys.stdout.write(prefix)
Got sys.prefix result: u'/home/olivier/lambdageo/env'
Creating env/lib/python2.7/distutils
Writing env/lib/python2.7/distutils/__init__.py
Writing env/lib/python2.7/distutils/distutils.cfg
Using existing distribute egg:
/usr/share/python-virtualenv/distribute-0.6.24.tar.gz
Installing distribute.done.
Installing existing pip-1.1.debian1.tar.gz distribution:
/usr/share/python-virtualenv/pip-1.1.debian1.tar.gz
Installing pip...
Error [Errno 2] No such file or directory while executing command
/home/olivier/lambdageo/env/bin/easy_install
/usr/share/python-vi...p-1.1.debian1.tar.gz
...Installing pip...done.
Traceback (most recent call last):
File /usr/bin/virtualenv, line 3, in module
virtualenv.main()
File /usr/lib/python2.7/dist-packages/virtualenv.py, line 938, in main
never_download=options.never_download)
File /usr/lib/python2.7/dist-packages/virtualenv.py, line 1054, in
create_environment
install_pip(py_executable, search_dirs=search_dirs,
never_download=never_download)
File /usr/lib/python2.7/dist-packages/virtualenv.py, line 643, in
install_pip
filter_stdout=_filter_setup)
File /usr/lib/python2.7/dist-packages/virtualenv.py, line 976, in
call_subprocess
cwd=cwd, env=env)
File /usr/lib/python2.7/subprocess.py, line 709, in __init__
errread, errwrite)
File /usr/lib/python2.7/subprocess.py, line 1306, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
Apparently, there's no bin/easy_install in the venv :-/
Thanks in advance.
Best regards,
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641278: update-alternatives fails install of postgresql-client
Version: 9.1.5-2
David Tulloh [2011-09-12 17:12 +0700]:
update-alternatives: error: alternative link
/usr/share/man/man1/psql.1.gz is already managed by psql.
This was mostly fixed in
postgresql-9.1 (9.1.4-2) unstable; urgency=low
[...]
* debian/postgresql-9.1.preinst: Remove postmaster.1.gz alternative on
upgrades to this version, so that the postinst can rebuild it. This is
necessary to drop pg_basebackup.1.gz from the server alternatives group,
so that it can go into the client group.
and more completely in
postgresql-9.1 (9.1.5-2) unstable; urgency=low
[...]
* Fix upgrades from older 9.1 releases in stable Ubuntu -updates/-security
releasese. The strict 9.1.4-2~ check for moving pg_basebackup.1.gz is
not sufficient, as Ubuntu stables have newer upstream releases by now.
- debian/control: Move Breaks/Replaces: from static version to
${binary:Version}.
- debian/postgresql-9.1.preinst: Also fix the alternatives when upgrading
from a -0something version.
- (LP: #1043449)
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (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#732464: manpages-dev: mcheck(3) typo in compiler flag
Package: manpages-dev Version: 3.44-1 Severity: minor Hi, mcheck(3) reads: linking the program with -mcheck inserts an implicit Whereas it should read: linking the program with -lmcheck inserts an implicit Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732463: python-virtualenv: virtualenv --system-site-packages fails on easy_install /usr/share/python-virtualenv/pip-1.1.debian1.tar.gz
On Wed, Dec 18, 2013 at 11:00:36AM +0100, Olivier Berger wrote:
I've tried installing a virtualenv with --system-site-packages on wheezy, and
got :
It seems, for whatever reason, that there's a problem on :
$ env/bin/python /usr/bin/easy_install
/usr/share/python-virtualenv/pip-1.1.debian1.tar.gz
Traceback (most recent call last):
File /usr/bin/easy_install, line 9, in module
load_entry_point('distribute==0.6.24dev-r0', 'console_scripts',
'easy_install')()
File /usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py,
line 1931, in main
with_ei_usage(lambda:
File /usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py,
line 1912, in with_ei_usage
return f()
File /usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py,
line 1935, in lambda
distclass=DistributionWithoutHelpCommands, **kw
File /usr/lib/python2.7/distutils/core.py, line 152, in setup
dist.run_commands()
File /usr/lib/python2.7/distutils/dist.py, line 953, in run_commands
self.run_command(cmd)
File /usr/lib/python2.7/distutils/dist.py, line 971, in run_command
cmd_obj.ensure_finalized()
File /usr/lib/python2.7/distutils/cmd.py, line 109, in ensure_finalized
self.finalize_options()
File /usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py,
line 204, in finalize_options
prefix, exec_prefix = get_config_vars('prefix', 'exec_prefix')
File /home/olivier/lambdageo/env/lib/python2.7/distutils/__init__.py, line
88, in sysconfig_get_config_vars
real_vars = old_get_config_vars(*args)
File /usr/lib/python2.7/distutils/sysconfig.py, line 495, in get_config_vars
func()
File /usr/lib/python2.7/distutils/sysconfig.py, line 439, in _init_posix
from _sysconfigdata import build_time_vars
File /usr/lib/python2.7/_sysconfigdata.py, line 6, in module
from _sysconfigdata_nd import *
ImportError: No module named _sysconfigdata_nd
Apparently, this can be fixed (depending on the architecture) with something
like :
sudo ln -s plat-i386-linux-gnu/_sysconfigdata_nd.py
/usr/lib/python2.7/_sysconfigdata_nd.py
Then, starting over works :
olivier@vm1:~/lambdageo$ virtualenv --system-site-packages env
New python executable in env/bin/python
Installing
distribute.done.
Installing pip...done.
olivier@vm1:~/lambdageo$ . env/bin/activate
(env)olivier@vm1:~/lambdageo$
Hope this helps.
Best regards,
--
Olivier BERGER
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732462: [Packaging] Bug#732462: munin-node: unowned directories after purge: /var/lib/munin-node/plugin-state/{munin, nobody, root}/
Hi Andreas, thanks for the bug report, I've seen and am seeing these issues in the PTS before and after every upload :/ I'm quite pretty ashamed to serve as a bad piuparts example, but so am I about the 50 open bugs against munin... cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#732465: RM: ruby-tidy -- ROM; does not support ruby = 1.9
Package: ftp.debian.org Severity: normal Dear FTP masters, please remove ruby-tidy. This package does not support newer Ruby version than 1.8, which will be removed before jessie. This package does not have reverse dependencies. It used to be required to build ruby-bluecloth, but this has been fixed in unstable yesterday, and will be in two days in testing. Thanks, Cédric signature.asc Description: Digital signature
Bug#688226: still reproduceable
Hello, I'm still able to reproduce this problem. In 4 of 5 cases f-spot crashed while starting up, in one case it is able to start. This can also be reproduced using a fresh user, while starting it up the first times. It would be nice if someone could figure out what is wrong here, as this renders f-spot nearly useable (together with some random crashes while it is running). Greetings Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732466: Fwd: [dev] Fwd: php5-xdebug should be avoided in php-horde* packages
Package: php-horde-core Sending to bug tracker. -- Forwarded message -- From: Michael M Slusarz slus...@horde.org Date: 2013/12/16 Subject: Re: [dev] Fwd: php5-xdebug should be avoided in php-horde* packages To: d...@lists.horde.org Quoting Mathieu Parent math.par...@gmail.com: (Forwarding to the proper mailing lists). Hi Hans, This question should probably be asked upstream. I'm forwarding to them too: horde depends on Horde_Core which has optional dep on Horde_Test which depends on phpunit which depends on CodeCoverage which has optional dep on xdebug extension. This extension creates the below PHP fatal errors: -- Forwarded message -- From: Hans Dingemans hans.dingem...@tacticalops.nl Date: 2013/12/14 Subject: php5-xdebug should be avoided in php-horde* packages To: math.par...@gmail.com Hello, First of all thanks for your excellent work on the packaging of horde for Debain! I wanted to share something with you, in the hope others will profit from it in the long run; I ran into this error message, when using the autocomplete function in IMP in the To: field, on an extremely large (200 contacts) contactlist. PHP Fatal error: Maximum function nesting level of '100' reached, aborting! in /usr/share/php/Horde/Mail/Rfc822/List.php on line 382, referer: followed by a lot of other error messages. There is nothing wrong with the Horde code. It is known (and desired) to have this kind of recursion for this particular action. There's nothing to fix from the Horde side. (FWIW, 100 is an artifically low default value that is not useful for any kind of advanced PHP functionality.) Not to mention that xdebug should never be enabled on a production system in the first place. So the error listed above is entirely harmless. If you are running xdebug, you are both expecting fatal errors to be possibly thrown at some point and have implicitly accepted that fact. Also ActiveSync of one of my users, with extremely high number of folders to synchronize, generated similar error messages. The cause seems to be the xdebug extension, that limits the number of recursions to 100 in PHP. Well, not exactly. First: it can be easily configured to something else (and probably should - see above). Second: there is NO requirement that this particular setting must be active (it can be 0, for example). xdebug can exist and be active on a PHP server without function nesting checking being active. I really hope Debian doesn't install php5-xdebug with xdebug on/active by default. A developer should have to manually activate it when they need it, not the other way around. Simply purging php5-xdebug, and with it php-code-coverage, php-horde-test and phpunit solved the problem. To avoid people installing these modules in a production environment, would it perhaps be a good idea to exclude these packages from the apt-get install horde install list? Obviously, that can only be answered by a packager. But there is nothing wrong with Horde packages listing xdebug as a dependency, whether required or optional. But as mentioned above, seems like the more correct solution is to disable xdebug from being active on installation of that package. michael ___ Michael Slusarz [slus...@horde.org] -- dev mailing list Frequently Asked Questions: http://wiki.horde.org/FAQ To unsubscribe, mail: dev-unsubscr...@lists.horde.org -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732467: RM: elastix [armel armhf kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x parc ia64] -- ANAIS; Build only architectures amd64 and i386, following ITK 4.
Package: ftp.debian.org Severity: normal elastix (4.6-1) unstable; urgency=low . * New upstream version. * control: Build-depend on libinsighttoolkit4-dev (instead of ITK 3). * control(elastix): Build only architectures amd64 and i386, following ITK 4. [...] Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732468: dolphin: Show in groups ordered by tag stopped working
Package: dolphin Version: 4:4.11.3-1 Severity: normal Dear Maintainer, Doplhin had a great feature where you could view a folder in groups based on associated tags that were assigned to each file. It lead to a column based view were the title of each column was the tag name. This was an excellent feature to taxinomise different files based on other characteristics. This now has stopped working. I go to a folder which contains files associated with more than one tags, I set show in groups option and order by Tags and column view (middle icon). The outcome is a regular list of files not taking into account the show in groups or order by tags. The outcome should be a column based folder view with column title the tag name and the list of files associated with that tag. Thank you. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.11-2-686-pae (SMP w/2 CPU cores) Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dolphin depends on: ii kde-runtime 4:4.11.3-1 ii libc6 2.17-97 ii libgcc1 1:4.8.2-1 ii libkactivities6 4:4.11.3-1 ii libkcmutils44:4.11.3-2 ii libkdecore5 4:4.11.3-2 ii libkdeui5 4:4.11.3-2 ii libkfile4 4:4.11.3-2 ii libkio5 4:4.11.3-2 ii libknewstuff3-4 4:4.11.3-2 ii libkonq5abi14:4.11.3-1 ii libkparts4 4:4.11.3-2 ii libnepomukcore4 4:4.11.3-1 ii libnepomukwidgets4abi1 4:4.11.3-1 ii libphonon4 4:4.7.0.0-2 ii libplasma3 4:4.11.3-2 ii libqt4-dbus 4:4.8.5+git192-g085f851+dfsg-2 ii libqt4-xml 4:4.8.5+git192-g085f851+dfsg-2 ii libqtcore4 4:4.8.5+git192-g085f851+dfsg-2 ii libqtgui4 4:4.8.5+git192-g085f851+dfsg-2 ii libsolid4 4:4.11.3-2 ii libsoprano4 2.9.4+dfsg-1 ii libstdc++6 4.8.2-1 ii libxrender1 1:0.9.8-1 ii phonon 4:4.7.0.0-2 Versions of packages dolphin recommends: pn ruby none Versions of packages dolphin suggests: pn kdesdk-dolphin-plugins 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#726998: [debian-policy] any news ? Lintian implement some check now
On Tue, Dec 17, 2013 at 11:38:05PM +, bastien ROUCARIES wrote: any new of this ? Lintian 2.6.20 detect this kind of problem now. What is the name of the lintian tag ? Could you provide example of package affected ? Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote: Adrian == Adrian Bunk b...@stusta.de writes: Adrian Yes, it is speculation that other new features (or even Adrian bugfixes) might appear in the kernel and might become Adrian mandatory in systemd between jessie and jessie+1. Adrian But that is a risk, and it is a risk that is unique to the Adrian systemd option since none of the alternatives is Adrian Linux-only. [2] Adrian My whole point is not about kdbus specifically (which might Adrian even end up in the jessie kernel), but about that (IMHO Adrian substantial) risk. I'm confused, when I hear you say that this risk is unique to the systemd option and not shared by other options. I would understand that statement if we thought we could avoid systemd entirely. It sounds like we may be able to avoid systemd as pid 1 but systemd is very likely to play an important role in the Debian desktop storpy even if we adopt another pid 1. It seems like if systemd starts depending on a new kernel feature then it might well need that feature even when not running as pid 1. So, when evaluating the opportunity costs of this risk in the pid 1 debate it seems like there are two important mitigating circumstances: * The extent to which upstream will provide stability, reducing the risk * The extent to which we cannot avoid the risk even if we choose another pid 1, reducing the portion of the cost of this risk properly in-scope for this bug. Thanks for the explanation, and apologies to Josselin and Russ that I completely misread their point regarding udev: I was misreading that as referring to the headaches udev had caused in the past for Debian upgrades, not that the systemd udev might be the cause of future upgrade headaches. But I do not buy this We already switched to systemd as upstream of udev, so we also have swallow the rest of it: When not using systemd as pid 1, that risk would be confined to the parts of systemd Debian would be using (currently only udev). And since Ubuntu will also be in the no systemd and supports upgrades from 2 year old releases camp, chances are that there would be solutions available that Debian could use. As an example, if the systemd udev gets a hard dependency on a too recent kernel or on systemd internals, there might be a fork of udev that provides a standalone udev that is suitable for Ubuntu and Debian. ... At some level, we also need to be community players. Since upgrade stability is important to us, we should advocate for it in open-source projects that we depend on. On the flip side, if enough of the rest of the community after having carefully considered our arguments decides that our desire for stability is too expensive, perhaps we need to reconsider our position. I hope we don't need to do that, but sometimes when enough of the rest of the world disagrees with you, you need to move on. That point you bring up is semi-orthogonal to the upgrade decision, but it also brings up two important points that have to be considered: 1. What is the governance model of the systemd community? This might be a bit polemic, but I'd fear that your enough of the rest of the community after having carefully considered our arguments decides might end up being the same as if Lennart decides it does not match his vision of how things should work. This is a real issue since systemd is attempting to absorb a lot of essential Linux functionality, giving whoever makes the decisions in systemd a lot of power over policies affecting all distributions using systemd. And 2. Does anyone have a complete overview of what Debian policies might have to be changed now or possibly at some later time as a result of making systemd pid 1? systemd does not support non-Linux kernels [1], and realistically using systemd as pid 1 in jessie will kill all non-Linux ports of Debian. [2] systemd upstream only reluctantly supports the option to have a separate /usr (as currently mandated by Debian policy), and I would not be surprised if that gets dropped any time if it becomes an obstacle for development of any part of systemd. And now you bring up the point that Debian should reconsider the lenght of it's release cycles if systemd upstream decides to not support upgrades between distribution releases as far apart as Debian's. [3] There are likely more areas where Debian would have to adapt if using systemd. The more I think about it, the more I wish the TC would decide: * jessie will continue to use sysvinit, and the TC will re-evaluate the situation after the release of jessie Rationale: - as time passes, the kernel-systemd interface will become more stable [4], reducing potential upgrade problems and - the full consequences of a switch to systemd on various areas of Debian will become more clear cu Adrian [1] which is not an unreasonable design decision
Bug#732493: samba-dbg: no debug symbols present
Package: samba-dbg Version: 2:4.0.13+dfsg-1 Severity: serious As you can see here, the samba-dbg package contains no debug symbols and is therefore not useful at all. It should either be removed or fixed. http://packages.debian.org/jessie/amd64/samba-dbg/filelist -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#732494: somewhat imprecise license information in debian/copyright
Package: procps Severity: minor User: alteh...@debian.org thanks Dear Maintainer, the debian/copyright file contains references to GPL-2 and LGPL-2. However the license of most of the source files is GPL2+ and LPGL2.1+. Can you please adapt debian/copyright accordingly? Thanks! Thorsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732495: Please update Suggests: for postgresql
Package: dotlrn Version: 2.5.0+dfsg-9 Severity: normal User: pkg-postgresql-pub...@lists.alioth.debian.org Usertags: migration-93 Package: dotlrn Suggests: postgresql-8.4, daemontools, daemontools-run 8.4 is long gone in sid, can you update that for the current PostgreSQL version 9.3? Ideally you would just Suggests: postgresql, so you don't have to update the field again in the future. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#732496: override: libclthreads-dev:libdevel/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above clthreads packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and as a library it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732499: override: libclxclient-dev:libdevel/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above clxclient packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and as a library it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732500: override: libclxclient3:libs/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above clxclient packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and as a library it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732501: override: librubberband-dev:libdevel/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above rubberband packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and as a library it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732497: Please update Depends/Suggests: for postgresql
Package: request-tracker4 Version: 4.0.17-2 Severity: normal User: pkg-postgresql-pub...@lists.alioth.debian.org Usertags: migration-93 Package: rt4-db-postgresql Depends: debconf (= 0.5) | debconf-2.0, libdbd-pg-perl (= 1.41), postgresql-client-8.3 | postgresql-client (= 8.1) Suggests: postgresql-8.3 | postgresql (= 8.1) 8.3 has been gone since squeeze, please upgrade to the current PostgreSQL version 9.3. As there are meta packages postgresql-client and postgresql, you can just Depends/Suggests on these without an alternative on a concrete version, so you don't have to update the fields in the future. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#732498: override: libclthreads2:libs/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above clthreads packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and as a library it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732502: override: librubberband2:libs/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above rubberband packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and as a library it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732503: override: rubberband-cli:sound/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above rubberband packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732504: override: rubberband-ladspa:sound/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above rubberband packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732505: override: libvamp-sdk2:libs/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above vamp-plugin-sdk packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and as a library it might want to be used by other optional packages in the future. There is a mismatch between the section/priority indicated in the current deb package (sound/optional) and the requested override (libs/optional). The maintainers have been informed and the next time the package gets uploaded, the section/priority will be fixed. In the meantime it would be great if you could fix the override. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732506: override: vamp-examples:sound/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above vamp-plugin-sdk packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732507: Update Suggests: postgresql
Package: knowledgeroot Version: 0.9.9.5-6 Severity: normal User: pkg-postgresql-pub...@lists.alioth.debian.org Usertags: migration-93 Package: knowledgeroot Suggests: mysql-server | postgresql-8.2 | postgresql-8.1 8.2 and 8.1 are gone for ages, please update that to just postgresql. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#721298: Boinc Client Idle Detection Progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Well, it certainly took longer than a weekend :) But winter break is here and I can now spend some time hacking away at this. I've had some progress debugging the problem. I'm still working on it, but it looks like there is a tty sitting somewhere that is trigging the user activity detection. I'm working on getting it to report what tty precisely is the culprit. Just thought I'd update with some progress on this bug report. Cheers, Preston -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsY7uAAoJEM8h7WmSAmadQzIIALayTdej/KI/tpcYxWUFhIVC 2LMcBorhajoUyxq+njU22MFIc4P7FcX67tob/xyZ5G2U8a5vuEPRyzSdI2s4OztX nx+ZH34mVBGW8ODkjPrwXPawD2jkPev9RQUGJxqB9WAwoOcLbMCvXXAcr4lFNFy3 BvaxMwVDq5YXpdbvtraKWNvuXXOJGWttWSZly9Drd1y9RnO5LDg2E4epy88lTcse kuQayrT35kndrj7aC11ugsg/hYg9pS+XOqjQxksoPMOQpEW8VicUJHs7PNsiHPyz JzFSlU0FF9jkaA2tyRJWjsQbKWOsoV+67phu5UB5slCwyzvYk82GFdOPBbEvlGI= =Sctj -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#727027: clamav: new upsteam version
Hi there, Please could I have an update to the current status of ClamAV 0.98 which is still not available anywhere as a Debian package. Since this is an update to the actual AV engine I would have hoped packaging this would have been deemed important. Steve -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732508: Add php5-pgsql as dependency to owncloud-pgsql
Package: owncloud-pgsql Severity: minor Version: 5.0.13+dfsg-2 Dear maintainers, the owncloud-pgsql bin:packages de facto depends on php5-pgsql, so it may probably be good to add it to the package's Depends: field. Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgp23yo9zwu12.pgp Description: Digitale PGP-Signatur
Bug#732509: mksh: missing octal support in arithmetic expressions
Package: mksh Version: 46-2 Severity: normal Unlike ksh (and sh), mksh doesn't support octal in arithmetic expressions: xvii% sh -c 'echo $((010))' 8 xvii% ksh93 -c 'echo $((010))' 8 xvii% mksh -c 'echo $((010))' 10 I hate this feature because of the ambiguity with decimal, but mksh intends to behave like ksh93. So, it should support octal in arithmetic expressions. Note: it is OK for hex support: xvii% ksh93 -c 'echo $((0x10))' 16 xvii% mksh -c 'echo $((0x10))' 16 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mksh depends on: ii libc62.17-97 ii libgcc1 1:4.8.2-10 mksh recommends no packages. Versions of packages mksh suggests: ii ed 1.9-2 -- 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#732510: Please upgrade to PostgreSQL 9.3
Package: postgresql-filedump Version: 9.1.0-1 Severity: normal User: pkg-postgresql-pub...@lists.alioth.debian.org Usertags: migration-93 Hi, for jessie, postgresql-9.1 will be replaced by postgresql-9.3, rendering postgresql-filedump 9.1 useless there. Please consider updating the package. (I've seen there's only pgfiledump 9.2.0 on pgfoundry, maybe there's more on github...) Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#727708: systemd jessie - jessie+1 upgrade problems
Hi Adrian, Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit : That point you bring up is semi-orthogonal to the upgrade decision, but it also brings up two important points that have to be considered: 1. What is the governance model of the systemd community? This might be a bit polemic, but I'd fear that your enough of the rest of the community after having carefully considered our arguments decides might end up being the same as if Lennart decides it does not match his vision of how things should work. This is a red herring that has been recurrently agitated, on the basis of the PulseAudio experience, but so far it has never proven to have any basis in reality. Just because Lennart is a developer in both projects, doesn’t mean they have the same governance model. Systemd’s development is driven by the needs of its users. It has even incorporated a lot of Debian’s needs, despite our choice so far to delay its inclusion. It has used some of Debian’s good practices (e.g. /etc/hostname or /etc/timezone) as a basis for standardization across other distributions. This is a real issue since systemd is attempting to absorb a lot of essential Linux functionality, giving whoever makes the decisions in systemd a lot of power over policies affecting all distributions using systemd. Things work the other way round. Debian will have more weight in the future of systemd if we adopt it. It is unreasonable to ask an upstream project to conform to your policies if you don’t even use it. We need to play with the community: embrace systemd, and use that weight in the decisions affecting its future. Let’s consider the kdbus example in this light. If Debian is a major systemd player, it is more likely that upstream will support a fallback to the old dbus-daemon until a kdbus-enabled kernel makes it to a stable Debian release, or at least makes it easier for us to maintain that fallback. If Debian does not pick systemd, what is the point for upstream in making their software more complex for the benefit of nobody? Maybe it will not work. Maybe the cost for upstream will be too high regardless. I might have to remind you that the sarge→etch upgrade had a locked-in upgrade of udev and the kernel. The world did not crumble, and we didn’t abandon our policies just because we had to make an exception. (Actually this upgrade was much smoother than the python shit in squeeze→wheezy.) We made it work that time, and if, despite our efforts, we have to make another exception, we will make it work again. Leaving out important features until a hypothetical date, just because we fear our own skills and ability to provide smooth upgrades, doesn’t sound like a great plan to me. systemd upstream only reluctantly supports the option to have a separate /usr (as currently mandated by Debian policy), and I would not be surprised if that gets dropped any time if it becomes an obstacle for development of any part of systemd. This is another red herring. The Debian code to support a split /usr by mounting it from the initrd is simple, and not likely to be broken by any new developments. I see much irony in seeing people fear for non-Linux ports, for one of which we have maintained easy patches for years allowing for a merged /usr, and at the same time argue that maintaining a split /usr for Linux will be hard. And now you bring up the point that Debian should reconsider the lenght of it's release cycles if systemd upstream decides to not support upgrades between distribution releases as far apart as Debian's. [3] Well, of course we should reconsider the length of our release cycle (and make it 3 years like major OS players do), but this is irrelevant to the choice of an init system. The more I think about it, the more I wish the TC would decide: * jessie will continue to use sysvinit, and the TC will re-evaluate the situation after the release of jessie This option does not look realistic to me. At least the upstart proponents have outlined a strategy to keep software depending on systemd interfaces working in jessie. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732511: Please upgrade Suggests: to postgresql-9.3-plr
Package: gnumed-server Version: 19.4-1 Severity: normal User: pkg-postgresql-pub...@lists.alioth.debian.org Usertags: migration-93 Package: gnumed-server Suggests: postgresql-contrib, postgresql-plr | postgresql-9.1-plr, bacula-console, postgresql-filedump In jessie, PostgreSQL 9.3 will replace 9.1, so please upgrade the Suggests to postgresql-9.3-plr. Also, postgresql-filedump should be removed there, as it is a super-low-level debugging tool, I can't imagine anyone using gnumed-server would actually use it. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#732462: munin-node: unowned directories after purge: /var/lib/munin-node/plugin-state/{munin, nobody, root}/
Hi Andreas, hi Holger, hi *! Am Wed, 18 Dec 2013 10:53:02 +0100 schrieb Andreas Beckmann a...@debian.org: Package: munin-node Version: 2.0.19-2 Severity: important User: debian...@lists.debian.org Usertags: piuparts during a test with piuparts I noticed your package left unowned directories on the system after purge, which is a violation of policy 6.8: ... From the attached log (scroll to the bottom...): 0m32.7s ERROR: FAIL: Package purging left files on system: /var/lib/munin-node/plugin-state/munin/ not owned /var/lib/munin-node/plugin-state/nobody/ not owned /var/lib/munin-node/plugin-state/root/ not owned The directory /var/lib/munin-node/ is created (and removed at purge) by the package munin-plugins-core. So maybe the path name is a little misleading... Best wishes, Matthias signature.asc Description: PGP signature
Bug#732514: [PATCH] fixes for Radeon KMS on kFreeBSD
Package: xserver-xorg-video-ati
Version: 7.2.0-1
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
Please consider this set of fixes for KMS support on kFreeBSD:
- Load radeonkms module instead of radeon.
- Replace linux-firmware with kfreebsd-downloader (non-free firmware).
Thanks
--
Robert Millan
diff -ur xserver-xorg-video-ati-7.2.0/debian/control xserver-xorg-video-ati-7.2.0.new/debian/control
--- xserver-xorg-video-ati-7.2.0/debian/control 2013-12-16 22:40:22.0 +0100
+++ xserver-xorg-video-ati-7.2.0.new/debian/control 2013-12-16 22:54:49.294891823 +0100
@@ -79,7 +79,7 @@
${misc:Depends},
${xviddriver:Depends}
Provides: ${xviddriver:Provides}
-Suggests: firmware-linux
+Suggests: firmware-linux [linux-any], kfreebsd-downloader (= 10) [kfreebsd-any] | kfreebsd-downloader-10 [kfreebsd-any]
Description: X.Org X server -- AMD/ATI Radeon display driver
This package provides the 'radeon' driver for the AMD/ATI cards. The
following chips should be supported: R100, RV100, RS100, RV200, RS200,
diff -ur xserver-xorg-video-ati-7.2.0/src/radeon_kms.c xserver-xorg-video-ati-7.2.0.new/src/radeon_kms.c
--- xserver-xorg-video-ati-7.2.0/src/radeon_kms.c 2013-08-07 10:44:09.0 +0200
+++ xserver-xorg-video-ati-7.2.0.new/src/radeon_kms.c 2013-12-16 23:09:20.300888549 +0100
@@ -606,7 +606,13 @@
dev-domain, dev-bus, dev-dev, dev-func);
#endif
-info-dri2.drm_fd = drmOpen(radeon, busid);
+info-dri2.drm_fd = drmOpen(
+#ifdef __FreeBSD_kernel__
+radeonkms,
+#else
+radeon,
+#endif
+busid);
if (info-dri2.drm_fd == -1) {
xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
Bug#732512: Upgrade to postgresql 9.3
Package: slurm-llnl Version: 2.6.4-1 Severity: serious User: pkg-postgresql-pub...@lists.alioth.debian.org Usertags: migration-93 Package: slurm-llnl Build-Depends: debhelper (= 7.0.0), autotools-dev, libmunge-dev, libncurses5-dev, libssl-dev, po-debconf, python, libglade2-dev, libgtk2.0-dev, libmysqlclient-dev, postgresql-server-dev-9.1, libpam0g-dev, libperl-dev, chrpath postgresql-server-dev-9.1 is being removed from sid, please upgrade to postgresql-server-dev-9.3. (Do you really need to B-D on -server-dev, are you building a server module? For client apps talking to the database, libpq-dev would be the correct dependency.) Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#732513: chromium-browser: Chromium browser is not starting
Package: chromium-browser Version: 31.0.1650.63-1~deb7u1 Severity: normal Tags: patch Dear Maintainer, When you start the browser via terminal appears as follows: sistemaids@debian:~$ chromium-browser [30782:30782:1218/102412:FATAL:zygote_host_impl_linux.cc(198)] Check failed: pid_ 0. Did not find zygote process (using sandbox binary /usr/lib/chromium /chrome-sandbox) Abortado -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=pt_BR.utf8, LC_CTYPE=pt_BR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages chromium-browser depends on: ii chromium 31.0.1650.63-1~deb7u1 chromium-browser recommends no packages. chromium-browser suggests no packages. -- no debconf information attachment: Captura de tela de 2013-12-18 10:24:37.png
Bug#696204: acct: Build fixes for acct: libtool, gnulib C11, cross-building, hardening
On Mon, Dec 17, 2012 at 07:40:00PM -0800, Steve Langasek wrote:
- autoreconf
+ autoreconf -f
You actually need to use autoreconf -fi, otherwise you get things like
this, seen in the Ubuntu ppc64el bootstrap:
configure.ac:16: error: required file './compile' not found
configure.ac:16: 'automake --add-missing' can install 'compile'
autoreconf: automake failed with exit status: 1
But it's better to just use dh_autoreconf, which is more complete than
most of the previous ad-hoc methods. I applied this on top of Steve and
Dimitri's changes, which hopefully you can massage into the Debian
package if and when you apply all this:
diff -Nru acct-6.5.5/debian/changelog acct-6.5.5/debian/changelog
--- acct-6.5.5/debian/changelog 2013-09-19 16:25:28.0 +0100
+++ acct-6.5.5/debian/changelog 2013-12-18 12:19:44.0 +
@@ -1,3 +1,9 @@
+acct (6.5.5-1ubuntu5) trusty; urgency=medium
+
+ * Use dh-autoreconf rather than various other less-complete methods.
+
+ -- Colin Watson cjwat...@ubuntu.com Wed, 18 Dec 2013 12:19:43 +
+
acct (6.5.5-1ubuntu4) saucy; urgency=low
* Fix FTBFS with new texinfo.
diff -Nru acct-6.5.5/debian/control acct-6.5.5/debian/control
--- acct-6.5.5/debian/control 2012-12-17 23:47:07.0 +
+++ acct-6.5.5/debian/control 2013-12-18 12:17:34.0 +
@@ -3,8 +3,7 @@
Priority: optional
Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com
XSBC-Original-Maintainer: Mathieu Trudel-Lapierre mathieu...@gmail.com
-Build-Depends: debhelper (= 7), autotools-dev, autoconf, automake,
- libtool, texi2html, texinfo
+Build-Depends: debhelper (= 7), dh-autoreconf, texi2html, texinfo
Standards-Version: 3.9.1
Homepage: http://www.gnu.org/software/acct/
diff -Nru acct-6.5.5/debian/rules acct-6.5.5/debian/rules
--- acct-6.5.5/debian/rules 2012-12-18 02:54:16.0 +
+++ acct-6.5.5/debian/rules 2013-12-18 12:17:10.0 +
@@ -12,24 +12,18 @@
dh_testdir
dh_testroot
rm -f build-stamp
- rm -f config.guess config.sub
[ ! -f Makefile ] || $(MAKE) distclean
rm -f accounting.html
rm -f accounting.info
+ dh_autoreconf_clean
dh_clean
config.status: configure
dh_testdir
-ifneq $(wildcard /usr/share/misc/config.sub)
- cp -f /usr/share/misc/config.sub config.sub
-endif
-ifneq $(wildcard /usr/share/misc/config.guess)
- cp -f /usr/share/misc/config.guess config.guess
-endif
- autoreconf -f
+ dh_autoreconf
./configure $(CROSS) --prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${prefix}/share/info $(shell dpkg-buildflags --export=configure)
build: build-stamp
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732139: PNG is not the preferred form for modification
Thanks Thorsten. I'll add a note to README.Debian for the next upload. James On Wed, 2013-12-18 at 12:27 +0100, Thorsten Alteholz wrote: Version: 1.5.1.is.1.3+dfsg-1 Hi James, based on the contents of the images you might be right. So I am closing this bug again. For future uploads, maybe you can document this somewhere in the debian directory? Thorsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732509: mksh: missing octal support in arithmetic expressions
And be careful not to break test/[. $ mksh -c '[ 10 -eq 010 ] echo OK' OK is correct. On this subject, see Geoff Clare's message in the Austin Group mailing-list: http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/8862 -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732518: override: libcsoundac-dev:libdevel/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above csound packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and as a library it might want to be used by other optional packages in the future. There is a mismatch between the section/priority indicated in the current deb package (libdevel/extra) and the requested override (libdevel/optional). The maintainers have been informed and the next time the package gets uploaded, the section/priority will be fixed. In the meantime it would be great if you could fix the override. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732516: override: csound-manpages:doc/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above csound-manual packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732519: override: libcsound64-dev:libdevel/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above csound packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and as a library it might want to be used by other optional packages in the future. There is a mismatch between the section/priority indicated in the current deb package (libdevel/extra) and the requested override (libdevel/optional). The maintainers have been informed and the next time the package gets uploaded, the section/priority will be fixed. In the meantime it would be great if you could fix the override. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732515: override: libvamp-hostsdk3:libs/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above vamp-plugin-sdk packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and as a library it might want to be used by other optional packages in the future. There is a mismatch between the section/priority indicated in the current deb package (sound/optional) and the requested override (libs/optional). The maintainers have been informed and the next time the package gets uploaded, the section/priority will be fixed. In the meantime it would be great if you could fix the override. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732517: override: libcsound64-doc:doc/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above csound packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631237: libreoffice works with ibus in sarge/wheezy/jessie
Hi, On Tue, Dec 17, 2013 at 02:17:07PM -1000, Ryo Furue wrote: Thank you for your response. As you say, this issue may well be due to ibus. Excuse me, I do not understand this response. I meant to say that you are creating problem by using ibus under the wrong environment due to misconfiguration. What locale you are running ibus mini-window and X matters. I do not have reference now but pretty sure it has to be UTF-8 locale. I'm not disagreeing with you, but it's strange that ibus should depend on a locale. It is natural for me. It's plugin-based and designed to handle all sorts of languages (and other phonetic alphabets) AT THE SAME TIME. You can input Russian, International Phonetic Alphabet, Korean, Japanese, etc. using ibus in a single text box without restarting ibus. Then, what locale should you set for it? Or is there any generic UTF-8 locale? like C.UTF-8 or anylanguage.UTF-8 or some such thing? There was a discussion to create non standard C.UTF-8 to avoid this kind of breakage by d-i folks as I understand. It did not happen. Your bug report indicates that you are in LANG=C for your machine. Yes! ... I'm not sure if I can do that. en_US.UTF-8 is a terrible setting. What files do you think the following command remove? $ rm [A-Z]* Under en_US.UTF-8, it deletes files starting with A-Z and a-y ! because the collating sequence is changed from A-Za-z to AaBbCc . . . YyZz . Another example is that the output of ls -l depends on the locale. I write and use a lot of shell scripts and I cannot accept that their behaviors depend on the locale and I don't want to start all my scripts with LANG=C; export C, and I cannot escape from the habit of typing something like rm [A-Z]*. I do agree it is annoyng. I have seen some erratic changes over behavior around UTF-8 locales. LANG=en_DK.UTF-8 does not sseem to work right anymore. Basically, I gave up relying on such thing. I'm not complaining to YOU. I just thank you for your response. If you concern is only this, you are working around in wrong way. Forcing ibus to work under C is not the way to fix issue. Maybe, should I ask the ibus folks? Wrong. Please customize your locale properly. Leave /etc/default/locale in UTF-8 to keep GUI program output UTF-8 characters to X for expected result. If you need to set environment for your shell prompt, set it with their startup code location for your shell such as ~/.bashrc or ~/.profile (Please make sure the gdm/kdm/.. like program which you use does not read .profile if you use it to set locale. kdm had such bug once). There, you can set LANG=C . Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695869: nvidia: I have same bug
Package: xserver-xorg-video-nvidia Version: 304.88-1+deb7u1 Followup-For: Bug #695869 Dear Maintainer, My Gnome 3 randomly feezes, all I can do is reboot. Xorg.log reports sth about nvidia propietary driver. I will try to add it too here later. -- Package-specific info: uname -a: Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux /proc/version: Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.51-1 /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 304.88 Wed Mar 27 14:26:46 PDT 2013 GCC version: gcc version 4.6.3 (Debian 4.6.3-14) lspci 'VGA compatible controller [0300]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF116 [GeForce GTX 550 Ti] [10de:1244] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:838c] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fc00 (32-bit, non-prefetchable) [size=32M] Region 1: Memory at d800 (64-bit, prefetchable) [size=128M] Region 3: Memory at d400 (64-bit, prefetchable) [size=64M] Region 5: I/O ports at cc00 [size=128] [virtual] Expansion ROM at fe90 [disabled] [size=512K] Capabilities: access denied Kernel driver in use: nvidia dmesg: [0.00] No AGP bridge found [0.00] No AGP bridge found [0.00] Console: colour VGA+ 80x25 [0.402116] vgaarb: device added: PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none [0.402116] vgaarb: loaded [0.402116] vgaarb: bridge control possible :01:00.0 [0.848997] Linux agpgart interface v0.103 [6.700936] nvidia: module license 'NVIDIA' taints kernel. [6.905889] nvidia :01:00.0: setting latency timer to 64 [6.905894] vgaarb: device changed decodes: PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem [6.906019] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 304.88 Wed Mar 27 14:26:46 PDT 2013 [7.960106] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input5 [7.960221] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input6 [7.960307] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input7 [7.960390] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input8 OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jun 22 2012 /etc/alternatives/glx - /usr/lib/nvidia lrwxrwxrwx 1 root root 48 Jun 22 2012 /etc/alternatives/glx--libGL.so-x86_64-linux-gnu - /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so lrwxrwxrwx 1 root root 48 Jun 22 2012 /etc/alternatives/glx--libGL.so-x86_64-linux-gnu - /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so lrwxrwxrwx 1 root root 43 Jun 22 2012 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jun 22 2012 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 51 Jun 22 2012 /etc/alternatives/glx--libXvMCNVIDIA.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libXvMCNVIDIA.so.1 lrwxrwxrwx 1 root root 59 Jun 22 2012 /etc/alternatives/glx--libXvMCNVIDIA_dynamic.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libXvMCNVIDIA_dynamic.so.1 lrwxrwxrwx 1 root root 51 Jun 22 2012 /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 Jun 22 2012 /etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 36 Jun 22 2012 /etc/alternatives/glx--nvidia-bug-report.sh - /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 29 Jun 22 2012 /etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 22 Jun 22 2012 /etc/alternatives/libGL.so-master - /usr/lib/mesa-diverted lrwxrwxrwx 1 root root 23 Jun 22 2012 /etc/alternatives/nvidia - /usr/lib/nvidia/current lrwxrwxrwx 1 root root 51 Jun 22 2012 /etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 51 Jun 22 2012 /etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 59 Jun 22 2012 /etc/alternatives/nvidia--libXvMCNVIDIA.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/current/libXvMCNVIDIA.so.1 lrwxrwxrwx 1 root
Bug#732521: VMs won't start with VERR_SYMBOL_NOT_FOUND
Package: virtualbox Version: 4.3.2-dfsg-1 Severity: important Hi, Since a few days, when I try to start a VM in virtualbox, the following happens: wouter@carillon:~$ vboxmanage startvm debsrv Waiting for VM debsrv to power on... VBoxManage: error: Failed to load VMMR0.r0 (VERR_SYMBOL_NOT_FOUND) VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component Console, interface IConsole The VM's window does pop up for a short while, but then it closes again. The same happens when trying to start from the GUI. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages virtualbox depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.5 ii libc62.17-97 ii libcurl3 7.33.0-2 ii libgcc1 1:4.8.2-10 ii libgsoap42.8.16-2 ii libpng12-0 1.2.49-5 ii libpython2.7 2.7.6-3 ii libsdl1.2debian 1.2.15-8 ii libssl1.0.0 1.0.1e-4 ii libstdc++6 4.8.2-10 ii libvncserver00.9.9+dfsg-1 ii libvpx1 1.2.0-2 ii libx11-6 2:1.6.2-1 ii libxcursor1 1:1.1.14-1 ii libxext6 2:1.3.2-1 ii libxml2 2.9.1+dfsg1-3 ii libxmu6 2:1.1.1-1 ii libxt6 1:1.1.4-1 ii python 2.7.5-5 ii python2.72.7.6-3 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages virtualbox recommends: ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libqt4-opengl 4:4.8.5+git192-g085f851+dfsg-2 ii libqtcore44:4.8.5+git192-g085f851+dfsg-2 ii libqtgui4 4:4.8.5+git192-g085f851+dfsg-2 ii virtualbox-qt 4.3.2-dfsg-1 ii virtualbox-source 4.3.2-dfsg-1 Versions of packages virtualbox suggests: pn vde2none ii virtualbox-guest-additions-iso 4.3.2-1 -- Configuration Files: /etc/default/virtualbox changed: LOAD_VBOXDRV_MODULE=1 SHUTDOWN_USERS=all SHUTDOWN=savestate -- 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#730884: lcas: FTBFS: configure: checking for GLOBUS_COMMON... no
Hi David, apologies that we took so long to respond. The same actually occurs for LCMAPS and all our globus-depending tools. The problem is not so much the dependency itself but the new multiarch. One of the globus headers is no longer found. The easiest workaround for the time being is to add a dependency on pkg-config, which is what we will do first. We are busy fixing it also in configure itself. Best regards, Mischa -- Nikhef Room H155 Science Park 105Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msa...@nikhef.nl __ .. ... _._. ._ ... ._ ._.. ._.. .._.. signature.asc Description: Digital signature
Bug#732520: abinit: New upstream version, package unmaintained
Package: abinit Severity: normal Hi, when checking a new QA tool to find aged packages[1] I noticed that abinit is obviously orphaned. It is lagging behind upstream for several (even major versions) and was not uploaded since five years - so the packaging can be considered quite outdated. As far as I can see the package is not even maintained in Vcs. It also seems to be consensus to stop using pkg-scicomp as maintainer team but either use debian-science or some other team that might fit more which probably is the case here since I think DebiChem makes a perfect fit. What do you think about taking over abinit into DebiChem? I'd volunteer to help in the migration step if any help is needed. Kind regards Andreas. [1] anonscm.debian.org/gitweb/?p=blends/website.git;a=blob;f=misc/sql/aging_packages_of_team -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.36-xenU-4814-i386 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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#732522: not linked correctly with libpython
Package: python-ldap Version: 2.4.10-1 Severity: important When trying to use python-ldap from an embedded python inside another application, I get errors such as this: Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/ldap/__init__.py, line 22, in module import _ldap ImportError: /usr/lib/python2.7/dist-packages/_ldap.so: undefined symbol: PyExc_SystemError Looking at _ldap.so with ldd, I notice it is not linked to Python: ldd /usr/lib/python2.7/dist-packages/_ldap.so | grep py As a hack, I add an explicit dlopen(libpython2.7.so, RTLD_LAZY |RTLD_GLOBAL); into my own code (a C++ app embedding Python) before Py_Initialize and then everything works nicely - but this is a hack and probably needs to be fixed by linking _ldap.so with -lpython2.7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732447: debian-reference: French templates translation
Hi, On Wed, Dec 18, 2013 at 06:37:51AM +0100, Alexandre Hoïde wrote: Package: debian-reference Version: 2.50 Severity: wishlist Tags: l10n Hello Osamu, Please find the french translation, proofread by the debian-l10n-french mailing list contributors, at this address : http://ubuntuone.com/6vYDOgAEvPKbXLrRcYkG8z Thanks. Note1: based on POT-Creation-Date: 2013-11-18 01:15+0900. I saw that the updated version you have in git gives about 3f2u, which I (or any l10n-french translator) will gladly process quickly when you request it with new merged file. Let me do trivial fixes first since I know what I changed. Note2: This version contains lots of fixes outside the scope of your initial request for unfuzying/de-untranslating. Thanks. I will. Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732525: override: rubberband-vamp:sound/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above rubberband packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732526: override: libcsnd-dev:libdevel/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above csound packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and as a library it might want to be used by other optional packages in the future. There is a mismatch between the section/priority indicated in the current deb package (libdevel/extra) and the requested override (libdevel/optional). The maintainers have been informed and the next time the package gets uploaded, the section/priority will be fixed. In the meantime it would be great if you could fix the override. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732523: override: vamp-plugin-sdk:sound/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above vamp-plugin-sdk packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732524: override: vamp-plugin-sdk-doc:doc/optional
Package: ftp.debian.org Severity: normal Dear ftp-masters, Please change the priority for the above vamp-plugin-sdk packages from extra to optional. According to Debian policy, i don't see a reason to not have priority optional, since the package does not have any specialized requirements such as mentioned in §2.5 of the Debian policy. Thus, this package doesn't need to be in extra, and it might want to be used by other optional packages in the future. Thanks, fgmasdr IOhannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote: On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote: I'm confused, when I hear you say that this risk is unique to the systemd option and not shared by other options. I would understand that statement if we thought we could avoid systemd entirely. It sounds like we may be able to avoid systemd as pid 1 but systemd is very likely to play an important role in the Debian desktop storpy even if we adopt another pid 1. Thanks for the explanation, and apologies to Josselin and Russ that I completely misread their point regarding udev: I was misreading that as referring to the headaches udev had caused in the past for Debian upgrades, not that the systemd udev might be the cause of future upgrade headaches. But I do not buy this We already switched to systemd as upstream of udev, so we also have swallow the rest of it: When not using systemd as pid 1, that risk would be confined to the parts of systemd Debian would be using (currently only udev). I think you still misread the argument: IMO it's clear that it considered more than udev as likely to be required, even if udev is the only one in current Debian. So if you disagree, you should at least address the question of why you believe udev will stay the only one. At some level, we also need to be community players. Since upgrade stability is important to us, we should advocate for it in open-source projects that we depend on. On the flip side, if enough of the rest of the community after having carefully considered our arguments decides that our desire for stability is too expensive, perhaps we need to reconsider our position. I hope we don't need to do that, but sometimes when enough of the rest of the world disagrees with you, you need to move on. systemd upstream only reluctantly supports the option to have a separate /usr (as currently mandated by Debian policy), and I would not be surprised if that gets dropped any time if it becomes an obstacle for development of any part of systemd. You're mixing two separate issues (or at least not clearly indicating which one you're talking about). Systemd fully supports having a separate /usr partition, and that is in no way deprecated AFAIK. What has changed compared to old practice is that /usr needs to be mounted together with root (requiring initramfs if you have a separate /usr; where you had mount / before you now have mount / and /usr). Whether the old way of later /usr mounting could keep working with any other init either is questionable. Then there is the move of binaries from /bin to /usr/bin, which does have some backwards compatibility logic for different paths in systemd. This is not directly connected to /usr being a separate partition or not (but having everything in /usr/bin obviously requires /usr mounted early). Does someone in Debian seriously oppose this move as a long term goal? And now you bring up the point that Debian should reconsider the lenght of it's release cycles if systemd upstream decides to not support upgrades between distribution releases as far apart as Debian's. [3] I don't think anyone said that. Nobody talked about long release cycles not being supported, and nobody said that upgrades would not be supported either. However, supporting upgrade from the old release does not equal things like being able to run the new userland on the 3+ year old kernel from the previous release. A development model where you have to wait 3+ years before you can have hard dependencies on the new features you write now is obviously very problematic. IMO such restraints should never be taken for granted; upgrade schemes should always be planned to at least make it possible to have newer dependencies without too much trouble. In the kdbus case, systemd upstream already mentioned the possibility of shipping kdbus as a new module for older kernels. More generally, you can have solutions like applying some upgrades at boot rather than trying to switch parts from under a fully live system. This does still count as fully supporting upgrades. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717776: tmux segfault
Hi, Damien CLAUZEL dam...@clauzel.eu writes: Tmux segfaults also on my server. No obvious reason. I have those kind of entries in /var/log/kern.log If it happens regularly please install corekeeper and send me the core file privately once it crashes. -- Romain Francoise rfranco...@debian.org http://people.debian.org/~rfrancoise/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732522: not linked correctly with libpython
On 2013-12-18 13:56:57, Daniel Pocock wrote: Package: python-ldap Version: 2.4.10-1 Severity: important When trying to use python-ldap from an embedded python inside another application, I get errors such as this: Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/ldap/__init__.py, line 22, in module import _ldap ImportError: /usr/lib/python2.7/dist-packages/_ldap.so: undefined symbol: PyExc_SystemError Looking at _ldap.so with ldd, I notice it is not linked to Python: ldd /usr/lib/python2.7/dist-packages/_ldap.so | grep py As a hack, I add an explicit dlopen(libpython2.7.so, RTLD_LAZY |RTLD_GLOBAL); into my own code (a C++ app embedding Python) before Py_Initialize and then everything works nicely - but this is a hack and probably needs to be fixed by linking _ldap.so with -lpython2.7 No. Extensions modules do not link against libpythonX.Y in Debian. Please check with Python Policy 2.1. It looks like the embedding application is built incorrectly. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#732527: GFDL not mentioned in debian/copyright
Package: libmbim Severity: serious User: alteh...@debian.org Usertags: ftp X-Debbugs-CC: ftpmas...@ftp-master.debian.org thanks Dear Maintainer, your new package libmbim-glib-doc contains files that are licensed under the GFDL. Please mention this license in debian/copyright as well. Thanks! Thorsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732462: munin-node: unowned directories after purge: /var/lib/munin-node/plugin-state/{munin, nobody, root}/
Am Wed, 18 Dec 2013 13:22:22 +0100 schrieb Matthias Schmitz matth...@sigxcpu.org: Hi Andreas, hi Holger, hi *! Am Wed, 18 Dec 2013 10:53:02 +0100 schrieb Andreas Beckmann a...@debian.org: Package: munin-node Version: 2.0.19-2 Severity: important User: debian...@lists.debian.org Usertags: piuparts ... From the attached log (scroll to the bottom...): 0m32.7s ERROR: FAIL: Package purging left files on system: /var/lib/munin-node/plugin-state/munin/not owned /var/lib/munin-node/plugin-state/nobody/ not owned /var/lib/munin-node/plugin-state/root/ not owned The directory /var/lib/munin-node/ is created (and removed at purge) by the package munin-plugins-core. Argl, i was a little rashly. Indeed munin-plugins-core doesn't remove the directory if its not empty. The files saved in the plugin-state/user/ directories are created when a plugin runs that needs to save a state (ether within munin-node or with munin-run). How should we deal with this data? When purging 'munin' we don't delete the rrd files. But the statefiles are not this important should we simply delete them at purge? Best wishes, Matthias signature.asc Description: PGP signature
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote: In the kdbus case, systemd upstream already mentioned the possibility of shipping kdbus as a new module for older kernels. More generally, you can have solutions like applying some upgrades at boot rather than trying to switch parts from under a fully live system. This does still count as fully supporting upgrades. You might think so. To me, that sounds like a hacky workaround for needlessly inflexible software. Much like Windows. -- Steve McIntyre, Cambridge, UK.st...@einval.com The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. -- James D. Nicoll -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732528: openjdk-7: FTBFS on mips and mipsel
Package: openjdk-7 Version: 7u45-2.4.3-2.3 Severity: important Tags: upstream patch Justification: fails to build from source Thanks for adding the mips patch to fix unaligned accesses in the latest upload. Unfortunately upstream has added more unaligned accesses in the new version, so openjdk-7 still FTBFS on mips and mipsel. You will find attached a new version of hotspot-mips-align.diff to drop in debian/patches. Could you please add it for the next upload? Thanks in advance. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: mips (mips64) Kernel: Linux 3.2.0-4-5kc-malta Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash --- openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.hpp +++ openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.hpp @@ -56,7 +56,16 @@ jlong l; jdouble d; uint32_t v[2]; -}; +} +#ifndef _LP64 + /* Hotspot only aligns the union to the uintptr_t type, that is 32 bit + on a 32-bit CPU. Accesses to double values should be 64-bit aligned + on at least MIPS and SPARC. Declare it to GCC for all 32-bit CPUs, + as it might also help GCC to select the best instruction on other + CPUs. */ + __attribute__ ((packed, aligned (4))) +#endif +; typedef class BytecodeInterpreter* interpreterState; @@ -169,7 +178,16 @@ jlong l; jdouble d; uint32_t v[2]; -}; +} +#ifndef _LP64 + /* Hotspot only aligns the union to the uintptr_t type, that is 32 bit + on a 32-bit CPU. Accesses to double values should be 64-bit aligned + on at least MIPS and SPARC. Declare it to GCC for all 32-bit CPUs, + as it might also help GCC to select the best instruction on other + CPUs. */ + __attribute__ ((packed, aligned (4))) +#endif +; /* * Generic 32-bit wide Java slot definition. This type occurs --- openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp +++ openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp @@ -322,7 +322,7 @@ ThreadStateTransition::transition_from_java(thread, _thread_in_native); // Make the call - intptr_t result[4 - LogBytesPerWord]; + intptr_t result[4 - LogBytesPerWord] __attribute__((__aligned__(__alignof__(double; ffi_call(handler-cif(), (void (*)()) function, result, arguments); // Change the thread state back to _thread_in_Java.
Bug#732521: VMs won't start with VERR_SYMBOL_NOT_FOUND
I think the root cause for your bug would be the same what Raphael found. Please see attached email. On Wednesday 18 December 2013 05:44 PM, Wouter Verhelst wrote: Package: virtualbox Version: 4.3.2-dfsg-1 Severity: important Hi, Since a few days, when I try to start a VM in virtualbox, the following happens: wouter@carillon:~$ vboxmanage startvm debsrv Waiting for VM debsrv to power on... VBoxManage: error: Failed to load VMMR0.r0 (VERR_SYMBOL_NOT_FOUND) VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component Console, interface IConsole The VM's window does pop up for a short while, but then it closes again. The same happens when trying to start from the GUI. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages virtualbox depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.5 ii libc62.17-97 ii libcurl3 7.33.0-2 ii libgcc1 1:4.8.2-10 ii libgsoap42.8.16-2 ii libpng12-0 1.2.49-5 ii libpython2.7 2.7.6-3 ii libsdl1.2debian 1.2.15-8 ii libssl1.0.0 1.0.1e-4 ii libstdc++6 4.8.2-10 ii libvncserver00.9.9+dfsg-1 ii libvpx1 1.2.0-2 ii libx11-6 2:1.6.2-1 ii libxcursor1 1:1.1.14-1 ii libxext6 2:1.3.2-1 ii libxml2 2.9.1+dfsg1-3 ii libxmu6 2:1.1.1-1 ii libxt6 1:1.1.4-1 ii python 2.7.5-5 ii python2.72.7.6-3 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages virtualbox recommends: ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libqt4-opengl 4:4.8.5+git192-g085f851+dfsg-2 ii libqtcore44:4.8.5+git192-g085f851+dfsg-2 ii libqtgui4 4:4.8.5+git192-g085f851+dfsg-2 ii virtualbox-qt 4.3.2-dfsg-1 ii virtualbox-source 4.3.2-dfsg-1 Versions of packages virtualbox suggests: pn vde2none ii virtualbox-guest-additions-iso 4.3.2-1 -- Configuration Files: /etc/default/virtualbox changed: LOAD_VBOXDRV_MODULE=1 SHUTDOWN_USERS=all SHUTDOWN=savestate -- no debconf information -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. ---BeginMessage--- Hi, On Mon, 09 Sep 2013, Jan Nordholz wrote: I cannot resume my VMs anymore. Virtualbox terminates any attempt (regardless of the instance or type of guest OS) with ] 00:00:11.973758 VMSetError: Failed to load VMMR0.r0 I got this error this morning as well but it's apparently a case of mismatch between the modules loaded in the kernel and virtualbox itself. A reboot was enough to fix the problem (provided that the latest version of modules are auto-built by DKMS as expected). I think this bug can be closed. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ ---End Message--- signature.asc Description: OpenPGP digital signature
Bug#732522: not linked correctly with libpython
On 18/12/13 14:12, Sebastian Ramacher wrote: On 2013-12-18 13:56:57, Daniel Pocock wrote: Package: python-ldap Version: 2.4.10-1 Severity: important When trying to use python-ldap from an embedded python inside another application, I get errors such as this: Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/ldap/__init__.py, line 22, in module import _ldap ImportError: /usr/lib/python2.7/dist-packages/_ldap.so: undefined symbol: PyExc_SystemError Looking at _ldap.so with ldd, I notice it is not linked to Python: ldd /usr/lib/python2.7/dist-packages/_ldap.so | grep py As a hack, I add an explicit dlopen(libpython2.7.so, RTLD_LAZY |RTLD_GLOBAL); into my own code (a C++ app embedding Python) before Py_Initialize and then everything works nicely - but this is a hack and probably needs to be fixed by linking _ldap.so with -lpython2.7 No. Extensions modules do not link against libpythonX.Y in Debian. Please check with Python Policy 2.1. It looks like the embedding application is built incorrectly. Is there any documentation on how such applications should be built/linked? I've found various discussion threads but many of them just contain things that look like hacks and that left me feeling that _ldap.so was not correct -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732529: Please mark transfig Multi-Arch: foreign
Package: transfig
Version: 1:3.2.5.e-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch
In Ubuntu, the attached patch was applied to achieve the following:
* Merge from Debian unstable. Remaining changes:
- Mark transfig Multi-Arch: foreign for cross-build-dependencies.
We've been carrying this one-line patch for a while now, as it greatly
improves the ability to cross-bootstrap the archive from one arch to
another. Would be great if it was included in Debian, so I could stop
merging the 1-liner in. ;)
... Adam
-- System Information:
Debian Release: wheezy/sid
APT prefers trusty-updates
APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500,
'trusty'), (500, 'saucy-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11.0-13-generic (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru transfig-3.2.5.e/debian/changelog transfig-3.2.5.e/debian/changelog
diff -Nru transfig-3.2.5.e/debian/control transfig-3.2.5.e/debian/control
--- transfig-3.2.5.e/debian/control 2013-10-15 06:51:45.0 -0600
+++ transfig-3.2.5.e/debian/control 2013-12-18 06:35:50.0 -0700
@@ -14,6 +14,7 @@
Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common, gawk
Recommends: netpbm (= 2:10.0-4), ghostscript
Suggests: xfig
+Multi-Arch: foreign
Description: Utilities for converting XFig figure files
This package contains utilities (mainly fig2dev) to handle XFig
(Facility for Interactive Generation of figures) files.
Bug#732522: not linked correctly with libpython
On 18/12/13 14:29, Daniel Pocock wrote: On 18/12/13 14:12, Sebastian Ramacher wrote: On 2013-12-18 13:56:57, Daniel Pocock wrote: Package: python-ldap Version: 2.4.10-1 Severity: important When trying to use python-ldap from an embedded python inside another application, I get errors such as this: Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/ldap/__init__.py, line 22, in module import _ldap ImportError: /usr/lib/python2.7/dist-packages/_ldap.so: undefined symbol: PyExc_SystemError Looking at _ldap.so with ldd, I notice it is not linked to Python: ldd /usr/lib/python2.7/dist-packages/_ldap.so | grep py As a hack, I add an explicit dlopen(libpython2.7.so, RTLD_LAZY |RTLD_GLOBAL); into my own code (a C++ app embedding Python) before Py_Initialize and then everything works nicely - but this is a hack and probably needs to be fixed by linking _ldap.so with -lpython2.7 No. Extensions modules do not link against libpythonX.Y in Debian. Please check with Python Policy 2.1. It looks like the embedding application is built incorrectly. Is there any documentation on how such applications should be built/linked? I've found various discussion threads but many of them just contain things that look like hacks and that left me feeling that _ldap.so was not correct The embedding application is slightly more complicated - it is actually a modular application itself. It does not link directly to Python, rather one of its modules encapsulates an embedded Python. The module is built using the values provided by python2.7-config as per the manual: http://docs.python.org/2/extending/embedding.html#compiling-and-linking-under-unix-like-systems The high level application loads its modules with dlopen() - I've found that adding RTLD_GLOBAL to that dlopen() call also provides a solution but it is not clear whether this is a good idea as it would mean symbols from all modules are exposed to all other modules. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730850: libghc-xmonad-dev: is not installable
Hi, I am also affected by this. Any idea when it can be fixed? Best regards, Magnus
Bug#732462: munin-node: unowned directories after purge: /var/lib/munin-node/plugin-state/{munin, nobody, root}/
Matthias, On Wed, Dec 18, 2013 at 2:21 PM, Matthias Schmitz matth...@sigxcpu.org wrote: How should we deal with this data? When purging 'munin' we don't delete the rrd files. But the statefiles are not this important should we simply delete them at purge? Yes, I recommend to take a similar policy to database packages : - rrd meta-data (/var/lib/munin/**) should be treated like DB data : only removed manually - munin plugin configuration (/etc/munin/**) should be treated like DB engine config : removed on purge - plugin states (/var/lib/munin-node/plugin-state/**) should also be treated like DB engine config : removed on purge - anything else should be treated like DB engine : removed on remove. The idea is to avoid removing data that has a value, and data that remains should remains usable (ie: with its metadata). Removing plugin state should not be automatic, but not retained at all costs, as one expects a clean reinstall after purge, specially on a node. Regards, -- Steve Schnepp http://blog.pwkf.org/tag/munin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724869: base: Deadkeys do not work in Xorg French canadian keyboard
On Tue, Dec 17, 2013 at 09:31:14PM -0500, James Brookes wrote: I solved the problem by selecting xim with im-config. The default wheezy installation was giving 2 valid choices, here is an extractfrom im-config: Current configuration for the input method: * Active configuration: xim (normally missing) * Automatic configuration: uim (normally ibus or fcitx or uim) * Number of valid choices: 2 (normally 1) The configuration set by im-config is activated by re-starting X. Explicit selection is not required to enable the automatic configuration if the active one is default/auto/cjkv/missing. Available input methods: uim xim Unless you really need them all, please make sure to install only one input method tool. In order to see if this bug belongs to console-setup one has to check the contents of /etc/config/keyboard. Is it correct? If it isn't then the bug belongs to console-setup. Otherwise it doesn't. Please send us the content of this file. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732207: tvtime: Fails to install + segfault
Package: tvtime
Followup-For: Bug #732207
Dear Maintainer,
I rebuild with dh_strip off. Which gives:
gdb --args tvtime-configure --configfile=/etc/tvtime/tvtime.xml --norm=SECAM
--frequencies=france --device=/dev/video0 --vbidevice=/dev/vbi0 --priority=-10
Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:42
42 ../sysdeps/x86_64/multiarch/../strlen.S: Aucun fichier ou dossier de ce
type.
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:42
#1 0x00401a1e in main (argc=7, argv=0x7fffbce8) at
tvtime-configure.c:39
(gdb) up
#1 0x00401a1e in main (argc=7, argv=0x7fffbce8) at
tvtime-configure.c:39
39 if( strlen( getenv( HOME ) ) 230 ) { fprintf( stderr, HOME is too
long\n ); exit( 1 ); }
It turns out that getenv always fails here (amd64), quick test for to reproduce:
$ gdb bash
(gdb) b main
(gdb) r
(gdb) p/s (char *)getenv(HOME)
$1 = 0xea8a Address 0xea8a out of bounds
Definitely looks like libc6 is broken on amd64 for its 2.17-97 deb at least (I
tested with same libc6 version,
on debian sid too on arm 32 (cortex A9) and i386 also 32 all is fine.
critical indeed , you might want to reassign to libc6 (or I will tomorrow)
BR,
Alban
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages tvtime depends on:
ii debconf [debconf-2.0] 1.5.52
ii fonts-freefont-ttf [ttf-freefont] 20120503-1
ii libc6 2.17-97
ii libfreetype6 2.5.1-1
ii libgcc11:4.8.2-10
ii libice62:1.0.8-2
ii libpng12-0 1.2.49-5
ii libsm6 2:1.2.1-2
ii libstdc++6 4.8.2-10
ii libx11-6 2:1.6.2-1
ii libxext6 2:1.3.2-1
ii libxinerama1 2:1.1.3-1
ii libxml22.9.1+dfsg1-3
ii libxtst6 2:1.2.2-1
ii libxv1 2:1.0.9-1
ii libxxf86vm11:1.1.3-1
ii perl-modules 5.18.1-5
ii ttf-freefont 20120503-1
ii ucf3.0027+nmu1
ii zlib1g 1:1.2.8.dfsg-1
Versions of packages tvtime recommends:
ii xmltv-util 0.5.63-2
Versions of packages tvtime suggests:
ii lirc-x 0.9.0~pre1-1
ii oss-compat 4
-- debconf information:
* tvtime/frequencies-pal: France
* tvtime/norm: SECAM
tvtime/vbidevice: /dev/vbi0
tvtime/frequencies-ntsc:
tvtime/frequencies-jp:
tvtime/v4ldevice: /dev/video0
tvtime/processpriority: -10
tvtime/setuid: false
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732531: ITP: pktools -- A collection of programs to process geo raster images
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine fran...@debian.org * Package name: pktools Version : 2.4.3 Upstream Author : Pieter Kempeneers kempe...@gmail.com * URL : http://www.nongnu.org/pktools/html/index.html * License : GPL3 Programming Lang: C++ Description : A collection of programs to process geo raster images pktools is a collection of programs written in C++ to perform operations, mostly on raster images. It heavily relies on the Geospatial Data Abstraction Library GDAL and OGR. The programs are similar to the gdal tools (gdalinfo, gdal_translate, gdal_merge,...) and some of the functionalities provided in pktools already exist in the gdal tools. The reason for implementing pktools is a combination of personal preference and additional functionality. All utilities in pktools use command line options and have a built in help. A list of tools available: pkascii2img program to create raster image based on ascii file pkascii2ogr program to create vector points or polygons from text file pkclassify_nn classify raster image using Artificial Neural Network pkclassify_svm classify raster image using Support Vector Machine pkcreatect program to create and import colour table to GTiff image pkcrop perform raster data operations on image such as crop, extract and stack bands pkdiff program to compare two raster image files pkdsm2shadow program to calculate sun shadow based on digital surface model and sun angles pkdumpimg program to dump image content to ascii or std out pkdumpogr dump ogr file to text file or standard output pkeditogr program to edit (rename fields) ogr fil pkegcs Utility for raster files in European Grid Coordinate System pkenhance program to enhance raster images pkextract extract pixel values from raster image from a (vector or raster) sample pkfillnodata program to fill holes in raster image pkfilterascii program to filter data in ASCII file (spectral respons function, dwt) pkfilter program to filter raster images pkfs_nn feature selection for nn classifier pkfs_svm feature selection for svm classifier pkgetmask program to create mask image based on values in input raster image pkinfo program to retrieve information from raster images pklas2img program to create (e.g., DEM) raster image from las files pkmosaic program to create mosaic geo-referenced images pkndvi program to calculate vegetation index image pkopt_svm program to optimize parameters for SVM classification pkpolygonize program to make vector file from raster image pkreclass program to replace pixel values in raster image pkregression_nn regression with artificial neural network (multi-layer perceptron) pksetmask program to apply mask image (set invalid values) to raster image pksieve program to sieve filter raster image pkstatascii pkstatogr program to calculate basic statistics from vector file -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732530: startup-notification: use dh-autoreconf for better new-port coverage
Package: startup-notification Version: 0.12-3 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch trusty Hi, The ppc64el port requires a patch to libtool.m4. I don't think that's in Debian yet, but when it is it will require autoreconfing a bunch of packages to pick it up. startup-notification could handle this quite easily by using dh-autoreconf, which will update its copies of the libtool macros. * Use dh-autoreconf to update libtool macros for new ports. diff -Nru startup-notification-0.12/debian/control startup-notification-0.12/debian/control --- startup-notification-0.12/debian/control2013-05-20 09:18:37.0 +0100 +++ startup-notification-0.12/debian/control2013-12-18 13:45:27.0 + @@ -12,6 +12,7 @@ Build-Depends: autotools-dev, cdbs (= 0.4.93~), debhelper (= 9), + dh-autoreconf, libx11-dev, libxt-dev, pkg-config, diff -Nru startup-notification-0.12/debian/control.in startup-notification-0.12/debian/control.in --- startup-notification-0.12/debian/control.in 2013-05-20 09:14:28.0 +0100 +++ startup-notification-0.12/debian/control.in 2013-12-18 13:45:24.0 + @@ -7,6 +7,7 @@ Build-Depends: autotools-dev, cdbs (= 0.4.93~), debhelper (= 9), + dh-autoreconf, libx11-dev, libxt-dev, pkg-config, diff -Nru startup-notification-0.12/debian/rules startup-notification-0.12/debian/rules --- startup-notification-0.12/debian/rules 2013-05-20 08:54:56.0 +0100 +++ startup-notification-0.12/debian/rules 2013-12-18 13:44:44.0 + @@ -3,6 +3,7 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/gnome.mk include /usr/share/cdbs/1/rules/utils.mk +include /usr/share/cdbs/1/rules/autoreconf.mk include /usr/share/gnome-pkg-tools/1/rules/uploaders.mk -include /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730850: [Pkg-haskell-maintainers] Bug#730850: libghc-xmonad-dev: is not installable
Hi, Am Mittwoch, den 18.12.2013, 14:43 +0100 schrieb Magnus R: I am also affected by this. Any idea when it can be fixed? as soon as a new pandoc package is uploaded (Bug #731391) – sorry. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
