Bug#613669: python-rbtools: New upstream version available
Package: python-rbtools Severity: wishlist There's a new upstream version available, 0.3.2: http://www.reviewboard.org/docs/releasenotes/dev/rbtools/0.3.2/ Could you please update the Debian package? Thanks, -Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535541: reviewboard: New upstream version available (1.5.2)
Package: reviewboard Severity: normal Review Board is now available as version 1.5.2, which has lots of improvements. I wish it would get packaged. :-) -Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609540: iftop: Silently SIGSEVs on certain interfaces (ppp0, sixxs)
Package: iftop Version: 0.17-17 Severity: important I just pulled 0.17-17 from experimental in order to get IPv6 support. Now I cannot get iftop to work on any interfaces other than eth0 and lo. If, e.g., I run it on the ppp0 (PPP) or sixxs (tunnel) interface, it merely prints the interface name and exits with an exit code of 139, which I think means it died from SIGSEV: $ sudo iftop interface: eth0 IP address is: 192.168.0.1 IPv6 address is: 2001:a60:f01d::1 MAC address is: 00:30:1b:bd:30:df [starts up ncurses view] $ sudo iftop -i eth0 interface: eth0 IP address is: 192.168.0.1 IPv6 address is: 2001:a60:f01d::1 MAC address is: 00:30:1b:bd:30:df [starts up ncurses view] $ sudo iftop -i lo interface: lo IP address is: 127.0.0.1 IPv6 address is: ::1 MAC address is: 00:00:00:00:00:00 [starts up ncurses view] $ sudo iftop -i ppp0 interface: ppp0 $ echo $? 139 $ sudo iftop -i sixxs interface: sixxs $ echo $? 139 Doesn't happen with 0.17-16. -Julian -- System Information: Debian Release: 6.0 APT prefers testing APT policy: (600, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages iftop depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libncurses5 5.7+20100313-4 shared libraries for terminal hand ii libpcap0.81.1.1-2system interface for user-level pa iftop recommends no packages. iftop 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#598447: postgresql-9.0: provide a usable way of upgrade from previous 8.4 server
For the record, it worked fine when I just installed the 9.0 packages: $ sudo aptitude [selected packages in UI] Reading changelogs... Done apt-listchanges: Do you want to continue? [Y/n] Preconfiguring packages ... (Reading database ... 149860 files and directories currently installed.) Preparing to replace libpq5 8.4.2-2+b1 (using .../libpq5_9.0.0-3_amd64.deb) ... Unpacking replacement libpq5 ... Preparing to replace postgresql-client-common 110 (using .../postgresql-client-common_111_all.deb) ... Unpacking replacement postgresql-client-common ... Selecting previously deselected package postgresql-client-9.0. Unpacking postgresql-client-9.0 (from .../postgresql-client-9.0_9.0.0-3_amd64.deb) ... Preparing to replace postgresql-common 110 (using .../postgresql-common_111_all.deb) ... Stopping PostgreSQL 8.4 database server: main. Fixing init script priority of /etc/rc2.d/S20postgresql to S19... Fixing init script priority of /etc/rc3.d/S20postgresql to S19... Fixing init script priority of /etc/rc4.d/S20postgresql to S19... Fixing init script priority of /etc/rc5.d/S20postgresql to S19... Fixing init script priority of /etc/rc0.d/K20postgresql to K21... Fixing init script priority of /etc/rc1.d/K20postgresql to K21... Fixing init script priority of /etc/rc6.d/K20postgresql to K21... Unpacking replacement postgresql-common ... Selecting previously deselected package postgresql-9.0. Unpacking postgresql-9.0 (from .../postgresql-9.0_9.0.0-3_amd64.deb) ... Preparing to replace postgresql 8.4.4-2 (using .../postgresql_9.0.0-3_all.deb) ... Unpacking replacement postgresql ... Preparing to replace postgresql-client 8.4.4-2 (using .../postgresql-client_9.0.0-3_all.deb) ... Unpacking replacement postgresql-client ... Selecting previously deselected package postgresql-contrib-9.0. Unpacking postgresql-contrib-9.0 (from .../postgresql-contrib-9.0_9.0.0-3_amd64.deb) ... Preparing to replace postgresql-contrib 8.4.4-2 (using .../postgresql-contrib_9.0.0-3_all.deb) ... Unpacking replacement postgresql-contrib ... Selecting previously deselected package postgresql-plperl-9.0. Unpacking postgresql-plperl-9.0 (from .../postgresql-plperl-9.0_9.0.0-3_amd64.deb) ... Selecting previously deselected package postgresql-plpython-9.0. Unpacking postgresql-plpython-9.0 (from .../postgresql-plpython-9.0_9.0.0-3_amd64.deb) ... Processing triggers for man-db ... Setting up libpq5 (9.0.0-3) ... Setting up postgresql-client-common (111) ... Setting up postgresql-client-9.0 (9.0.0-3) ... update-alternatives: using /usr/share/postgresql/9.0/man/man1/psql.1.gz to provide /usr/share/man/man1/psql.1.gz (psql.1.gz) in auto mode. Setting up postgresql-common (111) ... Starting PostgreSQL 8.4 database server: main. Setting up postgresql-9.0 (9.0.0-3) ... Creating new cluster (configuration: /etc/postgresql/9.0/main, data: /var/lib/postgresql/9.0/main)... Moving configuration file /var/lib/postgresql/9.0/main/postgresql.conf to /etc/postgresql/9.0/main... Moving configuration file /var/lib/postgresql/9.0/main/pg_hba.conf to /etc/postgresql/9.0/main... Moving configuration file /var/lib/postgresql/9.0/main/pg_ident.conf to /etc/postgresql/9.0/main... Configuring postgresql.conf to use port 5433... update-alternatives: using /usr/share/postgresql/9.0/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode. Starting PostgreSQL 9.0 database server: main. Setting up postgresql (9.0.0-3) ... Setting up postgresql-client (9.0.0-3) ... Setting up postgresql-contrib-9.0 (9.0.0-3) ... Setting up postgresql-contrib (9.0.0-3) ... Setting up postgresql-plperl-9.0 (9.0.0-3) ... Setting up postgresql-plpython-9.0 (9.0.0-3) ... Press return to continue. $ pg_lsclusters Version Cluster Port Status OwnerData directory Log file 8.4 main 5432 online postgres /var/lib/postgresql/8.4/main /var/log/postgresql/postgresql-8.4-main.log 9.0 main 5433 online postgres /var/lib/postgresql/9.0/main /var/log/postgresql/postgresql-9.0-main.log So there's nothing *fundamentally* broken. There may still be a bug that causes the creation of the 9.0 cluster to fail under *specific* circum- stances, of course. BTW, Martin, thanks for your great work on the PostgreSQL packages! I appreciate it very much. -Julian signature.asc Description: This is a digitally signed message part.
Bug#592835: 2.04 available + menu patch + debian/ modernization
Package: transmission Is there anything hindering an upload of 2.04 to unstable? I don't care so much about the patch presented by Barak (no offense) as about being able to upgrade to vanilla 2.04. TIA, -Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592835: 2.04 available + menu patch + debian/ modernization
Leo 'costela' Antunes wrote: On 24/09/10 18:58, Julian Mehnle wrote: Is there anything hindering an upload of 2.04 to unstable? Yes, the freeze[0]. I know about the freeze. However, I thought that just affected the migration of packages from unstable to testing? I use testing and am comfortable with installing packages from unstable. I'm not after getting 2.04 into squeeze. What's your reason for the upgrade? Are you being hit by one of the bugs closed in 2.04? No. Upstream asked me to verify whether a certain bug still exists in 2.04 and I was only able to confirm that it still exists in 2.03. -Julian signature.asc Description: This is a digitally signed message part.
Bug#592835: 2.04 available + menu patch + debian/ modernization
Experimental is cool, too. Thanks. -Julian signature.asc Description: This is a digitally signed message part.
Bug#580226: wkhtmltopdf: 0.9.0+ can run without an X server (package description is misleading)
package wkhtmltopdf retitle 580226 wkhtmltopdf: Do not require a running X server severity 580226 wishlist thanks Emmanuel Bouthenot wrote: Unless for some reason the QT dependency chain within Debian still makes a running X server necessary, the package description should be adjusted to not say This program requires an X11 server to run. Actually, wkhtmltopdf needs a patched QT to work without X. This patch is provided by the upstream developer but it is not suitable for Debian. I see. I'm changing this to a wishlist bug to make wkhtmltopdf run without an X server eventually. Even if it never happens, this bug report can serve as a pointer to the following workaround: If you install the xvfb package, you can use the xvfb-run script like this, without a real X server running: $ xvfb-run wkhtmltopdf ... -Julian signature.asc Description: This is a digitally signed message part.
Bug#580226: wkhtmltopdf: 0.9.0+ can run without an X server (package description is misleading)
Package: wkhtmltopdf Version: 0.9.0-1 Severity: normal The requirement for a running X server has been removed as on 0.9.0: http://code.google.com/p/wkhtmltopdf/issues/detail?id=3 Unless for some reason the QT dependency chain within Debian still makes a running X server necessary, the package description should be adjusted to not say This program requires an X11 server to run. -Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545224: grub-pc: Makes xen-hypervisor-3.2-1-amd64 hang with early fatal page fault on boot
This is possibly also related to the problem described here (in German only, unfornately): http://www.ctserver.org/viewtopic.php?t=2676highlight=ownder http://www.heise.de/ct/projekte/machmit/ctserver/ticket/102 So perhaps specifying pci=nomsi on the kernel command line is a working stop gap measure. I'll investigate some more. -Julian signature.asc Description: This is a digitally signed message part.
Bug#553896: mdadm: update-initramfs warning due to /dev/md/0 vs. /dev/md0.
martin f krafft wrote: Which sensitive bits? I am asking to be able to improve the bug script. Several bind mounts that were much more specific than the typical mount point. Serial numbers in hard disk device names. Stuff like that. I cannot figure out from the bugscript what your problem is. Hopefully you'll be able to spot the issue soon. I'll make another attempt at upgrading my system, although it make take me another two or three weeks before I get to it. Right now is not a good time. Thanks, -Julian signature.asc Description: This is a digitally signed message part.
Bug#553896: mdadm: update-initramfs warning due to /dev/md/0 vs. /dev/md0.
I've been having the same problem. I'm attaching my mdadm bug script output (with a few sensitive bits redacted). Also: | $ sudo mdadm -Ds | ARRAY /dev/md/0 metadata=0.90 UUID=222a461f:8303a4d2:4a90023e:7c4f4b06 -Julian --- mount output /dev/mapper/vg0-main_crypt on / type xfs (rw,noatime) 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) fusectl on /sys/fs/fuse/connections type fusectl (rw) /dev/mapper/vg0-boot on /boot type xfs (rw,noatime) /dev/mapper/vg0-bare on /media/bare type xfs (rw,noatime) /dev/mapper/usbdisk0_crypt on /media/usbdisk0 type fuseblk (rw,noexec,nosuid,nodev,allow_other,default_permissions,blksize=4096) /dev/sdd1 on /media/usbdisk1 type fuseblk (rw,noexec,nosuid,nodev,allow_other,default_permissions,blksize=4096) (bind mounts redacted for privacy reasons) --- mdadm.conf # mdadm.conf # # Please refer to mdadm.conf(5) for information about this file. # # by default, scan all partitions (/proc/partitions) for MD superblocks. # alternatively, specify devices to scan, using wildcards if desired. DEVICE partitions # auto-create devices with Debian standard permissions CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system HOMEHOST system # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays #ARRAY /dev/md0 level=raid1 num-devices=2 UUID=222a461f:8303a4d2:53851496:d0cc6843 #ARRAY /dev/md/0 level=raid1 num-devices=2 UUID=222a461f:8303a4d2:53851496:d0cc6843 #ARRAY /dev/md0 level=raid1 num-devices=2 UUID=222a461f:8303a4d2:4a90023e:7c4f4b06 ARRAY /dev/md/0 level=raid1 num-devices=2 UUID=222a461f:8303a4d2:4a90023e:7c4f4b06 # This file was auto-generated on Thu, 25 Dec 2008 23:23:49 + # by mkconf $Id$ --- /proc/mdstat: Personalities : [raid1] md0 : active raid1 sda1[0] sdb1[1] 488383936 blocks [2/2] [UU] bitmap: 6/233 pages [24KB], 1024KB chunk unused devices: none --- /proc/partitions: major minor #blocks name 80 488386584 sda 81 488384001 sda1 8 16 488386584 sdb 8 17 488384001 sdb1 90 488383936 md0 2530 122880 dm-0 2531 456257536 dm-1 2532 32002048 dm-2 8 32 488386584 sdc 8 33 32098 sdc1 8 34 488351902 sdc2 8 48 488386584 sdd 8 49 488384001 sdd1 2533 456256508 dm-3 2534 488351386 dm-4 --- initrd.img-2.6.30-2-amd64: 50770 blocks 66818791d08ce4ca57f4989c6e3b7d54 ./etc/mdadm/mdadm.conf 13b4102c11a94b2d9e300b617c9f806a ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/dm-mod.ko 988339597939b708e346a61bd4a6a343 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/dm-crypt.ko f4762b1f0d4f3e303072c637753ce366 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/dm-snapshot.ko 16ee20acf5405ba0947bdb6cc9cd54b9 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/dm-log.ko 4863981fb1954174ea77b9f476991536 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/dm-region-hash.ko 165fe6c1793eaedea1aa2db2cdb1aed3 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/dm-mirror.ko fac315a287715e2ca70756f758912cb0 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/md-mod.ko 3a081ea94071a3e5b2e72dd4c67eb671 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/linear.ko 20d388cd4ea7636d903ab522c20a97bb ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/multipath.ko 60c056c6dbbd2c46e932f5b25be86354 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/raid0.ko 2fc7df8b12010f788514021ddab80f12 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/raid1.ko 3c33b6068a91402431f25ab2a855fe08 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/raid6_pq.ko b1538856e0c3b7883940eeb800f68e20 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/raid456.ko 773fa6a5cdd4930ae7be012e37a6 ./lib/modules/2.6.30-2-amd64/kernel/drivers/md/raid10.ko 7966ccb72128e7a86d09b7c3b5df7557 ./sbin/mdadm 6b782ae76f866914ec236b2d14b43f24 ./scripts/local-top/mdadm --- /proc/modules: dm_crypt 12920 2 - Live 0xa01ba000 dm_mirror 14616 0 - Live 0xa01b1000 dm_region_hash 12704 1 dm_mirror, Live 0xa01ab000 dm_log 9924 2 dm_mirror,dm_region_hash, Live 0xa01a3000 dm_snapshot 22860 0 - Live 0xa0198000 dm_mod 59256 17 dm_crypt,dm_mirror,dm_log,dm_snapshot, Live 0xa0184000 raid1 21104 1 - Live 0xa0179000 md_mod 86628 2 raid1, Live 0xa015e000 --- /var/log/syslog: --- volume detail: /dev/sda is not recognised by mdadm. /dev/sda1: Magic : a92b4efc Version : 0.90.00 UUID : 222a461f:8303a4d2:4a90023e:7c4f4b06 Creation Time : Tue Dec 30 02:18:29 2008 Raid Level : raid1 Used Dev Size : 488383936 (465.76 GiB 500.11 GB) Array Size :
Bug#566279: ruby-prof: New upstream version available
Package: ruby-prof Severity: normal There seems to be a newer upstream version available: | $ gem list --remote ruby-prof | | *** REMOTE GEMS *** | | ruby-prof (0.7.9) Its CHANGELOG still lists 0.7.7 as the latest version, but that seems to be merely an oversight. Could you please update the ruby-prof package? Thanks, -Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545224: grub-pc: Makes xen-hypervisor-3.2-1-amd64 hang with early fatal page fault on boot
This bug report is NOT related to GNU partition tables (GPT). I (the original reporter of this bug) am NOT using a GPT. -Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545224: grub-pc: Makes xen-hypervisor-3.2-1-amd64 hang with early fatal page fault on boot
Julian Mehnle wrote: This bug report is NOT related to GNU partition tables (GPT). I (the original reporter of this bug) am NOT using a GPT. Err, I meant GUID partition table of course. Still I'm not using one of those. My partition table is MS-DOS-style. -Julian signature.asc Description: This is a digitally signed message part.
Bug#561312: Provide ri documentation in separate package (e.g., rails-doc)
Package: rails Severity: wishlist Currently the rails package doesn't install ri documentation. Others have complained (cf. #469524) about the rdoc docs already inflating the rails package and have requested a separate docs package. I'd be happy if such a, say, rails-doc package was created, if only to provide the ri docs, which I'm using all the time. Right now I have to install rails redundantly as a gem just to get the ri docs. :-( Regards, -Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545717: ITP: clamz -- Downloader for the Amazon.com MP3 music store
Stefan Schmidt wrote: Is there a draft package that I can test drive? Yes. You can find the packaging here: http://git.datenfreihafen.org/?p=stefan/clamz.git;a=summary I tried it and it looks good. I successfully downloaded an album from Amazon(.de). However, one of the patches didn't apply entirely cleanly: | Applying patch 01-output_dir_absolute_path_bug_id_14.patch | patching file download.c | patching file options.c | | Applying patch 02-downloads_file_permission_bug_id_10.patch | patching file download.c | Hunk #1 succeeded at 412 (offset 1 line). | | Now at patch 02-downloads_file_permission_bug_id_10.patch Seems it needs to be rediffed. Thanks for your packaging work! -Julian signature.asc Description: This is a digitally signed message part.
Bug#545717: ITP: clamz -- Downloader for the Amazon.com MP3 music store
What's the status of this? Is there a draft package that I can test drive? -Julian signature.asc Description: This is a digitally signed message part.
Bug#405789: rubygems: rubygems is too dumb to recognize debian packages
I have read http://pkg-ruby-extras.alioth.debian.org/rubygems.html However it isn't clear to me, after a period of almost three years, what the current situation is. Are there any plans for doing something about this, however remote? -Julian signature.asc Description: This is a digitally signed message part.
Bug#553408: lurker: New upstream version available: 2.3
Package: lurker Severity: normal A new upstream version, 2.3, with many useful bugfixes (hence normal, not wishlist severity), has been released today: http://terpstra.ca/lurker/message/20091030.200221.523a3e67.en.html Please package it! :-) -Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546937: bzr-builddeb: Bring over newer package from Ubuntu
Package: bzr-builddeb Version: 0.95 Severity: wishlist bzr-builddeb 0.95 seems to be quite old. Can you please upload the current package from Ubuntu? That would be nice. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541607: apache2: fails to start because of SSL configuration changes
Stefan Fritsch wrote: I can't reproduce that problem. Can one of you please provide some more detailed information about his configuration? The output of egrep -ir '^[^#]*(sslcertificate|sslengine|virtualhost)' /etc/apache2/*conf* /etc/apache2/*enabled would be nice. I cannot disclose the set of web sites I'm hosting, so I have to mask some of the information, but I think the following should give you an idea of my configuration: $ egrep -ir '^[^#]*(sslcertificate|sslengine|virtualhost)' /etc/apache2/*conf* /etc/apache2/*enabled /etc/apache2/apache2.conf:NameVirtualHost *:80 /etc/apache2/apache2.conf:NameVirtualHost *:443 /etc/apache2/sites-enabled/00default:VirtualHost *:80 /etc/apache2/sites-enabled/00default:SSLEngine off /etc/apache2/sites-enabled/00default:/VirtualHost /etc/apache2/sites-enabled/00default:VirtualHost *:443 /etc/apache2/sites-enabled/00default:SSLEngine on /etc/apache2/sites-enabled/00default:SSLCertificateFile /etc/ssl/certs/www.cer.pem /etc/apache2/sites-enabled/00default:SSLCertificateKeyFile /etc/ssl/private/www.cer+key.pem /etc/apache2/sites-enabled/00default:/VirtualHost /etc/apache2/sites-enabled/SITE01:VirtualHost *:80 /etc/apache2/sites-enabled/SITE01:/VirtualHost /etc/apache2/sites-enabled/SITE01:VirtualHost *:443 /etc/apache2/sites-enabled/SITE01:/VirtualHost /etc/apache2/sites-enabled/SITE01:VirtualHost *:80 /etc/apache2/sites-enabled/SITE01:/VirtualHost /etc/apache2/sites-enabled/SITE01:VirtualHost *:443 /etc/apache2/sites-enabled/SITE01:/VirtualHost /etc/apache2/sites-enabled/SITE01.A:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE01.A:/VirtualHost /etc/apache2/sites-enabled/SITE01.B:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE01.B:/VirtualHost /etc/apache2/sites-enabled/SITE01.C:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE01.C:/VirtualHost /etc/apache2/sites-enabled/SITE01.D:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE01.D:/VirtualHost /etc/apache2/sites-enabled/SITE01.E:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE01.E:/VirtualHost /etc/apache2/sites-enabled/SITE02:VirtualHost *:80 /etc/apache2/sites-enabled/SITE02:/VirtualHost /etc/apache2/sites-enabled/SITE02:VirtualHost *:443 /etc/apache2/sites-enabled/SITE02:/VirtualHost /etc/apache2/sites-enabled/SITE02.A:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE02.A:/VirtualHost /etc/apache2/sites-enabled/SITE02.B:VirtualHost *:80 /etc/apache2/sites-enabled/SITE02.B:/VirtualHost /etc/apache2/sites-enabled/SITE02.B:VirtualHost *:443 /etc/apache2/sites-enabled/SITE02.B:/VirtualHost /etc/apache2/sites-enabled/SITE02.C:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE02.C:/VirtualHost /etc/apache2/sites-enabled/SITE03:VirtualHost *:80 /etc/apache2/sites-enabled/SITE03:/VirtualHost /etc/apache2/sites-enabled/SITE03:VirtualHost *:443 /etc/apache2/sites-enabled/SITE03:/VirtualHost /etc/apache2/sites-enabled/SITE03.A:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE03.A:/VirtualHost /etc/apache2/sites-enabled/SITE04:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE04:/VirtualHost /etc/apache2/sites-enabled/SITE04.A:VirtualHost *:80 /etc/apache2/sites-enabled/SITE04.A:/VirtualHost /etc/apache2/sites-enabled/SITE04.B:VirtualHost *:80 /etc/apache2/sites-enabled/SITE04.B:/VirtualHost /etc/apache2/sites-enabled/SITE04.C:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE04.C:/VirtualHost /etc/apache2/sites-enabled/SITE05:VirtualHost *:80 /etc/apache2/sites-enabled/SITE05:/VirtualHost /etc/apache2/sites-enabled/SITE05:VirtualHost *:443 /etc/apache2/sites-enabled/SITE05:/VirtualHost /etc/apache2/sites-enabled/SITE05.A:VirtualHost *:80 /etc/apache2/sites-enabled/SITE05.A:/VirtualHost /etc/apache2/sites-enabled/SITE05.A:VirtualHost *:80 /etc/apache2/sites-enabled/SITE05.A:/VirtualHost /etc/apache2/sites-enabled/SITE05.B:VirtualHost *:80 /etc/apache2/sites-enabled/SITE05.B:/VirtualHost /etc/apache2/sites-enabled/SITE05.B:VirtualHost *:80 /etc/apache2/sites-enabled/SITE05.B:/VirtualHost /etc/apache2/sites-enabled/SITE05.C:VirtualHost *:80 /etc/apache2/sites-enabled/SITE05.C:/VirtualHost /etc/apache2/sites-enabled/SITE05.C:VirtualHost *:80 /etc/apache2/sites-enabled/SITE05.C:/VirtualHost /etc/apache2/sites-enabled/SITE06:VirtualHost *:80 /etc/apache2/sites-enabled/SITE06:/VirtualHost /etc/apache2/sites-enabled/SITE06:VirtualHost *:443 /etc/apache2/sites-enabled/SITE06:/VirtualHost /etc/apache2/sites-enabled/SITE06.A:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE06.A:/VirtualHost /etc/apache2/sites-enabled/SITE07:VirtualHost *:80 /etc/apache2/sites-enabled/SITE07:/VirtualHost /etc/apache2/sites-enabled/SITE07:VirtualHost *:443 /etc/apache2/sites-enabled/SITE07:/VirtualHost /etc/apache2/sites-enabled/SITE07.A:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE07.A:/VirtualHost /etc/apache2/sites-enabled/SITE07.B:VirtualHost *:80 *:443 /etc/apache2/sites-enabled/SITE07.B:/VirtualHost /etc/apache2/sites-enabled/SITE07.C:VirtualHost *:80
Bug#545224: grub-pc: Makes xen-hypervisor-3.2-1-amd64 hang with early fatal page fault on boot
Package: grub-pc
Version: 1.96+20090808-1
Severity: important
I have a machine running Xen 3.2 (from the xen-hypervisor-3.2-1-amd64
package). Previously I was using grub-pc 1.96+20080724-16 to boot the
hypervisor with a Xen-Dom0-enabled 2.6.26 Linux kernel (from the
linux-image-2.6.26-1-xen-amd64 package); this was working fine.
When I upgraded grub-pc and grub-common to 1.96+20090808-1, this broke the
booting of the Xen 3.2 hypervisor with an early fatal page fault error
message like described in the following:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516610
http://lists.xensource.com/archives/html/xen-users/2009-02/msg00768.html
Note that I'm merely referring to the described symptoms. I have no way
of telling whether these cases are also caused by a GRUB incompatibility.
In my case, however, this is definitely the cause, since downgrading
grub-pc and grub-common to 1.96+20080724-16 restores Xen 3.2 to a working
state.
Note further that I cannot upgrade to Xen 3.4 because, even though it does
not hang with an early fatal page fault error with the latest GRUB, the
Linux kernel then hangs during hardware detection, for possibly unrelated
reasons.
The currently latest version of GRUB, 1.97~beta2-1, too, makes Xen 3.2
hang with identical symptoms. I see that there were many other GRUB
releases between 1.96+20080724-16 (last known good) and 1.96+20090808-1
(first known bad), but I wasn't able to test them.
-Julian
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/md0 / xfs rw,noatime,attr2,nobarrier,noquota 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/sdc
(hd3) /dev/sdd
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/update-grub using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=5
terminal console
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/09_xen ###
menuentry Xen 3.2: Debian GNU/Linux, linux 2.6.26-1-xen-amd64 {
multiboot /boot/xen-3.2-1-amd64.gz dom0_mem=512M
module /boot/vmlinuz-2.6.26-1-xen-amd64 root=/dev/md0 ro
module /boot/initrd.img-2.6.26-1-xen-amd64
}
### END /etc/grub.d/09_xen ###
### BEGIN /etc/grub.d/10_hurd ###
### END /etc/grub.d/10_hurd ###
### BEGIN /etc/grub.d/10_linux ###
menuentry Debian GNU/Linux, linux 2.6.30-1-amd64 {
insmod raid
set root=(md0)
search --fs-uuid --set 2fe9a464-35bf-41b7-9284-5d5932ae06e0
linux /boot/vmlinuz-2.6.30-1-amd64 root=/dev/md0 ro
initrd /boot/initrd.img-2.6.30-1-amd64
}
menuentry Debian GNU/Linux, linux 2.6.30-1-amd64 (single-user mode) {
insmod raid
set root=(md0)
search --fs-uuid --set 2fe9a464-35bf-41b7-9284-5d5932ae06e0
linux /boot/vmlinuz-2.6.30-1-amd64 root=/dev/md0 ro single
initrd /boot/initrd.img-2.6.30-1-amd64
}
menuentry Debian GNU/Linux, linux 2.6.26-1-xen-amd64 {
insmod raid
set root=(md0)
search --fs-uuid --set 2fe9a464-35bf-41b7-9284-5d5932ae06e0
linux /boot/vmlinuz-2.6.26-1-xen-amd64 root=/dev/md0 ro
initrd /boot/initrd.img-2.6.26-1-xen-amd64
}
menuentry Debian GNU/Linux, linux 2.6.26-1-xen-amd64 (single-user mode) {
insmod raid
set root=(md0)
search --fs-uuid --set 2fe9a464-35bf-41b7-9284-5d5932ae06e0
linux /boot/vmlinuz-2.6.26-1-xen-amd64 root=/dev/md0 ro single
initrd /boot/initrd.img-2.6.26-1-xen-amd64
}
menuentry Debian GNU/Linux, linux 2.6.26-1-amd64 {
insmod raid
set root=(md0)
search --fs-uuid --set 2fe9a464-35bf-41b7-9284-5d5932ae06e0
linux /boot/vmlinuz-2.6.26-1-amd64 root=/dev/md0 ro
initrd /boot/initrd.img-2.6.26-1-amd64
}
menuentry Debian GNU/Linux, linux 2.6.26-1-amd64 (single-user mode) {
insmod raid
set root=(md0)
search --fs-uuid --set 2fe9a464-35bf-41b7-9284-5d5932ae06e0
linux /boot/vmlinuz-2.6.26-1-amd64 root=/dev/md0 ro single
initrd /boot/initrd.img-2.6.26-1-amd64
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file is an example on how to add custom entries
### END /etc/grub.d/40_custom ###
*** END /boot/grub/grub.cfg
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (600, 'testing'), (90, 'unstable'), (80, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8,
Bug#544365: libmimelib1c2a: Incompatible with kmail 3.5.9
Jonas Meurer wrote: are you sure that the bug is related to libmimelib1c2a? did you try whether _only_ downgrading mimelib to 1.1.2 from debian kdepim3 fixes it an then re-upgrading to standalone mimelib 1.1.4 makes it appear again? Exactly this is the case. Just tried it on two different systems once more. i'm asking because i checked ABI compliance very carefully, both manually and with tools like abi-compliance-checker. and the changes that where made to the code for the standalone mimelib1 1.1.4 package aren't related to pgp/mime handling at all. OK, then maybe the ABI didn't break but the library is working in some other incompatible way. Please let me know how I can help debugging this. -Julian signature.asc Description: This is a digitally signed message part.
Bug#541607: apache2: fails to start because of SSL configuration changes
I, too, can confirm this for 2.2.12-1. I wasted two hours trying to figure out if there was *some* way to adjust my configuration to make it work, to no avail. After all, I was forced to downgrade to 2.2.11, which I was using before. Luckily I still had the packages in my cache, or I would have been doomed, as snapshot.debian.net seems to carry only rather old versions of apache2 (2.2.8 or something). Surprisingly, this issue seems to be unknown upstream, so I'm not sure if this actually occurs in upstream or is rather caused by one of the Debian specific patches in this package. signature.asc Description: This is a digitally signed message part.
Bug#544365: libmimelib1c2a: Incompatible with kmail 3.5.9
Package: libmimelib1c2a Version: 5:1.1.4-1 Severity: important Maybe this doesn't bear any relevance now, but from my specific point of view this issue just ruined most of my day. I am a KDE user and have been running KDE 3.5 for a long time. I have been deferring the upgrade to KDE 4 due to KDE's horrendous history of breaking essential features in new releases for idiotic reasons or plain negligence, and also because even upstream kept saying that KDE 4 wasn't ready for prime time until at least 4.2. So I'm still on 3.5.9 and happy with it, waiting for 4.3 to appear in testing. However, I recently did upgrade all the rest of my packages to current Squeeze. This then broke decoding of PGP/MIME encrypted messages by KMail. Today I found out about libmimelib1c2a having been replaced by a build from a new mimelib1 source package that is supposed to be ABI compatible with that from kdelibs 3.5.9. It seems that it is not compatible. KMail doesn't crash, but it displays PGP/MIME encrypted messages (at least ones generated by KMail itself) as blank messages with two attachments: - unnamed (application/pgp-encrypted) - msg.asc (application/octet-stream) Even if you aren't going to dive into the mimelib/kmail guts and try to fix this, please change the ABI version and binary package name so any other leftover users of KDE 3.5.9 (such as users of Lenny who decide to move to current Squeeze) won't get bitten by this in the future. -Julian -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (600, 'testing'), (90, 'unstable'), (80, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libmimelib1c2a depends on: ii libc6 2.9-23 GNU C Library: Shared libraries ii libgcc1 1:4.4.1-1 GCC support library ii libstdc++64.4.1-1The GNU Standard C++ Library v3 libmimelib1c2a recommends no packages. libmimelib1c2a 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#537592: bittornado: Package description should mention that a tracker is included!
Package: bittornado Version: 0.3.18-8 Severity: normal So I decided I wanted to set up a BitTorrent tracker on my server. I browsed through the lists provided by `apt-cache --full search bittorrent`, but nothing suitable came up. So I just wasted 3 hours on compiling opentracker from scratch, only to have a friend tell me afterwards: Why did you not use bttrack from the bittornado package? Doh. Please make the bittornado package description mention that it also includes a tracker daemon. -Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534753: openoffice.org-common: openoffice.org not starting up, hangs every time until javaldx killed manually
Rene Engelhard wrote:
Julian Mehnle wrote:
Package: openoffice.org-common
Version: 1:3.0.1-9
Severity: important
Unsupported version. Yes, really, although it currently is in testing.
I'm not requesting support here, I'm reporting a potential bug. If you
want me to stop, please let me know. Otherwise, thanks for your time and
let's try to nail this down.
I'm running Debian Testing. Today I upgraded OpenOffice from 2.4.1,
which was working fine, to 3.0.1. Now I cannot start OpenOffice. It
just hangs
*Today*? You ypu use testing and upgraded OOo *today* while 3.0.1-9 is
already in testing since April, 10...
You read what I wrote. I'm not doing daily dist-upgrades. Still better
than updating my entire system every 4 years and missing lots of features
in between (i.e., using stable).
Yes, I have sun-java6-{bin,jdk,jre} installed. I don't have the
openoffice.org package installed, though, as I'm not using OO Base.
And openoffice.org-java-common?
openoffice.org-java-common is installed as well.
Please help! I'll happily do anything I can to assist in debugging
this.
Try 3.1.0 from sid.
Same effect, except that OO looks ugly now, without -kde.
-Julian
signature.asc
Description: This is a digitally signed message part.
Bug#534893: pdns-recursor: Enable Lua support
Package: pdns-recursor
Version: 3.1.7-5
Severity: wishlist
Tags: patch
Please enable Lua scripting support in pdns-recursor, either by default
(build and run-time dependencies are small!), or by building an
alternative binary package. I have tested a custom build based on the
attached patch, and it works fine! PowerDNS Recursor with scripting
support, mh!
-Julian
diff -ruN pdns-recursor-3.1.7.org/debian/changelog pdns-recursor-3.1.7/debian/changelog
--- pdns-recursor-3.1.7.org/debian/changelog 2009-06-27 22:57:12.084177435 +
+++ pdns-recursor-3.1.7/debian/changelog 2009-06-27 23:05:58.807980882 +
@@ -1,3 +1,9 @@
+pdns-recursor (3.1.7-5+lua) UNRELEASED; urgency=low
+
+ * Enable Lua scripting support.
+
+ -- Julian Mehnle jul...@mehnle.net Sat, 27 Jun 2009 23:05:47 +
+
pdns-recursor (3.1.7-5) unstable; urgency=low
* Fix FTBFS bug with GCC 4.4 (closes: #506003)
diff -ruN pdns-recursor-3.1.7.org/debian/control pdns-recursor-3.1.7/debian/control
--- pdns-recursor-3.1.7.org/debian/control 2009-06-27 22:57:12.084177435 +
+++ pdns-recursor-3.1.7/debian/control 2009-06-27 22:57:31.493381860 +
@@ -4,12 +4,12 @@
Standards-Version: 3.8.0
Maintainer: Debian PowerDNS Maintainers powerdns-deb...@workaround.org
Uploaders: Christoph Haas h...@debian.org, Matthijs Mohlmann matth...@cacholong.nl
-Build-Depends: debhelper (= 5.0.0), dpatch (= 2.0.0), dpkg-dev ( 1.10.17), libboost-dev, libboost-serialization-dev
+Build-Depends: debhelper (= 5.0.0), dpatch (= 2.0.0), dpkg-dev ( 1.10.17), libboost-dev, libboost-serialization-dev, liblua5.1-0-dev
Vcs-Git: git://github.com/Signum/debian-pdns-recursor.git
Package: pdns-recursor
Architecture: alpha amd64 i386 ia64 m68k powerpc s390 kfreebsd-i386 kfreebsd-amd64
-Depends: ${shlibs:Depends}, lsb-base (= 3.0-6), adduser
+Depends: ${shlibs:Depends}, lsb-base (= 3.0-6), adduser, liblua5.1-0
Replaces: pdns
Recommends: pdns-doc
Description: PowerDNS recursor
diff -ruN pdns-recursor-3.1.7.org/debian/rules pdns-recursor-3.1.7/debian/rules
--- pdns-recursor-3.1.7.org/debian/rules 2009-06-27 22:57:12.084177435 +
+++ pdns-recursor-3.1.7/debian/rules 2009-06-27 22:57:31.495177024 +
@@ -32,7 +32,7 @@
build-stamp: configure
# Add here commands to compile the arch part of the package.
- $(MAKE)
+ $(MAKE) LUA=1
touch build-stamp
Bug#534753: openoffice.org-common: openoffice.org not starting up, hangs every time until javaldx killed manually
Package: openoffice.org-common
Version: 1:3.0.1-9
Severity: important
I'm running Debian Testing. Today I upgraded OpenOffice from 2.4.1, which
was working fine, to 3.0.1. Now I cannot start OpenOffice. It just hangs
with no UI interaction or CPU usage. I then incidentally noticed that
there's a javaldx process lingering around that, when killed manually,
lets OpenOffice resume starting up normally.
Yes, I have sun-java6-{bin,jdk,jre} installed. I don't have the
openoffice.org package installed, though, as I'm not using OO Base.
I tried removing both
~/.openoffice.org2/user/config/javasettings_Linux_X86_64.xml
~/.openoffice.org/3/user/config/javasettings_Linux_X86_64.xml
several times as suggested by various bug reports and forum posts, to no
avail.
Please help! I'll happily do anything I can to assist in debugging this.
-Julian
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (600, 'testing'), (90, 'unstable'), (80, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages openoffice.org-common depends on:
ii openoffice.org-style-galaxy 1:3.0.1-9 full-featured office productivity
Versions of packages openoffice.org-common recommends:
ii openoffice.org-style-crystal 1:3.0.1-9 full-featured office productivity
pn openoffice.org-style-tangonone (no description available)
Versions of packages openoffice.org-common suggests:
pn openoffice.org-style-hicontra none (no description available)
pn openoffice.org-style-industri none (no description available)
-- 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#455220: aptitude: Reading package list percentage shown without % sign
Frans Pop wrote: This issue is certainly not specific to Gnome. I have been seeing the same problem for ages in KDE (using konsole with TERM=xterm). I can confirm this. I am using KDE konsole with TERM=xterm. signature.asc Description: This is a digitally signed message part.
Bug#522398: libcairo2: Missing R (red) channel in font/icon rendering on Exceed X server
Package: libcairo2 Version: 1.8.6-2 Severity: normal I am using my Debian workstation via an Exceed network X server from my Windows workstation. I recently upgraded my workstation to the latest Squeeze. Now I cannot run GTK applications without fonts and certain icons getting rendered in an odd way: it seems as if the R (red) channel was nulled. Please see the attached screen shot. You will notice that KDE applications (here: konqueror) are not affected. This looks very much like a problem that was discovered in the process of fixing http://bugs.freedesktop.org/show_bug.cgi?id=7294 (cf. comment #30 et al.), which I also was affected by back then. This is the main reason why I think that libcairo2 is the culprit now. During my system upgrade, libcairo2 was upgraded from 1.6.4-7 to 1.8.6-2. With 1.6.4 everything was working fine, although GTK applications admittedly ran more slowly than they do now. I do not dare marking this bug as important because probably only users of certain remote X servers are affected, but it effectively prevents me from using GTK applications productively. -Julian -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (600, 'testing'), (90, 'unstable'), (80, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libcairo2 depends on: ii libc6 2.9-4 GNU C Library: Shared libraries ii libdirectfb-1.0-0 1.0.1-11 direct frame buffer graphics - sha ii libfontconfig1 2.6.0-3 generic font configuration library ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib ii libpixman-1-0 0.14.0-1 pixel-manipulation library for X a ii libpng12-0 1.2.35-1 PNG library - runtime ii libx11-6 2:1.2-1 X11 client-side library ii libxcb-render-util00.3.3-2+b1utility libraries for X C Binding ii libxcb-render0 1.2-1 X C Binding, render extension ii libxcb11.2-1 X C Binding ii libxrender11:0.9.4-2 X Rendering Extension client libra ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime libcairo2 recommends no packages. libcairo2 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#520386: iftop: Add a min-bandwidth option, so less resolution is wasted on logarithmic scale
Package: iftop Version: 0.17-10 Severity: wishlist A min-bandwidth option analogous to the max-bandwidth option should be added. Currently the logarithmic display wastes a lot of space in the 0 - few-kilobytes-per-second range, which is often not useful (unless you're trying to examine intrusion attempts or something like that), causing the interesting range up to the maximum bandwidth to be crammed into just the right half of the screen. Being able to specify the minimum bandwidth to display would help a lot. Thanks for considering. -Julian Mehnle -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496909: opensync-plugin-kdepim: Confirming Mapping Write Errors
Package: opensync-plugin-kdepim Version: 0.22-3 Followup-For: Bug #496909 I can confirm this: $ msynctool --sync Pico --filter-objtype note --filter-objtype todo --filter-objtype contact --conflict 1 Synchronizing group Pico The previous synchronization was unclean. Slow-syncing Member 1 of type kdepim-sync just connected received event dsession Member 2 of type syncml-obex-client just connected All clients connected or error Received an reply to our Alert Going to receive 0 changes Received an entry KOrganizer-961318606.665 with data of size 8 from member 1 (kdepim-sync). Changetype ADDED Received an entry KOrganizer-1529342777.123 with data of size 8 from member 1 (kdepim-sync). Changetype ADDED Member 2 of type syncml-obex-client just sent all changes Received an entry KOrganizer-1772654145.261 with data of size 8 from member 1 (kdepim-sync). Changetype ADDED Received an entry KOrganizer-1152323585.194 with data of size 8 from member 1 (kdepim-sync). Changetype ADDED ... Received an entry KOrganizer-467295408.743 with data of size 8 from member 1 (kdepim-sync). Changetype ADDED Received an entry KOrganizer-728637434.183 with data of size 8 from member 1 (kdepim-sync). Changetype ADDED Member 1 of type kdepim-sync just sent all changes All clients sent changes or error All conflicts have been reported Member 1 of type kdepim-sync committed all changes. Received an reply to our sync Sent an entry 6124 of size 361 to member 2 (syncml-obex-client). Changetype ADDED Sent an entry 6125 of size 366 to member 2 (syncml-obex-client). Changetype ADDED ... Sent an entry 6145 of size 311 to member 2 (syncml-obex-client). Changetype ADDED Sent an entry 6146 of size 293 to member 2 (syncml-obex-client). Changetype ADDED Error writing entry 5783 to member 2 (syncml-obex-client): Unable to commit change. Error 415 Mapping Write Error: Unable to commit change. Error 415 Sent an entry 6147 of size 258 to member 2 (syncml-obex-client). Changetype ADDED Sent an entry 6148 of size 495 to member 2 (syncml-obex-client). Changetype ADDED ... Sent an entry 6191 of size 407 to member 2 (syncml-obex-client). Changetype ADDED Sent an entry 6192 of size 331 to member 2 (syncml-obex-client). Changetype ADDED Error writing entry 5830 to member 2 (syncml-obex-client): Unable to commit change. Error 415 Mapping Write Error: Unable to commit change. Error 415 Sent an entry 6193 of size 398 to member 2 (syncml-obex-client). Changetype ADDED Sent an entry 6194 of size 320 to member 2 (syncml-obex-client). Changetype ADDED ... ... ... Sent an entry 6479 of size 365 to member 2 (syncml-obex-client). Changetype ADDED Sent an entry 6480 of size 401 to member 2 (syncml-obex-client). Changetype ADDED Error writing entry 04008200E00074C5B7101A82E008C0324D12A880C90110007B5A2D7FE687AC4CAFBF68A41599FC5C to member 2 (syncml-obex-client): Unable to commit change. Error 415 Mapping Write Error: Unable to commit change. Error 415 Sent an entry 6481 of size 365 to member 2 (syncml-obex-client). Changetype ADDED Sent an entry 6482 of size 451 to member 2 (syncml-obex-client). Changetype ADDED Error writing entry 5187 to member 2 (syncml-obex-client): Unable to commit change. Error 415 Mapping Write Error: Unable to commit change. Error 415 Sent an entry 6483 of size 365 to member 2 (syncml-obex-client). Changetype ADDED Sent an entry 6484 of size 281 to member 2 (syncml-obex-client). Changetype ADDED Sent an entry 6485 of size 422 to member 2 (syncml-obex-client). Changetype ADDED Sent an entry 6486 of size 903 to member 2 (syncml-obex-client). Changetype ADDED Member 2 of type syncml-obex-client committed all changes. All clients have written Member 2 of type syncml-obex-client just disconnected Member 1 of type kdepim-sync just disconnected All clients have disconnected The sync failed: Unable to write one or more objects Error while synchronizing: Unable to write one or more objects I wish I knew what's going on there. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (600, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages opensync-plugin-kdepim depends on: ii kdelibs4c2a 4:3.5.10.dfsg.1-1+b1 core libraries and binaries for al ii libc6 2.7-18 GNU C Library: Shared libraries ii libgcc1 1:4.3.3-3GCC support library ii libkcal2b 4:3.5.9-5KDE calendaring library ii libopensync00.22-2 Synchronisation framework for emai ii libstdc++6
Bug#510883: subversion: `svn up` on repo sub-path requires r/w access to repo root (regression!)
Package: subversion Version: 1.5.0dfsg1-2 Severity: important There seems to be a regression in Subversion 1.5 that causes `svn up` on some sub-path in the repository to fail with a 403 error _unless_ the user has r/w access to the repository's root directory: http://subversion.tigris.org/issues/show_bug.cgi?id=3242 This has also been reported to the Ubuntu bug tracker: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/310739 This issue effectively prevents users of the Subversion 1.5 client from updating their working copies (and from performing various other, less frequent operations) in environments where they don't have r/w access to the entire repository! IOW, svn 1.5 is useless in those environments! I consider this a serious-level release critical bug, however reportbug tells me not to assign that severity myself, so I'm filing it as important and ask that the Subversion Debian maintainer upgrade it to serious. In effect, this would mean that either the subversion package has to downgraded to the last 1.4 version, some (as yet unknown) fix has to be applied, or the package has to be omitted from the Lenny release (certainly not desirable). Releasing 1.5 with Lenny, however, is going to piss off a LOT of Subversion users. Thanks for your consideration. -Julian Mehnle -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509960: grub-probe: Support for partitionable md RAID devices (/dev/md/d#, /dev/md/d#p#)
Package: grub-common Version: 1.96+20080724-12 Severity: normal GRUB 2 does not seem to support installing to partitionable md RAID devices such as /dev/md/d0 or /dev/md/d0p1. When attempting, e.g., `grub-install /dev/md/d0`, it says: | grub-probe: error: Unknown kind of RAID device `/dev/md/d0p1' -Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#392042: software RAID volumes can not be partitioned
I just ran into this after, over a period of two days, trying to figure out why D-I / partman doesn't allow me to partition /dev/md0, and why it would not even recognize a manual partitioning created via `cfdisk`. I think it would be very useful if partman supported partitionable md devices. It would save you from having to configure, and in case of failure, rebuild, several individual (classic, non-partitionable) md arrays. (Also, using LVM on top of a single big md device as a substitute for partitioning isn't really an option because LVM doesn't support write barriers.) Let me know if I can help with this -- anything short of providing a patch, given that I have absolutely no clue of the partman internals. -Julian signature.asc Description: This is a digitally signed message part.
Bug#392042: software RAID volumes can not be partitioned
A thought: The patch from #303914 might have to be partially undone in order to (re)admit partitionable md devices. signature.asc Description: This is a digitally signed message part.
Bug#507718: RFP: pynids -- Python binding for the libnids packet capture analysis library
Package: wnpp Severity: wishlist Tags: patch * Package name: pynids Version : 0.5.0 Upstream Author : Michael J. Pomraning [EMAIL PROTECTED] * URL : http://pilcrow.madison.wi.us/pynids/ * License : GPL Programming Lang: Python/C Description : Python binding for the libnids packet capture analysis library pynids is a Python binding for libnids, a Network Intrusion Detection System library offering sniffing, IP defragmentation, TCP stream reassembly and TCP port scan detection. -- I have already prepared a Debian package: http://files.mehnle.net/software/pynids/debian/ It disables the building of the version of libnids shipped with pynids and (build-)depends on Debian's libnids package instead. -Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506265: vpnc: New upstream release: 0.5.3
Package: vpnc Severity: wishlist A new upstream release, 0.5.3, has been released today: http://lists.unix-ag.uni-kl.de/pipermail/vpnc-announce/2008/07.html It fixes various bugs and, in particular, fixes phase 2 rekeying support. Please package it! :-) -Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487541: Solution/work-around: Force building with Tcl thread support
Package: eggdrop
Followup-For: Bug #487541
tag 487541 patch
thanks
Postings on the egghelp.org forums indicate that eggdrop's hanging in
background mode is caused by being compiled without Tcl thread support
while still being linked against a thread-enabled libtcl:
http://forum.egghelp.org/viewtopic.php?p=58877 (ignore the final two
postings on the thread, they're unrelated)
http://forum.egghelp.org/viewtopic.php?t=15805
To make things worse, eggdrop's auto-detection of the installed libtcl's
thread support seems to be broken (in design). See above as well as the
following 2002 posting on the eggdrop developer mailing list:
http://www.eggheads.org/pipermail/eggdev/2002-May/023002.html
And, indeed, when _forcing_ eggdrop to build with Tcl thread support
using the attached patch, eggdrop 1.6.19 works correctly.
diff -ruN eggdrop-1.6.19/configure eggdrop-1.6.19-threads/configure
--- eggdrop-1.6.19/configure 2008-04-19 04:21:20.0 +
+++ eggdrop-1.6.19-threads/configure 2008-08-03 19:25:20.0 +
@@ -10034,7 +10034,6 @@
fi
- if test $egg_cv_var_tcl_threaded = yes; then
if test $enable_tcl_threads = no; then
cat 'EOF' 2
@@ -10056,7 +10055,6 @@
if test ! ${ac_cv_lib_pthread-x} = x; then
LIBS=$ac_cv_lib_pthread $LIBS
fi
- fi
if test $EGG_CYGWIN = yes; then
diff -ruN eggdrop-1.6.19/debian/rules eggdrop-1.6.19-threads/debian/rules
--- eggdrop-1.6.19/debian/rules 2008-08-03 18:19:59.0 +
+++ eggdrop-1.6.19-threads/debian/rules 2008-08-03 19:04:59.0 +
@@ -5,6 +5,7 @@
include /usr/share/cdbs/1/class/autotools.mk
include /usr/share/cdbs/1/rules/simple-patchsys.mk
+DEB_CONFIGURE_EXTRA_FLAGS := --enable-tcl-threads
DEB_CONFIGURE_SCRIPT_ENV :=
DEB_INSTALL_MANPAGES_eggdrop-data := doc/man1/eggdrop.1
DEB_MAKE_INSTALL_TARGET := install prefix=$(DEB_DESTDIR)/usr
Bug#492996: python-dns: Should safely ignore IPv6 nameserver entries in resolv.conf as long as queyring those is not supported
Package: python-dns
Version: 2.3.1-6
Severity: normal
Tags: patch
Running python-dns on a system that has a nameserver entry with an IPv6
address in resolv.conf causes an
Address family for hostname not supported
error because the IPv6 address cannot be turned into an IPv4 atom.
Since python-dns currently does not support querying IPv6 nameservers
anyway, it should just ignore any IPv6 nameserver entries.
Patch attached.
diff -ruN python-dns-2.3.1.org/debian/changelog python-dns-2.3.1/debian/changelog
--- python-dns-2.3.1.org/debian/changelog 2008-07-30 13:55:26.0 +
+++ python-dns-2.3.1/debian/changelog 2008-07-30 14:23:43.0 +
@@ -1,3 +1,10 @@
+python-dns (2.3.1-6+ipv6safe) UNRELEASED; urgency=low
+
+ * Safely ignore nameserver entries in resolv.conf that list IPv6 resolvers,
+as querying those is not currently supported.
+
+ -- Julian Mehnle [EMAIL PROTECTED] Wed, 30 Jul 2008 14:16:29 +
+
python-dns (2.3.1-6) unstable; urgency=high
* Fix debian/patches/source-tid-random.patch so it doesn't lose socket
diff -ruN python-dns-2.3.1.org/DNS/Base.py python-dns-2.3.1/DNS/Base.py
--- python-dns-2.3.1.org/DNS/Base.py 2008-07-30 13:55:26.0 +
+++ python-dns-2.3.1/DNS/Base.py 2008-07-30 14:11:12.0 +
@@ -40,7 +40,11 @@
if fields[0]=='sortlist':
pass
if fields[0]=='nameserver':
-defaults['server'].append(fields[1])
+if fields[1].count(':'):
+ Ignore IPv6 nameservers as we currently do not support querying them.
+pass
+else:
+defaults['server'].append(fields[1])
def DiscoverNameServers():
import sys
Bug#461709: /usr/sbin/spamd: spf: lookup failed: Can't locate object method new via package Net::DNS::RR::SOA
Michael(tm) Smith wrote:
Not happening any longer. But up to March 13, I was getting a
different but similar message:
Can't locate object method new via package Net::DNS::RR::TXT
at /usr/lib/perl5/Net/DNS/RR.pm line 305
Since March 13, that seems to have disappeared (I assume because
when I did an apt-get upgrade, the Net::DNS::RR and/or
Mail::SPF::Server package got upgraded).
That was most likely a bug in Net::DNS, and certainly not one in
Mail::SPF, because before you upgraded your system, SpamAssassin was
using Mail::SPF::Query, which is an obsolete module different from
Mail::SPF.
But I'm now seeing another error in the SPF stuff:
spf: lookup failed: Can't locate object method
qualifier_pattern via package Mail::SPF::Mech at
usr/share/perl5/Mail/SPF/Record.pm line 212
So it almost seems like sort of a push-me-pull-you going on with
those packages -- one bug gets fixed, another bug gets
introduced...
Are you still experiencing this problem? If so, does it go away if you
apply the attached patch to /usr/share/perl5/Mail/SPF/Record.pm?
Julian.
--- /usr/share/perl5/Mail/SPF/Record.pm 2007-06-23 21:14:18.0 +
+++ Record.pm 2008-06-27 18:19:56.0 +
@@ -206,6 +206,7 @@
sub parse_term {
my ($self) = @_;
+require Mail::SPF::Mech;
if (
$self-{parse_text} =~ s/
^
signature.asc
Description: This is a digitally signed message part.
Bug#481970: libpam-pgsql: Ctrl+C while in authentication phase induces success, may circumvent sudo et al.
Package: libpam-pgsql Version: 0.6.3-1 Severity: critical Tags: security Justification: root security hole I recently upgraded libpam-pgsql to 0.6.3-1. I now noticed that pressing Ctrl+C during libpam-pgsql's authentication phase, e.g., when sudo is asking for the user's password, erroneously causes sudo to succeed as if the user had entered the correct password, IF pam_pgsql.so has been configured as a sufficient authentication module in the system's PAM setup. I am attaching my /etc/pam.d/common-auth and /etc/pam.d/sudo files for illustration. Only the former has been changed from the PAM defaults. Here's a transcript demonstrating the effect: | io:~ id | uid=1004(julian) gid=100(users) groups=0(root),4(adm),8(mail),32(postgres),40(src),50(staff),100(users),[...] | io:~ sudo -k | io:~ sudo id | [sudo] password for julian: ^C | uid=0(root) gid=0(root) groups=0(root),4(adm) Even though pam_pgsql.so is not configured as a sufficient auth module by default, I consider this a critical security issue in the libpam- pgsql package. Feel free to downgrade the severity if you think otherwise. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (600, 'testing'), (90, 'unstable') Architecture: i386 (i586) Kernel: Linux 2.6.24-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libpam-pgsql depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libmhash2 0.9.9-1Library for cryptographic hashing ii libpam0g 0.99.7.1-6 Pluggable Authentication Modules l ii libpq58.3.1-1PostgreSQL C client library libpam-pgsql recommends no packages. -- no debconf information # # /etc/pam.d/common-auth - authentication settings common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of the authentication modules that define # the central authentication scheme for use on the system # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. # # USM login authentication authsufficient pam_pgsql.so table=auth.login # Standard Un*x authentication. The nullok line allows passwordless # accounts. authrequiredpam_unix.so nullok try_first_pass #%PAM-1.0 @include common-auth @include common-account session required pam_permit.so session required pam_limits.so
Bug#475169: [kaddressbook] KAdressbook doesn't handle UTF8 when the contacts are stored in an IMAP folder
I can confirm this. This bug is extremely annoying and makes KAddressbook almost unusable for me. A real productivity killer! signature.asc Description: This is a digitally signed message part.
Bug#404228: Done: kmail's handling of passwords/kdewallet very broken
Kartik Mistry wrote: Package: kmail Version: 4:3.5.9-2 --- Please enter the report below this line. --- Fixed-upstream. See: https://bugs.kde.org/show_bug.cgi?id=95615 and KDE SVN commit 675974 Your message caused the Debian bug tracker to mark this bug as fixed in the kmail Debian package version 4:3.5.9-2. I downloaded the source package of that version and looked, but it doesn't look as if the upstream fix was in that version. However, this bug report should be closed only when the fix has actually reached a package version that is part of Debian. Can you please verify that the bug is fixed in kmail 4:3.5.9-2? Otherwise I am going to reopen the bug report. signature.asc Description: This is a digitally signed message part.
Bug#297730: closed by Julian Mehnle [EMAIL PROTECTED] (Re: Bug#297730: Any updates?)
Charles Fry wrote: reopen 297730 thanks I am satisfied with three of the four reported problems, but as far as I can tell you are still missing: libnet-address-ipv4-local-perl Yes, but this is only a suggestion, not a dependency or a recommendation, and suggestions are not required to be satisfiable. So if you insist on considering this a bug, I will downgrade it to wishlist severity. Agreed? (By the way, the upcoming new courier-filter-perl version will instead suggest libnet-address-ip-local-perl (without the v4 in ipv4), which corresponds to a new Perl module available on CPAN.) signature.asc Description: This is a digitally signed message part.
Bug#297730: Any updates?
Amaya wrote: As you are aware of, #297730 is a blocker for a Release Goal (http://release.debian.org/lenny/goals.txt - goal-recommends) Can you report any progress on this? None as of yet, but I'm about to upload a new upstream release and Debian package within this week. I was busy with exams and was planning to do this just about these days. Julian. signature.asc Description: This is a digitally signed message part.
Bug#466873: libpam-pgsql: New upstream version available
Package: libpam-pgsql Severity: wishlist There is a new 0.6.3 upstream version of libpam-pgsql: http://sourceforge.net/projects/pam-pgsql/ There is even an Ubuntu patch that brings the Debian package up to date: http://patches.ubuntu.com/p/pam-pgsql/pam-pgsql_0.6.3-0ubuntu1.patch Please update the package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466258: postgresql-common: pg_upgradecluster datadir argument undocumented
Package: postgresql-common Version: 85 Severity: minor The optional datadir argument shown in `pg_upgradecluster` and `man pg_upgradecluster` is not documented. I wonder what it does. Please document it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
Russ Allbery wrote: This is a Policy proposal that's sat in the Policy bug queue with wording and seconds for quite some time. I'd like to resurrect it and resolve it one way or the other. There's some room for clarification here. I think it is apparent from comments given in 2001 the that the policy wish-bug under debate concerns the _binary_ package name, and not the _source_ package name. The Debian policy however isn't entirely clear on whether it intends to mandate the source or binary package name or both. Let me repeat its current text: | 4.2 Module Package Names | | Perl module packages should be named for the primary module provided. | The naming convention for module Foo::Bar is libfoo-bar-perl. Packages | which include multiple modules may additionally include provides for | those modules using the same convention. I think that from the final sentence it can be inferred that it primarily intends to mandate the _binary_ package name. So while we're discussing the binary package naming, maybe we can decide whether the mandate should be extended to the _source_ package name as well while we're at it, and clarify the Perl policy to explicitly state whether or not the source package name is covered by the policy's recommendation. I know the question of source package naming for Perl modules has been discussed on debian-perl before, but that was just about the Debian Perl Group's own conventions, not about the global Perl policy. The Perl Group can still maintain stricter conventions even if the Perl policy gets relaxed with regard to source package names. As far as _binary_ package names are concerned, I think they should follow an automatable pattern (i.e. the Perl policy's recommendation for binary package names should stay as it is). Long package names are a non-issue given Bash completion and package managers with incremental search features. As for _source_ package names, I think they should be free-form. signature.asc Description: This is a digitally signed message part.
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
Don Armstrong wrote: On Wed, 02 Jan 2008, Julian Mehnle wrote: I think that from the final sentence it can be inferred that it primarily intends to mandate the _binary_ package name. So while we're discussing the binary package naming, maybe we can decide whether the mandate should be extended to the _source_ package name as well while we're at it, and clarify the Perl policy to explicitly state whether or not the source package name is covered by the policy's recommendation. Unless there's a compelling reason to the contrary, a source package should in general build at least one binary package of the same name. This is definetly the case when the source package only builds one binary package. According to a simple survey of the packages in Lenny/amd64 (main, contrib, non-free), 2365 of the 11757 source packages (20%!) have no binary package of the same name. 814 of these (7% of all) have only a single binary package. Wanna mass-file bugs? Or maybe the reason doesn't have to be all that compelling. signature.asc Description: This is a digitally signed message part.
Bug#455220: aptitude: Reading package list percentage shown without % sign
I can confirm this. I have been observing it for nearly a year now. signature.asc Description: This is a digitally signed message part.
Bug#458205: libnet-dns-perl: New upstream version 0.62 fixes various issues
Package: libnet-dns-perl Severity: wishlist A new upstream version, 0.62, was just released: http://search.cpan.org/dist/Net-DNS-0.62/ It fixes various issues: http://search.cpan.org/src/OLAF/Net-DNS-0.62/Changes (Personally, I'm interested in a fix for rt.cpan.org #29531, which plagues both 0.60 and 0.61.) Please package it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404228: kmail's handling of passwords/kdewallet very broken
This issue is known upstream (see bug's forwarded info). A work-around (that's acceptable at least to me) seems to be to disable the KDE Wallet system entirely (KDE Control Center - Security Privacy - KDE Wallet - Wallet Preferences - Enable the KDE wallet subsystem := OFF). signature.asc Description: This is a digitally signed message part.
Bug#448279: [new] wipnity: Why is package X not in testing yet? query script
Mohammed Adnène Trojette wrote: What's significantly different from grep-excuses in wipnity? I have little idea since I have never used grep-excuses before. However, from looking at it now, it seems that grep-excuses doesn't work for source package names, and doesn't give all the information that wipnity does, such as build dependency info (and it gives some information that wipnity doesn't, such as the maintainer name and bugs fixed). As I see the script is really short, couldn't it be merged into grep-excuses as an option? It probably could. However since I'm not a regular user (or, really no user at all) of grep-excuses, I'm probably not the best person to decide how it should be merged. I see that devscripts is team-maintained. What do the other members of your team think? Julian. signature.asc Description: This is a digitally signed message part.
Bug#175351: apache2-common: The problem persists with 2.0.52-1
Thijs Kinkhorst wrote: The problem persists with 2.0.52-1. The URIs mentioned above are still current. Thank you for your help in testing this problem. I'm working through the (rather long) list of Apache2 bugs. Could you try it again one more time with current Apache 2.2.3 ? That would really help. Sorry for the very long delay in my replying. I managed to upgrade my Apache to 2.2 only yesterday. Yes, the bug seems to still exist, which is consistent with the bug still being considered open by upstream. Julian. signature.asc Description: This is a digitally signed message part.
Bug#297765: Package should be named libmime-tools-perl, not libmime-perl
Niko Tyni wrote: I'm still not sure if it's worth it to rename, though. Gregor Herrmann wrote: Considering the arguments with versioned dependencies I'm inclined to propose to stick with the current name. Cost: This would be a one-time action, and we can easily supply a dummy libmime-perl binary package that depends on the renamed binary package for backwards compatibility. Benefit: Less confusion for all users searching for the package providing MIME-tools / MIME::Tools in the future. signature.asc Description: This is a digitally signed message part.
Bug#448671: spamassassin: Depend on Mail::SPF instead of legacy Mail::SPF::Query for SPF support
Package: spamassassin Severity: wishlist SpamAssassin can use both the new Mail::SPF and the old Mail::SPF::Query Perl modules for SPF support. Mail::SPF is fully compliant with the final SPFv1 specification (RFC 4408), whereas Mail::SPF::Query is a legacy implementation that has many issues and is far from compliant. As Mail::SPF has recently entered the Debian main archive as libmail-spf-perl, SpamAssassin should depend on that rather than libmail-spf-query-perl. SpamAssassin in Ubuntu already does. :-) Julian (author of Mail::SPF and upstream maintainer of Mail::SPF::Query) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448279: [new] wipnity: Why is package X not in testing yet? query script
Package: devscripts Severity: wishlist I'd like to suggest the inclusion of a command-line script that queries http://bjorn.haxx.se/debian/. I am attaching one that I wrote and use. It depends on w3m and libterm-size-perl. Here's some example output to give you an idea (although it's kind of obvious if you know http://bjorn.haxx.se/debian/): $ wipnity kmail Checking kmail * binary package kmail is part of source package kdepim + trying to update kdepim from 4:3.5.7-4 to 4:3.5.8-1 (candidate is 10 days old) + kdepim is not yet built on arm: 4:3.5.7-4 vs 4:3.5.8-1 (missing 45 binaries) + kdepim is not yet built on powerpc: 4:3.5.7-4 vs 4:3.5.8-1 (missing 45 binaries) + kdepim is waiting for kdelibs o kdelibs is only 2 days old. It must be 10 days old to go in. o kdelibs is not yet built on arm: 4:3.5.7.dfsg.1-7 vs 4:3.5.8.dfsg.1-3 (missing 3 binaries: kdelibs-dbg, kdelibs4-dev, kdelibs4c2a) o kdelibs is not yet built on powerpc: 4:3.5.8.dfsg.1-1 vs 4:3.5.8.dfsg.1-3 (missing 3 binaries: kdelibs-dbg, kdelibs4-dev, kdelibs4c2a) Dependency analysis (including build-depends; i386 only): * kdepim depends on kdelibs4-dev = 4:3.5.8 but testing has 4:3.5.7.dfsg.1-7 (unstable has 4:3.5.8.dfsg.1-3) + binary package kdelibs4-dev is part of source package kdelibs (explained above) Julian. wipnity Description: Perl program
Bug#444442: ITP: mail-spf-perl -- Perl implementation of Sender Policy Framework and Sender ID
Package: wnpp Severity: wishlist Owner: Julian Mehnle [EMAIL PROTECTED] * Package name: mail-spf-perl Version : 2.005 Upstream Author : Julian Mehnle [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/Mail-SPF/ * License : BSD Programming Lang: Perl Description : Perl implementation of Sender Policy Framework and Sender ID Mail::SPF is an object-oriented Perl implementation of the Sender Policy Framework (SPF) e-mail sender authentication system http://www.openspf.org. It supports both the TXT and SPF RR types as well as both SPFv1 (v=spf1) and Sender ID (spf2.0) records, and it is fully compliant to RFCs 4408 and 4406. (It does not however implement the patented PRA address selection algorithm described in RFC 4407.) The source package would generate two binary packages: libmail-spf-perl and spf-tools-perl, the latter of which would ship the executables included with the Mail::SPF upstream package (currently spfquery and spfd). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444443: ITP: net-dns-resolver-programmable-perl -- programmable DNS resolver class for offline emulation of DNS
Package: wnpp Severity: wishlist Owner: Julian Mehnle [EMAIL PROTECTED] * Package name: net-dns-resolver-programmable-perl Version : 0.003.1 Upstream Author : Julian Mehnle [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/Net-DNS-Resolver-Programmable/ * License : Perl (GPL-2 / Artistic) Programming Lang: Perl Description : programmable DNS resolver class for offline emulation of DNS Net::DNS::Resolver::Programmable is a Net::DNS::Resolver descendant class that allows a virtual DNS to be emulated instead of querying the real DNS. A set of static DNS records may be supplied, or arbitrary code may be specified as a means for retrieving DNS records, or even generating them on the fly. The source package would generate a libnet-dns-resolver-programmable-perl binary package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444443: ITP: net-dns-resolver-programmable-perl -- programmable DNS resolver class for offline emulation of DNS
David Paleino wrote: this package should be named libnet-dns-resolver-programmable-perl. I think this can be said merely of the _binary_ package, not the _source_ package. And as I said in the ITP, the binary package will be named like that. See also my response on #42. signature.asc Description: This is a digitally signed message part.
Bug#444442: ITP: mail-spf-perl -- Perl implementation of Sender Policy Framework and Sender ID
David Paleino wrote: Julian Mehnle wrote: Package: wnpp Severity: wishlist Owner: Julian Mehnle [EMAIL PROTECTED] * Package name: mail-spf-perl as per Debian Perl Policy, the package should be named libmail-spf-perl. You are probably referring to 4.2, Module Package Names: http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-package_names | Perl module packages should be named for the primary module provided. | The naming convention for module Foo::Bar is libfoo-bar-perl. Packages | which include multiple modules may additionally include provides for | those modules using the same convention. The last sentence indicates that this paragraph really just talks about binary package names, not source package names, as only binary packages, not source ones, do Provide: other packages. This also allows existing source packages to be named mime-tools, soap-lite, and timedate, while their corresponding binary packages are conformingly named libmime-perl, libsoap-lite-perl, and libtimedate- perl. Thus I think it is perfectly legitimate to name the _source_ package mail-spf-perl. The source package would generate two binary packages: libmail-spf-perl and spf-tools-perl, the latter of which would ship the executables included with the Mail::SPF upstream package (currently spfquery and spfd). This could let you name your package mail-spf-perl: there's a discussion about this on [EMAIL PROTECTED] . Please take a look at the archives. (In two words: one could name the source package other than lib*-perl if it brings something other than the Perl Module -- as the spf-tools in this case -- but not everyone agrees) FWIW, I am the one who initiated that thread. You could join the Debian Perl Group, I am already a member of the DPG, thanks. Julian. signature.asc Description: This is a digitally signed message part.
Bug#443923: svn-buildpackage: svn-inject fails with native packages
Not only that, but it fails specifically for repository layouts of type 2 as well, i.e. `svn-inject -l 2`! signature.asc Description: This is a digitally signed message part.
Bug#443923: svn-buildpackage: svn-inject fails with native packages
Julian Mehnle wrote: Not only that, but it fails specifically for repository layouts of type 2 as well, i.e. `svn-inject -l 2`! ... for native packages, I meant to say. (The patch from #433536 seems to support non-native packages OK.) signature.asc Description: This is a digitally signed message part.
Bug#443405: Bug#437508: debarchiver now _always_ warns: Loading config file /etc/debarchiver.conf:\n^I\n^I in syslog, even if no error condition
Ola Lundqvist wrote: `perldoc -f do` says: | If do cannot read the file, it returns undef and sets $! to the | error. If do can read the file but cannot compile it, it returns | undef and sets an error message in [EMAIL PROTECTED] If the file is | successfully compiled, do returns the value of the last | expression evaluated. Thus relying on $! and $@ is officially sanctioned. I can not see that. It do not say anything about the $! or $@ when the expression return true. It only tell that they are set when it returns false. The above statements formalized: If X return undef and set $! if Y return undef and set $@ if Z return $lastexpr I can not see anything about if return true, set $! = 0, set $@ = 0; It may be so that it do that and I did some test code that verifies that. However I do not want to rely on undocumented features too much if there are documented features that I can rely on. You're right, and it even actually says (in `perldoc perlvar`) that $! does NOT get set to 0 if there is no failure. Perhaps you could explicitly set $! to 0 before the do() call, though? About $@, I'm certain that it gets set to if the file could be read and compiled successfully. I think the check whether do() returns true idiom is a remnant from old times when Perl didn't know exceptions ($@). This is the result of the test code: Condition return$! $@ -- Read errorundef string Syntax error undef string No statements undef last 00 last 11 The above could also be undef, but I did not have the time to check that now. But this is from my perl version. In your case for No statements the value for $! and $@ was ^I. Maybe this is a syslog oddity? I've never seen $! or $@ getting set to ^I (\t), so I don't think this is their actual value. I can provide some testing code to you if you want so we can determine the table above for your perl version. I doubt it would be any different with Perl 5.8.8, which is what I'm running. Well, we could try setting $! to 0 before the do() call and checking ($! || $@) afterwards. If that doesn't work, then the debarchiver man-page would have to explain that there needs to be a final, true- valued statement in every config file. signature.asc Description: This is a digitally signed message part.
Bug#443405: Bug#437508: debarchiver now _always_ warns: Loading config file /etc/debarchiver.conf:\n^I\n^I in syslog, even if no error condition
Ola Lundqvist wrote:
I have now tried to reproduce your problem, but failed.
The current code that cause the warning looks like this:
if (-e $etcconfigfile) {
my $t = do $etcconfigfile;
unless ($t) {
pdebug(3, Loading config file $etcconfigfile:\n\t$!\n\t$@);
}
}
So I created the following test code:
my $t = do test.conf;
unless ($t) {
print [EMAIL PROTECTED];
}
And then copied your config file to test.conf.
I did not get any output.
Oh, now I get what the problem is!
I had sent you only my input.conf file from my (currently single)
debarchive's incoming/ directory, but not my /etc/debarchiver.conf file,
because I had all configuration directives commented out in the latter!
(I don't want to set any options globally.)
Now it occurs to me that debarchiver reads /etc/debarchiver.conf and since
it contains only empty and comment lines, the result of do() is 0, but $!
and $@ are empty since no error actually occurs. (Still no idea where
the '^I's come from, though.)
So I think debarchiver should check $! and $@ rather than the result of
do() (unless ($t)), which really says nothing about whether the file
could be read and compiled successfully, UNLESS you require every
configuration file to end with a true-valued statement (which the
debarchiver man-page says nothing about). And I would not make such a
requirement. Checking $! and $@ should do just fine.
If, however, you absolutely do not want to do this, then consider this bug
report a request for documentation of the config files must end with 1;
requirement.
Thanks,
Julian.
# This is a sample configuration file.
#
# The configuration file consist of perl variables that can be set to
# different values. The suggested value in this sample configuration file
# is the default value set by debarchiver.
# $destdir = /var/lib/debarchiver/dists;
# $inputdir = /var/lib/debarchiver/incoming;
# $copycmd = cp -af;
# $movecmd = mv;
# $rmcmd = rm -f;
# $vrfycmd = dscverify;
# $cinstall = installed;
# $distinputcriteria = ^linux.*\\.deb\$;
# Choose to enable or disable signature verification for packages uploaded
# into $inputdir (not %distinputdirs).
# $verifysignatures = 0;
# Choose to enable or disable signature verification for packages uploaded
# into %distinputdirs. This works indepentently from $verifysignatures.
# $verifysignaturesdistinput = 0;
# Generate bzip2 files or not (1 will generate and 0 will not do so).
# $bzip = 0;
# This one is used for debarchives that matches distinput criteria.
# %distinputdirs =
# (
# stable = 'stable',
# testing = 'testing',
# unstable = 'unstable'
# );
# What distributions that should exist.
# @distributions = ('stable', 'testing', 'unstable');
# Default major section to install to, if not defined in the uploaded files.
# $majordefault = main;
# Mapping of aliases.
# OBS! If you create a mapping that will only be created if you have
# added the key to @distributions above. If you want the symlink to be created
# in a proper way you MUST add them at the same time. Else you will have
# two directories that are independent (and not mapped).
# %distmapping =
# (
# stable = 'etch',
# testing = 'lenny',
# unstable = 'sid'
# );
# What architectures that should exist (automatically created).
# All and source will exist anyway.
# @architectures = ('i386');
# What sections that should exist.
# @sections = ('main', 'contrib', 'non-free');
# What changes file fields that should be used for determine where to send
# mail. If there is an '@' character is found here it will be used directly
# without consulting the .changes-file. Default is to mail no one. If there
# is an '@' character in the beginning, the user owning the file will be
# prepended.
# @mailtos = ('Maintainer', The Maintainer field in control file
# 'Uploaders', The Uploaders field in control file
# '@bar.com',User id @bar.com that own the changes file
# '[EMAIL PROTECTED]', An explicit email address
# 'Changed-By'); The email in the changelog file
# If you want additional information in the generated Release files you have
# to set this hash-value. Supported keys are origin, label, and description.
# %release = ( 'origin' = ,
# 'label' = ,
# 'description' = );
# Where to put the apt-ftparchive cache files if --index is used. Default
# is /var/cache/debarchiver. Must be a directory.
# $cachedir = '/var/cache/debarchiver';
# GnuPG key to use to sign the archive.
# $gpgkey = ;
# File to provide password to GnuPG.
# If you use a key with an empty passphrase, set this variable to 0 or .
# If the file does not exist, debarchiver will also fall back to .
# $gpgpassfile = $ENV{HOME}/.gnupg/passphrase;
signature.asc
Description: This is a digitally signed message part.
Bug#443405: Bug#437508: debarchiver now _always_ warns: Loading config file /etc/debarchiver.conf:\n^I\n^I in syslog, even if no error condition
Ola Lundqvist wrote: On Sun, Sep 23, 2007 at 11:49:36AM +, Julian Mehnle wrote: So I think debarchiver should check $! and $@ rather than the result of do() (unless ($t)), which really says nothing about whether the file could be read and compiled successfully, UNLESS you require every configuration file to end with a true-valued statement (which the debarchiver man-page says nothing about). And I would not make such a requirement. Checking $! and $@ should do just fine. The problem here is that $! $@ can contain quite different values, as you noticed... I do not know if perl actually requires the file to end with a true statement or not. Maybe it does. I have not checked the documentation for that. `perldoc -f do` says: | If do cannot read the file, it returns undef and sets $! to the error. | If do can read the file but cannot compile it, it returns undef and | sets an error message in [EMAIL PROTECTED] If the file is successfully compiled, | do returns the value of the last expression evaluated. Thus relying on $! and $@ is officially sanctioned. I think the check whether do() returns true idiom is a remnant from old times when Perl didn't know exceptions ($@). signature.asc Description: This is a digitally signed message part.
Bug#443405: Bug#437508: debarchiver now _always_ warns: Loading config file /etc/debarchiver.conf:\n^I\n^I in syslog, even if no error condition
Ola Lundqvist wrote: I think you need to end the configuration file with 1; Why would that make a difference? The last statement is ... $gpgkey = '74E1D63F'; which returns a true value. So this is equivalent to a trailing 1;. Please try that and tell me if the warning disappear. As expected, it did not make the warning go away. The ^I part is the error output from perl. It should contain the error code and error string. I do not know why it is ^I in your case. Odd. So can you do something about debarchiver filling up my syslog despite everything working fine? signature.asc Description: This is a digitally signed message part.
Bug#437508: debarchiver now _always_ warns: Loading config file /etc/debarchiver.conf:\n^I\n^I in syslog, even if no error condition
Package: debarchiver Version: 0.7.4 Followup-For: Bug #437508 debarchiver now _always_ warns in syslog: | debarchiver: Warning: Loading config file /etc/debarchiver.conf: | debarchiver: ^I | debarchiver: ^I even if there is no error condition! I think you changed one log level too many from 4 to 3. And what's this double ^I log output? -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (600, 'testing'), (90, 'unstable') Architecture: i386 (i586) Kernel: Linux 2.6.21-2-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages debarchiver depends on: ii adduser 3.105 add and remove users and groups ii apt-utils 0.7.6 APT utility programs ii dpkg-dev 1.14.5 package building tools for Debian ii opalmod 0.1.14 A set of Perl modules for various debarchiver recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443069: mailman: senddigests cron job: TypeError: iso-8859-1
Package: mailman Version: 1:2.1.9-8 Severity: important Followup-For: Bug #384016 It seems that #384016 is not resolved yet. I recently upgraded mailman from 1:2.1.8-4 to 1:2.1.9-8, and now I am getting the following error message whenever the senddigests cron job runs (i.e. daily): | Traceback (most recent call last): | File /usr/lib/mailman/cron/senddigests, line 94, in ? | main() | File /usr/lib/mailman/cron/senddigests, line 86, in main | mlist.send_digest_now() | File /usr/lib/mailman/Mailman/Digester.py, line 60, in send_digest_now | ToDigest.send_digests(self, mboxfp) | File /usr/lib/mailman/Mailman/Handlers/ToDigest.py, line 142, in send_digests | send_i18n_digests(mlist, mboxfp) | File /usr/lib/mailman/Mailman/Handlers/ToDigest.py, line 324, in send_i18n_digests | msg = scrubber(mlist, msg) | File /usr/lib/mailman/Mailman/Handlers/Scrubber.py, line 393, in process | replace_payload_by_text(msg, sep.join(text), charset) | File /usr/lib/mailman/Mailman/Handlers/Scrubber.py, line 175, in replace_payload_by_text | msg.set_payload(text, charset) | File email/Message.py, line 218, in set_payload | File email/Message.py, line 242, in set_charset | TypeError: iso-8859-1 I followed the trail of #384016 and found that its supposed fix (the mailman package shipping its own email Python package) does not seem to be in effect on my system: | io:/usr/lib/mailman/cron python | Python 2.4.4 (#2, Aug 16 2007, 02:03:40) | [GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2 | Type help, copyright, credits or license for more information. | import paths | import email | email.__version__ | '3.0.2' | Using python2.3 to run senddigests works around the problem as expected: | io:/usr/lib/mailman/cron sudo -H -u list python2.3 /usr/lib/mailman/cron/senddigests | io:/usr/lib/mailman/cron What's going on here? Has the inclusion of mailman's own email package been reverted? -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (600, 'testing'), (90, 'unstable') Architecture: i386 (i586) Kernel: Linux 2.6.21-2-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mailman depends on: ii adduser 3.105 add and remove users and groups ii apache2 2.0.55-4.1 next generation, scalable, extenda ii apache2-mpm-worker [httpd]2.0.55-4.1 high speed threaded model for Apac ii courier-mta [mail-transport-a 0.53.3-6 Courier Mail Server - ESMTP daemon ii cron 3.0pl1-100 management of regular background p ii debconf [debconf-2.0] 1.5.14 Debian configuration management sy ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries ii logrotate 3.7.1-3Log rotation utility ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip ii pwgen 2.06-1 Automatic Password generation ii python2.4.4-6An interactive high-level object-o ii python-support0.6.4 automated rebuilding support for p ii ucf 3.001 Update Configuration File: preserv mailman recommends no packages. -- debconf information: mailman/update_passwords: * mailman/site_languages: de, en * mailman/used_languages: de en * mailman/create_site_list: * mailman/queue_files_present: * mailman/default_server_language: en * mailman/gate_news: false mailman/update_aliases: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443069: mailman: senddigests cron job: TypeError: iso-8859-1
Joost van Baal wrote: FWIW, I've recently manually done: ln -s /usr/lib/mailman/pythonlib /var/lib/mailman/pythonlib after such a Mailman upgrade. It solved the shown errors from senddigests. Apparently, the postinst script fails to execute this under some circumstances. Not only that, but on my system /var/lib/mailman/pythonlib is a (empty) directory owned by the package mailman! Kind of difficult to place a symlink there when there's already a real directory of the same name. However if I remove the empty dir and replace it with a symlink as you said, then it works: | io:/usr/lib/mailman/cron python | Python 2.4.4 (#2, Aug 16 2007, 02:03:40) | [GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2 | Type help, copyright, credits or license for more information. | import paths | import email | email.__version__ | '2.5.8' | Thanks. So I guess this issue boils down to the mailman package needing to install a symlink rather than a directory as /var/lib/mailman/pythonlib. pgpOxxhIvq0wi.pgp Description: PGP signature
Bug#426968: webalizer: Wishing new conf setup were like logrotate
I agree completely. I think the new vhost/multiple-config-file support architecture is bad. I recently upgraded from a year-old version of the webalizer package to the current one and tried to adapt my homegrown vhost infrastructure (which is similar to Jacob's) to the new one in order to reduce the deviation from the official way of doing things, but it's just awful. See below for the rationale. I cannot even retain my own way of doing things because the webalizer package's configure script insists on moving /etc/webalizer.conf to /etc/webalizer/webalizer.conf on each and every configuration of the package. I considered filing a bug about this with serious severity, but then I figured that the entire official infrastructure should rather be improved instead. I think users of webalizer (like Jacob and me) have long been accustomed to using webalizer.conf as a default config file and use smaller config files on top of that with specific configuration directives for specific vhosts. Having this default config file (webalizer.conf) in the same directory as all the vhost config files is a mess. Either move webalizer.conf back to /etc/ (preferred, since it's upstream's way), or create a sub-directory in /etc/webalizer/ for the vhost config files. Please consider changing the package's config file architecture to that end. pgpOl0BGWfmW4.pgp Description: PGP signature
Bug#431239: Patches from Robert Millan
Robert Millan wrote: On Fri, Jul 13, 2007 at 11:25:26PM +, Julian Mehnle wrote: Robert's patch needs to be dual-licensed under LGPL and BSD just like libspf2 in order to allow the patched libspf2 to be distributed under the BSD license in the future. Robert, would you consider resubmitting your patch with the license note amended to that effect? To be honest, I have to say that I don't like the possibility of my code becoming non-free. I can see that. However, how would dual-licensing your patch under LGPL and BSD make your patch non-free? BSD just isn't copyleft (in FSF terms[1]), but it's free nonetheless. If there's ever someone actively maintaining libspf2 again, and that person wants to stick with an unprotected license, I'll gladly license it in these terms. What's an unprotected license? A copyleft one? References: 1. http://www.fsf.org/licensing/essays/copyleft.html pgpGG8GaPMje3.pgp Description: PGP signature
Bug#431239: Patches from Robert Millan
Robert Millan wrote: On Sat, Jul 14, 2007 at 01:23:56PM +, Julian Mehnle wrote: I can see that. However, how would dual-licensing your patch under LGPL and BSD make your patch non-free? BSD just isn't copyleft (in FSF terms[1]), but it's free nonetheless. For example, BSD license gives permission for Microsoft to incorporate the code in Exchange, improve it, and not give anything back. I find this unfair [1]. Sure, sure, but that doesn't mean the BSD license is non-free. It's just not copyleft, or viral, as Microsoft would call it. Is this a matter of principle for you, or would you actually feel exploited by a closed-source vendor who uses a libspf2 modified by your patch? I mean, they can use the UNmodified libspf2 under the BSD license already. I'm just curious, not trying to pressure you into anything. pgp7yXmsqYnsC.pgp Description: PGP signature
Bug#430508: Patches from Robert Millan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Magnus Holmgren wrote: Any comments or objections to these patches? http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;att=1;bug=430508 Thanks for your patch! Robert Millan wrote in bugs.debian.org #430508: spfquery segfaults when passing it a -guess argument: $ spfquery -ip 1.2.3.4 -sender [EMAIL PROTECTED] -helo foo -guess blah This is caused by spf_response_2mx being a null pointer in APPEND_RESULT(SPF_response_result(spf_response_2mx)); I *think* that usage of this variable is all wrong in this routine, since we're checking for fallback spf record not 2nd rcpt mx. See attached patch for a proposed fix. I think the use of the spf_response_2mx variable instead of an additional, separate spf_response_fallback for the fallback branch in spfquery.c was laziness on the spfquery author's part. However, the initialization of spf_response instead of spf_response_2mx was clearly erroneous. Overall, I think Robert's patch for bdo #430508 is sound. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGl/pRwL7PKlBZWjsRAnpuAKC7QdzqLZaA/anMRjEDWU+DywcOPQCdGUpo H01G+BtYJPDSJGo1tNhA0rg= =xWK1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433047: libspf2: debian/copyright misrepresents license as GPL/BSD, should be LGPL/BSD
Package: libspf2 Version: 4 Severity: serious Tags: patch Justification: Policy 12.5 debian/copyright misrepresents the license as GPL/BSD, but libspf2's README file says: | The code in the libspf2 distribution is Copyright 2005 by Shevek | and Wayne Schlitt, all rights reserved. Copyright retained for the | purpose of protecting free software redistribution. | | This program is free software; you can redistribute it and/or modify | it under the terms of either: | | a) the GNU Lesser General Public License as published by the Free | Software Foundation; either version 2.1, or (at your option) any | later version, or | | OR | | b) The two-clause BSD license. | | [...] So the license really is LGPL/BSD. I am attaching a patch that updates debian/copyright accordingly. diff -ruN libspf2-1.2.5.dfsg.org/debian/copyright libspf2-1.2.5.dfsg/debian/copyright --- libspf2-1.2.5.dfsg.org/debian/copyright 2007-07-13 22:06:15.0 + +++ libspf2-1.2.5.dfsg/debian/copyright 2007-07-13 22:56:41.0 + @@ -9,11 +9,12 @@ Copyright: -This software is copyright (c) 2004 by Wayne Schlitt [EMAIL PROTECTED] +This software is copyright (c) 2004-2005 by Wayne Schlitt [EMAIL PROTECTED] +and Shevek [EMAIL PROTECTED] -You are free to distribute this software under the terms of -the GNU General Public License version 2 or the BSD license, at your choice. +You are free to distribute this software under the terms of the GNU Lesser +General Public License version 2.1 or the BSD license, at your choice. -On Debian systems, the complete text of the GNU General Public -License can be found in the file `/usr/share/common-licenses/GPL-2' and +On Debian systems, the complete text of the GNU Lesser General Public +License can be found in the file `/usr/share/common-licenses/LGPL-2.1' and the BSD license can be found in the file `/usr/share/common-licenses/BSD'.
Bug#431239: Patches from Robert Millan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Kitterman wrote: On Friday 13 July 2007 16:20, Magnus Holmgren wrote: Any comments or objections to these patches? http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;att=1;bug=431239 RFC conformance issues #431239 is a little more complex: The patch carries an LGPL copyright notification. Libspf2 is currently dual licensed under BSD and GPL version 2. This seems to be a mistake in debian/copyright. libspf2's LICENSES file says: | The code in the libspf2 distribution is Copyright 2005 by Shevek | and Wayne Schlitt, all rights reserved. Copyright retained for the | purpose of protecting free software redistribution. | | This program is free software; you can redistribute it and/or modify | it under the terms of either: | | a) the GNU Lesser General Public License as published by the Free | Software Foundation; either version 2.1, or (at your option) any | later version, or | | OR | | b) The two-clause BSD license. I just reported this as a separate bug (bdo #433047[1]). I don't recall the exact rules on combining LGPL and GPL code (it hasn't come up in any packages I've done), but that needs to be considered. More important is that is LGPL code is incorporated, the package is no longer distributable under the BSD license. This is true even considering that libspf2's actual license is LGPL/BSD rather than GPL/BSD. Robert's patch needs to be dual-licensed under LGPL and BSD just like libspf2 in order to allow the patched libspf2 to be distributed under the BSD license in the future. Robert, would you consider resubmitting your patch with the license note amended to that effect? From a technical perspective: Adding the Null Mail From HELO check is useful. The approach used here is consistent with the approach that many long standing SPF libraries (Mail::SPF::Query and pyspf for two) take. So this is good. Agreed. (Do not construe this as a retreat from the newer Mail::SPF Perl module's more formal approach, whose author I am. Whereas I prefer the more formal approach, the less formal one used by Mail::SPF::Query, pyspf, and now libspf2, is certainly legitimate.) The second part of the change, changing the SPF None response string from %s is neither permitted nor denied by %s, to %s doesn't provide an SPF record is a wording improvement, but given that it's been this way for several years, I don't know if there are programs that are dependent on that string. If there was any code depending on the explanatory result text, then that would be a design bug in such code. So, I'd suggest this is an improvement, but not entirely without risk. I'd tend not to want to make it, but I could understand either way. I say go ahead with the change. I wouldn't... er... would not use a contraction, though. Say %s does not provide an SPF record instead. References: 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433047 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGmAnmwL7PKlBZWjsRAt/mAKDCQGnf80lNqAnUyxxFpWAxNrrtTwCghnUc PIPXpUOYbXPIKLlSQaef9Tg= =oZf7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365241: libmodule-build-perl: Upstream version 0.28 has been released
Julian Mehnle wrote: Upstream has released version 0.28 of Module::Build: [...] It fixes many bugs of 0.26 and brings many new useful features. Please package it! We're now at 0.2808. I updated the Debian package: http://files.mehnle.net/software/debian/libmodule-build-perl/ pgpaWz8XtCMRz.pgp Description: PGP signature
Bug#420294: pdns: Upstream version 2.9.21 released
Package: pdns Severity: wishlist PowerDNS 2.9.21 has been released upstream: http://mailman.powerdns.com/pipermail/pdns-announce/2007-April/76.html Please package it! Apparently this release also addresses at least the Debian bugs #406462 and #406461. See the changelog: http://doc.powerdns.com/changelog.html#CHANGELOG-2-9-21 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406428: Error on upgrade from 3.1.3-2: initscript pdns-recursor, action stop failed. [...] old ( new) pre-removal script returned error exit status 1
package pdns-recursor retitle 406428 pdns-recursor: initscript stop action fails if pdns-recursor not running (e.g. if disabled in current runlevel), makes prerm script fail thanks It seems that the pdns-recursor initscript's stop action fails if pdns- recursor is not running, e.g. if it has been disabled for the current runlevel. In effect, this causes the prerm script fail, e.g. on package upgrades. The initscript should tolerate pdns-recursor not running. pgpLnISaB1f7P.pgp Description: PGP signature
Bug#407799: KDM and desktop-base
Just wanting to follow up on a comment from Bastian Venthur in #406438: Bastian Venthur wrote: As the maintainer of kde-kdm-themes I don't think that desktop-base brakes my package. I'm happy that it finally enables the new KDM theme by default for the masses. The problem is that it doesn't just enable the new KDM theme by default, it forcefully enables it for everyone, ignoring all the KDE Control Center settings, without giving a hint on how to disable it. If this behavior is indeed intended or there isn't any other way to get The Holy New KDM Theme deployed for the masses, and the solution for those who don't want it is to remove desktop-base, then the package is clearly misnamed! Perhaps desktop-base-for-dummies or default-debian- desktop-base (along with a clarified package description) would be better alternatives. pgpryAwQkaTGi.pgp Description: PGP signature
Bug#407799: desktop-base: /etc/defaults/kdm.d/10_desktop_base overrides configured login desktop without warning on upgrade
Package: desktop-base Version: 4.0.0 Severity: normal After I had upgraded desktop-base to 4.0.0 yesterday, today I was forced to see a very weird login desktop totally unlike what I had configured for kdm and have been using for years. At first, I was unable to find any clue whatsoever about how to get rid of the new login desktop. At the very least, the change (and how to revert it) should have been mentioned in desktop-base's NEWS.Debian or changelog file! Luckily, I found a posting about the issue on one of the Debian mailing lists: http://groups.google.com/group/linux.debian.maint.kde/browse_thread/thread/a799751c09976c91/3065cf1d5b153bb0 I think there should also be a way to disable that option via the KDE control center. At least that's where I looked for it. While I don't use Debian stable releases, I suggest that Debian doesn't accept such last minute changes without the usual 10 days review, as it seems to have happened here. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (600, 'testing'), (90, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) desktop-base depends on no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407591: xml2rfc: New upstream version available: 1.32
Package: xml2rfc Severity: wishlist 1.32 has been released upstream: http://xml.resource.org Please package it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403750: jabberd2: New upstream release
Marcus Better wrote: I have a few other ideas about this package. First, I think we should build one binary package with support for all database and authentication options. This would simplify packaging a lot, for the price of a few additional library dependencies, which is not so bad. (And if you want to avoid it, then the proper solution is to put the db code in loadable modules à la freeradius.) What do you think, should I give it a try? I wouldn't like to install a package requiring me to install the libmysql* mess. I'm using PostgreSQL, so I don't need, and would like to avoid, any other DB client libs. pgphB21pTlcio.pgp Description: PGP signature
Bug#406427: apache2-mpm-worker: Error on upgrade from 2.0.55: Cannot load /usr/lib/apache2/modules/mod_actions.so into server: /usr/lib/apache2/modules/mod_actions.so: cannot open shared object file:
Package: apache2-mpm-worker Version: 2.2.3-3.2 Severity: important I just tried upgrading my slightly older Debian Testing system including the Apache 2.0 packages on it. When it came to upgrading apache2-mpm-worker, this is what happened: [...] Selecting previously deselected package libaprutil1. Unpacking libaprutil1 (from .../libaprutil1_1.2.7+dfsg-2_i386.deb) ... dpkg: apache2-common: dependency problems, but removing anyway as you request: apache2-mpm-worker depends on apache2-common (= 2.0.55-4.1); however: Package apache2-common is to be removed. libapache2-mod-perl2 depends on apache2-common (= 2.0.50-9). (Reading database ... 101322 files and directories currently installed.) Removing apache2-common ... Stopping apache 2.0 web server (Reading database ... 100954 files and directories currently installed.) Preparing to replace apache2-mpm-worker 2.0.55-4.1 (using .../apache2-mpm-worker_2.2.3-3.2_i386.deb) ... Stopping apache 2.0 web server...Syntax error on line 1 of /etc/apache2/mods-enabled/actions.load: Cannot load /usr/lib/apache2/modules/mod_actions.so into server: /usr/lib/apache2/modules/mod_actions.so: cannot open shared object file: No such file or directory failed! invoke-rc.d: initscript apache2, action stop failed. Stopping apache 2.0 web server...Syntax error on line 1 of /etc/apache2/mods-enabled/actions.load: Cannot load /usr/lib/apache2/modules/mod_actions.so into server: /usr/lib/apache2/modules/mod_actions.so: cannot open shared object file: No such file or directory failed! invoke-rc.d: initscript apache2, action stop failed. Unpacking replacement apache2-mpm-worker ... Preparing to replace libapache2-mod-perl2 2.0.2-2 (using .../libapache2-mod-perl2_2.0.2-2.3_i386.deb) ... Unpacking replacement libapache2-mod-perl2 ... Preparing to replace apache2-utils 2.0.55-4.1 (using .../apache2-utils_2.2.3-3.2_i386.deb) ... Unpacking replacement apache2-utils ... [...] Selecting previously deselected package apache2.2-common. (Reading database ... 100951 files and directories currently installed.) Unpacking apache2.2-common (from .../apache2.2-common_2.2.3-3.2_i386.deb) ... Stopping apache 2.0 web server...apache2: Syntax error on line 125 of /etc/apache2/apache2.conf: Syntax error on line 1 of /etc/apache2/mods-enabled/actions.load: Cannot load /usr/lib/apache2/modules/mod_actions.so into server: /usr/lib/apache2/modules/mod_actions.so: cannot open shared object file: No such file or directory failed! invoke-rc.d: initscript apache2, action stop failed. [...] Setting up apache2-mpm-worker (2.2.3-3.2) ... Starting web server (apache2)...apache2: Syntax error on line 671 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/sites-enabled/000-default: No such file or directory failed! invoke-rc.d: initscript apache2, action start failed. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (600, 'testing'), (90, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages apache2-mpm-worker depends on: ii apache2. 2.2.3-3.2 Next generation, scalable, extenda ii libapr1 1.2.7-8.2 The Apache Portable Runtime Librar ii libaprut 1.2.7+dfsg-2The Apache Portable Runtime Utilit ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libdb4.4 4.4.20-8Berkeley v4.4 Database Libraries [ ii libexpat 1.95.8-3.3 XML parsing C library - runtime li ii libldap2 2.1.30-13.2 OpenLDAP libraries ii libpcre3 6.7-1 Perl 5 Compatible Regular Expressi ii libpq4 8.1.5-2 PostgreSQL C client library ii libsqlit 3.3.8-1 SQLite 3 shared library ii libuuid1 1.39+1.40-WIP-2006.11.14+dfsg-1 universally unique id library apache2-mpm-worker recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406428: Error on upgrade from 3.1.3-2: initscript pdns-recursor, action stop failed. [...] old ( new) pre-removal script returned error exit status 1
Package: pdns-recursor Version: 3.1.4-1 Severity: important I just tried upgrading my slightly older Debian Testing system including the pdns-recursor package on it. When it came to upgrading pdns-recursor, this is what happened: Preparing to replace pdns-recursor 3.1.3-2 (using .../pdns-recursor_3.1.4-1_i386.deb) ... Stopping PowerDNS recursor: pdns-recursorinvoke-rc.d: initscript pdns-recursor, action stop failed. dpkg: warning - old pre-removal script returned error exit status 1 dpkg - trying script from the new package instead ... Stopping PowerDNS recursor: pdns-recursorinvoke-rc.d: initscript pdns-recursor, action stop failed. dpkg: error processing /var/cache/apt/archives/pdns-recursor_3.1.4-1_i386.deb (--unpack): subprocess new pre-removal script returned error exit status 1 [...] Errors were encountered while processing: /var/cache/apt/archives/pdns-recursor_3.1.4-1_i386.deb Repeated attempts didn't help. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (600, 'testing'), (90, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages pdns-recursor depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-19 GCC support library ii libstdc++6 4.1.1-19The GNU Standard C++ Library v3 Versions of packages pdns-recursor recommends: ii pdns-doc 2.9.20-7.0+spf PowerDNS manual -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329644: libnetaddr-ip-perl: New upstream release
FYI, I updated the package in my HTTP directory to the 4.004 upstream version. pgpiiyr9hykF7.pgp Description: PGP signature
Bug#308911: run-parts does not execute links/binaries containing periods in the name
Erich Minderlein wrote: As I learnt recently , run-parts executes cron and this is intended behaviour see man cron not a BUG. Well, so what? Why can't a command-line option be introduced that allows the dots? That wouldn't be incompatible with cron. pgpG45VQFWF2X.pgp Description: PGP signature
Bug#306875: spfquery: Support for alternatives system
Package: spfquery
Version: 1.2.5-4
Followup-For: Bug #306875
Here's a patch that installs the `spfquery` executable as `spfquery.
libspf2` and adds update-alternatives support for it.
diff -ruN libspf2-1.2.5.org/debian/compat libspf2-1.2.5/debian/compat
--- libspf2-1.2.5.org/debian/compat 1970-01-01 00:00:00.0 +
+++ libspf2-1.2.5/debian/compat 2006-12-03 02:12:31.0 +
@@ -0,0 +1 @@
+5
diff -ruN libspf2-1.2.5.org/debian/control libspf2-1.2.5/debian/control
--- libspf2-1.2.5.org/debian/control2006-12-02 20:05:56.0 +
+++ libspf2-1.2.5/debian/control2006-12-03 03:37:45.0 +
@@ -1,8 +1,8 @@
Source: libspf2
Priority: optional
Maintainer: Debian QA Group [EMAIL PROTECTED]
-Build-Depends: debhelper ( 4.1), cdbs
-Standards-Version: 3.6.1
+Build-Depends: debhelper ( 5), cdbs
+Standards-Version: 3.7.2
Package: libspf2-dev
Section: libdevel
@@ -34,6 +34,6 @@
Section: mail
Architecture: any
Depends: ${shlibs:Depends}
-Conflicts: libmail-spf-query-perl
+Conflicts: libmail-spf-query-perl ( 1:1.999.1-3)
Description: Sender Policy Framework library, written in C
Utilities to test and query SPF records.
\ No newline at end of file
diff -ruN libspf2-1.2.5.org/debian/rules libspf2-1.2.5/debian/rules
--- libspf2-1.2.5.org/debian/rules 2006-12-02 20:05:56.0 +
+++ libspf2-1.2.5/debian/rules 2006-12-03 02:46:42.0 +
@@ -1,6 +1,12 @@
#!/usr/bin/make -f
+SOURCE_PACKAGE = libspf2
+
include /usr/share/cdbs/1/class/autotools.mk
include /usr/share/cdbs/1/rules/debhelper.mk
DEB_DH_MAKESHLIBS_ARGS_ALL := -V
+
+binary-install/spfquery::
+ # Rename the `spfquery` tool for the alternatives system:
+ mv debian/spfquery/usr/bin/spfquery
debian/spfquery/usr/bin/spfquery.$(SOURCE_PACKAGE)
diff -ruN libspf2-1.2.5.org/debian/spfquery.postinst
libspf2-1.2.5/debian/spfquery.postinst
--- libspf2-1.2.5.org/debian/spfquery.postinst 1970-01-01 00:00:00.0
+
+++ libspf2-1.2.5/debian/spfquery.postinst 2006-12-03 00:28:47.0
+
@@ -0,0 +1,15 @@
+#!/bin/sh -e
+
+mode=$1
+
+source_package=libspf2
+
+case $mode in
+ configure )
+prev_version=$2
+
+update-alternatives --install /usr/bin/spfquery spfquery
/usr/bin/spfquery.$source_package 75
+;;
+esac
+
+#DEBHELPER#
diff -ruN libspf2-1.2.5.org/debian/spfquery.prerm
libspf2-1.2.5/debian/spfquery.prerm
--- libspf2-1.2.5.org/debian/spfquery.prerm 1970-01-01 00:00:00.0
+
+++ libspf2-1.2.5/debian/spfquery.prerm 2006-12-03 00:29:18.0 +
@@ -0,0 +1,13 @@
+#!/bin/sh -e
+
+mode=$1
+
+source_package=libspf2
+
+case $mode in
+ remove )
+update-alternatives --remove spfquery /usr/bin/spfquery.$source_package
+;;
+esac
+
+#DEBHELPER#
Bug#235028: libmail-spf-query-perl: no init.d script for /usr/sbin/spfd daemon
package libmail-spf-query-perl tags +wontfix thanks Sorry for wontfixing this so late. The problem here is that libmail-spf- query-perl really is a library package and not a tools package. Thus it should not run any daemons or install any init scripts for them. Further, Mail::SPF::Query has reached the end of its life-cycle upstream and will be obsoleted by the new Mail::SPF module soon. A corresponding tools package might then be created together with libmail-spf-per. Julian, both upstream maintainer and member of the Debian Perl Group. pgpKYAvp4KVtn.pgp Description: PGP signature
Bug#397779: libmail-spf-query-perl should have dependency on LMAP::CID2SPF module
Peter Fokkinga wrote: Package: libmail-spf-query-perl Version: 1.997-3 The Perl module Mail::SPF::Query in libmail-spf-query-perl uses LMAP::CID2SPF but AFAIK this module is not available as a Debian package. When spamassassin is installed in combination with libmail-spf-query-perl then the following error will end up in /var/log/mail.warn Nov 7 22:28:00 jet spamd[514]: Can't locate LMAP/CID2SPF.pm in @INC (@INC contains: ../lib /usr/share/perl5 /etc/perl /usr/local/lib/perl/5.8.7 /usr/local/share/perl/5.8.7 /usr/lib/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl) at /usr/shar e/perl5/Mail/SPF/Query.pm line 1757, GEN154 line 51. Short answer: This is really a design bug in Mail::SPF::Query 1.998. Long answer: LMAP::CID2SPF was supposed to translate DNS records of Microsoft's long- dead Caller ID[1] (not to be confused with their newer proposal called Sender ID) to SPF records. However the Caller ID records out there can be counted on a single hand, so there is no point in supporting those records in Mail::SPF::Query. Since this is a bug in Mail::SPF::Query 1.997 (and earlier), which is in the current stable (AKA Sarge) distribution, an upload to proposed- updates removing the use og LMAP::CID2SPF would be the appropriate and minimally invasive solution. An upload of 1.999.1 to proposed-updates might be a viable alternative. However, as Etch is about to be released soon, there is probably little point in making a proposed-updates upload now... Thus I propose to tag this bug wontfix. Any objections? Julian, both upstream maintainer and a member of the Debian Perl Group. References: 1. http://en.wikipedia.org/wiki/MARID pgpBYPkhLHnpX.pgp Description: PGP signature
Bug#389475: courier-mta: `newaliases` should not ignore /etc/courier/aliases(/) in favor of /etc/aliases
Package: courier-mta Version: 0.53.2-3 Severity: important Debian policy, section 11.6, mandates that every MTA package provide a `newaliases` program. The courier-mta package ships such a program, which calls `/usr/sbin/makealiases -src=/etc/aliases`. This call builds the e-mail aliases database from the /etc/aliases file, however it completely ignores Courier's usual /etc/courier/aliases file or /etc/courier/aliases/ directory. Thus the normal aliases database built using a plain `makealiases` call gets overwritten on each call to `newaliases` (automatic or manual), effectively killing many configured aliases. (In my case, I lost all my [EMAIL PROTECTED] aliases, among others! Baaad!) Nowhere does Debian policy require `newaliases` to build the aliases database only from /etc/aliases. /usr/sbin/newaliases should really just call `makealiases` (or maybe even just be a symlink to that), so that _all_ the configured aliases are respected. Furthermore, the /etc/courier/aliases/ directory should probably contain a symlink to /etc/aliases. If the symlink was named system, it could replace the /etc/courier/aliases/system file shipped with the courier-mta package. This would also resolve bug #229287. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387902: libnet-dns-perl: New upstream release 0.58 with helpful fixes
Package: libnet-dns-perl Severity: normal A new upstream release, 0.58, is available from CPAN. It includes a number of helpful fixes (see the changelog). Please upgrade the libnet-dns-perl package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#202488: isdnvboxserver: Spool directory incorrectly renamed on upgrade
package isdnvboxserver severity 202488 serious # Justification: Breaks package on every upgrade thanks This bug has occurred to us multiple times, everytime I upgrade isdnvboxserver! It always renames the spooldir to ttyI6 and thus breaks operation. On top of this, it always gives the following brain-dead debconf note: | Configuring isdnvboxserver | | two obsolete spool directories detected | | The directories `/vvaarr/ssppll/vvbbooxx/doesntexist_1' and | `/vvaarr/ssppll/vvbbooxx/doesntexist_1' (which aren't used anymore in | the standard configuration), and the new spool directory | `/var/spool/vbox/ttyI6' all exist. The old directories will no longer be | used; please manually move any messages from there to the new directory | (if any), and delete the old directories. This package is seriously broken! pgpEgRscBthpm.pgp Description: PGP signature
Bug#381130: dh-make-perl: Produces out-of-date-standards-version 3.6.1 (current is 3.7.2)
Package: dh-make-perl Version: 0.21 Severity: normal dh-make-perl produces debian/control with an out-of-date-standards-version 3.6.1. Please make dh-make-perl produce control files that conform to a current standards version, like 3.7.2. It may not hurt to raise the debhelper compat level (and the debhelper dependency) to 5 as well. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (600, 'testing'), (90, 'unstable') ... Versions of packages dh-make-perl depends on: ii debhelper 5.0.37.2 helper programs for debian/rules ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381148: dh-make-perl: build-depends-indep-without-arch-indep when building NetAddr::IP::Lite
Package: dh-make-perl Version: 0.21 Severity: normal When I build a libnetaddr-ip-lite-perl package from NetAddr::IP::Lite using dh-make-perl and run the resulting package through lintian, I get the following error message: E: libnetaddr-ip-lite-perl source: build-depends-indep-without-arch-indep N: N: The control file specifies source relations for N: architecture-independent packages, but no architecture-independent N: packages are built. N: N: Refer to Policy Manual, section 7.6 for details. N: I think dh-make-perl should say Build-Depends: perl (= ...) instead of Build-Depends-Indep: perl (= ...) when creating debian/control for an arch-specific package. Can dh-make-perl do that? -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (600, 'testing'), (90, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.15-1-686 Versions of packages dh-make-perl depends on: ii debhelper 5.0.37.2 helper programs for debian/rules ii dpkg-dev 1.13.21package building tools for Debian ii fakeroot 1.5.8 Gives a fake root environment ii libmodule-depends-perl0.10-1 identify the dependencies of a dis ii libyaml-perl 0.57-2 YAML Ain't Markup Language (tm) ii make 3.81-2 The GNU version of the make util ii perl 5.8.8-4Larry Wall's Practical Extraction ii perl-modules [libpod-parser-p 5.8.8-4Core Perl modules Versions of packages dh-make-perl recommends: ii apt-file 2.0.8 APT package searching utility -- c ii libmodule-build-perl 0.26-1 Subclassable and make-independant -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329644: libnetaddr-ip-perl: New upstream release
Julian Mehnle wrote: 3.33 is available on CPAN. I made an updated Debian package based on the updates in Jonas Genannt's 3.28 package: Incidentally, NetAddr::IP 4.001 has been released on CPAN today. This is a major update, as it now includes NetAddr::IP::Lite (and thus XS code) and fully supports IPv6. I again made an updated Debian package: http://files.mehnle.net/software/debian/libnetaddr-ip-perl/ Due to the XS code, the package is now an arch-any (vs. all) package. Take care of that when uploading it! pgp6bG5jRlBpU.pgp Description: PGP signature
Bug#380492: xml2rfc: New upstream version available
Package: xml2rfc Severity: wishlist 1.31 has been released upstream: http://xml.resource.org Please package it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
