Re: RFS: gtklp -- Frontend for CUPS written in GTK+
On 2004-04-29 Andreas Metzler [EMAIL PROTECTED] wrote: automake --add-missing --copy autoconf ‐‐force‐missing is missing. - Just for the archives. cu andreas
Re: use locale for python package test
On 2004-04-29 GCS [EMAIL PROTECTED] wrote: I maintain a package, which needs en_US locale for testing the build. I did it as writing en_US to /etc/locale.gen and generate the locales again, if it's not yet done. Then set LC_ALL to en_US, and do the test. So far, so good, it works. But now I got a FTBFS as a simple user it can not be built (no permission for /etc/locale.gen). The reporter says there's localedef -i en_US -f ISO-8859-1 $(CURDIR)/debian/locale/en_US but how can I use the generated locale like it would be the system's locale? I have tried setting LC_PATH to various directories (like $(CURDIR)/debian/locale/ ) without success. [...] The variable is named LOCPATH and not LC_PATH, LOCPATH=$(CURDIR)/debian/locale should work. I wished this was documented. I only found this with strings /lib/libc-2.3.2.so | grep 'PATH' because it is not doumented[1] in info manpages. cu andreas [1] The only reference is The variables ... LOCPATH ... influence locale handling, cf. locale(5). in environ(7) -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: RFS: gtklp -- Frontend for CUPS written in GTK+
On 2004-04-29 Zak B. Elep [EMAIL PROTECTED] wrote: On Tue, Apr 27, 2004 at 09:43:32AM +0200, Andreas Metzler wrote: [...] Imho the build-depency on gnutls should simply be droppep, gtklp does not use gnutls, it is just a libtool artefact caused by libcupsys2-dev, which already depends on libgnutls7-dev. Also dropped gnutls ;) And with the newest latest libcupsys2-dev version (1.1.20final+cvs20040330-3) gtklp won't uselessly link against gnutls. ;-) Did you repack the source? - The md5sum does not match: [...] Of course the md5sums won't match, they're _not_ the same sources! (Hint: it's a `p', not an `n' ;) I need to improve on my reading skills. ;-) - I'll offer advise in exchange: You should install or upgrade autotools-dev on your machine, config.(guess|sub) is still old because the respective code in debian/rules requires autotools-dev. I am willing to sponsor the package in its current state to rid of a gnutls5 dependency in sid. It would be nice if gtklp could be fixed with respect to http://bugs.debian.org/242950 but for gtklp it is a little bit more complicated than #1 Add AM_MAINTAINER_MODE near the start of configure.in #2 libtoolize --force --copy aclocal autoheader automake \ --add-missing --copy autoconf #3 clean up which suggests putting this of to the second upload. I played a little bit with it and needed to manually remove ./missing (because automake did not overwrite it with a fresh version) and work around a incompatibilty between po/Makefile.in.in of the antic version of gettext used in the package and current autotools -mkinstalldirs = $(SHELL) `case $(MKINSTALLDIRS) in /*) echo $(MKINSTALLDIRS) ;; *) echo $(top_builddir)/$(MKINSTALLDIRS) ;; esac` +mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs This looks hackish and I do not know whether it might break stuff. - The proper fix would be updating gettext, but I could not deal with that in the limited timeI chose to invest. - It is something upstream should do, imho. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gtklp -- Frontend for CUPS written in GTK+
On 2004-04-29 Andreas Metzler [EMAIL PROTECTED] wrote: automake --add-missing --copy autoconf forcemissing is missing. - Just for the archives. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use locale for python package test
On 2004-04-29 GCS [EMAIL PROTECTED] wrote: I maintain a package, which needs en_US locale for testing the build. I did it as writing en_US to /etc/locale.gen and generate the locales again, if it's not yet done. Then set LC_ALL to en_US, and do the test. So far, so good, it works. But now I got a FTBFS as a simple user it can not be built (no permission for /etc/locale.gen). The reporter says there's localedef -i en_US -f ISO-8859-1 $(CURDIR)/debian/locale/en_US but how can I use the generated locale like it would be the system's locale? I have tried setting LC_PATH to various directories (like $(CURDIR)/debian/locale/ ) without success. [...] The variable is named LOCPATH and not LC_PATH, LOCPATH=$(CURDIR)/debian/locale should work. I wished this was documented. I only found this with strings /lib/libc-2.3.2.so | grep 'PATH' because it is not doumented[1] in info manpages. cu andreas [1] The only reference is The variables ... LOCPATH ... influence locale handling, cf. locale(5). in environ(7) -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gtklp -- Frontend for CUPS written in GTK+
On 2004-04-27 Zak B. Elep [EMAIL PROTECTED] wrote: [...] * New maintainer (Closes: #244199, #245619) * New upstream version (Closes: #209172, #194459) * Fixed typo in man page (#170642), patch forwarded to upstream * Fixed translation bug (#226839), patch forwarded to upstream * Man page fixes (Closes: #100435) * English is the default language (Closes: #85962) * Rebuilt debian directory to reflect new Standards-Version (was 3.2.1) * Build-Dependencies already complete (Closes: #84581, #89878, #90528, #123676) [...] Hello, Thanks, nice. :-) Just some minor tidbits: You seem to have repackaged it almost from scratch dumping the dependency on debmake in the process (afaict on a very short glance), but it is still listed in Build-Dependends. Build-Depends: libcupsys2-dev, libglib1.2-dev, libgtk1.2-dev,libgnutls-dev | libgnutls5-dev, debmake, debhelper (= 4.0.0) You also should not build-depend on libgnutls-dev | libgnutls5-dev *If* you build-depend on gnutls you should have an exact build-dependency on libgnutls7-dev because cups is using this version and you do not want gtklp to link against two versions of gnutls. (Crashes might be the result.) Imho the build-depency on gnutls should simply be droppep, gtklp does not use gnutls, it is just a libtool artefact caused by libcupsys2-dev, which already depends on libgnutls7-dev. Did you repack the source? - The md5sum does not match: [EMAIL PROTECTED]:/tmp$ grep orig gtklp_0.9p-1.dsc 6e287468e9e01bae464c78a197f94160 533124 gtklp_0.9p.orig.tar.gz [EMAIL PROTECTED]:/tmp$ wget \ http://switch.dl.sourceforge.net/sourceforge/gtklp/gtklp-0.9n.src.tar.gz [EMAIL PROTECTED]:/tmp$ md5sum gtklp-0.9n.src.tar.gz aaae46694b96290113033420c1958ed7 gtklp-0.9n.src.tar.gz Just use mv name.of.downloaded.tar.gz gtklp_0.9p.orig.tar.gz before you start building. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: debian-mentors@lists.debian.org
On 2004-04-27 William Ballard [EMAIL PROTECTED] wrote: On Tue, Apr 27, 2004 at 11:27:59AM +0200, GCS wrote: public part to any keyserver like pgp.mit.edu then search someone who volunteers to sign your key and plan a meeting. [...] I don't understand how to do the snipped part above. On db.debian.org all I can do is search for all DDs in the USA and even then I wouldn't know who is willing to. http://nm.debian.org/gpg_offer.php cu andreas
Re: RFS: gtklp -- Frontend for CUPS written in GTK+
On 2004-04-27 Zak B. Elep [EMAIL PROTECTED] wrote: [...] * New maintainer (Closes: #244199, #245619) * New upstream version (Closes: #209172, #194459) * Fixed typo in man page (#170642), patch forwarded to upstream * Fixed translation bug (#226839), patch forwarded to upstream * Man page fixes (Closes: #100435) * English is the default language (Closes: #85962) * Rebuilt debian directory to reflect new Standards-Version (was 3.2.1) * Build-Dependencies already complete (Closes: #84581, #89878, #90528, #123676) [...] Hello, Thanks, nice. :-) Just some minor tidbits: You seem to have repackaged it almost from scratch dumping the dependency on debmake in the process (afaict on a very short glance), but it is still listed in Build-Dependends. Build-Depends: libcupsys2-dev, libglib1.2-dev, libgtk1.2-dev,libgnutls-dev | libgnutls5-dev, debmake, debhelper (= 4.0.0) You also should not build-depend on libgnutls-dev | libgnutls5-dev *If* you build-depend on gnutls you should have an exact build-dependency on libgnutls7-dev because cups is using this version and you do not want gtklp to link against two versions of gnutls. (Crashes might be the result.) Imho the build-depency on gnutls should simply be droppep, gtklp does not use gnutls, it is just a libtool artefact caused by libcupsys2-dev, which already depends on libgnutls7-dev. Did you repack the source? - The md5sum does not match: [EMAIL PROTECTED]:/tmp$ grep orig gtklp_0.9p-1.dsc 6e287468e9e01bae464c78a197f94160 533124 gtklp_0.9p.orig.tar.gz [EMAIL PROTECTED]:/tmp$ wget \ http://switch.dl.sourceforge.net/sourceforge/gtklp/gtklp-0.9n.src.tar.gz [EMAIL PROTECTED]:/tmp$ md5sum gtklp-0.9n.src.tar.gz aaae46694b96290113033420c1958ed7 gtklp-0.9n.src.tar.gz Just use mv name.of.downloaded.tar.gz gtklp_0.9p.orig.tar.gz before you start building. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-mentors@lists.debian.org
On 2004-04-27 William Ballard [EMAIL PROTECTED] wrote: On Tue, Apr 27, 2004 at 11:27:59AM +0200, GCS wrote: public part to any keyserver like pgp.mit.edu then search someone who volunteers to sign your key and plan a meeting. [...] I don't understand how to do the snipped part above. On db.debian.org all I can do is search for all DDs in the USA and even then I wouldn't know who is willing to. http://nm.debian.org/gpg_offer.php cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with Files section in .changes
On 2004-04-16 Steffen Nissen [EMAIL PROTECTED] wrote: When trying to upload files to mentors.debian.net an error occurs because of errors in the .changes file. I can see what the error is, but unfortunately I do not know how to fix them. The files section is as follows and I believe that the '-' is an error, but I do not know how to fix it. Any suggestions? Files: 1757f49ec7042da8d3ecaa183daafc27 512 - optional libfann1_1.1.0-1.dsc [...] apt-get update apt-get upgrade You need to update dpkg-dev. See http://bugs.debian.org/190611 http://bugs.debian.org/221989 http://bugs.debian.org/222760 BTW: an error occurs is a poor problem description, always *quote* the error message. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Problem with Files section in .changes
On 2004-04-16 Steffen Nissen [EMAIL PROTECTED] wrote: When trying to upload files to mentors.debian.net an error occurs because of errors in the .changes file. I can see what the error is, but unfortunately I do not know how to fix them. The files section is as follows and I believe that the '-' is an error, but I do not know how to fix it. Any suggestions? Files: 1757f49ec7042da8d3ecaa183daafc27 512 - optional libfann1_1.1.0-1.dsc [...] apt-get update apt-get upgrade You need to update dpkg-dev. See http://bugs.debian.org/190611 http://bugs.debian.org/221989 http://bugs.debian.org/222760 BTW: an error occurs is a poor problem description, always *quote* the error message. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: stripclub - Online Comic Reader/Archiver
On Fri, Apr 09, 2004 at 08:12:02AM -0600, Benjamin Cutler wrote: Brian Nelson wrote: Benjamin Cutler [EMAIL PROTECTED] writes: [...] * You should change the RFP for stripclub to an ITP (just change the bug title), and then close the bug in the changelog. My first attempt to do this kinda blundered it, obviously... I tried to retitle it by sending a message to [EMAIL PROTECTED], but it doesn't seem to have worked. I'm supposed to get at least an error response if I get it wrong, aren't I? [...] Yes, you are right. The BTS seems to be oveloaded currently, it can take a couple of hours until a request is processed. cu andreas
Re: RFS: stripclub - Online Comic Reader/Archiver
On Fri, Apr 09, 2004 at 08:12:02AM -0600, Benjamin Cutler wrote: Brian Nelson wrote: Benjamin Cutler [EMAIL PROTECTED] writes: [...] * You should change the RFP for stripclub to an ITP (just change the bug title), and then close the bug in the changelog. My first attempt to do this kinda blundered it, obviously... I tried to retitle it by sending a message to [EMAIL PROTECTED], but it doesn't seem to have worked. I'm supposed to get at least an error response if I get it wrong, aren't I? [...] Yes, you are right. The BTS seems to be oveloaded currently, it can take a couple of hours until a request is processed. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package adding users
On 2004-04-07 Erik Bourget [EMAIL PROTECTED] wrote: Matt Zimmerman [EMAIL PROTECTED] writes: [adding users] adduser is the correct tool. See policy 9.2.2. I do not think that useradd follows, e.g., the uid allocation guidelines in that section, and adduser's semantics are more convenient for maintainer scripts as well. Am I crazy, or is the --system option not available in woody for deluser? No, yes. It was only added in the newest latest upload of adduser which is currently _only_ available in sid. What's a 'nice way' to delete a system user if it exists (i.e. in postrm), deluser username || true (so the failure doesn't scuttle the postrm script)? I am using deluser --quiet Debian-exim /dev/null || true cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: package adding users
On 2004-04-07 Erik Bourget [EMAIL PROTECTED] wrote: Matt Zimmerman [EMAIL PROTECTED] writes: [adding users] adduser is the correct tool. See policy 9.2.2. I do not think that useradd follows, e.g., the uid allocation guidelines in that section, and adduser's semantics are more convenient for maintainer scripts as well. Am I crazy, or is the --system option not available in woody for deluser? No, yes. It was only added in the newest latest upload of adduser which is currently _only_ available in sid. What's a 'nice way' to delete a system user if it exists (i.e. in postrm), deluser username || true (so the failure doesn't scuttle the postrm script)? I am using deluser --quiet Debian-exim /dev/null || true cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package adding users
On 2004-04-06 Erik Bourget [EMAIL PROTECTED] wrote: What's the best/accepted way to have a package add users to a Debian system? Policy 9.2. | Packages which need a user or group, but can have this user or | group allocated dynamically and differently on each system, should | use adduser --system to create the group and/or user. adduser will | check for the existence of the user or group, and if necessary | choose an unused id based on the ranges specified in adduser.conf. cu andreas
Re: package adding users
On 2004-04-06 Erik Bourget [EMAIL PROTECTED] wrote: What's the best/accepted way to have a package add users to a Debian system? Policy 9.2. | Packages which need a user or group, but can have this user or | group allocated dynamically and differently on each system, should | use adduser --system to create the group and/or user. adduser will | check for the existence of the user or group, and if necessary | choose an unused id based on the ranges specified in adduser.conf. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Separating packages.
On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote: I have simple question which I could not find in the debian policy, maybe someone could point me out to that section or the right documentation? Or a explanation would be nice. I'm debianizing a package that I would like to split up in several parts, the package has a 'backgrounds' directory a 'icons' directory and a 'examples' directory. How do I handle this? I would like to create packages like: package-backgrounds package-icons package-examples package-name (which contains all of the above) Should I do this as a meta-package? How do I create a meta-package? [...] Why? How big are the components? Would somebdy e.g install package-name without package-icons or the other way round? cu andreas
Re: new maintainer application question
On Mon, Apr 05, 2004 at 05:17:47PM +0200, GCS wrote: I am applied[1] for a Debian Developer role, but as I see, Front Desk is stalling; I can't see any progress on applicants who have been advocated. So I have a couple of questions: - may I hope that Front Desk will assign an AM to me before Sarge is released? (IMHO not :( ). Depends on how long it takes to release sarge. ;-) I do not know the current status of NM first hand but it should not take *much* longer than a month. Asking on the correct ml (newmaint) might yield better results. - is it ok that a not-yet-DD has packages in the stable (to-be) version of Debian, in Sarge? (IMHO yes). Yes, of course. - should I work on my packages in Sarge/Sid, or helping others with their packages[2], so hopefully make Sarge release sooner? Are you asking what is slowing down sarge currently? * debian-installer. * About 300 release critical bugs http://bugs.debian.org/release-critical/ I do not know the status of /your/ packages, but the stuff you are not able to fix now will entertain sarge's users for 1-2 years. cu andreas
Re: Separating packages.
On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote: I have simple question which I could not find in the debian policy, maybe someone could point me out to that section or the right documentation? Or a explanation would be nice. I'm debianizing a package that I would like to split up in several parts, the package has a 'backgrounds' directory a 'icons' directory and a 'examples' directory. How do I handle this? I would like to create packages like: package-backgrounds package-icons package-examples package-name (which contains all of the above) Should I do this as a meta-package? How do I create a meta-package? [...] Why? How big are the components? Would somebdy e.g install package-name without package-icons or the other way round? cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new maintainer application question
On Mon, Apr 05, 2004 at 05:17:47PM +0200, GCS wrote: I am applied[1] for a Debian Developer role, but as I see, Front Desk is stalling; I can't see any progress on applicants who have been advocated. So I have a couple of questions: - may I hope that Front Desk will assign an AM to me before Sarge is released? (IMHO not :( ). Depends on how long it takes to release sarge. ;-) I do not know the current status of NM first hand but it should not take *much* longer than a month. Asking on the correct ml (newmaint) might yield better results. - is it ok that a not-yet-DD has packages in the stable (to-be) version of Debian, in Sarge? (IMHO yes). Yes, of course. - should I work on my packages in Sarge/Sid, or helping others with their packages[2], so hopefully make Sarge release sooner? Are you asking what is slowing down sarge currently? * debian-installer. * About 300 release critical bugs http://bugs.debian.org/release-critical/ I do not know the status of /your/ packages, but the stuff you are not able to fix now will entertain sarge's users for 1-2 years. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with SONAME which changes very often
On 2004-04-02 Bartosz Fenski aka fEnIo [EMAIL PROTECTED] wrote: I would like to package some very useful set of utilities[1]. It depends on library of the same author[2]. Unfortunatelly SONAME of this library changes with every new version. And to make this problem more annoying, new releases shows very often (about one version per two weeks). [...] Imho the only sane way to deal with this is not shipping the shared library but only a static one. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Becoming a Developer...
On 2004-04-02 Benjamin Cutler [EMAIL PROTECTED] wrote: First off I'll admit I only gave a quick glance at the Debian New Maintainters' Corner, but from what I saw, it looked like the first step wasn't an automated thing. It sounds like the first thing I need to do it get to know some of the current developers... In summary the reason I want to become a developer is that I have a program I've been working on for the last couple of weeks, and it's reached a point that I think it could benefit from being included in the Debian archives. [...] Hello, These two things (you becoming a maintainer and the program you have written being included in Debian) are only loosely connected: * The program can become part Debian without you maintaining it. (Neither Linus Torwalds nor Larry Wall are DDs[1] either ;-) Submit a request for package bug (RFP) using reportbug wnpp and hope somebody picks up. * You can maintain the package without being an official DD. - You do the actual work and a DD doublechecks and uploads it for you. This is called Sponsoring. Applying for becoming a DD by starting the NM process usually should only be done after you have participated in Debian for some time. The unofficial debian-mentors FAQ http://people.debian.org/~mpalmer/debian-mentors_FAQ.html explains this in more detail. hth, cu andreas [1] Debian developer. people with a fancy @debian.org address and the possibiltiy to upload packages. -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with SONAME which changes very often
On 2004-04-02 Bartosz Fenski aka fEnIo [EMAIL PROTECTED] wrote: I would like to package some very useful set of utilities[1]. It depends on library of the same author[2]. Unfortunatelly SONAME of this library changes with every new version. And to make this problem more annoying, new releases shows very often (about one version per two weeks). [...] Imho the only sane way to deal with this is not shipping the shared library but only a static one. cu andreas
Re: Becoming a Developer...
On 2004-04-02 Benjamin Cutler [EMAIL PROTECTED] wrote: First off I'll admit I only gave a quick glance at the Debian New Maintainters' Corner, but from what I saw, it looked like the first step wasn't an automated thing. It sounds like the first thing I need to do it get to know some of the current developers... In summary the reason I want to become a developer is that I have a program I've been working on for the last couple of weeks, and it's reached a point that I think it could benefit from being included in the Debian archives. [...] Hello, These two things (you becoming a maintainer and the program you have written being included in Debian) are only loosely connected: * The program can become part Debian without you maintaining it. (Neither Linus Torwalds nor Larry Wall are DDs[1] either ;-) Submit a request for package bug (RFP) using reportbug wnpp and hope somebody picks up. * You can maintain the package without being an official DD. - You do the actual work and a DD doublechecks and uploads it for you. This is called Sponsoring. Applying for becoming a DD by starting the NM process usually should only be done after you have participated in Debian for some time. The unofficial debian-mentors FAQ http://people.debian.org/~mpalmer/debian-mentors_FAQ.html explains this in more detail. hth, cu andreas [1] Debian developer. people with a fancy @debian.org address and the possibiltiy to upload packages. -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Unicode conversion goals for Sarge (was Re: debian-changelog-file-uses-obsolete-national-charset)
On 2004-03-31 Colin Watson [EMAIL PROTECTED] wrote: [..] man (mostly) supports you running in a UTF-8 locale by means of some complicated iconv kludges. [...] Hmm. I seem to be doing something seriously wrong. man is completely unuseable for me in uxterm with UTF-8 locale. http://www.logic.univie.ac.at/~ametzler/man_in_uxterm.png (5 KB) Checking man's output it does not recode at all. - Is there a simple gotcha I am missing? I am pretty sure my locale is basically ok, because tin and mutt work. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unicode conversion goals for Sarge (was Re: debian-changelog-file-uses-obsolete-national-charset)
On 2004-03-31 Andreas Metzler [EMAIL PROTECTED] wrote: On 2004-03-31 Colin Watson [EMAIL PROTECTED] wrote: [..] man (mostly) supports you running in a UTF-8 locale by means of some complicated iconv kludges. [...] Hmm. I seem to be doing something seriously wrong. [...] indeed. LESSCHARSET=latin1 was still set. Sorry for the noise. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unicode conversion goals for Sarge (was Re: debian-changelog-file-uses-obsolete-national-charset)
On 2004-03-31 Colin Watson [EMAIL PROTECTED] wrote: [..] man (mostly) supports you running in a UTF-8 locale by means of some complicated iconv kludges. [...] Hmm. I seem to be doing something seriously wrong. man is completely unuseable for me in uxterm with UTF-8 locale. http://www.logic.univie.ac.at/~ametzler/man_in_uxterm.png (5 KB) Checking man's output it does not recode at all. - Is there a simple gotcha I am missing? I am pretty sure my locale is basically ok, because tin and mutt work. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Unicode conversion goals for Sarge (was Re: debian-changelog-file-uses-obsolete-national-charset)
On 2004-03-31 Andreas Metzler [EMAIL PROTECTED] wrote: On 2004-03-31 Colin Watson [EMAIL PROTECTED] wrote: [..] man (mostly) supports you running in a UTF-8 locale by means of some complicated iconv kludges. [...] Hmm. I seem to be doing something seriously wrong. [...] indeed. LESSCHARSET=latin1 was still set. Sorry for the noise. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: debian-changelog-file-uses-obsolete-national-charset
On 2004-03-30 Martin-Éric Racine [EMAIL PROTECTED] wrote: [...] If I change my locale setting to [EMAIL PROTECTED] [1], debsign can no longer find my GPG key, because it expects the accent on my name to be encoded in UTF-8, even though the key was created in Latin-1. Have you tried adding a second UID that is UTF-8 encoded? Another thing is, several remote sites I need to access on a daily basis simply do not offer UTF-8 locales. In those cases, I still need a terminal that functions in Latin-1, including all accented characters. Switching locale would definitely break a lot of things there, because the remote end would receive accented characters using UTF-8 escape sequences, instead of plain Latin-1. [...] However... If anybody has clear solutions to ALL the above issues, I would gladly hear them. :-) The easiest way for the time being might be for you: #1 keep using latin1 locale. #2 keep debian/control and debian/changelog in latin1. #3 Before you start dpkg-buildpackage use iconv or recode to *temporarily* recode these files to UTF-8 #4 Use -k1E0CB9CD for debsign/dpkg-buildpackage. If you change debian/changelog to UTF-8 you have to also change debian/control, otherwise the maintainer-ids won't match and your upload will be classifed as NMU. [1] Shouldn't this @euro crap be gone by now? I mean the Euro is the only currency here since a few years already. Should fi_FI mean ISO-8859-15 by default, at this point? Imvho ISO-8859-15 just sucks. It is not as compatible as latin1 (e.g e-mail, usenet) and not as useful as unicode. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need help getting package built on arm
On 2004-03-30 Steve Halasz [EMAIL PROTECTED] wrote: My package, qgis, has failed to build on arm. The error is: uic: error while loading shared libraries: libICE.so.6: cannot open shared object file: No such file or directory Which was caused by broken X11 maintainer scripts at this time. When this first happened, I checked on packages.d.o and IIRC could not find a package on arm that contained that file. Now I can. So I suspect that it will work now. Should I just bump up my xlibs-dev build dep to the latest version and upload the package to be built again? No. Ask the arm buildd admins to requeue it. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-changelog-file-uses-obsolete-national-charset
On 2004-03-30 Martin-Éric Racine [EMAIL PROTECTED] wrote: [...] If I change my locale setting to [EMAIL PROTECTED] [1], debsign can no longer find my GPG key, because it expects the accent on my name to be encoded in UTF-8, even though the key was created in Latin-1. Have you tried adding a second UID that is UTF-8 encoded? Another thing is, several remote sites I need to access on a daily basis simply do not offer UTF-8 locales. In those cases, I still need a terminal that functions in Latin-1, including all accented characters. Switching locale would definitely break a lot of things there, because the remote end would receive accented characters using UTF-8 escape sequences, instead of plain Latin-1. [...] However... If anybody has clear solutions to ALL the above issues, I would gladly hear them. :-) The easiest way for the time being might be for you: #1 keep using latin1 locale. #2 keep debian/control and debian/changelog in latin1. #3 Before you start dpkg-buildpackage use iconv or recode to *temporarily* recode these files to UTF-8 #4 Use -k1E0CB9CD for debsign/dpkg-buildpackage. If you change debian/changelog to UTF-8 you have to also change debian/control, otherwise the maintainer-ids won't match and your upload will be classifed as NMU. [1] Shouldn't this @euro crap be gone by now? I mean the Euro is the only currency here since a few years already. Should fi_FI mean ISO-8859-15 by default, at this point? Imvho ISO-8859-15 just sucks. It is not as compatible as latin1 (e.g e-mail, usenet) and not as useful as unicode. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Need help getting package built on arm
On 2004-03-30 Steve Halasz [EMAIL PROTECTED] wrote: My package, qgis, has failed to build on arm. The error is: uic: error while loading shared libraries: libICE.so.6: cannot open shared object file: No such file or directory Which was caused by broken X11 maintainer scripts at this time. When this first happened, I checked on packages.d.o and IIRC could not find a package on arm that contained that file. Now I can. So I suspect that it will work now. Should I just bump up my xlibs-dev build dep to the latest version and upload the package to be built again? No. Ask the arm buildd admins to requeue it. cu andreas
Re: checkroot.sh script
On 2004-03-28 Brian T Glenn [EMAIL PROTECTED] wrote: Before attempting to post a bug to Debian directly, I wanted to ask the people here if perhaps I am doing something incorrectly. I installed Debian sarge on the sparc64 arch, then went out and grabbed the 2.6.4 kernel source from kernel.org and built a new kernel. After trying to boot this kernel, the checkroot.sh script would consistently fail to remount / into read-only during this section: [...] Isn't this #239735? I think you have chosen the wrong list BTW, -mentors about learning to package it is no user support list. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: checkroot.sh script
On 2004-03-28 Brian T Glenn [EMAIL PROTECTED] wrote: Before attempting to post a bug to Debian directly, I wanted to ask the people here if perhaps I am doing something incorrectly. I installed Debian sarge on the sparc64 arch, then went out and grabbed the 2.6.4 kernel source from kernel.org and built a new kernel. After trying to boot this kernel, the checkroot.sh script would consistently fail to remount / into read-only during this section: [...] Isn't this #239735? I think you have chosen the wrong list BTW, -mentors about learning to package it is no user support list. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: WNPP bugs are not closed with upload
On 2004-03-26 Bartosz Fenski aka fEnIo [EMAIL PROTECTED] wrote: On Fri, Mar 26, 2004 at 12:03:15AM +0100, Carlos Perelló Marín wrote: Hi, my packages (ttf-isabella and alleyoop) are now available with unstable but the wnpp bug reports are still open. The bug reports are: #190317, #208916 and #207153 [...] Am I doing something wrong? I suppose you've made similar mistake to mine ;) Consider one thing: the only one parsed changelog entry is LAST ONE. If you prepared dozen version on your box, and each of them closes some bugs, only last changelog will actually be closed. [...] Per default the changes-file will only contain the last changelog of the last revision and will only close the bugs these bugs. You can change this with the -v option of dpkg-buildpackage. cu andreas
Re: dpkg-shlibdeps and libtool interaction
On 2004-03-26 martin f krafft [EMAIL PROTECTED] wrote: I am packaging libhid for Debian, which I wrote and prepared with libtool. Next to the library, the libhid0 package also includes a binary /usr/bin/libhid-config, which is linked against libhid0. When I make the Debian package, dh_shlibdeps gives the following warning: dh_shlibdeps -v dpkg-shlibdeps -Tdebian/libhid0.substvars debian/libhid0/usr/bin/libhid-config debian/libhid0/usr/lib/libhid.so.0.0.0 dpkg-shlibdeps: warning: could not find path for libhid.so.0 Obviously it can't find the library, as that library is currently being installed. Therefore: [...] Specify the correct -l option, i.e. something like dh_shlibdeps -v -l$(DEBIAN)/libhid0/usr/lib cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Should I recommend less if I use it in some scripts?
On 2004-03-22 Number Six [EMAIL PROTECTED] wrote: Some of the scripts I include with my package use less (as well as sed, tr, and grep). I know for a fact less is not installed by default. (Not sure about this others). Should every little ordinary thing like less be included in my Recommends? It's surely not germane to the package, but if it's not there, these little scripts will break. Adapt your scripts to confirm to policy 11.4 Editors and pagers. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: updating gdal library
On Mon, Mar 22, 2004 at 04:39:19PM +0100, Silke Reimer wrote: First I don't know how to fill the Depends for libgdal1-dev correctly. http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN75 explains the following: The -dev package should depend on all -dev packages for libraries that the library package depends upon, with the specific (so)version that the library package is linked against. This includes libc-dev. [...] This is bogus. The Depends should list the -dev packages that are needed for linking against your library (basically if libgal's header files include header files from other packages you should depend on this packages) cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Development packages.
On Mon, Mar 22, 2004 at 04:26:49PM +0100, Frank Küster wrote: Stephen Frost [EMAIL PROTECTED] schrieb: * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: On Sunday 21 March 2004 20.49, Stephen Frost wrote: .la files shouldn't be included in anything, they're just plain broken. 940 .la files on my system. Report bugs? [...] So either you don't mean that absolutely, or three's a few buggy packages out there. It's the glorious brokenness that is libtool. Basically, libtool needs to be fixed to not use the stupid things on systems that don't need them (like, oh, all of Debian). I don't know that filing bug reports would be useful until libtool is fixed because I imagine most maintainers who havn't actually run into the problems caused by .la files will just whine libtool did it. Yes, it did :-|. Could you point me to a documentation where I could read about these problems, and under what weird circumstances it will be a bug nevertheless if I don't install the *la files? [...] Hello, Basically the essence of the mess is #191425. If libfoo links against libbar and application blah makes use of libfoo (but does not use libbar) libtool will link the application against both libraries. This is not necessary for dynamic linking on reasonably unbroken platforms like GNU/Linux and complicates matters a lot: Dependencies are immensly bloated. For example check the dependencies of ghex (a simple Hex-Editor). It links directly against libtasn1-0 although it sure as hell does not parse ASN certificates. This can make make migration to testing a lot more painful. Now, if libfoo is replaced by libfoo2 and libbar is rebuilt against it the application blah sudenly links against both libfoo2 and libfoo. If these libraries do not use versioned symbols you'll get symbol clashes and segmentation faults. Now libtool gets this information (libfoo links against libbar) from the .la file, if you do not ship it, libtool cannot be that stupid and link against all these dependcies. - The price you pay for that is that _static_ linking does require following these dependency chains. Personally I think the payoff is ok, due to dlopen in glibc (NSS, iconv) static linking is unreliable anyway. If you want to see a nice example for the results of this bug, check e.g. apt-cache showpkg libtasn1-0 and ask yourself how many of these packages really should link against it. cu andreas PS: Be aware that I do not maintain a library myself, I have just done one or two NMUs and have followed discussions on the issue. PPS: I gather that pkgconfig is also broken. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Development packages.
On 2004-03-22 Roger Leigh [EMAIL PROTECTED] wrote: Andreas Metzler [EMAIL PROTECTED] writes: On Mon, Mar 22, 2004 at 04:26:49PM +0100, Frank Küster wrote: [libtool brokenness] Yes, it did :-|. Could you point me to a documentation where I could read about these problems, and under what weird circumstances it will be a bug nevertheless if I don't install the *la files? [...] Basically the essence of the mess is #191425. If libfoo links against libbar and application blah makes use of libfoo (but does not use libbar) libtool will link the application against both libraries. How is this different to pkg-config: [...] See Steve's and Scott's answers. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should I recommend less if I use it in some scripts?
On 2004-03-22 Number Six [EMAIL PROTECTED] wrote: Some of the scripts I include with my package use less (as well as sed, tr, and grep). I know for a fact less is not installed by default. (Not sure about this others). Should every little ordinary thing like less be included in my Recommends? It's surely not germane to the package, but if it's not there, these little scripts will break. Adapt your scripts to confirm to policy 11.4 Editors and pagers. cu andreas
Re: updating gdal library
On Mon, Mar 22, 2004 at 04:39:19PM +0100, Silke Reimer wrote: First I don't know how to fill the Depends for libgdal1-dev correctly. http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN75 explains the following: The -dev package should depend on all -dev packages for libraries that the library package depends upon, with the specific (so)version that the library package is linked against. This includes libc-dev. [...] This is bogus. The Depends should list the -dev packages that are needed for linking against your library (basically if libgal's header files include header files from other packages you should depend on this packages) cu andreas
Re: Development packages.
On Mon, Mar 22, 2004 at 04:26:49PM +0100, Frank Küster wrote: Stephen Frost [EMAIL PROTECTED] schrieb: * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: On Sunday 21 March 2004 20.49, Stephen Frost wrote: .la files shouldn't be included in anything, they're just plain broken. 940 .la files on my system. Report bugs? [...] So either you don't mean that absolutely, or three's a few buggy packages out there. It's the glorious brokenness that is libtool. Basically, libtool needs to be fixed to not use the stupid things on systems that don't need them (like, oh, all of Debian). I don't know that filing bug reports would be useful until libtool is fixed because I imagine most maintainers who havn't actually run into the problems caused by .la files will just whine libtool did it. Yes, it did :-|. Could you point me to a documentation where I could read about these problems, and under what weird circumstances it will be a bug nevertheless if I don't install the *la files? [...] Hello, Basically the essence of the mess is #191425. If libfoo links against libbar and application blah makes use of libfoo (but does not use libbar) libtool will link the application against both libraries. This is not necessary for dynamic linking on reasonably unbroken platforms like GNU/Linux and complicates matters a lot: Dependencies are immensly bloated. For example check the dependencies of ghex (a simple Hex-Editor). It links directly against libtasn1-0 although it sure as hell does not parse ASN certificates. This can make make migration to testing a lot more painful. Now, if libfoo is replaced by libfoo2 and libbar is rebuilt against it the application blah sudenly links against both libfoo2 and libfoo. If these libraries do not use versioned symbols you'll get symbol clashes and segmentation faults. Now libtool gets this information (libfoo links against libbar) from the .la file, if you do not ship it, libtool cannot be that stupid and link against all these dependcies. - The price you pay for that is that _static_ linking does require following these dependency chains. Personally I think the payoff is ok, due to dlopen in glibc (NSS, iconv) static linking is unreliable anyway. If you want to see a nice example for the results of this bug, check e.g. apt-cache showpkg libtasn1-0 and ask yourself how many of these packages really should link against it. cu andreas PS: Be aware that I do not maintain a library myself, I have just done one or two NMUs and have followed discussions on the issue. PPS: I gather that pkgconfig is also broken.
Re: Development packages.
On Mon, Mar 22, 2004 at 06:28:43PM +0100, Frank Küster wrote: Andreas Metzler [EMAIL PROTECTED] wrote: [...] Personally I think the payoff is ok, due to dlopen in glibc (NSS, iconv) static linking is unreliable anyway. This I don't understand. What is the relation between dlopen calls and static linking? For sure a statically linked binary won't use dlopen, It does. and if it's a different one, what's the problem? The problem is that dlopen()ed stuffed is not linked and therefore not pulled in by static linking. - If you link static against glibc 2.2 and execute the program on a system using glibc 2.3 the NSS/iconv modules from the new version are used which might be incompatible. See http://bugs.debian.org/193310 The comment at the top of the mail is too broad, static linking against chosen libraries whih don't use dlopen works. cu andreas
Re: Development packages.
On 2004-03-22 Roger Leigh [EMAIL PROTECTED] wrote: Andreas Metzler [EMAIL PROTECTED] writes: On Mon, Mar 22, 2004 at 04:26:49PM +0100, Frank Küster wrote: [libtool brokenness] Yes, it did :-|. Could you point me to a documentation where I could read about these problems, and under what weird circumstances it will be a bug nevertheless if I don't install the *la files? [...] Basically the essence of the mess is #191425. If libfoo links against libbar and application blah makes use of libfoo (but does not use libbar) libtool will link the application against both libraries. How is this different to pkg-config: [...] See Steve's and Scott's answers. cu andreas
Re: .diff.gz became as big as upstream source
On 2004-03-21 GCS [EMAIL PROTECTED] wrote: I have a small package, which generates configure, Makefile[.in] at every compilation. Why? Do you patch configure.(in)? See /usr/share/doc/autotools-dev/README.Debian.gz, especially the part after »fix the timestamp skews using a proper chain of touch«. As upstream already contained these files, when I build my package, and these files are regenerated but different versions of auto[conf|make], I get a big .diff.gz (as big as upstream source). Policy says I should not tamper with upstream source except where really necessary; but am I allowed to delete these files from upstream, generate them from debian/rules and clean again afterwards? It would make the .diff.gz very small, without any differences in .deb . Yes ,this is allowed. But you'll need to adapt your build-dependencies, you'll prbably need autoconf and automake. cu andreas
Re: [Solved] Re: Bengali wordlist for aspell
On 2004-03-20 Soumyadip Modak [EMAIL PROTECTED] wrote: On Sat, 2004-03-20 at 03:06, Brian Nelson wrote: The configure script that comes with the aspell dicts is homebrew (not created by autoconf), and thus does not accept most of those options. Edit those out of the debian/rules file. Also, you might want to check out some of the aspell-* packages in the archive for reference. Thanks to all who have written in. It seems that the configure script lacked the ability to handle any options passed to it. :( I had to remove the options from the debian/rules script, and change make distclean to make clean. The package now builds correctly. Have i broken any packaging rule by the above steps? [...] No. dh_make's default values are simply tailored for packages using GNU autoconf (and automake. - You packages does not, therefore you have to make changes. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Solved] Re: Bengali wordlist for aspell
On 2004-03-20 Soumyadip Modak [EMAIL PROTECTED] wrote: On Sat, 2004-03-20 at 03:06, Brian Nelson wrote: The configure script that comes with the aspell dicts is homebrew (not created by autoconf), and thus does not accept most of those options. Edit those out of the debian/rules file. Also, you might want to check out some of the aspell-* packages in the archive for reference. Thanks to all who have written in. It seems that the configure script lacked the ability to handle any options passed to it. :( I had to remove the options from the debian/rules script, and change make distclean to make clean. The package now builds correctly. Have i broken any packaging rule by the above steps? [...] No. dh_make's default values are simply tailored for packages using GNU autoconf (and automake. - You packages does not, therefore you have to make changes. cu andreas
Re: Need a sponsor to upload #234303
On 2004-03-18 Everton da Silva Marques [EMAIL PROTECTED] wrote: --- Matthew Palmer [EMAIL PROTECTED] wrote: I'd start hitting up the maintainers (and upstreams) of packages which *could* use SRV records, regardless of whether they currently do or not, and suggest it to them. I plan to push that kind of SRV adoption. I have actually sent a ruli-based SRV-lookup patch for Exim, but then its author added SRV support throught its own internal, rather extensive, DNS facilities. I believe one may see SRV support in Exim 4.31. Other packages will come. [...] Judging from the latest snapshot Exim 4.31 *will* support SRV +Everton da Silva Marques Suggested patch for SRV handling [...] + 5. The dnslookup router now supports the use of SRV records (see RFC 2782) in +addition to MX and address records. The support is disabled by default. To +enable SRV support, you need to set the check_srv option to the name of +the service required. For example, + + check_srv = smtp cu andreas PS: Everton, what mailer are using? Webmail? It formats messages in an readable way. -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Versioning question
On 2004-03-18 Stephen Gran [EMAIL PROTECTED] wrote: This one time, at band camp, Colin Watson said: There's ~, but you can't use that until sarge has been released. In the absence of that, something like 0.69-really-0.70-rc-1 (or what you suggest) is a common workaround. It's not too bad to change the tarball name. OK, if it's not a big deal to change the tarball name, then I will just go ahead and do that. I was thinking it made for more complication than it apparently does - the thing I'm worried about is uploading when 0.70 comes out, and I am uploading a new tarball. If both are named 0.70 (wuith only the revision changing from -0rc1 to -1), I thought the pool managing scripts would complain. I think you are misparsing Colin. The pool managing scripts will definitely complain if you upload a new foish-bar_0.70.orig.tar.gz. You /cannot/ replace a foish-bar_0.70.orig.tar.gz in the archive without changing the name. You need to do this: wget ftp://upsteam.org/foish-bar-0.70-rc-1.tar.gz mv foish-bar-0.70-rc-1.tar.gz foish-bar_0.69-really-0.70-rc-1.orig.tar.gz tar xzf foish-bar_0.69-really-0.70-rc-1.orig.tar.gz cd foish-bar-0.70-rc-1 # The directory name in the tarball does not matter at all, you can # still use the original tarball generate debian/ etc. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need a sponsor to upload #234303
On 2004-03-18 Everton da Silva Marques [EMAIL PROTECTED] wrote: --- Matthew Palmer [EMAIL PROTECTED] wrote: I'd start hitting up the maintainers (and upstreams) of packages which *could* use SRV records, regardless of whether they currently do or not, and suggest it to them. I plan to push that kind of SRV adoption. I have actually sent a ruli-based SRV-lookup patch for Exim, but then its author added SRV support throught its own internal, rather extensive, DNS facilities. I believe one may see SRV support in Exim 4.31. Other packages will come. [...] Judging from the latest snapshot Exim 4.31 *will* support SRV +Everton da Silva Marques Suggested patch for SRV handling [...] + 5. The dnslookup router now supports the use of SRV records (see RFC 2782) in +addition to MX and address records. The support is disabled by default. To +enable SRV support, you need to set the check_srv option to the name of +the service required. For example, + + check_srv = smtp cu andreas PS: Everton, what mailer are using? Webmail? It formats messages in an readable way. -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Versioning question
On 2004-03-18 Stephen Gran [EMAIL PROTECTED] wrote: This one time, at band camp, Colin Watson said: There's ~, but you can't use that until sarge has been released. In the absence of that, something like 0.69-really-0.70-rc-1 (or what you suggest) is a common workaround. It's not too bad to change the tarball name. OK, if it's not a big deal to change the tarball name, then I will just go ahead and do that. I was thinking it made for more complication than it apparently does - the thing I'm worried about is uploading when 0.70 comes out, and I am uploading a new tarball. If both are named 0.70 (wuith only the revision changing from -0rc1 to -1), I thought the pool managing scripts would complain. I think you are misparsing Colin. The pool managing scripts will definitely complain if you upload a new foish-bar_0.70.orig.tar.gz. You /cannot/ replace a foish-bar_0.70.orig.tar.gz in the archive without changing the name. You need to do this: wget ftp://upsteam.org/foish-bar-0.70-rc-1.tar.gz mv foish-bar-0.70-rc-1.tar.gz foish-bar_0.69-really-0.70-rc-1.orig.tar.gz tar xzf foish-bar_0.69-really-0.70-rc-1.orig.tar.gz cd foish-bar-0.70-rc-1 # The directory name in the tarball does not matter at all, you can # still use the original tarball generate debian/ etc. cu andreas
Re: dh_make generates Stds. version 3.6.0 but latest is 3.6.1
On 2004-03-16 Number Six [EMAIL PROTECTED] wrote: If dh_make generates debian/control at Standards-Version: 3.6.0, and the latest Standards-Version: is 3.6.1, how can I verify my project actually meets the correct standards (if I just bump the number)? Can a tool do it? No. Check policy's changelog and /usr/share/doc/debian-policy/upgrading-checklist.* cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_make generates Stds. version 3.6.0 but latest is 3.6.1
On 2004-03-16 Number Six [EMAIL PROTECTED] wrote: If dh_make generates debian/control at Standards-Version: 3.6.0, and the latest Standards-Version: is 3.6.1, how can I verify my project actually meets the correct standards (if I just bump the number)? Can a tool do it? No. Check policy's changelog and /usr/share/doc/debian-policy/upgrading-checklist.* cu andreas
Re: silly questions about devel machines
On 2004-03-13 Magosányi Árpád [EMAIL PROTECTED] wrote: I am trying to check if I could fix an arch-dependent bug, so I have to compile my package on an arm, powerpc or s390. Picked bruckner from the list, done a dchroot sid. Now I would need tla to get the source (I could work around it), and several build dependencies. Is it true that I have to bother the admin to install the packages for me, or there is a way to do it for myself? [...] Yes, you have the ask the admin/debian-admin. For testing-purposes you can install with dpkg -x in ~/deb and use -I~/deb/usr/include -L~/deb/usr/lib but I gather you already knew that (I could work around it). cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: silly questions about devel machines
On 2004-03-13 Magosányi Árpád [EMAIL PROTECTED] wrote: I am trying to check if I could fix an arch-dependent bug, so I have to compile my package on an arm, powerpc or s390. Picked bruckner from the list, done a dchroot sid. Now I would need tla to get the source (I could work around it), and several build dependencies. Is it true that I have to bother the admin to install the packages for me, or there is a way to do it for myself? [...] Yes, you have the ask the admin/debian-admin. For testing-purposes you can install with dpkg -x in ~/deb and use -I~/deb/usr/include -L~/deb/usr/lib but I gather you already knew that (I could work around it). cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Packaging for Sid on the Debian machines?
On 2004-03-10 Jörgen Hägg [EMAIL PROTECTED] wrote: I'm trying to compile and pack on different architectures, but after my first attempt I realized that all Debian hosts are running Woody, not Sid. Question: how and where do I build for Sid? Has '+chroots' anything to do with it? (Like bruckner: woody Debian GNU/Linux (+chroots)) [...] Login normally and execute dchroot sid. cu andreas
Re: RFS: truncate (now it's free, for real!)
On 2004-03-09 Luca Pasquali [EMAIL PROTECTED] wrote: [...] and now a strange, dumb-sounding request: if you mentors have better/more useful packaging exercises to suggest me, I'll welcome the advices, it may be a strange request but I'm not a programmer, I mainly use console to do network administration, I'm lost in WNPP search something to package that will of use for myself without great results. If you are trying to be helpful take the list of packages you actually have installed and use and check their bug-reports, you have good chances of finding one or the other which is in need of attention, be it patches, or just testing and verifying bug-reports. This will not teach you how to package something from scratch (but imho this is not too difficult for the normal autotool thingy anyways). Co-maintainership or adoption can follow. Is this a bad approach to debian maintainig? I mean dealing with packages you don't use. [...] There are two problems with that: - Motivation. I am much more inclined to invest time and effort in maintaining a package I really use because I immediately benefit from it and suffer from its deficencies. - Quality of the result. If you do not use the package regularily you might not know how to test it and won't stumble upon well hidden bugs yourself. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging for Sid on the Debian machines?
On 2004-03-10 Jörgen Hägg [EMAIL PROTECTED] wrote: I'm trying to compile and pack on different architectures, but after my first attempt I realized that all Debian hosts are running Woody, not Sid. Question: how and where do I build for Sid? Has '+chroots' anything to do with it? (Like bruckner: woody Debian GNU/Linux (+chroots)) [...] Login normally and execute dchroot sid. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: truncate (now it's free, for real!)
On 2004-03-09 Luca Pasquali [EMAIL PROTECTED] wrote: [...] and now a strange, dumb-sounding request: if you mentors have better/more useful packaging exercises to suggest me, I'll welcome the advices, it may be a strange request but I'm not a programmer, I mainly use console to do network administration, I'm lost in WNPP search something to package that will of use for myself without great results. If you are trying to be helpful take the list of packages you actually have installed and use and check their bug-reports, you have good chances of finding one or the other which is in need of attention, be it patches, or just testing and verifying bug-reports. This will not teach you how to package something from scratch (but imho this is not too difficult for the normal autotool thingy anyways). Co-maintainership or adoption can follow. Is this a bad approach to debian maintainig? I mean dealing with packages you don't use. [...] There are two problems with that: - Motivation. I am much more inclined to invest time and effort in maintaining a package I really use because I immediately benefit from it and suffer from its deficencies. - Quality of the result. If you do not use the package regularily you might not know how to test it and won't stumble upon well hidden bugs yourself. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Renaming a package, proper values for replaces/conflicts?
Hello,
I know this is a standard szenario, but the natural solution conflicts
with suggestions in policy.
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling (4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it. (Testing shows that this seems to work, apt-get
dselect-upgrade and apt-get dist-upgrade will install pcregrep.)
However policy 7.3 says:
| 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.
My gut feeling tells me to ignore this because I _need_ to conflict with
pgrep(4.5) and because high-level packaging managment tools like apt
or dselect handle this quite fine.
cu andreas
[1] Actually it is any version from 3.3-1 up to the version currently
available, 4.3-4, but I've no idea how to express a range in
replaces/conflicts except by listing all of them, there is no AND.
--
See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in Snow Crash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package, proper values for replaces/conflicts?
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling (4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it.
I think you just need Replaces: pgrep ( 4.5), not Conflicts: at all.
It's a straightforward file conflict. Conflicts: makes the upgrade
painful because it adds extra complexity to the unpack order: this is
why policy recommends against it.
So it is no bug that this file-conflict
| X:/ dpkg -i /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
| dpkg - warning: downgrading pgrep from 4.5-0.1 to 4.3-0.0.1.
| (Reading database ... 9669 files and directories currently installed.)
| Preparing to replace pgrep 4.5-0.1 (using
| .../pgrep_4.3-0.0.1_i386.deb) ...
| Unpacking replacement pgrep ...
| dpkg: error processing /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
| (--install):
| trying to overwrite `/usr/bin/pcregrep', which is also in package
| pcregrep
| Errors were encountered while processing:
| /apt-zusatz/pgrep_4.3-0.0.1_i386.deb
is not expressed in Conflicts: because basically we only care about
upgrading?
cu andreas
--
See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in Snow Crash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Renaming a package, proper values for replaces/conflicts?
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 01:17:46PM +0100, Andreas Metzler wrote:
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling (4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it.
I think you just need Replaces: pgrep ( 4.5), not Conflicts: at all.
It's a straightforward file conflict. Conflicts: makes the upgrade
painful because it adds extra complexity to the unpack order: this is
why policy recommends against it.
Actually, Replaces:/Conflicts: has the special meaning of this package
completely replaces that other package, which I guess is what you want.
Nothing depends on pgrep, so is the dummy package really needed?
[...]
Yes. If you have pgrep installed and there is no dummy package neither
apt-get (dist-)upgrade nor dselect will install pcregrep. The
outdated package will be kept indefinitely.
cu andreas
--
See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in Snow Crash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Renaming a package, proper values for replaces/conflicts?
Hello,
I know this is a standard szenario, but the natural solution conflicts
with suggestions in policy.
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling (4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it. (Testing shows that this seems to work, apt-get
dselect-upgrade and apt-get dist-upgrade will install pcregrep.)
However policy 7.3 says:
| 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.
My gut feeling tells me to ignore this because I _need_ to conflict with
pgrep(4.5) and because high-level packaging managment tools like apt
or dselect handle this quite fine.
cu andreas
[1] Actually it is any version from 3.3-1 up to the version currently
available, 4.3-4, but I've no idea how to express a range in
replaces/conflicts except by listing all of them, there is no AND.
--
See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in Snow Crash
Re: Renaming a package, proper values for replaces/conflicts?
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 01:17:46PM +0100, Andreas Metzler wrote:
On 2004-03-07 Colin Watson [EMAIL PROTECTED] wrote:
On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
to provide seamless upgrades I'd introduce a dummy package pgrep
depending on pcregrep, however replaces/conflicts gives me a headache.
Package: pcregrep
Architecture: any
Depends: ${shlibs:Depends}
Conflicts: pgrep(4.5)
Replaces: pgrep(4.5)
Package: pgrep
Section: oldlibs
Architecture: all
Depends: pcregrep
This looks correct, doesn't it? Any[1] version of pgrep fulfilling
(4.5)
is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
must conflict with it.
I think you just need Replaces: pgrep ( 4.5), not Conflicts: at all.
It's a straightforward file conflict. Conflicts: makes the upgrade
painful because it adds extra complexity to the unpack order: this is
why policy recommends against it.
Actually, Replaces:/Conflicts: has the special meaning of this package
completely replaces that other package, which I guess is what you want.
Nothing depends on pgrep, so is the dummy package really needed?
[...]
Yes. If you have pgrep installed and there is no dummy package neither
apt-get (dist-)upgrade nor dselect will install pcregrep. The
outdated package will be kept indefinitely.
cu andreas
--
See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in Snow Crash
Re: How to access cvs.debian.org with ssh/rsa keys?
On 2004-03-06 Frank Küster [EMAIL PROTECTED] wrote: I've recently been given write access to the tetex directories on cvs.debian.org, but it seems when I login, the password is blown over the net in plaintext. I have put my rsa key into the LDAP system, and can login e.g. into gluck with ssh. Since the key is protected by a password, I'm asked this password, but then the question asked is: Enter passphrase for key '/home/frank/.ssh/id_rsa': I have set CVS_RSH=ssh, and I try to access the cvs with cvs -d :pserver:[EMAIL PROTECTED]:/cvs/tetex login [...] Yes cvs pserver is using with plaintext authentication, if you were using ssh it would read :ext:[EMAIL PROTECTED]:/cvs/tetex (ext instead of pserver). cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to access cvs.debian.org with ssh/rsa keys?
On 2004-03-06 Frank Küster [EMAIL PROTECTED] wrote: I've recently been given write access to the tetex directories on cvs.debian.org, but it seems when I login, the password is blown over the net in plaintext. I have put my rsa key into the LDAP system, and can login e.g. into gluck with ssh. Since the key is protected by a password, I'm asked this password, but then the question asked is: Enter passphrase for key '/home/frank/.ssh/id_rsa': I have set CVS_RSH=ssh, and I try to access the cvs with cvs -d :pserver:[EMAIL PROTECTED]:/cvs/tetex login [...] Yes cvs pserver is using with plaintext authentication, if you were using ssh it would read :ext:[EMAIL PROTECTED]:/cvs/tetex (ext instead of pserver). cu andreas
Re: scripts in /usr/share/$package?
On Fri, Mar 05, 2004 at 04:24:01PM +0100, Frank Küster wrote: although I've read the policy again, I am not sure whether it is allowed to store scripts in /usr/share/$package? In particular, scripts that are only meant to be called by postinst (or prerm), never by a user. They could go to /usr/lib/$package, but that would mean creating an extra directory. Therefore I'd prefer to keep them in /usr/share/$package which exists anyway. Is this o.k.? *IMHO* If they are arch-independent (and scripts usually are) /usr/share/$package is correct and /usr/lib/$package would be a bug. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scripts in /usr/share/$package?
On Fri, Mar 05, 2004 at 04:24:01PM +0100, Frank Küster wrote: although I've read the policy again, I am not sure whether it is allowed to store scripts in /usr/share/$package? In particular, scripts that are only meant to be called by postinst (or prerm), never by a user. They could go to /usr/lib/$package, but that would mean creating an extra directory. Therefore I'd prefer to keep them in /usr/share/$package which exists anyway. Is this o.k.? *IMHO* If they are arch-independent (and scripts usually are) /usr/share/$package is correct and /usr/lib/$package would be a bug. cu andreas
Re: How do I compile for different architectures?
On 2004-03-04 Jörgen Hägg [EMAIL PROTECTED] wrote: I'm maintaining a package in non-free, which means that it will probably never be compiled automatically (lowest priority). So I need to do that myself. And I can find the available compile hosts on http://db.debian.org/machines.cgi. I usually builds my package using 'dpkg-buildpackage -rfakeroot' and that works well. But now I need to do at least the compile on a different machine. I would still like to include all architecture specific deb-files in the changes-file I got for my source and i386 build. And I do not want to sign the package on another machine for obvious reasons. :-) [...] debsign. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do I compile for different architectures?
On 2004-03-04 Jörgen Hägg [EMAIL PROTECTED] wrote: I'm maintaining a package in non-free, which means that it will probably never be compiled automatically (lowest priority). So I need to do that myself. And I can find the available compile hosts on http://db.debian.org/machines.cgi. I usually builds my package using 'dpkg-buildpackage -rfakeroot' and that works well. But now I need to do at least the compile on a different machine. I would still like to include all architecture specific deb-files in the changes-file I got for my source and i386 build. And I do not want to sign the package on another machine for obvious reasons. :-) [...] debsign. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: RFS: New version of cvs-autoreleasedeb
On 2004-02-20 Eike zyro Sauer [EMAIL PROTECTED] wrote: Raphael Goulais schrieb: - Why do you remove /var/log/cvs-autoreleasedeb.log at postrm, since the log files are in /var/log/cvs-autoreleasedeb/ ? Also, I don't think you should remove the log files anyway, even on a purge. Is this consensus? No, it is not. I thought I'd get rid of everything a package made when purging. I would not go that far (Reductio ad absurdum: Removing /var/mail/* when uninstalling the MTA) but logfiles should indeed be deleted on purge, see policy 10.8. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: New version of cvs-autoreleasedeb
On 2004-02-20 Eike zyro Sauer [EMAIL PROTECTED] wrote: Raphael Goulais schrieb: - Why do you remove /var/log/cvs-autoreleasedeb.log at postrm, since the log files are in /var/log/cvs-autoreleasedeb/ ? Also, I don't think you should remove the log files anyway, even on a purge. Is this consensus? No, it is not. I thought I'd get rid of everything a package made when purging. I would not go that far (Reductio ad absurdum: Removing /var/mail/* when uninstalling the MTA) but logfiles should indeed be deleted on purge, see policy 10.8. cu andreas
Re: data files in /etc?
On 2004-02-12 Magosányi Árpád [EMAIL PROTECTED] wrote: There are some files in /etc which are actually data files representing the state of the system. Like /etc/mtab, /etc/network/ifstate, or /etc/lvmconf/* (it is not even a text file). These files are written by programs in occasions one cannot with good heart call configuration. Isn't it against the policy? [...] Yes, but. ;-) There for two reasons for files like mtab: * history. * These files need to be available early the boot process, and therefore reside on the root file-system. There has been a _big_ discussion about this -devel in 2003, search for readonly root file-system. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: data files in /etc?
On 2004-02-13 Bernhard R. Link [EMAIL PROTECTED] wrote: * Magosányi Árpád [EMAIL PROTECTED] [040212 22:52]: -if one wants to make the boot process unable to modify configuration, they will also be stumbled upon. (And given the fact that mount actually deletes and recreates /etc/mtab, the challenge is... challenging.) At least some time ago mount was able to deal with /etc/mtab beeing a link to /proc/mounts. (As long as no loop-devices where involved). [...] Besides breaking -o loop this also breaks the user option, the can user can mount the filesystem but is not allowed to unmount it because /proc/mounts does not hold the name of the user who mounted the file system. cu andreas
Re: problem with files in /etc/dir.d
On 2004-02-12 Filippo Rusconi [EMAIL PROTECTED] wrote: [...] I effectively get the said file in debian/polyxmassdata/etc/polyxmass.d/polyxmassdata.conf telling me that the make install target has worked ok. However, I also noticed that this file is referenced here: debian/polyxmassdata/DEBIAN/conffiles Debhelper in =v3 mode will automaticaly flag all files in /etc as conffiles. although I never had a conffiles for this package, because the polyxmassdata.conf SHOULD be overwritten upon a new install. Then it is misplaced in /etc (which is a release-critical bug) and should go to /usr/share/. The result of all this is that the polyxmassdata.conf seems to be included in the deb file (as seen using dpkg -X file.deb /tmp), but does not get installed (presumably because, indeed, the debian packaging system does think it is a conffile). dpkg-conffile handling preserves file-removal. So my question ? How can I have a configuration file installed somewhere in /etc without having the debian packaging system think it is a conffile ? [...] Please read policy 10.7 and check whether this indeed is a configuration file as specified by policy (Typically, configuration files are intended to be modified by the system administrator) which requires you to fulfill 10.7.3, local changes must be preserved. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: problem with files in /etc/dir.d
On 2004-02-12 Filippo Rusconi [EMAIL PROTECTED] wrote: [...] I effectively get the said file in debian/polyxmassdata/etc/polyxmass.d/polyxmassdata.conf telling me that the make install target has worked ok. However, I also noticed that this file is referenced here: debian/polyxmassdata/DEBIAN/conffiles Debhelper in =v3 mode will automaticaly flag all files in /etc as conffiles. although I never had a conffiles for this package, because the polyxmassdata.conf SHOULD be overwritten upon a new install. Then it is misplaced in /etc (which is a release-critical bug) and should go to /usr/share/. The result of all this is that the polyxmassdata.conf seems to be included in the deb file (as seen using dpkg -X file.deb /tmp), but does not get installed (presumably because, indeed, the debian packaging system does think it is a conffile). dpkg-conffile handling preserves file-removal. So my question ? How can I have a configuration file installed somewhere in /etc without having the debian packaging system think it is a conffile ? [...] Please read policy 10.7 and check whether this indeed is a configuration file as specified by policy (Typically, configuration files are intended to be modified by the system administrator) which requires you to fulfill 10.7.3, local changes must be preserved. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help packaging Synaptics TouchPad driver
On Wed, Feb 04, 2004 at 03:19:04PM +0100, Mattia Dongili wrote: [I'm sending this message here as it seems that debian-x wasn't the most appropriate place] xfree86-driver-synaptics is an xserver-xfree86 driver that supports special features of synaptics touchpad devices (a pointing device). [...] W: xfree86-driver-synaptics; Shared binary object /usr/X11R6/lib/modules/input/synaptics_drv.o has no dependancy information. The binary object listed above is a shared object, but does not report that it depends on any other shared libraries. [...] I think that is a false positive, as this is not a shared library, but a plugin, i.e. it is subject to this part of policy: | Shared object files (often .so files) that are not public libraries, | that is, they are not meant to be linked to by third party executables | (binaries of other packages), should be installed in subdirectories of | the /usr/lib directory. Such files are exempt from the rules that | govern ordinary shared libraries, except that they must not be | installed executable and should be stripped.[51] Checking the other files I have in my /usr/X11R6/lib/modules/input/ I think the other warning is a false positive, too, as the other driver modules are not stripped either. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help packaging Synaptics TouchPad driver
On Wed, Feb 04, 2004 at 03:19:04PM +0100, Mattia Dongili wrote: [I'm sending this message here as it seems that debian-x wasn't the most appropriate place] xfree86-driver-synaptics is an xserver-xfree86 driver that supports special features of synaptics touchpad devices (a pointing device). [...] W: xfree86-driver-synaptics; Shared binary object /usr/X11R6/lib/modules/input/synaptics_drv.o has no dependancy information. The binary object listed above is a shared object, but does not report that it depends on any other shared libraries. [...] I think that is a false positive, as this is not a shared library, but a plugin, i.e. it is subject to this part of policy: | Shared object files (often .so files) that are not public libraries, | that is, they are not meant to be linked to by third party executables | (binaries of other packages), should be installed in subdirectories of | the /usr/lib directory. Such files are exempt from the rules that | govern ordinary shared libraries, except that they must not be | installed executable and should be stripped.[51] Checking the other files I have in my /usr/X11R6/lib/modules/input/ I think the other warning is a false positive, too, as the other driver modules are not stripped either. cu andreas
Re: RFS: secure-delete
On Fri, Jan 30, 2004 at 02:15:18PM +0100, Robert Lemmen wrote: i am looking for a sponsor for secure-delete, it's a small package that quite some people might find usefull. from the control file: Description: tools to wipe files, free disk space, swap and memory Even if you overwrite a file 10+ times, it can still be recovered. This package conatins tools to securely wipe data from files, free disk space, swap and memory. [...] Seems to be similar to http://packages.debian.org/unstable/utils/wipe, can you describe their differences? cu andreas
Re: Multiple binary source per-package dh_ options?
On Fri, Jan 30, 2004 at 04:01:33PM -0500, Stephen Gran wrote: I am working on a multi-binary source, and what I want to do is pass different options to different packages. Is this possible? I see the -p option common to all debhelper programs, but how to do this? dh_installinit -p foo -n dh_installinit -a or something? Anybody doing anything like this? [...] Check for example the cdrtools package, which has separate targets in debian/rules for each binary und uses -p$@ binary-arch: build install cdrecord mkisofs and cdrecord: install dh_installdirs -p$@ dh_link -p$@ [...] dh_builddeb -p$@ cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: RFS: fig2sxd
On Thu, Jan 29, 2004 at 10:30:47AM +0100, Alexander Bürger wrote: Anyhow, besides the fact I don't like your changelog entry for -2.1 ( * Fix packaging problem - which? I know, but changelog is for documenting the actual changes) i'll see over this, the package otherwise is ok and uploaded. Please write better changelog entries next time, though... Shall I add a comment in the changelog when the next upstream version / debian revision is coming? Maybe something like: clarification for 0.10-2.1: the packaging problem of version 0.10-2 consisted solely of using a wrong fig2sxd-0.10.orig.tar.gz for creating .diff.gz, .dsc, .changes and .deb. Imho no, that is just too ugly. Either rectify history by shipping a corrected changelog entry of 0.10-2.1 in 0.10-3 or let it be. cu andreas
Re: RFS: fig2sxd
On Wed, Jan 28, 2004 at 06:45:41PM +0100, Alexander Bürger wrote: Argh. This is just plainly _wrong_. Read policy and developers reference about versioning what -2.1 actually means... I'm sorry, but I cannot find anything negative about 2.1 as debian revision. [...] says lt to me. Please tell me what is wrong, and where I can find that info. Debian revisions containing a dot are reserved for special purposes, 2.1 designates a source NMU, and 2.1.1 would be a binary-NMU of this source NMU 2.1. See http://www.at.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu http://www.at.debian.org/doc/developers-reference/ch-pkgs.en.html#s-porter-guidelines hth, cu andreas
Re: Delayed upload doesn't work (nor SSH to ftp-master)
On Mon, Jan 26, 2004 at 03:47:56PM +0200, Jarno Elonen wrote: Delayed uploading by ftp doesn't seem to work (missing directory) and ftp-master doesn't let me in with SSH/SCP (altough master, for example, does). Is this still an intentional restriction due to the server compromise or/and am I doing something wrong? Yes, no. When this came up on dd the suggested workaround was to use an at job on a open-debian machine. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ike-scan
On 30.12.03 12:12 Benoit Mortier wrote: Le Lundi 29 Décembre 2003 23:54, Jochen Friedrich a écrit : [...] - do you really need to link /usr/share/doc/ike-scan to /usr/doc? If not, you might remove the postinst and prerm scripts. thats what lintian wanted but linda not so i removed it You should upgrade you version of lintian. A not completely outdated version of lind (i.e. the version in sid or sarge) should not want the /usr/doc/ symlink but should issue a warning if it exists. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ike-scan
On 30.12.03 12:12 Benoit Mortier wrote: Le Lundi 29 Décembre 2003 23:54, Jochen Friedrich a écrit : [...] - do you really need to link /usr/share/doc/ike-scan to /usr/doc? If not, you might remove the postinst and prerm scripts. thats what lintian wanted but linda not so i removed it You should upgrade you version of lintian. A not completely outdated version of lind (i.e. the version in sid or sarge) should not want the /usr/doc/ symlink but should issue a warning if it exists. cu andreas
Re: Debian diff / Debian Policy (-dev)
On Sat, Dec 20, 2003 at 03:25:10PM +, n.v.t n.v.t wrote: I noticed that dh_make doesn't create diffs , why is that? dh_make does not creat debs or .dsc either Is there a way to (re)generate the the *.diff.gz ? Manually generate (by simple ranaming of the upstream sources) a correctly named foo_1.9.orig.tar.gz and dpkg-buildpackage will generate the corresponding diff. How to decide which cflags could be use best? Policy 10.1. Since dh_make created -O2 -Wall -g , I can see the point of -O2 -Wall , but what's the point of -g? You can run gdb or whatever on the binary in the build-tree (The debug infos won't end up in the package itself, because it will be stripped.) [...] The development files associated to a shared library need to be placed in a package called librarynamesoversion-dev, or if you prefer only to support one development version at a time, libraryname-dev. - What's the point of make -dev packages? Is it about the amount of space? No, that is nice side-effect. But you want to be able to install versions of the runtimelibrary with different sonames at the same time, that is only possible if they have no common files. If you did not split out -dev that would be impossible because both had at least one common file. - the symlink /usr/lib/libfoo.so. Where can I find a more verbose explanation about creating/(separating -dev files)? The library packaging guide. (referenced in developer's reference.) [...] The development package should contain a symlink for the associated shared library without a version number. For example, the libgdbm-dev package should include a symlink from /usr/lib/libgdbm.so to libgdbm.so.3.0.0. cu andreas
Re: Bootsplash packages.
On Wed, Dec 17, 2003 at 04:17:21PM -0500, Matthew A. Nicholson wrote: [..] I was planning on posting the packages on my website (although I don't have much bandwith), but I am having problems making a package that replaces sysv-rc. In order for bootsplash to operate correctly it needs to replace this package, but it is essential. [...] Can't you follow file-rc's example? cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bootsplash packages.
On Wed, Dec 17, 2003 at 04:17:21PM -0500, Matthew A. Nicholson wrote: [..] I was planning on posting the packages on my website (although I don't have much bandwith), but I am having problems making a package that replaces sysv-rc. In order for bootsplash to operate correctly it needs to replace this package, but it is essential. [...] Can't you follow file-rc's example? cu andreas
Conflicts: foo (=x =y) - how?
Hello, How do I conflict with a certain range of versions? The package is exim4 and I want to conflict with passwd =1:* but =1:4.0.3-8. - Both versions up to 2902-12 and later than 1:4.0.3-8 work for me and I do not want to conflict with them. Is there a nicer way than Conflicts: passwd (=1:4.0.3-1), passwd (=1:4.0.3-2), passwd (=1:4.0.3-3) ... On a sidenote I wonder whether I should actually bother with this. - The version in woody and the versions currently available in sid and sarge are ok, 1:4.0.3-9 was uploaded almost half a year ago (20 Aug 2003), is it necessary to carter for completely outdated sid and sarge? cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Conflicts: foo (=x =y) - how?
Hello, How do I conflict with a certain range of versions? The package is exim4 and I want to conflict with passwd =1:* but =1:4.0.3-8. - Both versions up to 2902-12 and later than 1:4.0.3-8 work for me and I do not want to conflict with them. Is there a nicer way than Conflicts: passwd (=1:4.0.3-1), passwd (=1:4.0.3-2), passwd (=1:4.0.3-3) ... On a sidenote I wonder whether I should actually bother with this. - The version in woody and the versions currently available in sid and sarge are ok, 1:4.0.3-9 was uploaded almost half a year ago (20 Aug 2003), is it necessary to carter for completely outdated sid and sarge? cu andreas
Re: Standards-Version
On Fri, Dec 12, 2003 at 08:10:47PM +0100, Florian Zaehringer wrote: On Thu, 11 Dec 2003 23:35:16 +0100 Frank Lichtenheld [EMAIL PROTECTED] wrote: On Thu, Dec 11, 2003 at 11:00:45PM +0100, Florian Zaehringer wrote: So I wonder how I can do that? Is there some ChangeLog for the Debian Policy? [...] install the debian-policy package (from unstable of course) and read /usr/share/doc/debian-policy/upgrading-checklist.txt.gz Thanks for the hint with unstable. Any idea where I can get that package? ftp://ftp.at.debian.org/debian/pool/main/d/debian-policy/ I'm running testing and I couldn't find a server with unstable... Eh. You don't need a server /running/ unstable just a regular Debian mirror. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Standards-Version
On Fri, Dec 12, 2003 at 08:10:47PM +0100, Florian Zaehringer wrote: On Thu, 11 Dec 2003 23:35:16 +0100 Frank Lichtenheld [EMAIL PROTECTED] wrote: On Thu, Dec 11, 2003 at 11:00:45PM +0100, Florian Zaehringer wrote: So I wonder how I can do that? Is there some ChangeLog for the Debian Policy? [...] install the debian-policy package (from unstable of course) and read /usr/share/doc/debian-policy/upgrading-checklist.txt.gz Thanks for the hint with unstable. Any idea where I can get that package? ftp://ftp.at.debian.org/debian/pool/main/d/debian-policy/ I'm running testing and I couldn't find a server with unstable... Eh. You don't need a server /running/ unstable just a regular Debian mirror. cu andreas
Packaging a perl-script
Hello, I'd like to see http://www.jetmore.org/john/code/swaks (Swiss Army Knife SMTP) in Debian. As the name suggests this is a wonderful tool to test SMTP servers (including starttls and lots of SMTP auth), for all of us who are tired of telnet foo 25. ;-) However this is only 40KB (with pod) and I think it might be rejected by ftp-master. - Are there any better possibilities? This is not very urgent, I have to clear up a copyright issue (it is GPL and uses libnet-ssleay-perl) anyway. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a perl-script
On Thu, Dec 11, 2003 at 01:46:58PM +0100, Joerg Jaspert wrote: Andreas Metzler [EMAIL PROTECTED] writes: However this is only 40KB (with pod) and I think it might be rejected by ftp-master. - Are there any better possibilities? Why should they reject it? Only 40kb is not a reason. (If its split out from another source into too small packages, then yes, a reject maybe ok. But not if the whole tool is 40kb). I see. Thanks. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Packaging a perl-script
Hello, I'd like to see http://www.jetmore.org/john/code/swaks (Swiss Army Knife SMTP) in Debian. As the name suggests this is a wonderful tool to test SMTP servers (including starttls and lots of SMTP auth), for all of us who are tired of telnet foo 25. ;-) However this is only 40KB (with pod) and I think it might be rejected by ftp-master. - Are there any better possibilities? This is not very urgent, I have to clear up a copyright issue (it is GPL and uses libnet-ssleay-perl) anyway. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: Packaging a perl-script
On Thu, Dec 11, 2003 at 01:46:58PM +0100, Joerg Jaspert wrote: Andreas Metzler [EMAIL PROTECTED] writes: However this is only 40KB (with pod) and I think it might be rejected by ftp-master. - Are there any better possibilities? Why should they reject it? Only 40kb is not a reason. (If its split out from another source into too small packages, then yes, a reject maybe ok. But not if the whole tool is 40kb). I see. Thanks. cu andreas
Re: RFS: msmtp, wmnetload, wmwifi
On Mon, Nov 24, 2003 at 06:26:15PM -0800, Jess Mahan wrote: I made a lot of changes to my packages (Thanks BTW for all the helpfull comments from everyone. Can you please check them out now, and see if I did it right this time? deb http://digitalssg.net/debian/ stable main non-US deb-src http://digitalssg.net/debian/ stable main non-US [EMAIL PROTECTED]:/tmp LANG=C wget http://digitalssg.net/debian/dists/stable/main/source/wmnetload_1.3.orig.tar.gz --09:16:20-- http://digitalssg.net/debian/dists/stable/main/source/wmnetload_1.3.orig.tar.gz = `wmnetload_1.3.orig.tar.gz' Resolving digitalssg.net... done. Connecting to digitalssg.net[209.134.35.180]:80... connected. HTTP request sent, awaiting response... 403 Forbidden 09:16:21 ERROR 403: Forbidden. But this was no big problem, I got the sources from upstream and the diff is readable. However I did not find wmnetload on msmtp.sourceforge.net as your debian/copyright files claimed. Crash: == [EMAIL PROTECTED]:/tmp/wmnetload-1.3/src gdb ./wmnetload [...] (gdb) run -b Starting program: /tmp/wmnetload-1.3/src/wmnetload -b Program received signal SIGSEGV, Segmentation fault. 0x401ad783 in strncpy () from /lib/libc.so.6 (gdb) bt #0 0x401ad783 in strncpy () from /lib/libc.so.6 #1 0x0804a511 in if_next (fd=7, ifname=0x0, nextifname=0xb8ec [EMAIL PROTECTED]@À\227) at wmnetload.c:997 #2 0x08049276 in main (argc=2, argv=0xb974) at wmnetload.c:215 (gdb) Other issues: [EMAIL PROTECTED]:/tmp lintian wmnetload_1.3-1_i386.deb W: wmnetload: binary-or-shlib-defines-rpath ./usr/bin/wmnetload :/usr/local/lib Have fun hacking */Makefile.* or configure* * package contains upstreams ChangeLog as /u/s/d/wmnetload/ChangeLog and /u/s/d/wmnetload/changelog.gz. Remove the former one. * Outdated Standards-Version. * Long description uses 82 characters per line, that produces ugly output of dpkg --info, rewrap at something like 72. * as libdockapp-dev depends on (and actually _must_ depend on) libdockapp1 there is no point in listing it in Build-Depends. * Cosmetical: Imho README.Debian is superfluous. On Thu, Nov 20, 2003 at 11:57:28AM -0600, Joe Wreschnig wrote: On Wed, 2003-11-19 at 16:53, Jess Mahan wrote: [...] msmtp (0.6.1 0.6.2 ) - An SMTP plugin for Mutt and probably other MUAs. - With your build-dependencies, the result is a binary linked against OpenSSL. This is a violation of copyright to distribute, since the OpenSSL license and GPL are not compatible. The source seems to have GNU TLS support in it; you should make sure it uses that (via ./configure) instead of OpenSSL. Unfortunatly, I cannot get it to build with gnutls3 on woddy, so i created the package anyway, and made a non-US section on my repository. [...] There seems to be a misunderstanding, Non-US is not for illegal software. You'll need a sid system for testing anyway, if your main system runs woody get a gnutls7 backport, e.g. http://www.logic.univie.ac.at/~ametzler/debian/gnutls/ cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: msmtp, wmnetload, wmwifi
On Mon, Nov 24, 2003 at 06:26:15PM -0800, Jess Mahan wrote: I made a lot of changes to my packages (Thanks BTW for all the helpfull comments from everyone. Can you please check them out now, and see if I did it right this time? deb http://digitalssg.net/debian/ stable main non-US deb-src http://digitalssg.net/debian/ stable main non-US [EMAIL PROTECTED]:/tmp LANG=C wget http://digitalssg.net/debian/dists/stable/main/source/wmnetload_1.3.orig.tar.gz --09:16:20-- http://digitalssg.net/debian/dists/stable/main/source/wmnetload_1.3.orig.tar.gz = `wmnetload_1.3.orig.tar.gz' Resolving digitalssg.net... done. Connecting to digitalssg.net[209.134.35.180]:80... connected. HTTP request sent, awaiting response... 403 Forbidden 09:16:21 ERROR 403: Forbidden. But this was no big problem, I got the sources from upstream and the diff is readable. However I did not find wmnetload on msmtp.sourceforge.net as your debian/copyright files claimed. Crash: == [EMAIL PROTECTED]:/tmp/wmnetload-1.3/src gdb ./wmnetload [...] (gdb) run -b Starting program: /tmp/wmnetload-1.3/src/wmnetload -b Program received signal SIGSEGV, Segmentation fault. 0x401ad783 in strncpy () from /lib/libc.so.6 (gdb) bt #0 0x401ad783 in strncpy () from /lib/libc.so.6 #1 0x0804a511 in if_next (fd=7, ifname=0x0, nextifname=0xb8ec [EMAIL PROTECTED]@À\227) at wmnetload.c:997 #2 0x08049276 in main (argc=2, argv=0xb974) at wmnetload.c:215 (gdb) Other issues: [EMAIL PROTECTED]:/tmp lintian wmnetload_1.3-1_i386.deb W: wmnetload: binary-or-shlib-defines-rpath ./usr/bin/wmnetload :/usr/local/lib Have fun hacking */Makefile.* or configure* * package contains upstreams ChangeLog as /u/s/d/wmnetload/ChangeLog and /u/s/d/wmnetload/changelog.gz. Remove the former one. * Outdated Standards-Version. * Long description uses 82 characters per line, that produces ugly output of dpkg --info, rewrap at something like 72. * as libdockapp-dev depends on (and actually _must_ depend on) libdockapp1 there is no point in listing it in Build-Depends. * Cosmetical: Imho README.Debian is superfluous. On Thu, Nov 20, 2003 at 11:57:28AM -0600, Joe Wreschnig wrote: On Wed, 2003-11-19 at 16:53, Jess Mahan wrote: [...] msmtp (0.6.1 0.6.2 ) - An SMTP plugin for Mutt and probably other MUAs. - With your build-dependencies, the result is a binary linked against OpenSSL. This is a violation of copyright to distribute, since the OpenSSL license and GPL are not compatible. The source seems to have GNU TLS support in it; you should make sure it uses that (via ./configure) instead of OpenSSL. Unfortunatly, I cannot get it to build with gnutls3 on woddy, so i created the package anyway, and made a non-US section on my repository. [...] There seems to be a misunderstanding, Non-US is not for illegal software. You'll need a sid system for testing anyway, if your main system runs woody get a gnutls7 backport, e.g. http://www.logic.univie.ac.at/~ametzler/debian/gnutls/ cu andreas
