Bug#679714: postgres-xc: fails to install: missing dependency on postgresql server?
Package: postgres-xc Version: 1.0.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. From the attached log (scroll to the bottom...): [...] creating template1 database in datanode2/base/1 ... ok initializing pg_authid ... ok initializing dependencies ... ok creating system views ... ok creating cluster information ... ok loading system objects' descriptions ... ok creating collations ... ok creating conversions ... ok creating dictionaries ... ok setting privileges on built-in objects ... ok creating information schema ... ok loading PL/pgSQL server-side language ... ok vacuuming database template1 ... ok copying template1 to template0 ... ok copying template1 to postgres ... ok WARNING: enabling trust authentication for local connections You can change this by editing pg_hba.conf or using the -A option the next time you run initdb. Success. You can now start the database server of the Postgres-XC coordinator using: postgres -C -D datanode2 or pg_ctl start -D datanode2 -Z coordinator -l logfile You can now start the database server of the Postgres-XC datanode using: postgres -X -D datanode2 or pg_ctl start -D datanode2 -Z datanode -l logfile invoke-rc.d: policy-rc.d denied execution of start. dpkg: error processing postgres-xc (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: postgres-xc Retrying manually and adding set -x before running dpkg-configure --pending results in [...] + i=9 + sleep 1 + '[' 9 -gt 10 ']' + '[' '!' -S /var/run/postgresql/.s.PGSQL.5432 ']' + i=10 + sleep 1 + '[' 10 -gt 10 ']' + '[' '!' -S /var/run/postgresql/.s.PGSQL.5432 ']' + i=11 + sleep 1 + '[' 11 -gt 10 ']' + exit 1 dpkg: error processing postgres-xc (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: postgres-xc Where should the socket come from? cheers, Andreas postgres-xc_1.0.0-1.log.gz Description: GNU Zip compressed data
Bug#679715: fs2ram: modifying files from another package
Package: fs2ram Version: 0.3.11 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package modifies files from another package. This is so wrong, I'm not even bothered to look up the part of policy this violates ;-P From the attached log (scroll to the bottom...): 0m25.1s ERROR: FAIL: After purging files have been modified: /etc/default/tmpfs owned by: initscripts cheers, Andreas fs2ram_0.3.11.log.gz Description: GNU Zip compressed data
Bug#679716: rpcbind: Please consider patch to enable socket-based activation for systemd
Package: rpcbind Version: 0.2.0-8 Severity: wishlist Hi, when installing the sysvinit replacement systemd, rpcbind is still started through LSB compatibility support by systemd. This results in rpcbind not being reliably started before any services that depend on rpcbind like NFS mounts. In our particular case, the home directory would not get mounted upon boot since systemd often tries to mount the home directory before it starts rpcbind due to the boot parallelization. A problem that we have also observed when using sysvinit when rpcbind might not get reliably started or crashes for whatever reason. To resolve this problem, systemd upstream has patched rpcbind to be compatible with socket-based activation [1]. With the patch, rpcbind will be started by systemd through socket-based activation and is hence always guaranteed to be available for services like NFS. While I understand that this patch might be problematic for Debian since it might trigger problems with the non-Linux kernels, I'd still like to point out the need for a socket-activated rpcbind and this patch. I will perfom some testing with a patched rpcbind on the kFreeBSD- and Hurd-based versions of Debian and report back. If rpcbind still continues to build and work fine on these platforms with sysvinit, the idea might not be too bad for Debian to patch rpcbind for socket-based activation, since it really improves reliability for NFS mounts. Thanks, Adrian [1] http://lists.freedesktop.org/archives/systemd-devel/2012-February/004336.html -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rpcbind depends on: ii initscripts 2.88dsf-22.1 ii insserv 1.14.0-3 ii libc62.13-33 ii libtirpc10.2.2-5 ii libwrap0 7.6.q-23 ii lsb-base 4.1+Debian7 rpcbind recommends no packages. rpcbind 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#679596: libghc-github-prof: Should be in contrib
Joey Hess wrote: http://lists.debian.org/20111204195557.ga11...@gnu.kitenet.net This seemed a good opportunity to expand that into a BoF, so I've submitted this: https://penta.debconf.org/penta/submission/dc12/event/931 classifying and exposing network dependencies Does youtube-dl belong in contrib if it depends on Youtube.com to function? What about xfce4-weather-plugin, with its less obvious dependency on a hardcoded Weather.com API key? What about flickrbackup, which obviously relies on a specific web site, but in a way that helps users avoid being locked into that site? A first step to resolving these questions is agreeing on package (or debtags) metadata that exposes network API dependencies, and classifies them along a spectrum from no dependence on specific servers, through default servers for open protocols, to dependency on proprietary services. -- see shy jo signature.asc Description: Digital signature
Bug#679717: accessodf: unowned files after purge (policy 6.8, 10.8)
Package: accessodf Version: 0.1-1.1 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...): 1m42.2s ERROR: FAIL: Package purging left files on system: /root/libreoffice/ not owned /root/libreoffice/3/ not owned /root/libreoffice/3/user/ not owned /root/libreoffice/3/user/config/ not owned /root/libreoffice/3/user/config/javasettings_Linux_X86_64.xml not owned /root/libreoffice/3/user/extensions/ not owned /root/libreoffice/3/user/extensions/bundled/ not owned /root/libreoffice/3/user/extensions/bundled/extensions.db not owned /root/libreoffice/3/user/extensions/bundled/lastsynchronized not owned /root/libreoffice/3/user/extensions/bundled/registry/ not owned /root/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.bundle.PackageRegistryBackend/ not owned /root/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/ not owned /root/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/ not owned /root/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml not owned /root/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.executable.PackageRegistryBackend/ not owned /root/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.help.PackageRegistryBackend/ not owned /root/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.help.PackageRegistryBackend/backenddb.xml not owned /root/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.script.PackageRegistryBackend/ not owned /root/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.sfwk.PackageRegistryBackend/ not owned /root/libreoffice/3/user/extensions/shared/not owned /root/libreoffice/3/user/extensions/shared/extensions.db not owned /root/libreoffice/3/user/extensions/shared/lastsynchronizednot owned /root/libreoffice/3/user/extensions/shared/log.txt not owned /root/libreoffice/3/user/extensions/shared/registry/ not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.bundle.PackageRegistryBackend/ not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.bundle.PackageRegistryBackend/backenddb.xml not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/ not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/Linux_X86_64.rdb not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/Linux_X86_64_.rdb not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/Linux_X86_64rc not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/backenddb.xml not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/common.rdb not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/common_.rdb not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/unorc not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/ not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/configmgr.ini not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lu2mpe1r.tmp/ not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lu2mpe1r.tmp/Addons.xcu not owned /root/libreoffice/3/user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lu2mpe1t.tmp/ not
Bug#679596: libghc-github-prof: Should be in contrib
On Sat, 2012-06-30 at 19:54 -0400, Joey Hess wrote: Joey Hess wrote: http://lists.debian.org/20111204195557.ga11...@gnu.kitenet.net This seemed a good opportunity to expand that into a BoF, so I've submitted this: https://penta.debconf.org/penta/submission/dc12/event/931 classifying and exposing network dependencies Does youtube-dl belong in contrib if it depends on Youtube.com to function? What about xfce4-weather-plugin, with its less obvious dependency on a hardcoded Weather.com API key? What about flickrbackup, which obviously relies on a specific web site, but in a way that helps users avoid being locked into that site? is this still the case, because if so, I would be happy to switch it over to using weather.gov and/or some other NOAA source directly for US weather. (this is the source for 99.9% of US weather data anyways) A first step to resolving these questions is agreeing on package (or debtags) metadata that exposes network API dependencies, and classifies them along a spectrum from no dependence on specific servers, through default servers for open protocols, to dependency on proprietary services. The reimplamentation of the github API argument you put forward just doesn't pan out. Sure I could re-implement the windows API too, (and Wine does so), but that doesn't mean that free windows software that DOESN'T work with wine could just be put in main willy-nilly. The desert Island test here is certainly the clearest here, if the software requires non-free software in order to be functional it belongs in contrib. -- -Shawn Landden -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679718: nginx: ship a nginx-source package for out-of-tree modules
Source: nginx Severity: normal I am interested in packaging passenger, which would provide a nginx-passenger package. However, to do so (while avoiding duplication) I believe I need nginx to provide a source package. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (101, 'unstable'), (1, 'experimental') Architecture: armel (armv5tel) Kernel: Linux 3.4.0-tomoyo-6-gfd64aac (PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) 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#679714: postgres-xc: fails to install: missing dependency on postgresql server?
On Sun, Jul 01, 2012 at 01:39:30AM +0200, Andreas Beckmann wrote: + '[' '!' -S /var/run/postgresql/.s.PGSQL.5432 ']' + i=11 + sleep 1 + '[' 11 -gt 10 ']' + exit 1 dpkg: error processing postgres-xc (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: postgres-xc Where should the socket come from? It created when coordinator starts. Try to start/stop it with init script and see what prevents to do so. *** ### Vladimir Stavrinov ### vstavri...@gmail.com *** -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679719: mdadm monthly cron job should NOT check all arays at the same time
Package: mdadm Version: 3.1.4-1+8efb9d1+squeeze1 Severity: normal I have deleted -- after finding through pain it existed -- the monthly mdadm cron job in cron.d. the problem is that this cron job will cause ALL raid's to be checked at the same time, causing a potentially very high I/O load. In my particular case with 2 RAID 6 and 2 RAID 5 it causes an I/O load that will overload the link between the CPU and the expansion cabinet. This WILL result in a number of disks being kicked from arrays, as they cannot answer in time. As it is not predictable which disks will be kicked, this can cause data loss resulting in the need to recover from backup. I have written a script in cron.daily what will cause each raid to be checked weekly, and never more then 1 at the same time. I am aware that in a profesional environment this problem should not occur. For home/small business users though a setup like mine is well usable. BUT care must be taken that the I/O rate remains within limites. And checking all raid at the same time can cause very significant The currently running recovery on the 2 raid 6 is causing an io load of about 1500 - 1600 tps. I have not checked what the limit is. Doing a check on all 4 raid is clearly over the limit though. -- Package-specific info: --- mdadm.conf DEVICE partitions CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST system MAILADDR r...@romunt.nl ARRAY /dev/md/0 metadata=1.2 UUID=0482022f:ea8b960d:d4f06e8c:cd86f783 name=mythfiler2:0 ARRAY /dev/md/1 metadata=1.2 UUID=08e1195f:ccecb5ca:f4ad5439:f950bc53 name=mythfiler2:1 ARRAY /dev/md/2 metadata=1.2 UUID=1f5e84d1:bb0477a4:96a852a0:29ec7e81 name=mythfiler2:2 ARRAY /dev/md4 metadata=1.2 name=mythfiler:4 UUID=045c7d02:f0d86b64:74bb6a9a:45589b23 --- /etc/default/mdadm INITRDSTART='none' AUTOSTART=true AUTOCHECK=true START_DAEMON=true DAEMON_OPTIONS=--syslog VERBOSE=false --- /proc/mdstat: Personalities : [raid6] [raid5] [raid4] md4 : active raid5 sda[0] sdf[4] sde[2] sdb[1] 4395405312 blocks super 1.2 level 5, 4096k chunk, algorithm 2 [4/4] [] md2 : active raid5 sdi[0] sdn[4] sdm[2] sdj[1] 4395405312 blocks super 1.2 level 5, 4096k chunk, algorithm 2 [4/4] [] md1 : active raid6 sdv[7](S) sdu[6] sdc[0] sdq[5] sds[4] sdk[1](F) sdo[2] sdg[3](F) 7814037504 blocks super 1.2 level 6, 4096k chunk, algorithm 2 [6/4] [U_U_UU] [] recovery = 0.3% (6986240/1953509376) finish=5639.4min speed=5752K/sec md0 : active raid6 sdw[7] sdd[6](F) sdt[5] sdr[4] sdp[3] sdl[2] sdh[1] 7814037504 blocks super 1.2 level 6, 4096k chunk, algorithm 2 [6/5] [_U] [] recovery = 0.4% (8924416/1953509376) finish=3129.2min speed=10356K/sec unused devices: none --- /proc/partitions: major minor #blocks name 1040 143367120 cciss/c0d0 1041 487424 cciss/c0d0p1 10425859328 cciss/c0d0p2 10435859328 cciss/c0d0p3 1044 1 cciss/c0d0p4 10455858304 cciss/c0d0p5 10463905536 cciss/c0d0p6 1047 14647296 cciss/c0d0p7 1048 106743808 cciss/c0d0p8 80 1465138584 sda 8 16 1465138584 sdb 8 32 1953514584 sdc 8 64 1465138584 sde 8 80 1465138584 sdf 8 112 1953514584 sdh 8 128 1465138584 sdi 8 144 1465138584 sdj 8 176 1953514584 sdl 8 192 1465138584 sdm 8 208 1465138584 sdn 8 224 1953514584 sdo 8 240 1953514584 sdp 650 1953514584 sdq 65 16 1953514584 sdr 65 32 1953514584 sds 65 48 1953514584 sdt 90 7814037504 md0 91 7814037504 md1 92 4395405312 md2 94 4395405312 md4 65 64 1953514584 sdu 65 80 1953514584 sdv 65 96 1953514584 sdw --- LVM physical volumes: LVM does not seem to be used. --- mount output /dev/cciss/c0d0p2 on / type xfs (rw) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/cciss/c0d0p1 on /boot type xfs (rw) /dev/cciss/c0d0p7 on /data/sql type xfs (rw) /dev/cciss/c0d0p8 on /home type xfs (rw) /dev/cciss/c0d0p6 on /tmp type xfs (rw) /dev/cciss/c0d0p5 on /var type xfs (rw) /dev/md0 on /data/mythstorage0 type xfs (rw) /dev/md1 on /data/mythstorage1 type xfs (rw) /dev/md2 on /data/huishouden type xfs (rw) /dev/md4 on /data/mythstorage2 type xfs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) --- initrd.img-2.6.38.6: 14563 blocks 2c62ad86f2b72f3d0118fa01e9dc9c8f ./etc/mdadm/mdadm.conf cb1cf979d6024e34c525db1cb6069ddd ./lib/modules/2.6.38.6/kernel/drivers/md/linear.ko
Bug#677825: Unable to update Twitter status
On Sun, 2012-07-01 at 01:34 +0200, Michael Stapelberg wrote: Hi Ben, Quoting Ben Hutchings (2012-06-18 00:49:28) Downgrading both tircd and libnet-twitter-lite-perl to the stable versions gives me a working system. So, at a guess, the problem is that one of the other dependencies needs to be versioned. It's a shame that upstream doesn't specify this. No, I don’t think so. I just installed a chroot with Debian stable, installed tircd (and I can tweet using tircd). Then I upgraded only tircd to the version in testing, and I can still tweet with it. Note that auto_post was not in the default configuration file on stable, so it’s set to undef. This means I can only tweet using !tweet foo or I have to add auto_post 1 to my config file. This seems to be the problem. tircd should have a built-in default of auto_post=1 (backward-compatible) in case the configuration file doesn't define it. Although /etc/tircd.cfg did get upgraded because I never modified it, I ~/.tircd obviously did not - and I forgot to look there previously, so I wrongly told you that auto_post was enabled. Can you still reproduce this issue? Could you also enable debug logging within tircd by using 'debug 1' in your config and provide me with the output when you can’t tweet? I’m also changing the bug severity to 'normal' since I cannot reproduce your issue and it is currently not proven that the package is unusable :-). We can change this later in case it needs to be changed. Sure, it's obviously not grave but I left it to you to work out what the proper severity was. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Bug#679461: pleiades: [INTL:de] Initial German debconf translation
On Fri, 29 Jun 2012 06:50:25 +0200 Christian PERRIER bubu...@debian.org wrote: please find attached the initial German debconf translation of pleiades. One string has been changed upstream after the call for translations to trop a double space. That fuzzies this translation for that string. Attached is a fixed version. Maintainer, please use that one. Thanks, applied. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679720: vsftpd uninstallable: init script syntax error
Package: vsftpd Version: 3.0.0-3 Severity: serious The installation fails with following message: /etc/init.d/vsftpd: 36: /etc/init.d/vsftpd: Syntax error: } unexpected invoke-rc.d: initscript vsftpd, action start failed. dpkg: error processing vsftpd (--configure): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: vsftpd Regards, Lifeng -- signature.asc Description: Digital signature
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
Anything happening on this bug? I note that wheezy still has it, and i have to manually mount my nfs after a reboot. cheers, Rudy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679721: midori just gets XML
Package: midori Version: 0.4.3-1 $ midori http://ppt.cc/sR5T #just gets XML $ firefox http://ppt.cc/sR5T #works fine -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-486 Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages midori depends on: ii dbus-x111.6.2-1 ii libc6 2.13-34 ii libcairo2 1.12.2-2 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libgtk2.0-0 2.24.10-1 ii libjavascriptcoregtk-1.0-0 1.8.1-3.1 ii libnotify4 0.7.5-1 ii libpango1.0-0 1.30.0-1 ii libsoup2.4-12.38.1-2 ii libsqlite3-03.7.13-1 ii libunique-1.0-0 1.1.6-4 ii libwebkitgtk-1.0-0 1.8.1-3.1 ii libx11-62:1.5.0-1 ii libxml2 2.8.0+dfsg1-4 ii libxss1 1:1.2.2-1 Versions of packages midori recommends: ii gnome-icon-theme 3.4.0-2 midori 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#679687: mkinitrd no longer exists
I confim the bug reported by Rupert Swarbrick. But even pointing those two lines to the the right place, it won't work because the command mkinitrd invoked on /usr/lib/i386-linux-gnu/plymouth/plymouth-update-initrd no longer exists on my system. For me it worked editing /usr/lib/i386-linux-gnu/plymouth/plymouth-update-initrd to: #!/bin/bash update-initramfs -u -k $(uname -r) Krishnamurti Lelis Lima Vieira Nunes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679722: python-dev: none
Package: python-dev Severity: low Dear Maintainer, python-dev has circular or incorrect dependencies in testing. I can get around this by using aptitude to install the 2.7.3-1 package. sudo apt-get install python-dev build-essential python-pip Reading package lists... Done Building dependency tree Reading state information... Done build-essential is already the newest version. Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python-dev : Depends: python2.7-dev (= 2.7.3~rc2-1~) but it is not going to be installed E: Broken packages sudo apt-get install python2.7-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python2.7-dev : Depends: python2.7 (= 2.7.3~rc2-2.1) but 2.7.3-1 is to be installed Depends: libpython2.7 (= 2.7.3~rc2-2.1) but 2.7.3-1 is to be installed E: Broken packages -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (600, 'stable'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Michael Tomkins mic...@gmail.com +61 408 172 142 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679596: libghc-github-prof: Should be in contrib
shawn wrote: is this still the case, because if so, I would be happy to switch it over to using weather.gov and/or some other NOAA source directly for US weather. (this is the source for 99.9% of US weather data anyways) http://bugs.debian.org/647749 -- see shy jo signature.asc Description: Digital signature
Bug#679687: plymouth: initramfs hook fails to find renderers with multi-arch
severity 679687 grave thanks dj_palindrome wrote (30 Jun 2012 23:11:14 GMT) : This package seems to have similar initramfs-hooks problems on amd64, and the only solution I've found is to revert to plymouth 0.8.5.1-1. Perhaps someone more knowledgeable than myself would consider whether this warrants escalation to grave. Fails here too. I don't see how the package can be usable with this bug, so I'm bumping the severity to grave. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678247: Thanks for the troubleshooting
I've looked into this a bit and the bogus proxy host is a function of whatever debconf feeds to the postinst. I can't tell if it's inadvertent data entry or some other issue, but it's not a clamav bug. The part of this that is a clamav bug is that if the proxy port is not specified, the hostname is incorrectly and blindly copied into the configuration file as the port number. This is obviously a bug and inconsistent with the debconf template that promises the port entry is optional. I'll fix the postinst to behave the way the template says it will. signature.asc Description: This is a digitally signed message part.
Bug#678979: postgresql-9.1-slony1-2: Slony 2.0.7 is not supported with Postgresql 9.1
No, I meant that stable has slony for 8.4, and testing (the next stable) has slony for 9.1, which means someone upgrading from stable to the next stable won't experience a regression, except that they will need to make sure they use the repeatable read isolation level. Testing is currently frozen, so putting in a new major upstream release is not possible. The problem is that slony 2.0.x (slon) opens up serializable transactions that caues the conflicts. This can happen even if user applications only perform repeatable read transactions. The transactions will be retried after they are aborted so they should eventually get through. If updating the upstream release isn't possible then it isn't possible, there isn't much that I can say to that. The feedback we received from sites that deployed the PG 9.1 + Slony 2.0.7 combination is what lead to the bug report and fix in 2.1 in the winter.
Bug#638741: test results
Hi, Hope you guys don't mind if I just jump in here and try to cool down the discussion, since it's getting kinda flamy. * Goswin von Brederlow wrote: That was 10 month ago. A revised patch came in December, still 6 month for you to do something. Your first response was Fri, 29 Jun 2012 23:27:51 +0930. There is only one person to blame for not applying the patch or raising concerns about it in a timely fashion and that is you. Ron mentioned he took over the package a few weeks back [0], so this blame shifting isn't really accurate (not to mention it's IMHO a bit too confrontational to be constructive; though I understand you were reacting to a equally confrontational comment from the previous email). To get some distance and perspective I'd suggest referring this to the release-team: if they see the possible downfall as an acceptable trade-off for the multi-arch release goal, then go ahead with the patching, uploading and fixing bugs as they appear. Otherwise leave it be. Cheers [0] http://packages.qa.debian.org/liba/libao/news/20120602T121911Z.html -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678247: Fix debdiff
Attached.diff -u clamav-0.97.5+dfsg/debian/changelog clamav-0.97.5+dfsg/debian/changelog --- clamav-0.97.5+dfsg/debian/changelog +++ clamav-0.97.5+dfsg/debian/changelog @@ -1,3 +1,11 @@ +clamav (0.97.5+dfsg-3) unstable; urgency=low + + * Fix proxy port configuration handling in clamav-freshclam.postinst so that +failure to specify port does not result in an invalid configuration +(Closes: #678247), (LP: #784797) + + -- Scott Kitterman sc...@kitterman.com Sat, 30 Jun 2012 21:35:33 -0400 + clamav (0.97.5+dfsg-2) unstable; urgency=medium * Medium urgency due to security fixes diff -u clamav-0.97.5+dfsg/debian/clamav-freshclam.postinst.in clamav-0.97.5+dfsg/debian/clamav-freshclam.postinst.in --- clamav-0.97.5+dfsg/debian/clamav-freshclam.postinst.in +++ clamav-0.97.5+dfsg/debian/clamav-freshclam.postinst.in @@ -81,6 +81,9 @@ url=`echo $RET | sed -e 's,^http://,,g' | sed -e 's,/$,,g'` phost=`echo $url | cut -d':' -f 1` pport=`echo $url | cut -d':' -f 2` +if [ $pport = $phost ]; then +pport= +fi fullurl=$RET db_metaget clamav-freshclam/proxy_user value || true if [ $RET != ]; then @@ -239,10 +242,12 @@ grep -q $m $DEBCONFILE || echo DatabaseMirror $m $DEBCONFILE done - if [ -n $phost ] [ -n $pport ]; then + if [ -n $phost ]; then echo # Proxy: $fullurl $DEBCONFILE echo HTTPProxyServer $phost $DEBCONFILE -echo HTTPProxyPort $pport $DEBCONFILE +if [ -n $pport ]; then + echo HTTPProxyPort $pport $DEBCONFILE +fi fi if [ -n $puser ] [ -n $ppass ]; then echo # Proxy authentication: $fulluser $DEBCONFILE
Bug#679723: mysqld: started using loads of CPU when leapsecond passed
Package: mysql-server-core-5.5 Version: 5.5.24+dfsg-4 My mysqld recently started using loads of CPU, on two different computers. There was no obvious reason, and restarting the daemon did not appear to help. Finding a thread about mythtv suggested a possible reason: the leap second which occurred at 23:59:60 GMT on 30 June 2012 (about 3 hours ago now). Rebooting the computer seems to have sorted the problem. Obviously, this is going to be hard to reproduce and test - either it will have happened to lots of people or not, and it probably won't be reproducible until the next leap second occurs :-( I'm running kernel 3.2.0-2-amd64 (linux-image 3.2.20-1) and running ntpd. Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549681: bug#549681: mkvmlinuz: use xz to compress vmlinuz-boxed initrd
some OpenFirmware implementations, such as the one in the PegasosII, have a 12 MB size limit on kernel images, and no initrd loading capability. The latter is worked around by merging the initrd into the image with the mkvmlinuz tool, however the generated images are unbootable if they exceed 12 MB. The attached patch brings vmlinuz from about 13MB to about 9.5MB, which is well under the 12MB limit. Downside is that xz compressing is noticeably slower than currently used gzip, but decompressing speed difference is not noticeable. I've tested it on Pegasos II machine, it boots really fast. Updated mkvmlinuz package is waiting on mentors.debian.net for a willing sponsor for upload. Milan Index: mkvmlinuz === --- mkvmlinuz (revision 19233) +++ mkvmlinuz (working copy) @@ -133,11 +133,6 @@ # if no release was specified, extract it from the kernel image name if test -z $release; then release=$(echo $kernel | sed s/.*vmlinux-//) -if echo $release | grep -q '2\.[46]\.[0-9]*'; then - : -else - release= -fi fi if dpkg --compare-versions $release ge 2.6.16 test $arch != prep ; then @@ -158,6 +153,12 @@ post_2_6_19= fi +if dpkg --compare-versions $release ge 2.6.38 test $arch != prep ; then + post_2_6_38=Yes +else + post_2_6_38= +fi + test -z $verbose || echo === Release version seems to be $release. # if no object file directory was specified, try to find one @@ -206,6 +207,11 @@ test -z $verbose || echo === Doing build in $work. # utilities +if test $post_2_6_38; then + XZ=xz --check=crc32 -8 +else + XZ=false +fi if test $post_2_6_16; then ADDNOTE=$objdir/addnote # must be present in mkvmlinuz fallback tools if test \! -f $ADDNOTE; then @@ -291,22 +297,35 @@ # create the compressed initrd image file if test -n $initrd; then -test -z $verbose || echo === Creating compressed initrd image initrd.gz... +test -z $verbose || echo === Creating compressed initrd image if test -z $compressed; then -# Detect if the file was already compressed by gzip. - if test `od -A n -c -N 2 $initrd` = 037 213; then - compressed=Yes + if test `xxd -p -l2 $initrd` = 1f8b; then + test -z $verbose || echo === $initrd is already gzip compressed + do_cmd cp -p $initrd $work/initrd.gz + if test -n $post_2_6_38 test $arch != prep; then + test -z $verbose || echo === recompressing to xz + zcat $initrd | $XZ - $work/initrd.xz + fi + elif test `xxd -p -l6 $initrd` = fd377a585a00; then + test -z $verbose || echo === $initrd is already xz compressed + do_cmd cp -p $initrd $work/initrd.xz else + test -z $verbose || echo === assuming $initrd was not compressed compressed=No fi fi case $compressed in Yes) do_cmd cp -p $initrd $work/initrd.gz + do_cmd ln -s $work/initrd.gz $work/initrd.xz ;; No) do_cmd cp -p $initrd $work/initrd - do_cmd $GZIP $work/initrd + if test -n $post_2_6_38 test $arch != prep; then + do_cmd $XZ $work/initrd + else + do_cmd $GZIP $work/initrd + fi ;; esac fi @@ -317,7 +336,11 @@ WRAPPER=$objdir/wrapper vmlinuz=$work/vmlinuz.$arch if test -n $initrd; then -INITRD=-i $work/initrd.gz +if test $post_2_6_38; then + INITRD=-i $work/initrd.xz +else + INITRD=-i $work/initrd.gz +fi fi $WRAPPER -c -o $vmlinuz -p $arch $INITRD -D $objdir -W $work $kernel else signature.asc Description: OpenPGP digital signature
Bug#676144: llvm-3.1 doesn't introduce line number information recognizable by gdb
Le 30/06/2012 20:29, Ben Longbons a écrit : The bug is actually in llvm. The attached patch reverts the change that broke it. (Note that llvm does not have point releases, it is a long time to 3.2, and this bug is severe enough to make the package unusable for development, so you have to patch it) OK. I will be my first wheezy-freeze exception :p S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679723: [debian-mysql] Bug#679723: mysqld: started using loads of CPU when leapsecond passed
Actually on my Linux system it the mysqld process has the hghest CPU: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2560 mysql 20 0 408m 2372 692 S 53 0.1 155:39.60 mysqld On kreebsd-i386 its low 74852 mysql128 0 223m 32m0 S 0.0 1.6 3:30.71 mysqld I tried an strace root@taylor:/tmp# strace -p 2560 Process 2560 attached - interrupt to quit restart_syscall(... resuming interrupted call ... I'm thinking what else I can do to investigate. On 01/07/12 03:55, Julian Gilbey wrote: Package: mysql-server-core-5.5 Version: 5.5.24+dfsg-4 My mysqld recently started using loads of CPU, on two different computers. There was no obvious reason, and restarting the daemon did not appear to help. Finding a thread about mythtv suggested a possible reason: the leap second which occurred at 23:59:60 GMT on 30 June 2012 (about 3 hours ago now). Rebooting the computer seems to have sorted the problem. Obviously, this is going to be hard to reproduce and test - either it will have happened to lots of people or not, and it probably won't be reproducible until the next leap second occurs :-( I'm running kernel 3.2.0-2-amd64 (linux-image 3.2.20-1) and running ntpd. Julian ___ pkg-mysql-maint mailing list pkg-mysql-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676009: patch available
tags 676009 patch thanks Tz-Huan has uploaded a patch for this issue to the git packaging repo on collab-maint but apparently he hasn't had the time to announce it here, yet. Thanks, Tz-Huan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679724: scim FTFBS on all arches but i386
Package: scim Version: 1.4.14-1 Severity: serious Justification: FTFBS The latest upload of scim is affected by FTFBS. This is another multi-arch related issue, the build fails in dh_install. It seems that for some reason i386 arch does not properly build some of the packages with multi-arch paths and fails if that is assumed. https://buildd.debian.org/status/package.php?p=scim has logs Just in case it was not clear, I am the maintainer of the package and will deal with uploading a fix in due time. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679723: [debian-mysql] Bug#679723: Bug#679723: mysqld: started using loads of CPU when leapsecond passed
forwarded 679723 http://bugs.mysql.com/bug.php?id=65778 thanks Mozilla IT report the same issue and a possible work around. http://blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/ On 01/07/12 04:28, Nicholas Bamber wrote: Actually on my Linux system it the mysqld process has the hghest CPU: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2560 mysql 20 0 408m 2372 692 S 53 0.1 155:39.60 mysqld On kreebsd-i386 its low 74852 mysql128 0 223m 32m0 S 0.0 1.6 3:30.71 mysqld I tried an strace root@taylor:/tmp# strace -p 2560 Process 2560 attached - interrupt to quit restart_syscall(... resuming interrupted call ... I'm thinking what else I can do to investigate. On 01/07/12 03:55, Julian Gilbey wrote: Package: mysql-server-core-5.5 Version: 5.5.24+dfsg-4 My mysqld recently started using loads of CPU, on two different computers. There was no obvious reason, and restarting the daemon did not appear to help. Finding a thread about mythtv suggested a possible reason: the leap second which occurred at 23:59:60 GMT on 30 June 2012 (about 3 hours ago now). Rebooting the computer seems to have sorted the problem. Obviously, this is going to be hard to reproduce and test - either it will have happened to lots of people or not, and it probably won't be reproducible until the next leap second occurs :-( I'm running kernel 3.2.0-2-amd64 (linux-image 3.2.20-1) and running ntpd. Julian ___ pkg-mysql-maint mailing list pkg-mysql-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint ___ pkg-mysql-maint mailing list pkg-mysql-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674634: transition: celt
On Sun, Jul 01, 2012 at 01:16:17AM +0200, Julien Cristau wrote: On Sat, May 26, 2012 at 18:38:11 +0930, Ron wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We'd like to remove the celt package from the distro for the Wheezy release. CELT was an experimental codec from Xiph, and that work has now been merged into the Opus codec which is about to be ratified as an IETF standard. The only rdep left in testing at this point is mumble. What's the plan here? There are too many things that still need fixing with mumble at this stage for me to recommend it as a viable release candidate for wheezy. It currently FTBFS now that boost1.46 was removed, and I don't know yet if that will just need the build-dep adjusted, or actual changes to the source - which is kind of academic while it's also still blocked by the zeroc-ice ABI breakage of #672066 (which at this stage is debian specific, and we have no idea what zeroc-ice upstream is really going to do to make it work with gcc 4.7). So the best plan I have right now would be to remove mumble from testing and worry about fixing its problems in unstable with a free hand (knowing we won't be annoying the release team with large patches to review - which I'm pretty sure it's going to need still before this is all in good shape again). That will let you close this bug - and also give you the option of removing zeroc-ice too if that bug doesn't get a sane fix soon (since mumble is also its only rdep). Shipping that in its current state doesn't really seem like something I'd recommend either, but that one is less of my call to make ... Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679725: RFP: staf -- Software Testing Automation Framework
Package: wnpp Severity: wishlist * Package name: staf Version : 3.4.10 * URL : http://staf.sourceforge.net/index.php * License : Eclipse Public License (EPL) V1.0 (http://www.opensource.org/licenses/eclipse-1.0.php) Programming Lang: Seems to be Java mainly but it supports a variety of languages Description : Software Testing Automation Framework The Software Testing Automation Framework (STAF) is an open source, multi-platform, multi-language framework designed around the idea of reusable components, called services (such as process invocation, resource management, logging, and monitoring). STAF removes the tedium of building an automation infrastructure, thus enabling you to focus on building your automation solution. The STAF framework provides the foundation upon which to build higher level solutions, and provides a pluggable approach supported across a large variety of platforms and languages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
On Sun, Jul 01, 2012 at 03:58:45AM +0200, Leo 'costela' Antunes wrote: Hi, Hope you guys don't mind if I just jump in here and try to cool down the discussion, since it's getting kinda flamy. Yeah, that tends to happen when people get tired of repeating themselves to Goswin, and he keeping wanting to harp on about it ... This already got resolved on IRC, and I only replied here to make it clear to anyone looking at the bug that this really was off the table for Wheezy now. The discussion can't really get much cooler than Wheezy is now frozen. To get some distance and perspective I'd suggest referring this to the release-team: if they see the possible downfall as an acceptable trade-off for the multi-arch release goal, then go ahead with the patching, uploading and fixing bugs as they appear. Otherwise leave it be. So let's not annoy them with this now please. The only possible outcome of doing this now for them is more pain and more work and more delays before we are in a state to release. It will make it impossible for them to binNMU this package should it need it, and it will burn up their time needing to review patches that really aren't fixing anything that is remotely release critical. And they already have enough people requesting crazy freeze exceptions from them ... If nobody noticed they needed an m-a version of this before now, then clearly it's not a high priority for them, and it can easily wait until there is a better time to start experimenting with this again. The sooner the remaining RC bugs are fixed and we release, the sooner that will happen. This is how release cycles work. It's too late for untested things now. But thanks for the good intentions, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679726: schroot: error messages on exit
Package: schroot Version: 1.6.0-1 Severity: minor Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? I enter the schroot and exit and get an error message: sisyphus@taylor:~/chroot-sid$ schroot -c sisyphus (sisyphus)sisyphus@taylor:~/chroot-sid$ exit logout E: 10mount: /sbin/umount.aufs:plink.c:223: proc: No such file or directory E: 10mount: /sbin/umount.aufs:plink.c:223: proc: No such file or directory E: sisyphus-4723cc80-05b7-4599-8631-6cb1c35ee405: Chroot setup failed: stage=setup-stop -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages schroot depends on: ii libboost-filesystem1.49.0 1.49.0-3.1 ii libboost-iostreams1.49.01.49.0-3 ii libboost-program-options1.49.0 1.49.0-3.1 ii libboost-regex1.49.01.49.0-3.1 ii libboost-system1.49.0 1.49.0-3.1 ii libc6 2.13-32 ii libgcc1 1:4.6.3-1 ii liblockdev1 1.0.3-1.4+b2 ii libpam0g1.1.3-7.1 ii libstdc++6 4.6.3-1 ii libuuid12.20.1-5 ii schroot-common 1.6.0-1 schroot recommends no packages. Versions of packages schroot suggests: pn aufs-modules | unionfs-modules none pn btrfs-tools none pn debootstrap 1.0.40 pn lvm2none pn qemu-user-staticnone -- Configuration Files: /etc/schroot/schroot.conf changed: [sisyphus] description=Sisyphus sid (unstable) type=directory union-type=aufs directory=/home/sisyphus/chroot-sid users=nicholas,sisyphus groups=sbuild root-users=sisyphus -- 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#567849: install-info: warning: no info dir entry
On Fri, 29 Jun 2012, Julian Gilbey wrote: Hi Don! On Wed, Jun 13, 2012 at 07:45:43AM +0100, Julian Gilbey wrote: On Thu, Oct 06, 2011 at 04:17:59PM +0200, Paul Menzel wrote: When installing lilypond on unstable, I get following warnings. They pop up evertime install-info is triggered. install-info: warning: no info dir entry in `/usr/share/info/lilypond.info-images-dir-dep.gz' [...] I've fixed the problem. Attached is a diff of my proposed version; it would be great to upload it before the freeze. I'll upload it as an NMU tomorrow evening unless you either have a chance to apply the patch before then or tell me not to. Unfortunately, this patch is basically unusable, because it's screwed up the encoding. [It doesn't appear to be UTF8 any longer.] Don Armstrong -- Identical parts aren't. -- Beach's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679727: RM: netapplet/1.0.8 -- ROM
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm netapplet was meant to offer a user-friendly interface for dealing with networking configuration for the GNOME desktop. Currently there are better options and the package lacks of upstream. I've orphaned it before since I cannot commit to act both as upstream and maintainer for a stable release, despite better options exist now for the GNOME desktop. Thanks, Rudy -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Rudy Godoy http://stone-head.org signature.asc Description: Digital signature
Bug#679728: systemd: diversion removed in postinst, should be removed in preinst
Package: systemd Version: 44-2 Severity: serious This breaks other packages installed in the same apt run. 00:12 uau Mithrandir: with latest debian systemd package, /lib/lsb/init-functions doesn't exist between unpacking and postinst that removes diversion 00:12 uau /etc/init.d/vsftpd: 22: .: Can't open /lib/lsb/init-functions - vsftpd prerm executed during that interval -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.4.0 (SMP w/4 CPU cores) Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii dpkg 1.16.4.3 ii initscripts 2.88dsf-22.1 ii libacl1 2.2.51-8 ii libaudit01:1.7.18-1.1 ii libc62.13-33 ii libcap2 1:2.22-1 ii libcryptsetup4 2:1.4.3-2 ii libdbus-1-3 1.6.0-1 ii libkmod2 8-2 ii liblzma5 5.1.1alpha+20120614-1 ii libpam0g 1.1.3-7.1 ii libselinux1 2.1.9-5 ii libsystemd-daemon0 44-2 ii libsystemd-id128-0 44-2 ii libsystemd-journal0 44-2 ii libsystemd-login044-2 ii libudev0 175-3.1 ii libwrap0 7.6.q-23 ii udev 175-3.1 ii util-linux 2.20.1-5.1 Versions of packages systemd recommends: ii libpam-systemd 44-2 Versions of packages systemd suggests: ii python2.7.3~rc2-1 ii python-cairo 1.8.8-1+b2 ii python-dbus 1.1.0-1 pn systemd-gui none -- no debconf information -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
