Re: manual how to create a lib-package
Nikolaus Regnat [EMAIL PROTECTED] immo vero scripsit I'm searching for a manual (like New Maintainers' Guide) how to craete a package from a libary. Is there anything like that? As far as I know, the answer is No, and I think we need one too. You can see some of it in the debian-policy. What to do when the upstream soname changes, incompatible changes are made in the library interface, etc. shoud be documented, if such a manual (or policy) exists. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -BEGIN GEEK CODE BLOCK- Version: 3.12 GE d+ s:- a-- C+ UL P- L+++ E W++ N o-- K- w++ O- M- V-- PS+ PE-- Y+ PGP+ t-- 5 X-- R* tv- b+ DI- D++ G e h* r% !y+ --END GEEK CODE BLOCK-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unresolved symbol
Hi everybody, I'm learning to make kernel modules and am currently working on a block device driver. I had installed kernel version 2.2.16-22 (RH - 7.0) and then changed it to 2.2.16 (downloaded from kernel.org). PROBLEM : When I try to "insmod blkdev.o" it gives a message "unresolved symbol __constant_test_bit unresolved symbol __test_bit" and the module is not inserted . These two are being generated because I'm using INIT_REQUEST. If I put INIT_REQUEST in comments (/* */) the module gets inserted. But of course it doesn't work the way it should because of obvious reasons. Can anybody tell me where am I going wrong ? NOTE : I've included asm/bitops.h which has these two functions. HOW I INSTALLED MY NEW KERNEL (2.2.16): Probably I'm going wrong in my links. So here I reproduce the actual steps I took 1. tar -xvf linux-2.2.16 in /usr/src 2. The new source tree was installed in /usr/src/linux so, mv linux linux-new ln -s /usr/src/linux-new linux 3. Then I got my links right i.e. in /usr/include I did ln -s /usr/src/linux/include/linux linux ln -s /usr/src/linux/include/asm asm ln -s /usr/src/linux/include/scsi scsi 4. cd /usr/src/linux make mrproper make menuconfig make dep make clean make bzImage make modules make modules_install 5.cp /usr/src/linux/arch/i-386/boot/bzImage /boot/new 6. Updated/etc/lilo.conf and ran lilo 7. Rebooted from this new kernel 8. Now I compiled my block device driver module and tried to insert it and it gave me the aforesaid error. NOTE : 1. They say RH7.0 doesn't have a stable gcc so I had done cd /usr/bin rm -f gcc ln -s /usr/bin/kgcc gcc before recompiling the kernel. 2. insmod blkdev.o -f doesn't work either I'm not on any mailing list so please reply to me separately Thanks for your time I'd be glad if somebody can help me out Regards Sumit
Re:Unresolved symbol
unresolved symbol __constant_test_bit unresolved symbol __test_bit NOTE : I've included asm/bitops.h which has these two functions. If you've got unresolved symbols then the inline functions aren't actually being inlined. Are you giving gcc the -O option? Matt -- The contents of this communication are confidential to the normal user of the email address to which it was sent. If you have received this email in error, any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If this is the case, please notify the sender and delete this message. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
looking for sponsor for gpmudmon-applet
Hello, I'm looking for a sponsor for my package of gpmudmon; walters@space-ghost:~$ dpkg -s gpmudmon-applet Package: gpmudmon-applet Status: install ok installed Priority: optional Section: misc Installed-Size: 152 Maintainer: Colin Walters [EMAIL PROTECTED] Version: 0.1.1-3 Depends: pmud, gdk-imlib1 (= 1.9.10-3), libart2 (= 1.2.13-5), libaudiofile0, libc6 (= 2.2.3-1), libcapplet0 (= 1.4.0.2-3), libdb3 (= 3.2.9-1), libesd0 (= 0.2.22-4) | libesd-alsa0 (= 0.2.22-4), libglib1.2 (= 1.2.0), libgnome32 (= 1.2.13-5), libgnomesupport0 (= 1.2.13-5), libgnomeui32 (= 1.2.13-5), libgnorba27 (= 1.2.13-5), libgtk1.2 (= 1.2.10-1), liborbit0 (= 0.5.8), xlibs ( 4.0.3) Description: GNOME battery applet for PMUD gpmudmon is a GNOME applet which displays battery status obtained from the PMU daemon (powerpc only). It is apt-able from: deb http://www.cis.ohio-state.edu/~walters/debian/sid ./ Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patch problem -- always fuzzy?
Mikael Hedin [EMAIL PROTECTED] writes: /tmp/micce$tar xzf ~/sw/cvsdeb/tela/tela_1.32.orig.tar.gz /tmp/micce$cd tela-1.32/ /tmp/micce/tela-1.32$diff -u doc/usrguide-7.html ~/debian/cvsdeb/tela/doc/usrguide-7.html ../mydiff /tmp/micce/tela-1.32$patch -p0 ../mydiff patching file doc/usrguide-7.html Hunk #1 succeeded at 59 with fuzz 1. /tmp/micce/tela-1.32$ Interesting, I see the same behaviour. A diff generated with -u2 has no problems, OTOH. So you may want to work around this by manually replacing the chunk in the diff.gz with that. You should definitely look if this bug in patch is known, and report it otherwise. -- Robbe signature.ng
Re: [zeratul2@wanadoo.es: Bug#102811: grub: cannot access newer ext2 filesystems]
Matt Zimmerman [EMAIL PROTECTED] writes: The bug is not serious enough to justify an update to stable, especially not when we are preparing for a new release. You could of course upload a potato package anyway, and punt the decision to the release managers. AFAIK the package will end up in potato-proposed-updates where interested users of stable can get it. The chances of it appearing in potato are pretty slim, of course, because (a) it sounds like a big enough change, that even a backport (should you take this work on you) is probably too destabilizing, (b) it's dubious whether another potato point release will be done at all. Explain to the user that the fixed version is already in 'testing', and will be included in the next stable release. If you wish, you can leave the bug open (and downgrade it, it doesn't qualify as important) so that users know that they can fetch the latest version from testing. You should definitely tag it with potato if you keep it open. -- Robbe signature.ng
Re: g++ 3.0
On Sun, Jul 08, 2001 at 10:45:31PM -0400, Matt Zimmerman wrote: On Sun, Jul 08, 2001 at 11:01:52PM +0200, Robert Bihlmeyer wrote: I read on -devel that compiling packages with g++ 3 is problematic since they will not correctly link with C++ libraries built with an older compiler. I figure this will not be a problem for my package because it does not depend on any C++ libraries other than libstdc++, which should be ok. Normal C libraries are no bother, I assume. Is this correct? If the problem occurs only on certain architectures, you may want to try it yourself on as many as possible before switching entirely to g++-3.0. What is gained by this? Either he uses g++-3.0 for building these himself or he will still have to deal with all the problems. If he builds them with g++-3.0 he may just as well Build-Depend: on it and be done with it. In fact, if he doesn't Build-Depend: on g++-3.0 but does build manually with it, it might cause major trouble (NMU's, or just someone trying to build himself from sources without knowing he needs 3.0) On some Debian architectures, 3.0 is already the default compiler (see the source for gcc-defaults, I think). If those are the same architectures where your package has problems, then there is no problem for Debian. I think if those were the architectures, he wouldn't know of any problems... As long as it doesn't link against any other C++ libraries, it should work, yes. Whether or not this is a good idea, I'm not sure. There are issues with g++-3.0 other than ABI compatibility (such as debugging). It seems to be available on all platforms, though, so it might be worth a try if it turns out to be necessary. It might be wise to restrict the change to the problematic architectures, though. If the package builds fine with g++-3.0, and must be built with it even on some arches, I don't see why one would want to restrict this usage. It will become the default compiler eventually anyway. Regards, Filip -- Coderjoe gib, perl? gib methinks perl is the programmer's Swiss Army Chainsaw PGP signature
Re: Unresolved symbol
On Tue, Jul 10, 2001 at 04:51:00PM +0530, sumit kalra wrote: Hi everybody, I'm learning to make kernel modules and am currently working on a block device driver. I had installed kernel version 2.2.16-22 (RH - 7.0) and then changed it to 2.2.16 (downloaded from kernel.org). FYI, this is a Debian mailing list. Maybe you could post to Suse lists. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: [zeratul2@wanadoo.es: Bug#102811: grub: cannot access newer ext2 filesystems]
On Wed, 11 Jul 2001 00:17:43 +0200 (CEST), Santiago Vila [EMAIL PROTECTED] wrote: Robert Bihlmeyer wrote: (b) it's dubious whether another potato point release will be done at all. How can you be so certain about the dubiousness of that? :-) We should consider *all* the possibilities, including (but not limited to) that the release of woody will be delayed and there will be more potato point releases. hello, I'd like to suggest renaming it to grub1 or something and moving the woody version to potato, so we still have the chance to use both of them. regards, -- Robert Millan Debian GNU (Hurd) user zeratul2 wanadoo es http://getyouriso.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proud maintainer that do no want NUM :-)
On Mon, Jul 09, 2001 at 05:32:31PM +0200, Samuel Tardieu wrote: On 9/07, Stefano Zacchiroli wrote: | I know that is a really silly question, but I really dislike fixed in | NMU on my own bug pages :-))) Send a mail containing close ... in the body (by using the right bug number) to [EMAIL PROTECTED] Don't do that; email [EMAIL PROTECTED] with a copy of the changelog entry instead, otherwise the submitter will get this uninformative message that the bug has been closed with no rationale. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [zeratul2@wanadoo.es: Bug#102811: grub: cannot access newer ext2 filesystems]
On Tue, Jul 10, 2001 at 01:25:08PM +1000, Jason Thomas wrote: was wondering if anyone could suggest how to handle this bug. It is fixed in new versions of grub. The bug is not serious enough to justify an update to stable, especially not when we are preparing for a new release. It's certainly not necessary to remove grub from stable, as many people use it with no problems (I use grub on my potato system). Explain to the user that the fixed version is already in 'testing', and will be included in the next stable release. If you wish, you can leave the bug open (and downgrade it, it doesn't qualify as important) so that users know that they can fetch the latest version from testing. However, the bug is fixed, and the usual policy for fixed bugs is to close them. Some people use the 'fixed' tag for this purpose, but it only seems to cause confusion, since the BTS reports such bugs as 'fixed in NMU'. -- - mdz
Re: Policy question about web application
On Mon, Jul 09, 2001 at 11:25:38PM -0400, Jimmy Kaplowitz wrote: On Mon, Jul 09, 2001 at 10:33:20PM +0200, R?mi Perrot wrote: I read in the Debian policy that cgi script of web application must go in /usr/lib/cgi-bin/cgi-bin-name and should be referred as http://localhost/cgi-bin/cgi-bin-name (section 12.5). It look like that it is not allowed to have subdirectory under /usr/lib/cgi-bin/ if I have well understanding the policy. [...] So is subdirectory is allowed under /usr/lib/cgi-bin/ ? And if no do we need to amend the policy or report bug against packages that violate the policy ? Although I don't recall this section of Policy and have no firsthand experience with this issue, I recall it being mentioned that it is OK and even recommended to make subdirectories in /usr/lib/cgi-bin/ if you need a number of different scripts or if they have names that would conflict with other scripts. If Policy contradicts this, it should (in my opinion) be changed, since I don't think anyone intends it to do so. I agree. I've had cricket's CGI scripts in a subdirectory since the beginning. Since they have generic names like 'grapher.cgi', it helps to show which package they belong to. IMO, any package which has more than one or two CGI scripts should do this (*cough*, doc-central). The one that really bugs me is viewcvs, which installs /usr/lib/cgi-bin/query.cgi. In fact, I think it deserves a wishlist bug. -- - mdz
manual how to create a lib-package
I'm searching for a manual (like New Maintainers' Guide) how to craete a package from a libary. Is there anything like that? Nikolaus
Re: manual how to create a lib-package
Nikolaus Regnat [EMAIL PROTECTED] immo vero scripsit I'm searching for a manual (like New Maintainers' Guide) how to craete a package from a libary. Is there anything like that? As far as I know, the answer is No, and I think we need one too. You can see some of it in the debian-policy. What to do when the upstream soname changes, incompatible changes are made in the library interface, etc. shoud be documented, if such a manual (or policy) exists. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -BEGIN GEEK CODE BLOCK- Version: 3.12 GE d+ s:- a-- C+ UL P- L+++ E W++ N o-- K- w++ O- M- V-- PS+ PE-- Y+ PGP+ t-- 5 X-- R* tv- b+ DI- D++ G e h* r% !y+ --END GEEK CODE BLOCK--
Unresolved symbol
Hi everybody, I'm learning to make kernel modules and am currently working on a block device driver. I had installed kernel version 2.2.16-22 (RH - 7.0) and then changed it to 2.2.16 (downloaded from kernel.org). PROBLEM : When I try to "insmod blkdev.o" it gives a message "unresolved symbol __constant_test_bit unresolved symbol __test_bit" and the module is not inserted . These two are being generated because I'm using INIT_REQUEST. If I put INIT_REQUEST in comments (/* */) the module gets inserted. But of course it doesn't work the way it should because of obvious reasons. Can anybody tell me where am I going wrong ? NOTE : I've included asm/bitops.h which has these two functions. HOW I INSTALLED MY NEW KERNEL (2.2.16): Probably I'm going wrong in my links. So here I reproduce the actual steps I took 1. tar -xvf linux-2.2.16 in /usr/src 2. The new source tree was installed in /usr/src/linux so, mv linux linux-new ln -s /usr/src/linux-new linux 3. Then I got my links right i.e. in /usr/include I did ln -s /usr/src/linux/include/linux linux ln -s /usr/src/linux/include/asm asm ln -s /usr/src/linux/include/scsi scsi 4. cd /usr/src/linux make mrproper make menuconfig make dep make clean make bzImage make modules make modules_install 5.cp /usr/src/linux/arch/i-386/boot/bzImage /boot/new 6. Updated/etc/lilo.conf and ran lilo 7. Rebooted from this new kernel 8. Now I compiled my block device driver module and tried to insert it and it gave me the aforesaid error. NOTE : 1. They say RH7.0 doesn't have a stable gcc so I had done cd /usr/bin rm -f gcc ln -s /usr/bin/kgcc gcc before recompiling the kernel. 2. insmod blkdev.o -f doesn't work either I'm not on any mailing list so please reply to me separately Thanks for your time I'd be glad if somebody can help me out Regards Sumit
Re:Unresolved symbol
unresolved symbol __constant_test_bit unresolved symbol __test_bit NOTE : I've included asm/bitops.h which has these two functions. If you've got unresolved symbols then the inline functions aren't actually being inlined. Are you giving gcc the -O option? Matt -- The contents of this communication are confidential to the normal user of the email address to which it was sent. If you have received this email in error, any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If this is the case, please notify the sender and delete this message. --
looking for sponsor for gpmudmon-applet
Hello, I'm looking for a sponsor for my package of gpmudmon; [EMAIL PROTECTED]:~$ dpkg -s gpmudmon-applet Package: gpmudmon-applet Status: install ok installed Priority: optional Section: misc Installed-Size: 152 Maintainer: Colin Walters [EMAIL PROTECTED] Version: 0.1.1-3 Depends: pmud, gdk-imlib1 (= 1.9.10-3), libart2 (= 1.2.13-5), libaudiofile0, libc6 (= 2.2.3-1), libcapplet0 (= 1.4.0.2-3), libdb3 (= 3.2.9-1), libesd0 (= 0.2.22-4) | libesd-alsa0 (= 0.2.22-4), libglib1.2 (= 1.2.0), libgnome32 (= 1.2.13-5), libgnomesupport0 (= 1.2.13-5), libgnomeui32 (= 1.2.13-5), libgnorba27 (= 1.2.13-5), libgtk1.2 (= 1.2.10-1), liborbit0 (= 0.5.8), xlibs ( 4.0.3) Description: GNOME battery applet for PMUD gpmudmon is a GNOME applet which displays battery status obtained from the PMU daemon (powerpc only). It is apt-able from: deb http://www.cis.ohio-state.edu/~walters/debian/sid ./ Thanks!
Re: Patch problem -- always fuzzy?
Mikael Hedin [EMAIL PROTECTED] writes: /tmp/micce$tar xzf ~/sw/cvsdeb/tela/tela_1.32.orig.tar.gz /tmp/micce$cd tela-1.32/ /tmp/micce/tela-1.32$diff -u doc/usrguide-7.html ~/debian/cvsdeb/tela/doc/usrguide-7.html ../mydiff /tmp/micce/tela-1.32$patch -p0 ../mydiff patching file doc/usrguide-7.html Hunk #1 succeeded at 59 with fuzz 1. /tmp/micce/tela-1.32$ Interesting, I see the same behaviour. A diff generated with -u2 has no problems, OTOH. So you may want to work around this by manually replacing the chunk in the diff.gz with that. You should definitely look if this bug in patch is known, and report it otherwise. -- Robbe signature.ng Description: PGP signature
Re: [zeratul2@wanadoo.es: Bug#102811: grub: cannot access newer ext2 filesystems]
Matt Zimmerman [EMAIL PROTECTED] writes: The bug is not serious enough to justify an update to stable, especially not when we are preparing for a new release. You could of course upload a potato package anyway, and punt the decision to the release managers. AFAIK the package will end up in potato-proposed-updates where interested users of stable can get it. The chances of it appearing in potato are pretty slim, of course, because (a) it sounds like a big enough change, that even a backport (should you take this work on you) is probably too destabilizing, (b) it's dubious whether another potato point release will be done at all. Explain to the user that the fixed version is already in 'testing', and will be included in the next stable release. If you wish, you can leave the bug open (and downgrade it, it doesn't qualify as important) so that users know that they can fetch the latest version from testing. You should definitely tag it with potato if you keep it open. -- Robbe signature.ng Description: PGP signature
Re: g++ 3.0
On Sun, Jul 08, 2001 at 10:45:31PM -0400, Matt Zimmerman wrote: On Sun, Jul 08, 2001 at 11:01:52PM +0200, Robert Bihlmeyer wrote: I read on -devel that compiling packages with g++ 3 is problematic since they will not correctly link with C++ libraries built with an older compiler. I figure this will not be a problem for my package because it does not depend on any C++ libraries other than libstdc++, which should be ok. Normal C libraries are no bother, I assume. Is this correct? If the problem occurs only on certain architectures, you may want to try it yourself on as many as possible before switching entirely to g++-3.0. What is gained by this? Either he uses g++-3.0 for building these himself or he will still have to deal with all the problems. If he builds them with g++-3.0 he may just as well Build-Depend: on it and be done with it. In fact, if he doesn't Build-Depend: on g++-3.0 but does build manually with it, it might cause major trouble (NMU's, or just someone trying to build himself from sources without knowing he needs 3.0) On some Debian architectures, 3.0 is already the default compiler (see the source for gcc-defaults, I think). If those are the same architectures where your package has problems, then there is no problem for Debian. I think if those were the architectures, he wouldn't know of any problems... As long as it doesn't link against any other C++ libraries, it should work, yes. Whether or not this is a good idea, I'm not sure. There are issues with g++-3.0 other than ABI compatibility (such as debugging). It seems to be available on all platforms, though, so it might be worth a try if it turns out to be necessary. It might be wise to restrict the change to the problematic architectures, though. If the package builds fine with g++-3.0, and must be built with it even on some arches, I don't see why one would want to restrict this usage. It will become the default compiler eventually anyway. Regards, Filip -- Coderjoe gib, perl? gib methinks perl is the programmer's Swiss Army Chainsaw pgplPnhyH1VXV.pgp Description: PGP signature
Re: Unresolved symbol
On Tue, Jul 10, 2001 at 04:51:00PM +0530, sumit kalra wrote: Hi everybody, I'm learning to make kernel modules and am currently working on a block device driver. I had installed kernel version 2.2.16-22 (RH - 7.0) and then changed it to 2.2.16 (downloaded from kernel.org). FYI, this is a Debian mailing list. Maybe you could post to Suse lists. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: g++ 3.0
On Tue, Jul 10, 2001 at 02:37:09PM +0200, Filip Van Raemdonck wrote: On Sun, Jul 08, 2001 at 10:45:31PM -0400, Matt Zimmerman wrote: If the problem occurs only on certain architectures, you may want to try it yourself on as many as possible before switching entirely to g++-3.0. What is gained by this? Either he uses g++-3.0 for building these himself or he will still have to deal with all the problems. If he builds them with g++-3.0 he may just as well Build-Depend: on it and be done with it. In fact, if he doesn't Build-Depend: on g++-3.0 but does build manually with it, it might cause major trouble (NMU's, or just someone trying to build himself from sources without knowing he needs 3.0) I stated in the following paragraph what could be gained from such a test. Obviously, if the package were meant to be built with a different compiler on certain architectures, this would be enforced in the debian/rules file, and there would be no difference between manual and automated builds. On some Debian architectures, 3.0 is already the default compiler (see the source for gcc-defaults, I think). If those are the same architectures where your package has problems, then there is no problem for Debian. I think if those were the architectures, he wouldn't know of any problems... That is not necessarily true. Most likely, not all users of the program are Debian users. There is no telling which compiler versions are in use when these problems surface. As long as it doesn't link against any other C++ libraries, it should work, yes. Whether or not this is a good idea, I'm not sure. There are issues with g++-3.0 other than ABI compatibility (such as debugging). It seems to be available on all platforms, though, so it might be worth a try if it turns out to be necessary. It might be wise to restrict the change to the problematic architectures, though. If the package builds fine with g++-3.0, and must be built with it even on some arches, I don't see why one would want to restrict this usage. It will become the default compiler eventually anyway. Read what I wrote. g++-3.0 is a big step, and when it becomes the default compiler, there will be a transition plan. Just build random packages with 3.0 is not a transition plan. Who's to say that building with g++-3.0 on i386 will not introduce new bugs? -- - mdz
Re: [zeratul2@wanadoo.es: Bug#102811: grub: cannot access newer ext2 filesystems]
Robert Bihlmeyer wrote: (b) it's dubious whether another potato point release will be done at all. How can you be so certain about the dubiousness of that? :-) We should consider *all* the possibilities, including (but not limited to) that the release of woody will be delayed and there will be more potato point releases.
Re: Re: [zeratul2@wanadoo.es: Bug#102811: grub: cannot access newer ext2 filesystems]
On Wed, 11 Jul 2001 00:17:43 +0200 (CEST), Santiago Vila [EMAIL PROTECTED] wrote: Robert Bihlmeyer wrote: (b) it's dubious whether another potato point release will be done at all. How can you be so certain about the dubiousness of that? :-) We should consider *all* the possibilities, including (but not limited to) that the release of woody will be delayed and there will be more potato point releases. hello, I'd like to suggest renaming it to grub1 or something and moving the woody version to potato, so we still have the chance to use both of them. regards, -- Robert Millan Debian GNU (Hurd) user zeratul2 wanadoo es http://getyouriso.org/
Re: proud maintainer that do no want NUM :-)
On Mon, Jul 09, 2001 at 05:32:31PM +0200, Samuel Tardieu wrote: On 9/07, Stefano Zacchiroli wrote: | I know that is a really silly question, but I really dislike fixed in | NMU on my own bug pages :-))) Send a mail containing close ... in the body (by using the right bug number) to [EMAIL PROTECTED] Don't do that; email [EMAIL PROTECTED] with a copy of the changelog entry instead, otherwise the submitter will get this uninformative message that the bug has been closed with no rationale. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
