Bug#698504: cups-pk-helper - offer of assistance
Hi Guido, I work on Endless OS (www.endlessos.org) which is a derivative of Debian. We carry a number of patches to cups-pk-helper to address bugs present in Debian which are fixed in Ubuntu: - a polkit policy that grants admin rights to members of the lpadmin group - a separate UID for cups-pk-helper which is a member of the lpadmin group, meaning job management works correctly (as detailed in https://bugs.launchpad.net/ubuntu/+source/cups-pk-helper/+bug/934291 ) These issues are not meaningfully fixable upstream as cups-pk-helper is just a mechanism and the policy is intended to be distro-determined. The lpadmin group and CUPS configuration is up to each distro, but at least for Debian derivatives it makes sense that these issues can be addressed once and then Ubuntu and other derivatives (such as Endless OS) not need to diverge and carry the same patches. I see from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698504#44 that you are open to assistance with the package, which we're happy to offer. I'm wondering if you would consider a) moving the package into to the printing-team on Salsa, and there b) we can send some patches to address the above issues and lower the delta between Debian and Ubuntu / Endless OS. Let us know if this would be of interest. Many Thanks, Rob
Bug#934167: #934167: workaround for buster users
I was facing the error described at https://github.com/cweiske/grauphel/issues/72#issuecomment-519173520 In case anyone finds themselves here, and is running Debian buster, I was able to fix relatively easily. The latest version of php-oauth in bullseye (currently 2.0.5+1.2.3- 1+b1) depends on PHP 7.4 so isn't trivially installable on buster via apt pinning etc. However, the previous version (2.0.5+1.2.3-1, I guess before a mass rebuild) is still binary compatible with buster and PHP 7.3, so I was able to fetch the binary from snapshot and install directly: http://snapshot.debian.org/package/php-oauth/2.0.5%2B1.2.3-1/#php-oauth_2.0.5:2b:1.2.3-1 Cheers, Rob
Bug#906923: hpijs-ppds package is nearly empty
Package: hpijs-ppds Version: 3.18.7+dfsg1-1 Updating the hplip package in Endless OS we noticed that hpijds-ppds package seems to be close to empty. The PPDs named here: https://salsa.debian.org/printing-team/hplip/blob/debian/master/debian/ hpijs-ppds.install Are not present: ramcq@upsilon:~/endless/home/ramcq/branches/eos/master/core/hplip/binar ies$ dpkg -c hpijs-ppds_3.18.7+dfsg1-1endless1bem1_all.deb drwxr-xr-x root/root 0 2018-08-22 12:27 ./ drwxr-xr-x root/root 0 2018-08-22 12:27 ./usr/ drwxr-xr-x root/root 0 2018-08-22 12:27 ./usr/lib/ drwxr-xr-x root/root 0 2018-08-22 12:27 ./usr/lib/cups/ drwxr-xr-x root/root 0 2018-08-22 12:27 ./usr/lib/cups/driver/ -rwxr-xr-x root/root 7376 2018-08-22 12:27 ./usr/lib/cups/driver/hpijs-ppds drwxr-xr-x root/root 0 2018-08-22 12:27 ./usr/share/ drwxr-xr-x root/root 0 2018-08-22 12:27 ./usr/share/cups/ drwxr-xr-x root/root 0 2018-08-22 12:27 ./usr/share/cups/ppd- updaters/ -rw-r--r-- root/root 618 2018-08-13 15:54 ./usr/share/cups/ppd- updaters/hpijs-ppds.ppd-updater drwxr-xr-x root/root 0 2018-08-22 12:27 ./usr/share/doc/ drwxr-xr-x root/root 0 2018-08-22 12:27 ./usr/share/doc/hpijs- ppds/ -rw-r--r-- root/root 81076 2018-08-22 12:27 ./usr/share/doc/hpijs- ppds/changelog.Debian.gz -rw-r--r-- root/root 15438 2018-08-13 15:54 ./usr/share/doc/hpijs- ppds/copyright None of the ones from sid seem to be there any more: https://packages.debian.org/sid/all/hpijs-ppds/filelist Cheers, Rob
Bug#904023: re-add file dependencies on libav*.so.*
Package: gstreamer1.0-libav As discussed on IRC, the gst-libav1.0 packaging seemed to accidentally drop the Debian patch which adds the file dependency of the libav plugin on libavcodec itself, as part of this patchchange: https://salsa.debian.org/gstreamer-team/gst-libav1.0/commit/1a87e740 This means that that changes to the installed libavcodec won't cause the GST registry to be refreshed. This patch should be re-instated. Thanks, Rob
Bug#860888: Please reorder the dependencies
Hi there, I agree with this. We ran into a bug in Endless OS with aspell-en being installed unintentionally by libenchant dependencies, when we have otherwise deprecated/removed aspell from the OS. The current dependency line is inconsistent with the internal behaviour/policy of Enchant. Enchant upstream always universally prefers hunspell to aspell. You can see that here: https://github.com/AbiWord/enchant/blob/master/src/enchant.ordering Considering this, and that hunspell is the active upstream for myspell now, I suggest this dependency line: hunspell-en-us | hunspell-dictionary | myspell-dictionary | aspell-dictionary | ispell-dictionary Thanks, Rob On Fri, 21 Apr 2017 13:13:37 +0200 Laurent Bigonville wrote: > Package: libenchant1c2a > Version: 1.6.0-11+b1 > Severity: normal > > Hi, > > ATM, the libenchant1c2a package declares the following dependencies > against spellchecker "backends": > > aspell-en | myspell-dictionary | aspell-dictionary | ispell-dictionary | > hunspell-dictionary > > AFAIK, aspell is obsolete and hunspell should be prefered. Shouldn't it > be a good idea to move hunspell as the 1st alternative? > > It seems that other distributions are prefering hunspell aswell, see: > > https://fedoraproject.org/wiki/Releases/FeatureDictionary > https://wiki.ubuntu.com/ConsolidateSpellingLibs > > What do you think? > > Regards, > > Laurent Bigonville > > -- System Information: > Debian Release: 9.0 > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, > 'experimental-debug'), (1, 'experimental') > Architecture: amd64 > (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages libenchant1c2a depends on: > ii aspell-fr [aspell-dictionary]0.50-3-8 > ii hunspell-en-us [hunspell-dictionary] 20070829-7 > ii hunspell-fr-classical [hunspell-dictionary] 1:5.7-1 > ii ifrench-gut [ispell-dictionary] 1:1.0-32 > ii libaspell15 0.60.7~20110707-3+b2 > ii libc62.24-10 > ii libgcc1 1:6.3.0-14 > ii libglib2.0-0 2.50.3-2 > ii libhunspell-1.4-01.4.1-2+b2 > ii libstdc++6 6.3.0-14 > ii zlib1g 1:1.2.8.dfsg-5 > > Versions of packages libenchant1c2a recommends: > ii enchant 1.6.0-11+b1 > > Versions of packages libenchant1c2a suggests: > pn libenchant-voikko > > -- no debconf information > > Robert McQueen | +1.415.413.4159 | Endless <http://endlessm.com/>
Bug#680125: subversion build still racy
Hi folks, Endless OS has been rebasing to Debian stretch and found that #680125 is alive and well. We can't reproduce it locally but it happens every time in our OBS. Adding .NOTPARALLEL: to the end of debian/rules fixes it, stopping the top-level debian/rules running parallel but leaving MAKEFLAGS to pass -j down to everything else - otherwise we see install-arch and install-indep running concurrently and stomping on each other. Cheers, Rob .... Robert McQueen | +1.415.413.4159 | Endless <http://endlessm.com/>
Bug#788185: Info received (potential fix for mksquashfs corruption?)
I can confirmed that, at least in our test case (a 19GB .img file alone inside a .squashfs) this patch fixes the corruption. Our patched package is here: http://ramcq.net/files/tmp/squashfs-tools_4.3-3endless1.dsc http://ramcq.net/files/tmp/squashfs-tools_4.3-3endless1.debian.tar.xz http://ramcq.net/files/tmp/squashfs-tools_4.3.orig.tar.gz Cheers, Rob On 07/06/17 16:57, Debian Bug Tracking System wrote: > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Laszlo Boszormenyi (GCS) > > If you wish to submit further information on this problem, please > send it to 788...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. ............ Robert McQueen | Endless <http://endlessm.com/>
Bug#788185: potential fix for mksquashfs corruption?
tags 788185 patch thanks Hi there, We've run into corruption at the end of long files in the image builder at Endless OS, causing signature verification failures in our installer. After some digging, it seems that this issue has been found and fixed in RH some time ago: https://bugzilla.redhat.com/show_bug.cgi?id=1141206 So there is a patch available upstream: https://github.com/plougher/squashfs-tools/commit/9c1db6d13a51a2e009f0027ef336ce03624eac0d I'm going to apply it here and see if it helps, would be great to see it in Debian. Thanks, Rob
Bug#851247: missing dependency on python3-six
Package: python3-transmissionrpc Version: 0.11-1 The python3-transmissionrpc module does not work without python3-six installed, but does not depend on it: robot101@nu:~$ ./eos-transmission-seeder -g base,en,es,pt_BR -d Traceback (most recent call last): File "./eos-transmission-seeder", line 11, in import transmissionrpc File "/usr/lib/python3/dist-packages/transmissionrpc/__init__.py", line 5, in from transmissionrpc.constants import DEFAULT_PORT, DEFAULT_TIMEOUT, PRIORITY, RATIO_LIMIT, LOGGER File "/usr/lib/python3/dist-packages/transmissionrpc/constants.py", line 6, in from six import iteritems ImportError: No module named 'six' The module worked after manually installing python3-six. Thanks, Rob
Bug#803197: libldap built against GNUTLS breaks SOGo
Package: libldap-2.4-2 Version: 2.4.40+dfsg-1 Hi there, Since upgrading to Jessie I ran into a bug in the SOGo groupware where it goes into an infinite loop after connecting to my LDAP server over TLS. This bug doesn't happen if I downgrade libldap to 2.4.31-2, or if you configure SOGo to connect to LDAP without TLS, which are both detailed on the upstream bug: http://www.sogo.nu/bugs/view.php?id=3211 Inverse (upstream developers of SOGo groupware) have investigated and found that it seems like initialising TLS in LDAP is closing an unrelated file descriptor used internally for SOGo's event handling: http://www.sogo.nu/bugs/view.php?id=3211#c9021 Seeing as downgrading libldap seems to fix the bug it suggests a regression or side-effect from some changes between Wheezy and Jessie. I'm not sure what the best next step is - I wonder if Ludovic (CC'd) or someone at Inverse would be able to create a standalone test/reproduction program so somebody could bisect and find a libldap change that exposes the bug, or if someone familiar with the code could review changes to the TLS code in libldap to see what has changed from 2.4.31 to 2.4.40 that might explain it? Let me know how I can help. Thanks, Rob
Bug#623216: can this be fixed?
I ran into this a couple of months ago on a partial upgrade and had to roll back my libebook version to get various desktop functionality back. I was going to file a bug but it was already filed since April - now I've just upgraded some other stuff and run into the same problem and can't find a version of libebook to roll back to any more. The Breaks: fix seems appropriate to make sure that all libebook users are upgraded at once along with e-d-s or not at all. It seems quite easy to fix. Would you like a patch? Thanks, Rob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628749: libebook should depend on newer e-d-s somehow
Package: libebook1.2-10 Version: 3.0.0-1 In 3.0.0-1 libebook needs the evolution-data-server that provides the org.gnome.evolution.dataserver.AddressBook0 service, but in 2.32.x e-d-s provides the old org.gnome.evolution.dataserver.AddressBook service. I had libebook 3.0.0-1 installed after installing some apps from experimental, but my evolution-data-server was still 2.32.x, so none of my apps could find contacts until I downgraded libebook again. For a smooth GNOME 2 -> 3 migration, libebook should express some dependency on the e-d-s that it works with. Regards, Rob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523923: run-rsnapshot script
Hi Johan, I was looking for exactly this script by googling for rsnapshot and anacron - so I'm very glad it's been written! I did find a small bug - if you just don't have the monthly interval defined, then it doesn't run. Might be best to make the higher intervals optional. It'd be good to see this fixed and it included in the Debian package, but ultimately I wonder however if this functionality should be included upstream. Either with the script as-is or a patch for the main rsnapshot so that it optionally does age checks and rotations by itself with a single invocation. Many Thanks, Rob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#592104: libpam-ldapd: change to common-account left accounts broken on upgrade
Package: libpam-ldapd Version: 0.7.7 Severity: important When I upgraded this system to libpam-ldapd 0.7.7 a few weeks ago, user logins all broke in SAMBA, resulting in users being unable to print and a general wailing and gnashing of teeth. I quickly tracked it down to a PAM authorisation problem but it took quite a while longer to find that pam_ldap was no longer a primary component in common-account, and hence it had become necessary to have shadow: ... ldap in nsswitch.conf, which was not previously the case (nor the configuration on my other working systems with earlier libpam-ldapd versions). I found the changelog and discussion in #583492, and I agree that this is probably a reasonable change and correct configuration now. However, if you're requiring the system to be configured differently like this from 0.7.7 onwards, rather than just breaking all of the systems which don't have ldap in shadow currently, it would be good if you could introduce a check for this and provide a note to the admin via debconf. Regards, Rob -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: armel (armv5tel) Kernel: Linux 2.6.32-3-kirkwood Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpam-ldapd depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libpam-runtime1.1.1-3Runtime support for the PAM librar ii libpam0g 1.1.1-3Pluggable Authentication Modules l ii nslcd 0.7.7 Daemon for NSS and PAM lookups usi Versions of packages libpam-ldapd recommends: ii libnss-ldapd [libnss-ldap]0.7.7 NSS module for using LDAP as a nam libpam-ldapd 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#530000: upgrading dbus and hal at the same time can break hal's init script
Package: dbus-daemon Version: 1.2.14-2 Severity: grave Justification: renders package unusable I just upgraded dbus from 1.2.12-1 to 1.2.14-2, and in the same dpkg/aptitude run, hal was upgraded from 0.5.11-8 to 0.5.12~git20090406.46dc48-2. The run didn't complete because the hal postinst script failed - after some investigation I found that it was failing to start hal, because hal was already running. Manually stopping hal allowed my remaining packages to be configured. Unfortunately I don't have logs from the console, but I believe what happened is that hal was deconfigured and stopped, and during this time, dbus-daemon was configured, which restarted the system bus and therefore also restarted hal. To avoid this, the dbus-daemon init script should only restart services which were running when it is run, or this should be moved to a trigger. Regards, Rob -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dbus depends on: ii adduser 3.110 add and remove users and groups ii libc6 2.9-12 GNU C Library: Shared libraries ii libdbus-1-3 1.2.14-2 simple interprocess messaging syst ii libexpat1 2.0.1-4XML parsing C library - runtime li ii libselinux1 2.0.71-1 SELinux shared libraries ii lsb-base 3.2-22 Linux Standard Base 3.2 init scrip dbus recommends no packages. Versions of packages dbus suggests: ii dbus-x11 1.2.14-2 simple interprocess messaging syst -- 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#529996: hald-addon-acpi wakes up every 5s if acpid isn't installed
Package: hal Version: 0.5.12~git20090406.46dc48-2 Severity: normal When debugging a separate issue I turned on --verbose=yes --use-syslog in /etc/default/hal and found that I had this error logged every 5 seconds: May 22 19:03:00 tau hald-addon-acpi: [3815]: 19:03:00.569 [E] addon-acpi.c:83: Cannot connect to acpid socket: No such file or directory May 22 19:03:05 tau hald-addon-acpi: [3815]: 19:03:05.569 [E] addon-acpi.c:83: Cannot connect to acpid socket: No such file or directory This system doesn't have acpid installed any longer, so it probably shouldn't do this. Regards, Rob -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hal depends on: ii acl 2.2.47-2Access control list utilities ii adduser 3.110 add and remove users and groups ii consolekit 0.3.0-2 framework for defining and trackin ii dbus 1.2.14-2simple interprocess messaging syst ii hal-info 20090309-1 Hardware Abstraction Layer - fdi f ii libc62.9-12 GNU C Library: Shared libraries ii libdbus-1-3 1.2.14-2simple interprocess messaging syst ii libdbus-glib 0.80-4 simple interprocess messaging syst ii libexpat12.0.1-4 XML parsing C library - runtime li ii libgcc1 1:4.4.0-5 GCC support library ii libglib2.0-0 2.20.1-2The GLib library of C routines ii libhal-stora 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer - share ii libhal1 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer - share ii libpolkit2 0.9-3 library for accessing PolicyKit ii libsmbios2 2.0.3.dfsg-1Provide access to (SM)BIOS informa ii libstdc++6 4.4.0-5 The GNU Standard C++ Library v3 ii libusb-0.1-4 2:0.1.12-13 userspace USB programming library ii libvolume-id 0.141-1 libvolume_id shared library ii lsb-base 3.2-22 Linux Standard Base 3.2 init scrip ii mount2.13.1.1-1 Tools for mounting and manipulatin ii pciutils 1:3.1.2-4 Linux PCI Utilities ii pm-utils 1.2.5-2 utilities and scripts for power ma ii policykit0.9-3 framework for managing administrat ii udev 0.141-1 /dev/ and hotplug management daemo ii usbutils 0.82-1 Linux USB utilities Versions of packages hal recommends: ii eject 2.1.5+deb1+cvs20081104-6 ejects CDs and operates CD-Changer ii libsmbios-bin 2.0.3.dfsg-1 Provide access to (SM)BIOS informa Versions of packages hal suggests: ii gnome-device-manager 0.2-3 GNOME device manager based on HAL -- 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#518631: [PATCH] example configuration for expire seems broken
Package: dovecot-imapd
Version: 1:1.1.11-3
Severity: wishlist
Tags: patch
(I tried to submit this upstream via GMane, but it's queued for
moderation. In the meantime...)
The expire configuration in the example config file in 1.1.11 is broken:
r...@omega:/etc/dovecot# /etc/init.d/dovecot restart
Restarting IMAP/POP3 mail server: dovecot
Unknown dict module: db
expire plugin: dict_init() failed
Error: imap dump-capability process returned 89
Fatal: Invalid configuration in /etc/dovecot/dovecot.conf
failed!
It's inconsistent with the documentation at
http://wiki.dovecot.org/Plugins/Expire, so I've made the attached patch
to try and fix it.
Note: I don't know if this new configuration is correct either, because
its a new box and I've not got any mails old enough to cause the plugin
to try and write anything, but at least I can start dovecot like this. :)
Regards,
Rob
--- dovecot-1.1.11/dovecot-example.conf~ 2009-03-06 17:28:46.785662296 +
+++ dovecot-1.1.11/dovecot-example.conf 2009-03-06 17:29:23.082571853 +
@@ -1057,7 +1057,8 @@
# referenced using URIs in format "proxy::".
dict {
- #quota = mysql:/etc/dovecot-dict-quota.conf
+ #expire = db:/var/lib/dovecot/expire.db
+ #quota = mysql:/etc/dovecot-dict-quota.conf
}
# Path to Berkeley DB's configuration file. See doc/dovecot-db-example.conf
@@ -1136,7 +1137,7 @@
# you must set up:
# dovecot --exec-mail ext /usr/libexec/dovecot/expire-tool
#expire = Trash 7 Spam 30
- #expire_dict = db:/var/lib/dovecot/expire.db
+ #expire_dict = proxy::expire
# Lazy expunge plugin. Currently works only with maildirs. When a user
# expunges mails, the mails are moved to a mailbox in another namespace
Bug#518630: [PATCH] enable libdb dict support for the expire plugin
Package: dovecot-imapd Version: 1:1.1.11-3 Severity: wishlist Tags: patch Hi there, I've applied the following patch locally to my dovecot package so that I can use a db: dict with the expire plugin as suggested in the example configuration. Regards, Rob diff -u dovecot-1.1.11/debian/changelog dovecot-1.1.11/debian/changelog --- dovecot-1.1.11/debian/changelog +++ dovecot-1.1.11/debian/changelog @@ -1,3 +1,9 @@ +dovecot (1:1.1.11-3.1) unstable; urgency=low + + * Enable libdb dict for use with the expire plugin. + + -- Robert McQueen Fri, 06 Mar 2009 16:57:36 + + dovecot (1:1.1.11-3) unstable; urgency=low * debian/dovecot-common.init: applied patch from HÃ¥kon Stordahl to call diff -u dovecot-1.1.11/debian/rules dovecot-1.1.11/debian/rules --- dovecot-1.1.11/debian/rules +++ dovecot-1.1.11/debian/rules @@ -28,6 +28,7 @@ # Add here commands to configure the package. ./configure --with-ldap \ --with-ssl=openssl \ + --with-db \ --with-pgsql \ --with-mysql \ --with-sqlite \ diff -u dovecot-1.1.11/debian/control dovecot-1.1.11/debian/control --- dovecot-1.1.11/debian/control +++ dovecot-1.1.11/debian/control @@ -3,7 +3,7 @@ Priority: optional Maintainer: Dovecot Maintainers Uploaders: Jaldhar H. Vyas , Fabio Tranchitella , Joel Johnson -Build-Depends: debhelper (>= 5.0.0), automake1.9, autoconf, libtool, pkg-config, libssl-dev, libpam0g-dev, libldap2-dev, libpq-dev, libmysqlclient15-dev, libsqlite3-dev, libsasl2-dev | libsasl-dev, zlib1g-dev, libkrb5-dev, dpatch, byacc, flex, drac-dev (>= 1.12-5), libbz2-dev +Build-Depends: debhelper (>= 5.0.0), automake1.9, autoconf, libtool, pkg-config, libssl-dev, libpam0g-dev, libldap2-dev, libpq-dev, libmysqlclient15-dev, libsqlite3-dev, libsasl2-dev | libsasl-dev, zlib1g-dev, libkrb5-dev, dpatch, byacc, flex, drac-dev (>= 1.12-5), libbz2-dev, libdb-dev Build-Conflicts: linux-kernel-headers (<= 2.5.999-test7-bk-17), automake1.4 Standards-Version: 3.8.0.1 Vcs-Svn: svn://svn.debian.org/svn/collab-maint/deb-maint/dovecot/trunk
Bug#438455: warning is misleading
I do get interception messages logged in /var/log/clamav/clamav.log, and I only have clamav-milter running and installed. So, yes, the warning about no interception logging is misleading. HTH, Rob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518628: clamav-milter: log rotation is broken/missing
Package: clamav-milter
Version: 0.94.dfsg.2-1~volatile1
Severity: normal
I've only got the clamav-milter package installed, and not
clamav-daemon, and I noticed today when configuring munin that my
/var/log/clamav/clamav.log file is written to by clamav-milter, but is
not being logrotated. I made a file like this:
r...@sigma:~# cat /etc/logrotate.d/clamav-milter
/var/log/clamav/clamav.log {
rotate 12
weekly
compress
delaycompress
create 640 clamav adm
postrotate
pkill -USR1 -o clamav-milter
endscript
}
This seemed to work on my system, but I guess this really means
logrotate file should be in the clamav-base package with the missingok
keyword in case neither the daemon nor the milter are installed.
Regards,
Rob
-- Package-specific info:
--- configuration ---
#Automatically Generated by clamav-base postinst
#To reconfigure clamd run #dpkg-reconfigure clamav-base
#Please read /usr/share/doc/clamav-base/README.Debian.gz for details
LocalSocket /var/run/clamav/clamd.ctl
FixStaleSocket true
TemporaryDirectory /tmp
User clamav
AllowSupplementaryGroups true
ScanMail true
ScanArchive true
ArchiveLimitMemoryUsage false
ArchiveBlockEncrypted false
MaxDirectoryRecursion 15
FollowDirectorySymlinks false
FollowFileSymlinks false
ReadTimeout 180
MaxThreads 12
MaxConnectionQueueLength 15
StreamMaxLength 10M
LogSyslog false
LogFacility LOG_LOCAL6
LogClean false
LogVerbose false
PidFile /var/run/clamav/clamd.pid
DatabaseDirectory /var/lib/clamav
SelfCheck 3600
Foreground false
Debug false
ScanPE true
ScanOLE2 true
ScanHTML true
DetectBrokenExecutables false
MailFollowURLs false
ExitOnOOM false
LeaveTemporaryFiles false
AlgorithmicDetection true
ScanELF true
IdleTimeout 30
PhishingSignatures true
PhishingScanURLs true
PhishingAlwaysBlockSSLMismatch false
PhishingAlwaysBlockCloak false
DetectPUA false
ScanPartialMessages false
HeuristicScanPrecedence false
StructuredDataDetection false
LogFile /var/log/clamav/clamav.log
LogTime true
LogFileUnlock false
LogFileMaxSize 0
# Automatically created by the clamav-freshclam postinst
# Comments will get lost when you reconfigure the clamav-freshclam package
DatabaseOwner clamav
UpdateLogFile /var/log/clamav/freshclam.log
LogVerbose false
LogSyslog false
LogFacility LOG_LOCAL6
LogFileMaxSize 0
LogTime false
Foreground false
Debug false
MaxAttempts 5
DatabaseDirectory /var/lib/clamav/
DNSDatabaseInfo current.cvd.clamav.net
AllowSupplementaryGroups false
PidFile /var/run/clamav/freshclam.pid
ConnectTimeout 30
ReceiveTimeout 30
ScriptedUpdates yes
CompressLocalDatabase no
# Check for new database 12 times a day
Checks 12
DatabaseMirror db.local.clamav.net
DatabaseMirror database.clamav.net
DatabaseMirror db.uk.clamav.net
--- data dir ---
total 44328
-rw-r--r-- 1 clamav clamav 990208 2009-03-06 20:40 daily.cld
drwxr-xr-x 2 clamav clamav 4096 2008-06-04 23:17 daily.inc
-rw-r--r-- 1 clamav clamav 44391424 2009-02-16 00:11 main.cld
drwxr-xr-x 2 clamav clamav 124 2008-06-04 23:17 main.inc
-rw--- 1 clamav clamav 572 2009-03-07 14:40 mirrors.dat
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages clamav-milter depends on:
ii clamav-base 0.94.dfsg.2-1~volatile1 anti-virus utility for Unix - base
ii clamav-freshclam 0.94.dfsg.2-1~volatile1 anti-virus utility for Unix - viru
ii libbz2-1.0 1.0.3-6 high-quality block-sorting file co
ii libc62.7-18 GNU C Library: Shared libraries
ii libclamav5 0.94.dfsg.2-1~volatile1 anti-virus utility for Unix - libr
ii libgmp3c22:4.2.1+dfsg-4 Multiprecision arithmetic library
ii libmilter0 8.13.8-3Sendmail Mail Filter API (Milter)
ii libwrap0 7.6.dbs-13 Wietse Venema's TCP wrappers libra
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
ii zlib1g 1:1.2.3-13 compression library - runtime
Versions of packages clamav-milter recommends:
pn clamav-daemon (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#517449: seems to be a common issue...
I've just run across this bug when investigating a recurrence of #499745 on another box. It seems that this bug could be the root cause of mine and many other similar bugs filed against Lenny's kernel. Seems worth pushing as a stable update at any rate. Looking at the last comments on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/276476 it seems there are three patches to fix this issue, rather than just the two linked to by the OP. The upstream commits are: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.28.y.git;a=commit;h=e17036dac189dd034c092a91df56aa740db7146d http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.28.y.git;a=commit;h=6bc912b71b6f33b041cfde93ca3f019cbaa852bc http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.28.y.git;a=commit;h=cce7ade803699463ecc62a065ca522004f7ccb3d If I have time I'll try and build a lenny kernel with these patches and see how it works, but if someone else beats me to it I'd be happy to try. HTH, Rob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#239111: Grub is shockingly bad code
Robert Millan wrote: > It would seem that running sync would suffice for that. Unfortunately, it > seems that: > > - sync is not enough > (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111#53) Correct. This is a property of XFS. As I said, it considers that putting metadata into the journal, and knowing it's flushed there, to meet the API guarantee of sync(). sync() doesn't make any guarantee that the files can be found by an an incomplete implementation of the filesystem (such as GRUB's, which ignores the journal). > - xfs_freeze could hang even if you don't write anything > (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111#194) I believe this report is unreliable, perhaps it froze because it's made an echo in a process whose stdout is being logged? > This is odd. I think I'm going to assume sync does what is expected from > it. If it doesn't maybe it's a bug in Linux, which maybe got fixed already, > or maybe it's a (lesser) bug in GRUB which we can't find untill it's > exposed. It's not a bug, it's the behaviour of XFS which I've explained a few times already. The bug in GRUB is trying to read the filesystem at a block level, behind the kernel's back. > In any case, we're better off not using xfs_freeze untill we know for sure > why it is needed, and are certain it won't cause hangs. I know why it's needed, and have done for around 4 years, and have had this confirmed from the XFS developers too. > I'm waiting for Ron's confirmation that this works for him, and then I'll > remove the patch & upload. I'm pretty sure it won't work reliably without some xfs_freeze, so I still prefer including the patch. I will try to find some time to test it as well as Ben's simple freeze; unfreeze patch which I prefer, as I believe it will make things work in lenny's kernel (although not etch, where freeze is sadly broken, which is why the patch in #179 has such horrible looping sleep/freeze hacks anyway). Cheers, Rob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#239111: Grub is shockingly bad code
Robert Millan wrote: > Grmf. I was making wrong assumptions. This is not about block lists > (I still think block lists suck, but let's be fair...): ... > So we freeze the filesystem and afterwards try to write to it. Not a > good idea... Indeed not. > #239111 initial report claims GRUB hangs before we added > xfs_freeze.diff, but according to what Rob says, not freezing makes it > work for him. I didn't test that, I was basing on my experiences of installing GRUB manually. I usually do: mkdir /boot/grub cp -a /usr/lib/grub/i386-pc/* /boot/grub vi /boot/grub/device.map grub --device-map=/boot/grub/device.map # doesn't work because XFS hasn't put /boot/grub onto disk ... # swear a bit xfs_freeze -f / xfs_freeze -u / grub --device-map=/boot/grub/device.map # works update-grub # makes me a menu.lst file This never froze for me. > Rob, can you test removing the patch completely? I suppose, it would at least make it fail rather than fuck my system, but based on my understanding of the problem, won't make installations on XFS work reliably. > I'm almost certain it's the fwrite() call in install_func. I could be > wrong, but I still don't see why we would want to use xfs_freeze anyway. You use xfs_freeze to force XFS to flush the metadata for the newly created stage* files out of the journal and into the directory entries themselves. sync() puts the data on disk and the metadata in the journal, but xfs_freeze gives the extra guarantee of the journal being clean and empty so the filesystem can be shapshotted and mounted as read-only (with no journal replay). > And if we _really_ need xfs_freeze, it means we're doing something wrong. I thought the wrongness was well known: the GRUB shell tries to read the block device directly and traverse the filesystem directories itself to to find which blocks on the disk are where the stage* files are located. XFS considers putting the metadata into the journal an acceptable implementation of sync(), but grub's filesystem reading code ignores the journal, so can't find the files. If the shell used FIBMAP ioctl to find the blocks when running under the OS, it'd always find them and all would be sweetness and light. Thats what Steve was trying to do, I think, before he gave up and sent the OP on this thread. Regards, Rob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#239111: Grub is shockingly bad code
Robert Millan wrote: > Rob, > > Did you hit this problem when installing GRUB to a partition, or to the > whole disk? I was upgrading from etch to lenny on a box where / is XFS and /boot and /var are on the same partition. GRUB is installed into the MBR. I know you can't install bootloaders onto XFS partitions. (If that had happened, based on previous experience the FS would've panicked and all IO returned with an error, so I'd probably have been able to log in and get a lot of errors, assuming bash was still in the cache. :D) So no, it's nothing to do with where I'm trying to install GRUB to, the problem is the Debian patch to grub-install did xfs_freeze on my root filesystem and then did various crap including trying to write to the log file (and make a /boot/grub/default file, I think?), all of which go into D state while the filesystem is frozen so don't finish, and meanwhile everything else on my system ground to a halt too. Obviously hard for me to debug given I lost all my access to the system, but asking SysRq for backtraces showed everything was blocked on FS access. (Actually as a result of my experience I think XFS devs are adding an unfreeze SysRq atm...) Just make the script not try do anything at all which might potentially cause a write to the filesystem while it's frozen, is the main thing... Backing out the bullshit XFS Debian patch would do that, applying Ben's might even make it work properly on lenny. Regards, Rob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#239111: Grub is shockingly bad code
Robert Millan wrote: > Hi Rob, Hi Robert, > You just convinced me that this is completely fucked up. This is not the > first time someone claims to have fixed this problem, only to discover that > it wasn't, and I'm not going to gamble with ioctls, freeze/unfreeze combos > or Linux version checks. We all know this is fucked up. :) I'm not claiming to fix anything so it somehow works flawlessly. I just want to avoid my system being locked up when I follow the instructions in NEWS.Debian. So the changes I'm proposing for lenny are just: a) change the Debian XFS hack to grub-install so that it does "copy stage files; freeze; unfreeze; install grub" rather than "copy stage files; freeze; lots of shit; unfreeze" which is guaranteed. I don't care if it *works*, but it will at least print me an error message which is fine because everyone who has Grub and XFS probably installed it manually once anyway. Anyway, Ben's simpler patch (just xfs_freeze followed by unfreeze) probably *does* work on lenny and at least fails gracefully on etch. I'll test it. b) clarify the documentation in NEWS.Debian which encourages people to run "grub-install" unequivocally, so that it tells people with an XFS /boot filesystem to either upgrade after rebooting, or upgrade later. If you can tell me which kernel versions that etch's Grub can boot, I can propose a patch. For what it's worth I've chatted to XFS developers on IRC (Eric Sandeen amongst others) and pointed them to this bug, and they agree with my suggested approach here. > I (and upstream in general) believe that the only right way to rely on a > hardcoded list of blocks that live inside a filesystem is _not to_. You're in 100% agreement with the XFS developers here. > I'll see if it's feasible to make it use embedding, and if not, XFS support > in GRUB Legacy will be terminated, and users will be advised to either > leave /boot/grub untouched or upgrade to GRUB 2. Maybe sensible, but I suggest the above two changes are made as well to avoid fucking people's systems if they /do/ run grub-install, because the current Debian XFS hack makes things much much worse than upstream. Regards, Rob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#239111: Grub is shockingly bad code
severity 239111 grave thanks Robert Millan wrote: > The whole approach is wrong, so maybe it makes sense to avoid it, or maybe > it's too late for that, and we should issue a critical debconf warning when > XFS is detected. > > I will have to think about it. The problem is that Debian's patch to try and make it work on XFS makes it /worse/. It turns "grub-install fails" into "grub-install fucks my system". There's no question we should just fix that ASAP by applying a patch which just does freeze immediately followed by unfreeze. That's why I raised the severity, and I still consider this RC for lenny because the upgrade instructions in NEWS.Debian encouraged me to do something which bricked my system. (Note that although I didn't try it yet, I'm almost certain that Ben's approach with a helper binary to run FIBMAP ioctl won't help any more than calling sync() will. sync is /not/ broken in XFS - if you call it then it does flush the data to disk - the "problem" is that it considers metadata synced to the journal as safely sync()'d, so calling it isn't sufficient to udate the dentry's for grub to read directly.) Given even xfs_freeze is broken in etch's kernel, we can't make grub-install work reliably there, but if we put freeze/unfreeze between copying the files and invoking grub then it will a) not hose people's systems under etch, and b) will work with lenny's kernel. There's also no need for a critical warning, because grub-install has to be done by the user manually anyway. We should just include the correct advice. If you'd answer my question about which kernel / grub versions are actually incompatible, then we can choose between the two behaviours. If etch's grub can boot lenny's kernel, we can tell XFS users to just update grub after rebooting, otherwise we can direct them at some manual install instruction and say "please freeze and unfreeze the filesystem, run sync a few times, and then have a cup of tea, between copying the stage* files and running the grub shell". Regards, Rob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#239111: following etch->lenny grub upgrade instructions locks up a system with XFS root
severity 239111 grave found 239111 0.97-47 thanks Sorry to drag this ancient bug up to RC status, but I just got *totally* screwed by it. I've just upgraded an etch system to lenny, and following the instructions in grub's NEWS.Debian file, I ran 'grub-install (hd0)' after verifying my device.map in order to update the bootloader, under the threat that my system would not be able to boot a >= 2.6.23 kernel. Unfortunately, because of this grub-install hanging while my XFS root filesystem is frozen, my entire (remote, headless) system is now unresponsive on all of the ssh logins I had open to it, as well as on its serial console, because any login activity ends up trying to write to disk. (I could sysrq or powercycle it, but I'm not actually certain whether the bootloader will be intact currently. Thankfully its the dom0 of a Xen system, and the mission-critical domUs are working still, so I can risk a reboot over the weekend.) Previously this bug has just been a minor annoyance because under d-i, you can work around this freeze by going to the shell (which is in memory in a different filesystem) and killing grub-install, unfreezing the filesystem, and doing it manually. However, this is the first time I've been enticed into using grub-install on a live system, and now I've realised quite what a screwup this actually is. It's moved from a mild annoyance for deviants like me who insist on choosing grub from the d-i menu when using an XFS root, to a way to lock-up and potentially even brick (I can tell you tomorrow evening) a running system. As I noted, er, four and a half years ago[1], and by many previous reporters, what the script currently does will *always* fail where /boot and / are the same filesystem: xfs_freeze -f grub --bullshit... # tries to write to the filesystem and log file too, # will never make any progress because / is frozen xfs_freeze -u On a live system, not only does this just hang the grub-install process, but it effectively stops you from being able to log in to fix the situation too. 1: http://lists.debian.org/debian-boot/2004/06/msg02301.html Previous reporters have provided patches[2] to change the behaviour to this: xfs_freeze -f xfs_freeze -u grub --bullshit... The failures of this approach (see below) are that grub might not succeed in upgrading/installing, or that it might install an older version of grub. It will, however, never freeze your system. 2: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=152;filename=xfs_freeze.diff;att=1;bug=239111 Earlier reporters on the bug in 2006 commented that the above doesn't work reliably. This is due to #306966, which is present in etch's kernel, and means xfs_freeze -f can return before the data is actually synced. I've spoken to the XFS developers about this on IRC, and apparently it was fixed upstream around 2.6.19 or 20. So actually, applying that patch to re-order things like that will make this freezing bug go away on lenny kernel system once and for all, and d-i won't need to force LILO on XFS users any more. :) However it /will/ re-introduce the race condition so that grub-install fails when you're running under etch's kernel, but that's /much/ less of a problem than locking up or bricking the system, because you can work around it by just installing grub manually. So, definitely for lenny we must apply a patch which fixes the script to do freeze / unfreeze / grub. The only remaining issue is then: how old a grub can really not read the 2.6.26 kernel that comes with lenny? If etch's grub /can/ read lenny's kernel, and it's only /older/ grubs that have problems, then this race bug will affect a pretty small number of people. We can just edit NEWS.Debian then to say "If grub-install fails and you have XFS /boot and etch's kernel, reboot and try it again". Any people with >3 year old Debian systems with XFS root and grub are probably able to figure out how to reinstall grub manually. If etch's grub /can't/ read lenny's kernel, then I guess we need to provide a smoother migration path for people who are doing as I did and running grub-install, so we can apply the patch with the sleep workaround[3] and include a message: "If you got a file not found error and use an XFS root filesystem, please try re-running grub-install with the --sync-sleep=60 option to work around a bug in the 2.6.18 kernel in etch." 3: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=179;filename=xfs_freeze.diff;att=1;bug=239111 Regards, Rob P.S. If we were being "enterprise", we'd probably push an etch kernel patch which fixed the race condition with xfs_freeze, so people could reliably upgrade their kernel and grub at the same time before rebooting into lenny. But, eh, screw it. P.P.S. The XFS developers would like to take this opportunity to remind viewers that reading/writing the block device underneath a filesystem is the true bug here, and that the grub shell should just be made to use FIBMAP to find the stage 1.5
Bug#452016: bug is caused by removal of TinyMCE from roundcube package
tags 452016 - unreproducible moreinfo thanks Hi guys, After running into this bug, I spent a while debugging in Firefox with the DOM editor and error console. Even after editing the DOM to make the Save button sensitive, it doesn't actually have any defined action. I realised from the error console that there was a JavaScript error accessing the tinyMCE object, so the functions which sets up the button callbacks and makes them sensitive never get called. And the reason I don't have a TinyMCE object is because I don't have tinymce installed, so the include(.../tiny_mce_src.js) fails. So, installing tinymce and uncommenting the appropriate apache configuration as explained in README.Debian fixed this issue for me. It looks like the package has a patch to make it optional in the Compose screen, but needs a similar patch to the Identities (Edit and New) screens, or some preference about whether or not to use MCE editing isn't getting applied properly. Hope this helps. Regards, Rob
Bug#327836: libdjvulibre15: packages are not co-installable but do not conflict
Package: libdjvulibre15 Version: 3.5.15-1 Followup-For: Bug #327836 This probably constitutes a serious bug - libdjvulibre15 has a specific conflict/replaces libdjvulibre1 (= 3.5.14-6), but I have 3.5.14-5 installed, so I experience this error. Either: 1. Make the conflicts/replaces more generic (why does it conflict/replace just this version, but no others?) 2. Implement library policy properly so that any version of libdjvulibre15 is co-installable with libdjvulibre1. The usual way of doing this is to separate the data files into an eg libdjvulibre-data package, which both versions of the library can be installed against. If the data changed incompatibly between library versions, you should move the data to a path which is different depending on the version being used. Regards, Rob -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-8-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321949: window-selector no longer bringing windows back to front for me
Ralph Aichinger wrote: > There is also a link to an upstream bug I found > in Gnome bugzilla, maybe the same thing. According to http://bugzilla.gnome.org/show_bug.cgi?id=312659 this breakage was due to a bug introduced in gtk 2.6.9 which has now been fixed in 2.6.10. This was uploaded to unstable yesterday, and the problem is now gone for me. > /ralph Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326260: pdns-backend-mysql: sed on non-existent pdns.local makes postrm fail
Package: pdns-backend-mysql
Version: 2.9.17-13sarge1
Severity: serious
The postrm says:
PDNSCONF=/etc/powerdns/pdns.conf
PDNSDIR=`cat $PDNSCONF | grep include | awk -F '=' '{print $2}'`
PDNSLOCAL=$PDNSDIR/pdns.local
...
case "$1" in
remove)
sed -i -e 's/^gmysql/# gmysql/' $PDNSLOCAL
...
My pdns.conf has no line saying include in it because when I upgraded
from the previous version, I didn't put the new config file in[*], so
PDNSLOCAL is set to "/pdns.local". So we get this:
Stopping PowerDNS authoritative nameserver: not running
sed: can't read /pdns.local: No such file or directory
dpkg: error processing pdns-backend-mysql (--remove):
subprocess post-removal script returned error exit status 2
Bad mojo...
Regards,
Rob
*: Now I've looked, I appreciate that the include pdns.d way is
better, but when I was upgrading to sarge and answered the question
I didn't know that my existing config was already reflected in
pdns.d/pdns.local. It might've been a good idea to ship a NEWS.Debian
explaining this but it's a bit late for sarge now... :)
-- System Information:
Debian Release: 3.1
Architecture: i386 (i586)
Kernel: Linux 2.4.24-xfs-exec-shield-sky1
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages pdns-backend-mysql depends on:
ii libc6 2.3.2.ds1-22GNU C Library: Shared libraries an
ii libgcc11:3.4.3-13 GCC support library
ii libmysqlclient12 4.0.24-10 mysql database client library
ii libstdc++5 1:3.3.5-13 The GNU Standard C++ Library v3
rc pdns-server2.9.17-13sarge1 extremely powerful and versatile
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323035: Processed: referring issue to technical committee
Raul Miller wrote: > It's not clear to me why this was assigned to the technical committee. > > There's definitely some issues here. For example, it sounds like libsilc > has some bugs that need to be fixed. > > But is there any problem that the technical committee needs to decide on? > > If so, could someone clearly and simply state what this problem is? The problem is that the maintainer refuses to concede that his packages are in violation of Debian's shared library packaging policy, or believes that this policy is incorrect or somehow irrelevant to his package. I was hoping that the technical committee might be able to discern which of these is the case, and then decide which elements need to be fixed and by whom, in order that the adoption of SILC-based software may continue in Debian. However, it now seems that he's willing for someone else to maintain the package (see his mail on #273871), so it might be in order to orphan the package and close this technical committee bug. > Thanks, Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#273871: referring issue to technical committee
clone 273871 -1 reassign -1 tech-ctte thanks (cloning bug to leave RC bug open on libsilc) The bug is reasonably self-explanatory - on top of the package itself being incorrectly named (not reflecting the SONAME), this library does not increment its version when symbols are added, or change the shlibs values to ensure the appropriate version is depended on. The maintainer has amply demonstrated that he doesn't understand the issue and has made it exceedingly clear that he doesn't care, and that it's apparently not a problem because nobody on -devel replied to his message. As indicated by Steve Langasek, this is not a theoretical problem - previous uploads of silc clients to unstable have broken because they do not have tight enough dependencies on the version of the library that they were built against. I do not wish to make Gaim depend on this library while it is so poorly maintained, because it will cause an excess burden of support next time it breaks. I personally am not interested in silc functionality otherwise I might've tried to fix it and NMU or hijack the package, but I do recieve occasional user requests for the silc functionality to be enabled in Gaim. This problem has caused there to be no silc clients whatsoever in the sarge release, because they are all blocked on this library which will not migrate to testing until this bug is closed, and the same problem looks set to happen for etch unless something happens. Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320734: mailscanner: tweak to logcheck rules
Package: mailscanner
Version: 4.41.3-2
Severity: minor
When using MailScanner with postfix, the following expression added to
/etc/logcheck/ignore.d.server prevents log messages from MailScanner in
normal operation being included in reports:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ MailScanner\[[0-9]+\]: Requeue:
[[:alnum:].]+ to [[:alnum:].]+$
Regards,
Rob
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.24-xfs-exec-shield-sigma1
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages mailscanner depends on:
ii debconf 1.4.30.13 Debian configuration management sy
ii libarchive-zip-perl 1.14-1 Module for manipulation of ZIP arc
ii libcompress-zlib-perl 1.34-1 Perl module for creation and manip
ii libconvert-binhex-perl1.119-2Perl5 module for extracting data f
ii libconvert-tnef-perl 0.17-4 Perl module to read TNEF files
ii libhtml-parser-perl 3.45-2 A collection of modules that parse
ii libmime-perl 5.417-1Perl5 modules for MIME-compliant m
ii libnet-cidr-perl 0.10-1 Manipulate IPv4/IPv6 netblocks in
ii perl 5.8.4-8Larry Wall's Practical Extraction
ii postfix [mail-transport-agent 2.1.5-9A high-performance mail transport
ii spamassassin 3.0.3-2Perl-based spam filter using text
ii ucf 1.17 Update Configuration File: preserv
ii unzip 5.52-1 De-archiver for .zip files
ii wget 1.9.1-12 retrieves files from the web
-- debconf information excluded
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294656: "malloc: Input/output error" is due to bad error handling of FAMOpen failures
Package: courier-imap
Version: 3.0.8-4
Followup-For: Bug #294656
I saw these malloc: Input/output error messages in my syslog... I was
pretty worried because... er... malloc's not meant to return EIO. I did
some stracing to find what was going on, and found like the original
reporter that it was to do with IDLE (I'm also using Thunderbird).
I've done some digging in the code, looking for things that might log
mallocs, and found this in imapenhancedidle() in imap/imapd.c:1387:
if ((w=maildirwatch_alloc(current_mailbox)) == NULL)
{
perror("malloc");
return (-1);
}
Which is incredibly misleading, it's not doing a malloc at all! At the
very least this should be changed to say what's actually been attempted.
In maildirwatch_alloc() in maildir/maildirwatch.c:64, if you have FAM
support compiled in, failure of the FAMOpen function causes EIO to be
returned:
if (FAMOpen(&maildirwatch_currentfam->fc) < 0)
{
errno=EIO;
free(maildirwatch_currentfam);
maildirwatch_currentfam=NULL;
}
Which is also incredibly misleading. It should at the very least log a
message about failing to connect to FAM, or perhaps just silently fall
back to normal maildir watching if so configured.
I note that I had to strace /all/ the imapds on a busy server to work
out which imapd was actually causing the error. Logging the PID might
be handy, but I'm not quite sure where that would be feasible.
These problems all seem to exist in CVS courier, as well as the version
in sarge.
Regards,
Rob
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.29-rc1-exec-shield-light1
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages courier-imap depends on:
ii courier-authdaemon 0.47-4 Courier Mail Server - Authenticati
ii courier-base0.47-4 Courier Mail Server - Base system
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libfam0c102 2.7.0-6 client library to control the FAM
ii libgdbm31.8.3-2 GNU dbm database routines (runtime
ii postfix [mail-transport-age 2.1.5-9 A high-performance mail transport
-- debconf information excluded
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317743: gaim: Got the same problem... Very annonying!!!
Nicolas wrote: > I can't reinstall gaim since an upgrade some weeks ago. That's REALLY > annonying, and I don't understand why developpers don't solve this > problem really quickly, since it's critical... > > Les paquets suivants contiennent des dépendances non satisfaites : > gaim: Dépend: libaspell15c2 (>= 0.60) mais ne sera pas installé > E: Paquets défectueux This is not a critical bug. Sorry, but Debian's undergoing a change in C++ library ABI. Every package that contains or depends on a C++ library needs to be manually edited and then rebuilt. Gaim is linked to aspell, which is a C++ library, because of the built-in GtkSpell spell checking. Bsically until all of the packages you've got installed that use C++ have been updated, you won't be able to upgrade any of them, or install any already-updated ones (such as gaim), unless you play around and see what you can remove to allow the updated packages to be installed. You'll just have to be patient. See here for more details: http://lists.debian.org/debian-devel-announce/2005/07/msg1.html > Bye. > Nicolas, Paris. Regards, Rob
Bug#311386: Question about Gaim unstable
submitter 311386 [EMAIL PROTECTED] thanks stripes wrote: > That's because I didn't get the email. You filed the bug with a different e-mail address which evidently failed to work. I've changed it. Please include the bug's address in CC when replying. >>Please run these commands on your system, and >>show me the output, as I requested: >...< The package is obviously installed correctly. >>Finally, try running gaim with "gaim -n -d" which will just show the >>login window, providing lots of debugging output, and paste that in an >>e-mail too. > > It's attached as a separate file. "GdkPixbuf: Cannot open pixbuf loader module file '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory" This indicates that /usr/sbin/update-gtk-immodules hasn't been called, so the file listing the GTK pixbuf loader modules isn't available to any GTK applications. It should be called by the libgtk2.0-bin (which libgtk2.0-0 depends on) post-install script. Please check this package is installed correctly with dpkg -l libgtk2.0-bin. >>Are you using any GTK themes? > > Nope. Thanks for your help. > > -Anne Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311386: Question about Gaim unstable
stripes wrote: > Hi there, > > When you have a moment, can you please ping me? All my graphics for > Gaim have disappeared :( > > An install and reinstall didn't fix the problem. > > -Anne You've already filed this as a bug - I asked you for more information and you havn't replied. Please run these commands on your system, and show me the output, as I requested: gaim -v which gaim df -h dpkg -L gaim-data ls -laR /usr/share/pixmaps/gaim Finally, try running gaim with "gaim -n -d" which will just show the login window, providing lots of debugging output, and paste that in an e-mail too. Are you using any GTK themes? Thanks, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311540: mono-common: causes zombie directory to exist
Package: mono-common Version: 1.1.6-4 Severity: normal The mono-common.postinst migrates stuff from /usr/share/dotnet/mono to /usr/lib/mono, and replaces it with a symlink, but doesn't actually contain the /usr/share/dotnet directory. When upgrading the last package that owns files in /usr/share/dotnet, dpkg complains that the directory can't be removed. For the lifetime of this compatibility measure (not long because /usr/share/dotnet will never appear in a stable release?) the package should at least contain the directory, if not also the symlink so that dpkg will remove it when the package is removed. Regards, Rob -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10-alpha2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages mono-common depends on: ii binfmt-support1.2.3 Support for extra binary formats -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311386: gaim: Smilies and all graphics GONE with upgrade to 1.3.0-1
Anne Henmi wrote: > When I upgraded to gaim 1.3.0-1, all of my graphics disappeared. No > smilies are accessible, no buddy graphics, etc. This makes it a REAL > PAIN to use. :( Can I get the output of: gaim -v which gaim df -h dpkg -L gaim-data ls -laR /usr/share/pixmaps/gaim Thanks, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281381: gaim: Alright
Rolf Leggewie wrote: > I doubt that. But I readily admit I always fail to understand why so > often technical competence is coupled with utter social ineptitude. > Sorry to disturb. I was trying to help, but I guess some ppl really > have no clue apart from programming at all, if that. How sad. Guys, I'm not impressed by this. Luke, yes he made an error, but it wasn't explained to him before everyone assumed he was a moron. A little more thinking before hitting reply perhaps... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309119: rhythmbox: fails to check return value when writing playlists to disk
Package: rhythmbox Version: 0.8.8-11 Severity: grave Justification: causes non-serious data loss I just ran out of disk space in ~, and rhythmbox just destroyed my playlist file. In the function rb_playlist_manager_save_thread_main in shell/rb-playlist-manager.c, it calls xmlSaveFormatFile to write the playlist to a temporary file, but does not check the return value of this function before renaming the temporary file to playlists.xml, clobbering the original and losing my playlists in the process. As detailed in http://xmlsoft.org/html/libxml-tree.html#xmlSaveFormatFile, the function returns -1 if an error was encountered. Rhythmbox should only rename the temporary file to the original name if this was not the case. Regards, Rob -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-alpha2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages rhythmbox depends on: ii gconf2 2.8.1-5 GNOME configuration database syste ii gstreamer0.8-alsa [g 0.8.8-3 ALSA plugin for GStreamer ii gstreamer0.8-esd [gs 0.8.8-3 Enlightened Sound Daemon plugin fo ii gstreamer0.8-flac0.8.8-3 FLAC plugin for GStreamer ii gstreamer0.8-gnomevf 0.8.8-3 Gnome VFS plugin for GStreamer ii gstreamer0.8-mad 0.8.8-3 MAD MPEG audio decoder plugin for ii gstreamer0.8-misc0.8.8-3 Collection of various GStreamer pl ii gstreamer0.8-oss [gs 0.8.8-3 OSS plugin for GStreamer ii gstreamer0.8-vorbis 0.8.8-3 Vorbis plugin for GStreamer ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libaudiofile00.2.6-6 Open-source version of SGI's audio ii libbonobo2-0 2.8.1-2 Bonobo CORBA interfaces library ii libbonoboui2-0 2.8.1-2 The Bonobo UI library ii libc62.3.5-1 GNU C Library: Shared libraries an ii libesd0 0.2.35-2.1 Enlightened Sound Daemon - Shared ii libgconf2-4 2.8.1-5 GNOME configuration database syste ii libgcrypt11 1.2.0-11LGPL Crypto library - runtime libr ii libglade2-0 1:2.4.2-2 library to load .glade files at ru ii libglib2.0-0 2.6.4-1 The GLib library of C routines ii libgnome-keyring00.4.2-1 GNOME keyring services library ii libgnome2-0 2.8.1-2 The GNOME 2 library - runtime file ii libgnomecanvas2-02.8.0-1 A powerful object-oriented display ii libgnomeui-0 2.8.1-3 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.8.4-3 The GNOME virtual file-system libr ii libgnutls11 1.0.16-13 GNU TLS library - runtime library ii libgpg-error01.0-1 library for common error values an ii libgstreamer-gconf0. 0.8.8-3 GConf support for GStreamer ii libgstreamer0.8-00.8.9-2 Core GStreamer libraries, plugins, ii libgtk2.0-0 2.6.4-1 The GTK+ graphical user interface ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange library ii libjpeg626b-10 The Independent JPEG Group's JPEG ii liborbit21:2.12.2-1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-01.8.1-1 Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System Session Management ii libtasn1-2 0.2.10-4Manage ASN.1 structures (runtime) ii libx11-6 6.8.2-10X Window System protocol client li ii libxml2 2.6.16-7GNOME XML library ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308596: Mistyped /something commands are lost
I think the default of not sending unrecognised slash commands is quite frustrating - although I wasn't aware it was an option you could disable. Ideally it'd have a heuristic to decide something looks like a filename (multiple slashes), and send them through - there are few other situations where a non-command line starts with a /. Generally though, whether or not processed as commands or sent, all slash commands should be included in history anyway - consider an IRC client. Regards, Rob Luke Schierer wrote: > On Wed, May 11, 2005 at 11:48:18AM +0200, Enrico Zini wrote: > >>I occasionally stumble in this annoyance with /something commands: >>suppose I want to send someone a pathname in a message like this: >> >> "/var/log/syslog: this is the file you have to look at" >> >>Then gaim will print: >> >> "Command not existent" (or whatever the English version is) > > > in preferences, tell gaim to send unknown slash commands. > > >>That's fine. However, I now have to retype all the message, as my >>original mistyping is not preserved in the history. This can be >>extremely annoying if what was lost is a long message with a lot of >>thinking on it. > > > that's odd, it is preserved in the history here, if I press > control-up, it is right there. (I turned off sending unknown slash > commands to test). > > >>It would be better if gaim said: >> >> "Command not existent: '/var/log/syslog: this is the file you have to look >> at'" >> >>That way I can just copy from the history and paste it in the message >>instead of retyping it all from scratch. > > > no, I think that'd be overly verbose. I think the right answer is > just to make sure it is indeed in the history, as it is for me. are > you sure it is not for you? > > luke > > >> >>Ciao, >> >>Enrico >> > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304124: unison 2.9.1-2.sarge.1 NMU
I have prepared an NMU for unison 2.9.1-2 in sarge to fix the FTBFS bug
#304124, as well as removing the unlicensed unison-manual.html and
unison-manual.ps files which were obtained from the upstream website. It
is based on 2.9.1-2.1, which fixed the FTBFS in sid shortly before
2.10.2 was uploaded, preventing it from ever reaching sarge.
I also amended the clean target to remove win32 binary resource files
unison.res and unison.res.lib, but AFAICT it's not necessary to repack
the tarball to remove these, because the source (unison.rc) is provided
and it's trivial to regenerate the binaries from this with windres.
Interdiff between 2.9.1-2 and 2.9.1-2.sarge.1 is attached, although I've
filtered out the removal of the large unison-manual documents for
readability.
Changelog:
unison (2.9.1-2.sarge.1) testing-proposed-updates; urgency=high
* Non-maintainer upload by sponsor. Upload the previous 2.9.1-2.1 NMU
to testing-proposed-updates to fix the FTBFS in sarge, because the
2.10.2 upload prevented it from reaching testing. (closes: #304124)
* debian/rules:
- remove binary objects (win32rc/unison.res{,.lib}) in the tarball
in the clean target to guarantee that the binary build is
reproducible
* debian/unison-manual.{html,ps}:
- remove because they were obtained from the upstream website, and
they apparently have no license or source
* debian/unison.doc{s,-base}:
- remove mention of the HTML and PostScript manuals
Diffstat:
changelog | 31 +++
control |2 +-
rules |1 +
unison.doc-base |9 +
unison.docs |2 --
5 files changed, 34 insertions(+), 11 deletions(-)
I will upload in a few hours if nobody protests.
Regards,
Rob
diff -u unison-2.9.1/debian/unison.docs unison-2.9.1/debian/unison.docs
--- unison-2.9.1/debian/unison.docs
+++ unison-2.9.1/debian/unison.docs
@@ -4,2 +3,0 @@
-debian/unison-manual.html
-debian/unison-manual.ps
diff -u unison-2.9.1/debian/control unison-2.9.1/debian/control
--- unison-2.9.1/debian/control
+++ unison-2.9.1/debian/control
@@ -2,7 +2,7 @@
Section: net
Priority: optional
Maintainer: Sylvain Le Gall <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 4.0.0), ocaml-nox-3.08, liblablgtk-ocaml-dev,
dpatch, chrpath
+Build-Depends: debhelper (>= 4.0.0), ocaml-nox-3.08.3, liblablgtk-ocaml-dev,
dpatch, chrpath
Standards-Version: 3.6.1.0
Package: unison
reverted:
diff -u unison-2.9.1/debian/changelog unison-2.9.1/debian/changelog
--- unison-2.9.1/debian/changelog
+++ unison-2.9.1/debian/changelog
@@ -1,3 +1,34 @@
+unison (2.9.1-2.sarge.1) testing-proposed-updates; urgency=high
+
+ * Non-maintainer upload by sponsor. Upload the previous 2.9.1-2.1 NMU
+ to testing-proposed-updates to fix the FTBFS in sarge, because the 2.10.2
+ upload prevented it from reaching testing. (closes: #304124)
+
+ * debian/rules:
+ - remove binary objects (win32rc/unison.res{,.lib}) in the tarball
+in the clean target to guarantee that the binary build is
+reproducible
+
+ * debian/unison-manual.{html,ps}:
+ - remove because they were obtained from the upstream website, and they
+apparently have no license or source
+
+ * debian/unison.doc{s,-base}:
+ - remove mention of the HTML and PostScript manuals
+
+ -- Robert McQueen <[EMAIL PROTECTED]> Sun, 8 May 2005 10:20:30 +0100
+
+unison (2.9.1-2.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Updated build-dependency from ocaml-nox-3.08 to ocaml-nox-3.08.3
+as suggested by Aurelien Jarno. Closes: #304124 (which is release
+critical, hence the high urgency).
+ * Changed debian/unison.doc-base to refer to unison-manual.txt instead
+of unison-manual.text.
+
+ -- Lars Wirzenius <[EMAIL PROTECTED]> Sat, 30 Apr 2005 17:13:00 +0300
+
unison (2.9.1-2) unstable; urgency=medium
* Version to fix maintainer fields
diff -u unison-2.9.1/debian/unison.doc-base unison-2.9.1/debian/unison.doc-base
--- unison-2.9.1/debian/unison.doc-base
+++ unison-2.9.1/debian/unison.doc-base
@@ -12,9 +12,2 @@
-Format: postscript
-Files: /usr/share/doc/unison/unison-manual.ps.gz
-
Format: text
-Files: /usr/share/doc/unison/unison-manual.text.gz
-
-Format: HTML
-Index: /usr/share/doc/unison/unison-manual.html
-Files: /usr/share/doc/unison/unison-manual.html
+Files: /usr/share/doc/unison/unison-manual.txt.gz
reverted:
diff -u unison-2.9.1/debian/rules unison-2.9.1/debian/rules
--- unison-2.9.1/debian/rules
+++ unison-2.9.1/debian/rules
@@ -32,6 +32,7 @@
dh_testroot
rm -f build-stamp configure-stamp
rm -f unison-manual.txt unison-gtk
+ rm -f win32rc/unison.res win32rc/unison.res.lib
-$(MAKE) clean
dh_clean
Bug#305741: gaim: the spell checker doesent work
Luke Schierer wrote: > if you install aspell-en, it will, using english. We currently do not > offer locale-based or non-english spell checking, as > 1)gtkspell offers no good way to know what dictionaries are available > 2)no good way to control this per conversation > 3)a previous debian-specific patch reveiled that locale-based checking > does not reduce the number of bug reports, it just changes them. > (people don't necessarily want to send messages in the same language > the UI is in, just as they don't necessarily want to send in english) > > luke Luke, far be it from me to accuse you of jumping to conclusions, but the problem he reported is that spell checking doesn't work, not that it's in the wrong language. Despite your beliefs to the contrary, Debian still has the patch to register the dictionary as your locale has reduced the bug reports pertaining to spell checking language (of which there were a handful before the patch) to zero (after the patch). The issue here is probably along the lines of attempting to load a da_DK dictionary fails to find a da dictionary - if so the patch can be fixed accordingly. I am e-mailing him to ask for debug output and try LANG=da to confirm this for us. Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305741: gaim: the spell checker doesent work
Thomas Ter-Borch wrote: > Gaim dont underline misspelled words. I have aspell-da installed. I have > tried myspell-da, idanish and aspell-da. I use Gnome > > Thomas Ter-Borch Sorry for the confusing reply from Luke, an upstream Gaim developer. Ignoring his assumptions... I'm assuming you have spell checking is enabled in preferences. If so, can you get us the output of the debug window (Help->Debug Window) when you first open a conversation window, and also try running Gaim with LANG set to just da rather than da_DK and see if that fixes it? aspell-da should be all that's necessary. Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#273871: libsilc package policy violations (bug #273871)
Tamas SZERB wrote: > once upon a time, I closed this bug. then the submitter reopened it, > so currently I don't give it a f*ck. Our opinion are different, so if > you feel any ambition to get the both sides together, feel free to > volunteer. :) This package's violation of Debian policy on the packaging of shared library packages is a fact, not an opinion. You have given no sound reasons why this package is not correctly versioned, or given any indication that you understand the issues at hand, such as how it is expected to retain compatibility with existing packages when the API or ABI undergoes changes (indeed, as it has just done upstream). In your favour, you have correctly not closed this bug because it is not fixed. Unfortunately this release critical bug is preventing the propogation of any SILC-based software into testing, and hence Debian's iminent sarge release. This is not a good situation for our users, and I would like to be able to enable Gaim's SILC plugin. Hence I suggest one of the following courses of action: a) you correct the package issues yourself in the ways we have outlined in the bug; or b) you admit to not understanding the issues involved in packaging a shared library, and orphan or put this package up for adoption forthwith; or c) you do nothing (or close this bug without fixing it, whereupon I will reopen it) and I refer a this bug to the technical committee for them to ruminate upon over the course of several months, essentially guaranteeing that no SILC-based software will be released with sarge I'm sorry to issue an ultimatum like this, but you have clearly indicated you are not willing to fix the package - indeed, far worse, you have stated that you don't care that it's broken - and everyone I have sought advice from on this issue agrees that you are in the wrong here. Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302799: gaim: spelling plugin interprets apostrophe as word separator
reassign 302799 libgtkspell0 thanks Justin Pryzby wrote: > Package: gaim > Version: 1.2.0-2 > Severity: normal > > I typed "wasn't" in the middle of a sentence, and it got a red > squiggle under it. I checked to make sure that I had correctly > contracted the two words "was not". Then, I looked at the spelling > suggestions, and chose "wasn't", assuming that I had dyslexically > transposed two letters. Gaim replaced "wasn't" with "wasn't't" (which > was still underlined with a red squiggle). So it seems that it is > incorrectly interpretting an apostrophe as a word separator. Gaim does nothing but attatch GtkSpell to its text area - this is definitely their bug not us. :) Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298467: gaim.postinst doesn't work if directory doesn't already exist
Ari Pollak wrote: Okay, but why would /usr/share/doc/gaim not exist at all? That link is included in the gaim package. I'm assuming there is some legitimate situation that we have not forseen which causes /usr/share/doc/gaim to not exist, otherwise the reporter wouldn't have run into the bug and filed it. I'm not against making the postinst script more cautious provided it does its job - when upgrading from a package with /usr/share/doc/gaim as a directory, it should remove it and make the symlink, because dpkg will not do that for us. Given that I can't work out the situation a missing /usr/share/doc/gaim arises in, I don't think it's worth a seperate upload though, so pencil it in for our next upload? Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298010: monodoc-browser: fails to depend on any Gtk#/etc bindings necessary to function
Package: monodoc-browser Version: 1.0.4-1 Severity: serious Justification: Policy 7.2 This package claims to be a Gtk+ browser for documentation, but depends on none of the CIL bindings to Gtk+/etc that are necessary to make it work, and there is nothing else in the package which could be conceived of as useful by itself. Obviously this is horribly broken according to Policy 7.2: "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." As far as I can tell, these dependencies should include libgtk-cil, libglade-cil, and libgnome-cil. Viz: $ sudo apt-get install monodoc-browser ... Setting up monodoc-browser (1.0.4-1) ... generating monodoc search index... ** (browser.exe:9864): WARNING **: Could not find assembly gtk-sharp, references from /usr/share/dotnet/monodoc/browser.exe (assemblyref_index=2) Major/Minor: 1,0 Build: 0,0 Token: 35e10195dab3c99f System error: No such file or directory cannot open assembly browser.exe $ sudo apt-get install libgtk-cil ... $ monodoc ** (browser.exe:9917): WARNING **: Could not find assembly glade-sharp, references from /usr/share/dotnet/monodoc/browser.exe (assemblyref_index=3) ... cannot open assembly browser.exe $ sudo apt-get install libglade-cil ... $ monodoc ** (browser.exe:9946): WARNING **: Could not find assembly gtkhtml-sharp, references from /usr/share/dotnet/monodoc/browser.exe (assemblyref_index=6) ... cannot open assembly browser.exe $ sudo apt-get install libgnome-cil ... $ monodoc Finally! Except the search doesn't work, because even though the postinst failed to generate a search index due to the missing dependencies, the script didn't return an error, so I have the package installed with no index. Heinous missing dependencies aside, errors in this process should also be caught and flagged up appropriately by making the postinst script fail. Regards, Rob -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-alpha2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages monodoc-browser depends on: ii mono-jit 1.0.5-2fast CLI/.NET JIT compiler for Mon ii monodoc-base 1.0.4-1shared MonoDoc binaries ii monodoc-manual1.0.4-1compiled XML documentation from th -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292258: this file conflict now occurs
package libgtksourceview-cil priority 292258 serious thanks This package still contains the file /usr/share/gtksourceview-1.0/language-specs/nemerle.lang, which is now present in libgtksourceview-common, rendering the C# bindings uninstallable on an unstable system at the moment. This is a policy violation (7.5.1 "it is usually an error for a package to contain files which are on the system in another package"): Unpacking libgtksourceview-cil (from .../libgtksourceview-cil_0.5-2_all.deb) ...dpkg: error processing /var/cache/apt/archives/libgtksourceview-cil_0.5-2_all.deb (--unpack): trying to overwrite `/usr/share/gtksourceview-1.0/language-specs/nemerle.lang', which is also in package libgtksourceview-common Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297205: gaim X usage idle time missing
Sean Egan wrote: As Ari pointed out, this is a compile-time option. The only possibility is that he's not using the Gaim package, but a self-compiled Gaim. -s. He *is* using the Gaim package, I've compiled it incorrectly. :( Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297205: oops
tags 297205 -unreproducible thanks He's right, it's not compiled with XSS. Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296130: libdc0: versioned conflicts on dcgui-qt renders it uninstallable
Package: libdc0 Version: 0.3.2-1 Severity: serious Justification: Policy 7.3 "A Conflicts entry should almost never have an "earlier than" version clause. This would prevent dpkg from upgrading or installing the package which declared such a conflict until the upgrade or removal of the conflicted-with package had been completed." Package: libdc0 Version: 0.3.7-1 Conflicts: dcgui-qt (<< 0.3.3) Package: dcgui-qt Version: 0.3.2-2 Depends: ... libdc0 (>= 0.3.1) ... It is now impossible to install dcgui-qt because it depends on libdc0, which in turn conflicts with it. Policy states that versioned conflicts with less than clauses are horribly broken - dpkg will not be able to upgrade libdc0 and dcgui-qt in the same run, because dcgui-qt will need to be FULLY UNINSTALLED (as is the definition of Conflicts) before libdc0 can be upgraded, so you will need to invoke dpkg once to remove dcgui-qt, and then again to install libdc0 and upgrade dcgui-qt. If the reason for adding this conflict is that libdc0 has broken binary compatibility, then the shlibs file of libdc-dev should make the resultant libdc0 dependency more version-specific. This is not the correct way to deal with breaking ABIs. Regards, Rob -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-alpha2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages libdc0 depends on: ii libbz2-1.0 1.0.2-5 high-quality block-sorting file co ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-9GCC support library ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii libstdc++5 1:3.3.5-8The GNU Standard C++ Library v3 ii libxml2 2.6.16-2 GNOME XML library ii zlib1g 1:1.2.2-4compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291836: libgphoto2-2: print-usb-usermap should be run every upgrade, not just at initial install
Package: libgphoto2-2 Version: 2.1.5-2 Severity: normal When trying my Canon IXUS 500 camera on my laptop, I was confused because hotplug/hal/udev/gnome-volume-manager/gthumb and friends didn't do the appropriate magic that should happen when you plug in a supported camera, although I was able to access it with the command line or gtkam. After a while of poking around, I realised this was because the /etc/hotplug/usb/libgphoto2-2.usermap had been generated when I first installed libgphoto2-2, and that support for my camera had been added later. Re-running print-usb-usermap added tens of new cameras to the list, and the utopia magic started working correctly. To take account of all new supported cameras, print-usb-usermap should always be run when libgphoto is upgraded, not just the first time it's installed. This could be done by simply removing the conditional execution (if [ ! -e /etc/hotplug/usb/$PACKAGE.usermap ]) in the postinst script. Regards, Rob -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-alpha2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages libgphoto2-2 depends on: ii adduser 3.59 Add and remove users and groups ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libexif10 0.6.9-4 The EXIF library allows you to par ii libgphoto2-port02.1.5-2 The gphoto2 digital camera port li ii libjpeg62 6b-9 The Independent JPEG Group's JPEG -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#216654: gaim has lots of stupid assertions
Jan Hudec wrote: Instead of removing, the g_return_if_fail(condition) should be replaced with: if(condition) return; It's equivalent in behavior, but does not spit the warning. I don't really consider this much of a bug, all of the g_log output that Gaim produces is now directed to its debug window, and you don't see it on stdout unless you run "gaim -d". If the original submitter agrees, I'd quite like to just close this bug... --- Jan 'Bulb' Hudec <[EMAIL PROTECTED]> Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291827: /usr/share/doc/gaim is empty
Angel Abad (Indio) wrote: The /usr/share/doc/gaim directory is empty, please fill it, show: # dpkg -L gaim /usr/share/doc/gaim This is correct, the package contains a symlink from gaim to gaim-data. The error is that I forgot that dpkg won't replace a symlink with a directory, or vice versa, because of undefined behaviour when the directory has contents. I've added a preinst that rmdir's the /usr/share/doc/gaim directory, and will upload now. Bye, Regards, Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
