Re: Adopting packages
On Sat, Apr 28, 2001 at 03:36:04AM +0200, Eric Van Buggenhaut wrote: I regularly receive WNPP report. List is divided in 2 : - orphaned packages. orphaned, as in no maintainer. - packages up for adoption. packages up for adoption do have a maintainer, but the maintainer wants someone else to take over. Someone, correct me if I'm wrong, as I am a new maintainer myself ! viral -- For long you live and high you fly, but only if you ride the tide, And balanced on the biggest wave, you race towards an early grave. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
purging bug of removed package
I have a pending bug on an old package that does not yet exists in debian archive. What I have to do ? Have I to close the bug signalling that the package has been removed from debian or have I to inform someone that the packge is defunct ? -- - Zack - Stefano Zacchiroli [EMAIL PROTECTED] ICQ# 33538863 Home Page: http://www.students.cs.unibo.it/~zacchiro Undergraduate Student of Computer Science at University of Bologna, Italy SysAdm of verdicchio.students.cs.unibo.it (130.136.3.134) Information wants to be Open PGP signature
Re: porting questions
On Thu, Apr 26, 2001 at 12:28:03AM -0700, Joshua Haberman wrote: I'm trying to do my part to take a load off the porters by ensuring my package compiles on all available architectures. However, I'm running into questions: 1. It seems the only machine with chroots available is vore. What about builds on architectures other than sparc? IIRC there aren't any other chroots on any other machine. Perhaps voltaire, but I haven't checked. 2. Even on vore in the unstable chroot, my package Build-depends on several packages that are not installed. How do I remedy this? Ask debian-admin to install them? -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: purging bug of removed package
On Sat, Apr 28, 2001 at 05:12:52PM +0200, Stefano Zacchiroli wrote: I have a pending bug on an old package that does not yet exists in debian archive. What I have to do ? Have I to close the bug signalling that the package has been removed from debian or have I to inform someone that the packge is defunct ? Give us more exact information about which packages are included. There's no general rule... -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: purging bug of removed package
On Sat, Apr 28, 2001 at 06:24:11PM +0200, Josip Rodin wrote: On Sat, Apr 28, 2001 at 05:12:52PM +0200, Stefano Zacchiroli wrote: I have a pending bug on an old package that does not yet exists in debian archive. snip Give us more exact information about which packages are included. There's no general rule... OK, the package is gtkmathview that does not loger exists cause it have been replaced by three libgtkmathview-* packages. There is a bug pending on gtkmathview regarding a missing build-dep, the bug is outstanding since 64 days ago. -- - Zack - Stefano Zacchiroli [EMAIL PROTECTED] ICQ# 33538863 Home Page: http://www.students.cs.unibo.it/~zacchiro Undergraduate Student of Computer Science at University of Bologna, Italy SysAdm of verdicchio.students.cs.unibo.it (130.136.3.134) Information wants to be Open PGP signature
Re: purging bug of removed package
On Sat, Apr 28, 2001 at 06:47:51PM +0200, Stefano Zacchiroli wrote: I have a pending bug on an old package that does not yet exists in debian archive. snip Give us more exact information about which packages are included. There's no general rule... (maybe I misread :) OK, the package is gtkmathview that does not loger exists cause it have been replaced by three libgtkmathview-* packages. There is a bug pending on gtkmathview regarding a missing build-dep, the bug is outstanding since 64 days ago. If the same bug applies to the new package, reassign it. Else, close it saying the package was removed. -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libtool headaches
Hi Filip, On Sat, 28 Apr 2001, Filip Van Raemdonck wrote: (Please cc: me on replies, I'm trying to subscribe but the mailing list seems to be slow in sending confirm requests) Hi, I am working on a package of fam (available from http://oss.sgi.com/projects/fam/), and I have some trouble wrt libtool. They use a selfcontained version of libtool in the build process, to build a shared library. The resulting library gets named libfam.so.0.0.0 This seemed rather odd to me, as the source distribution is already at 2.6.4 (it's an opensource release of an old SGI Irix tool), and I was correct in being suspicious: in a rpm spec file distributed with the sources there were commented out lines in the `%files' section that referenced a libfam.1.0 file (but a comment also seemed to indicate failure of correct soname generation on rpm systems). I suspect this is probably just a problem with the way libtool gets called (either incorrect or incomplete), but I'm not too good on reading Makefile.in's and apparently (to make things even more complicated) the libtool isn't even really distributed but gets generated from a file `ltconfig' in the top source directory. I'd really like some help to build the library with a correct major and minor version number. It's not that I can't build it or it doesn't work right now, but I fear severe breakage if one of the version numbers changes. It's not out of the question that a library which is released as version 2.6.4 would still have an so version of 0.0.0; the major version of the library soname changes any time the library interface changes, but the major version of the /package/ would change at the author's discretion. Still, even though it doesn't need to match the release version 2.6.4, 0.0.0 does seem a little low. If you search through the makefiles for 'soname', do you find anywhere that this argument is being passed to libtool (or supposed to be)? Steve Langasek postmodern programmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libtool headaches
Filip == Filip Van Raemdonck [EMAIL PROTECTED] writes: I suspect this is probably just a problem with the way libtool gets called (either incorrect or incomplete), but I'm not too good on reading Makefile.in's and apparently (to make things even more complicated) the libtool isn't even really distributed but gets generated from a file `ltconfig' in the top source directory. Normally libtool is used with automake, which means there are Makefile.am. So you shouldn't bother with the Makefile.in's but rather with the Makefile.am which are far easier to read. W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libtool headaches
Libtool does things a bit differently. I'm going to quote some from the
'libtool-doc' info file in Node: Versioning. ('info libtool' and either
pick it from the menu or type 'g Versioning').
*_Never_* try to set the interface numbers so that they correspond
to the release number of your package. This is an abuse that only
fosters misunderstanding of the purpose of library versions.
and
1. Start with version information of `0:0:0' for each libtool library.
The way libtool does versions is an attempt to clarify what library versions
are binary compatible and which are not. Please read Debian Policy section
11.2 for information on what to do with libtool's .la files.
On Sat, Apr 28, 2001 at 04:32:35PM +0200, Filip Van Raemdonck wrote:
(Please cc: me on replies, I'm trying to subscribe but the mailing list seems
to be slow in sending confirm requests)
Hi,
I am working on a package of fam (available from
http://oss.sgi.com/projects/fam/), and I have some trouble wrt libtool.
They use a selfcontained version of libtool in the build process, to build a
shared library. The resulting library gets named libfam.so.0.0.0
This seemed rather odd to me, as the source distribution is already at 2.6.4
(it's an opensource release of an old SGI Irix tool), and I was correct in
being suspicious: in a rpm spec file distributed with the sources there were
commented out lines in the `%files' section that referenced a libfam.1.0 file
(but a comment also seemed to indicate failure of correct soname generation
on rpm systems).
I suspect this is probably just a problem with the way libtool gets called
(either incorrect or incomplete), but I'm not too good on reading
Makefile.in's and apparently (to make things even more complicated) the
libtool isn't even really distributed but gets generated from a file
`ltconfig' in the top source directory.
I'd really like some help to build the library with a correct major and minor
version number. It's not that I can't build it or it doesn't work right now,
but I fear severe breakage if one of the version numbers changes.
Regards,
Filip
--
If we knew what it was we were doing, we wouldn't call it research.
-- Albert Einstein
--
;;
;; Matthew Danish email: [EMAIL PROTECTED] ;;
;; GPG public key available from:'finger [EMAIL PROTECTED]' ;;
;;
PGP signature
gpg keyrings.
Hi, I want to know whether I have to import all the keys in the debian-keyring into my public keyring to be able to verify signatures, or is there a better way, such as defining other public keyrings/querying a keyserver etc. Thanks, viral -- And if your head explodes with dark forebodings too, I'll see you on the dark side of the moon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpg keyrings.
On Sun, Apr 29, 2001 at 10:41:37AM +0530, Viral wrote: I want to know whether I have to import all the keys in the debian-keyring into my public keyring to be able to verify signatures, or is there a better way, such as defining other public keyrings/querying a keyserver etc. Install the debian-keyring package (if you haven't already), and add the following line to ~/.gnupg/options: keyring /usr/share/keyrings/debian-keyring.gpg Make sure it comes _before_ ~/.gnupg/pubring.gpg, since gpg will try to add new keys to the last keyring listed. You can use the Debian keyserver (which is usually more up-to-date than the package) with this line: keyserver keyring.debian.org -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian errors and warnings
Bob Hilliard wrote: The only guidance I can find in policy 3.5.2.0 on the subject of stripping binaries is in section 11.1. Binaries: Note that by default all installed binaries should be stripped, either by using the `-s' flag to `install', or by calling `strip' on the binaries after they have been copied into `debian/tmp' but before the tree is made into a package. I have always followed this provision, using the `-s' flag to `install' in my rules files. The binaries lintian objected to were stripped. It's a warning because it's not a policy violation or anything, just something you can do a bit better. [EMAIL PROTECTED]:~echo 'W: dict: binary-has-unneeded-section ./usr/bin/dict .note' | lintian-info W: dict: binary-has-unneeded-section ./usr/bin/dict .note N: N: The binary or shared library is stripped, but still contains a section N: that is not useful. The utilities (install -s and dh_strip) are N: patched to remove the .note and .comment sections. N: Another poster recommended using `strip --strip-unneeded' for these binaries, but that does not remove anything more than `strip' without options. The dictzip binary, unstripped, is 394689 bytes. After running `strip dictzip', it is 125116 bytes. After running `strip --strip-unneeded dictzip' it is still 125116 bytes. Running `strip --remove-section=.comment --remove-section=.note dictzip' reduces it to 122396 bytes. Right, and that size saving is why I made debhelper's dh_strip program begin to stip those sections (and more for shared libs). IIRC debhelper was first, lintian picked up on it, and nobody has even seen a need to mention it in policy. -- see shy jo
Re: Lintian errors and warnings
Colin Watson wrote: You should not create hard links in the manual page directories, nor put absolute filenames in .so directives. Heh. There's a man page somewhere in debian that looks something like: a few man header-type things here .so /usr/bin/foo a few man footer-type things here You can probably imagine what an unholy mess of groff pretending to be shell comments and shell pretending to be groff comments are in /usr/bin/foo. :-) -- see shy jo
Adopting packages
I regularly receive WNPP report. List is divided in 2 : - orphaned packages. - packages up for adoption. I still haven't catched the subtle difference between those 2 titles. Packages of what list may I adopt ? As non-english speaker, I find it obvious that an orphaned package has to be adopted, so what's the point ? -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: Adopting packages
On Sat, Apr 28, 2001 at 03:36:04AM +0200, Eric Van Buggenhaut wrote: I regularly receive WNPP report. List is divided in 2 : - orphaned packages. orphaned, as in no maintainer. - packages up for adoption. packages up for adoption do have a maintainer, but the maintainer wants someone else to take over. Someone, correct me if I'm wrong, as I am a new maintainer myself ! viral -- For long you live and high you fly, but only if you ride the tide, And balanced on the biggest wave, you race towards an early grave.
Re: porting questions
On Thu, Apr 26, 2001 at 12:28:03AM -0700, Joshua Haberman wrote: I'm trying to do my part to take a load off the porters by ensuring my package compiles on all available architectures. However, I'm running into questions: 1. It seems the only machine with chroots available is vore. What about builds on architectures other than sparc? IIRC there aren't any other chroots on any other machine. Perhaps voltaire, but I haven't checked. 2. Even on vore in the unstable chroot, my package Build-depends on several packages that are not installed. How do I remedy this? Ask debian-admin to install them? -- Digital Electronic Being Intended for Assassination and Nullification
Re: purging bug of removed package
On Sat, Apr 28, 2001 at 05:12:52PM +0200, Stefano Zacchiroli wrote: I have a pending bug on an old package that does not yet exists in debian archive. What I have to do ? Have I to close the bug signalling that the package has been removed from debian or have I to inform someone that the packge is defunct ? Give us more exact information about which packages are included. There's no general rule... -- Digital Electronic Being Intended for Assassination and Nullification
Re: purging bug of removed package
On Sat, Apr 28, 2001 at 06:24:11PM +0200, Josip Rodin wrote: On Sat, Apr 28, 2001 at 05:12:52PM +0200, Stefano Zacchiroli wrote: I have a pending bug on an old package that does not yet exists in debian archive. snip Give us more exact information about which packages are included. There's no general rule... OK, the package is gtkmathview that does not loger exists cause it have been replaced by three libgtkmathview-* packages. There is a bug pending on gtkmathview regarding a missing build-dep, the bug is outstanding since 64 days ago. -- - Zack - Stefano Zacchiroli [EMAIL PROTECTED] ICQ# 33538863 Home Page: http://www.students.cs.unibo.it/~zacchiro Undergraduate Student of Computer Science at University of Bologna, Italy SysAdm of verdicchio.students.cs.unibo.it (130.136.3.134) Information wants to be Open pgp2KK3yX5rMw.pgp Description: PGP signature
Re: purging bug of removed package
On Sat, Apr 28, 2001 at 06:47:51PM +0200, Stefano Zacchiroli wrote: I have a pending bug on an old package that does not yet exists in debian archive. snip Give us more exact information about which packages are included. There's no general rule... (maybe I misread :) OK, the package is gtkmathview that does not loger exists cause it have been replaced by three libgtkmathview-* packages. There is a bug pending on gtkmathview regarding a missing build-dep, the bug is outstanding since 64 days ago. If the same bug applies to the new package, reassign it. Else, close it saying the package was removed. -- Digital Electronic Being Intended for Assassination and Nullification
Re: libtool headaches
Hi Filip, On Sat, 28 Apr 2001, Filip Van Raemdonck wrote: (Please cc: me on replies, I'm trying to subscribe but the mailing list seems to be slow in sending confirm requests) Hi, I am working on a package of fam (available from http://oss.sgi.com/projects/fam/), and I have some trouble wrt libtool. They use a selfcontained version of libtool in the build process, to build a shared library. The resulting library gets named libfam.so.0.0.0 This seemed rather odd to me, as the source distribution is already at 2.6.4 (it's an opensource release of an old SGI Irix tool), and I was correct in being suspicious: in a rpm spec file distributed with the sources there were commented out lines in the `%files' section that referenced a libfam.1.0 file (but a comment also seemed to indicate failure of correct soname generation on rpm systems). I suspect this is probably just a problem with the way libtool gets called (either incorrect or incomplete), but I'm not too good on reading Makefile.in's and apparently (to make things even more complicated) the libtool isn't even really distributed but gets generated from a file `ltconfig' in the top source directory. I'd really like some help to build the library with a correct major and minor version number. It's not that I can't build it or it doesn't work right now, but I fear severe breakage if one of the version numbers changes. It's not out of the question that a library which is released as version 2.6.4 would still have an so version of 0.0.0; the major version of the library soname changes any time the library interface changes, but the major version of the /package/ would change at the author's discretion. Still, even though it doesn't need to match the release version 2.6.4, 0.0.0 does seem a little low. If you search through the makefiles for 'soname', do you find anywhere that this argument is being passed to libtool (or supposed to be)? Steve Langasek postmodern programmer
Re: libtool headaches
Filip == Filip Van Raemdonck [EMAIL PROTECTED] writes: I suspect this is probably just a problem with the way libtool gets called (either incorrect or incomplete), but I'm not too good on reading Makefile.in's and apparently (to make things even more complicated) the libtool isn't even really distributed but gets generated from a file `ltconfig' in the top source directory. Normally libtool is used with automake, which means there are Makefile.am. So you shouldn't bother with the Makefile.in's but rather with the Makefile.am which are far easier to read. W.
Re: libtool headaches
Libtool does things a bit differently. I'm going to quote some from the
'libtool-doc' info file in Node: Versioning. ('info libtool' and either
pick it from the menu or type 'g Versioning').
*_Never_* try to set the interface numbers so that they correspond
to the release number of your package. This is an abuse that only
fosters misunderstanding of the purpose of library versions.
and
1. Start with version information of `0:0:0' for each libtool library.
The way libtool does versions is an attempt to clarify what library versions
are binary compatible and which are not. Please read Debian Policy section
11.2 for information on what to do with libtool's .la files.
On Sat, Apr 28, 2001 at 04:32:35PM +0200, Filip Van Raemdonck wrote:
(Please cc: me on replies, I'm trying to subscribe but the mailing list seems
to be slow in sending confirm requests)
Hi,
I am working on a package of fam (available from
http://oss.sgi.com/projects/fam/), and I have some trouble wrt libtool.
They use a selfcontained version of libtool in the build process, to build a
shared library. The resulting library gets named libfam.so.0.0.0
This seemed rather odd to me, as the source distribution is already at 2.6.4
(it's an opensource release of an old SGI Irix tool), and I was correct in
being suspicious: in a rpm spec file distributed with the sources there were
commented out lines in the `%files' section that referenced a libfam.1.0 file
(but a comment also seemed to indicate failure of correct soname generation
on rpm systems).
I suspect this is probably just a problem with the way libtool gets called
(either incorrect or incomplete), but I'm not too good on reading
Makefile.in's and apparently (to make things even more complicated) the
libtool isn't even really distributed but gets generated from a file
`ltconfig' in the top source directory.
I'd really like some help to build the library with a correct major and minor
version number. It's not that I can't build it or it doesn't work right now,
but I fear severe breakage if one of the version numbers changes.
Regards,
Filip
--
If we knew what it was we were doing, we wouldn't call it research.
-- Albert Einstein
--
;;
;; Matthew Danish email: [EMAIL PROTECTED] ;;
;; GPG public key available from:'finger [EMAIL PROTECTED]' ;;
;;
pgpegACfV9lv2.pgp
Description: PGP signature
