Re: undocumented(7)
[ CC:'ed to Nicolás Lichtmaier as maintainer of manpages ] Matt Zimmerman [EMAIL PROTECTED] wrote: undocumented(7) is in the manpages package (Priority: important). It seems sensible to allow users to remove this package without breaking anything, and if they care enough to remove the manpages package, they probably won't miss undocumented(7). Actually, the reason I ask is because I *did* miss undocumented(7), without realising it. In fact, a bug almost got filed against an entirely unrelated package for not having man pages for its binaries, when in reality it had symlinks to undocumented(7), which didn't exist. I've decided that I agree with Colin Watson on this one: undocumented(7) should be in an Essential: yes package, probably base-files. Either that, or any package with a symlink to undocumented(7) should declare a Depends: on manpages. Anything else leaves dangling symlinks, which is broken. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C PGP signature
missing file in my package
Hello, I'm having some trouble in packaging a program called esms. It only consists of a single binary-all (perl) file that must go on /usr/bin/esms. The problem is that the package is created without it, here's a snapshot of an alienized package: bash-2.03$ tar -xvzf esms-0.9.0-2.tgz ./ ./usr/ ./usr/bin/ ./usr/share/ ./usr/share/doc/ ./usr/share/doc/esms/ ./usr/share/doc/esms/copyright ./usr/share/doc/esms/changelog.Debian.gz bash-2.03$ Here is the (IMHO) relevant part of my debian/rules file: install: build dh_testdir dh_testroot dh_clean -k dh_installdirs # Add here commands to install the package into debian/tmp. install -d debian/tmp/usr/bin install -m755 -o root -g root `pwd`/esms `pwd`/debian/tmp/usr/bin/esms If i missed some information let me know and i'll post it here. Thanks, -- Robert MillanDebian GNU (Hurd) user zeratul2 wanadoo eshttp://getyouriso.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: missing file in my package
Robert Millan [EMAIL PROTECTED] wrote: I'm having some trouble in packaging a program called esms. It only consists of a single binary-all (perl) file that must go on /usr/bin/esms. The problem is that the package is created without it, here's a snapshot of an alienized package: [...] install: build dh_testdir dh_testroot dh_clean -k dh_installdirs # Add here commands to install the package into debian/tmp. install -d debian/tmp/usr/bin install -m755 -o root -g root `pwd`/esms `pwd`/debian/tmp/usr/bin/esms You aren't using DH_COMPAT=2 or 3, are you? When that is set, the various debhelper commands (like dh_installdocs, which is installing your documentation, and dh_builddeb, which calls dpkg to construct the .deb itself) use debian/package-name rather than debian/tmp. Cheers, -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Closing BUGS on a package's changelog
Gergely Nagy [EMAIL PROTECTED] wrote: Thus spoke Sergio Talens-Oliag [EMAIL PROTECTED] on 2001-07-03 11:02:12: * If this happens to me again, shoud I move all the 'Close' tags on the REJECTED package to the last version? I saw something like this in some packages: * Fixed in previous upload: Closes #xxx, #yyy, #zzz That made sense to me That makes no sense to me; it's just noise in the changelog (and it doesn't tell the submitter anything useful, since it doesn't say *how* the bugs were fixed ...). There have even been some uploads with no other purpose than to close some bugs, which just puts more load on the autobuilders for no reason. If you've already fixed something, just mail [EMAIL PROTECTED] about it. If people are looking through the history of old bugs in a package, they can always use http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=fooarchive=yes, since we don't expunge old bug reports any more. Personally, if an upload of mine was REJECTed, I'd just fix it and re-upload with the same version number. If this was inappropriate for some reason (e.g. I'd been pointing people at the version in incoming), I'd build with 'dpkg-buildpackage -vversion-before-the-REJECTed-one'. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: undocumented(7)
On Sun, Jul 08, 2001 at 06:23:37PM +1000, Sam Couter wrote: Actually, the reason I ask is because I *did* miss undocumented(7), without realising it. In fact, a bug almost got filed against an entirely unrelated package for not having man pages for its binaries, when in reality it had symlinks to undocumented(7), which didn't exist. My humble opinion? Undocumented(7) is simply a crutch for lazy developers. File the bug! Write the missing manpage and attach it to the bug report. The sooner we can remove undocumented(7) without causing dangling links, the better debian will be. -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: missing file in my package
On Sun, 08 Jul 2001 13:25:50 +0100, [EMAIL PROTECTED] (Colin Watson) wrote: You aren't using DH_COMPAT=2 or 3, are you? When that is set, the various debhelper commands (like dh_installdocs, which is installing your documentation, and dh_builddeb, which calls dpkg to construct the ..deb itself) use debian/package-name rather than debian/tmp. heh. as i remember, i was told to use DH_COMPAT=2 by someone who uses debian/package-name instead of debian/tmp :). thank you, -- Robert MillanDebian GNU (Hurd) user zeratul2 wanadoo eshttp://getyouriso.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sponsor package
Hello, I've packaged esms (esms.sourceforge.net), anyone could sponsor it? thanks, -- Robert MillanDebian GNU (Hurd) user zeratul2 wanadoo eshttp://getyouriso.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Makefile.in
Use the --prefix=/usr option to ./configure
Then when running 'make install' do this instead:
'make install prefix=/path/to/temporary/directory'
On Sun, Jul 08, 2001 at 06:39:22PM +0200, Robert Millan wrote:
Hello,
I'm modifiing a Makefile.in to got rid of the /usr/local but i have some doubts.
Makefile.in
SHELL = @SHELL@
srcdir = @srcdir@
top_srcdir = @top_srcdir@
VPATH = @srcdir@
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
sbindir = @sbindir@
libexecdir = @libexecdir@
datadir = @datadir@
sysconfdir = @sysconfdir@
sharedstatedir = @sharedstatedir@
localstatedir = @localstatedir@
libdir = @libdir@
infodir = @infodir@
mandir = @mandir@
includedir = @includedir@
oldincludedir = /usr/include
--Makefile (after running ./configure)
SHELL = /bin/sh
srcdir = .
top_srcdir = .
prefix = /usr/local
exec_prefix = ${prefix}
bindir = ${exec_prefix}/bin
sbindir = ${exec_prefix}/sbin
libexecdir = ${exec_prefix}/libexec
datadir = ${prefix}/share
sysconfdir = ${prefix}/etc
sharedstatedir = ${prefix}/com
localstatedir = ${prefix}/var
libdir = ${exec_prefix}/lib
infodir = ${prefix}/info
mandir = ${prefix}/man
includedir = ${prefix}/include
oldincludedir = /usr/include
--
Looking at the Makefile* (relevant parts below), I believe that changing the prefix
line
to prefix = /usr will solve the problem for some files but others won't have a
place to go,
for example, the /usr/etc dir does not exist.
What should i do?
thanks,
--
Robert MillanDebian GNU (Hurd) user
zeratul2 wanadoo eshttp://getyouriso.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
;;
;; Matthew Danish email: [EMAIL PROTECTED] ;;
;; OpenPGP public key available from:'finger [EMAIL PROTECTED]' ;;
;;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Makefile.in
On Sun, Jul 08, 2001 at 12:51:31PM -0400, [EMAIL PROTECTED] wrote: Use the --prefix=/usr option to ./configure Then when running 'make install' do this instead: 'make install prefix=/path/to/temporary/directory' Also, set --mandir=/usr/share/man and --infodir=/usr/share/info, if applicable. And if you're installing things in /etc, set --sysconfdir=/etc. In general: don't be afraid to run ./configure --help nor to read the INSTALL file! -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Makefile.in
On Sun, 8 Jul 2001 12:51:31 -0400, [EMAIL PROTECTED] wrote: Use the --prefix=/usr option to ./configure Then when running 'make install' do this instead: 'make install prefix=/path/to/temporary/directory' On Sun, 8 Jul 2001 13:08:57 -0400, Steve M. Robbins [EMAIL PROTECTED] wrote: Also, set --mandir=/usr/share/man and --infodir=/usr/share/info, if applicable. And if you're installing things in /etc, set --sysconfdir=/etc. In general: don't be afraid to run ./configure --help nor to read the INSTALL file! i'm sorry, i forgot to say i don't want to install it but to make a package :) will changing the prefix = @prefix@ line to prefix = /usr do? --Makefile.in SHELL = @SHELL@ srcdir = @srcdir@ top_srcdir = @top_srcdir@ VPATH = @srcdir@ prefix = @prefix@ exec_prefix = @exec_prefix@ bindir = @bindir@ sbindir = @sbindir@ libexecdir = @libexecdir@ datadir = @datadir@ sysconfdir = @sysconfdir@ sharedstatedir = @sharedstatedir@ localstatedir = @localstatedir@ libdir = @libdir@ infodir = @infodir@ mandir = @mandir@ includedir = @includedir@ oldincludedir = /usr/include --- thanks, -- Robert MillanDebian GNU (Hurd) user zeratul2 wanadoo eshttp://getyouriso.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Makefile.in
On Sun, Jul 08, 2001 at 08:57:38PM +0200, Robert Millan wrote: On Sun, 8 Jul 2001 12:51:31 -0400, [EMAIL PROTECTED] wrote: Use the --prefix=/usr option to ./configure Then when running 'make install' do this instead: 'make install prefix=/path/to/temporary/directory' On Sun, 8 Jul 2001 13:08:57 -0400, Steve M. Robbins [EMAIL PROTECTED] wrote: Also, set --mandir=/usr/share/man and --infodir=/usr/share/info, if applicable. And if you're installing things in /etc, set --sysconfdir=/etc. In general: don't be afraid to run ./configure --help nor to read the INSTALL file! i'm sorry, i forgot to say i don't want to install it but to make a package :) Making a package involves installing it! You had better re-read the packaging manual. The New Maintainer's Guide http://www.debian.org/doc/maint-guide/ is quite good. Then have a look at debian/rules in a package that uses autoconf (e.g. isapnptools). will changing the prefix = @prefix@ line to prefix = /usr do? No. -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: undocumented(7)
[I think Colin reads this list, but CCing @packages to be sure.]
Matt Zimmerman [EMAIL PROTECTED] writes:
undocumented(7) is in the manpages package (Priority: important). It seems
sensible to allow users to remove this package without breaking anything, and
if they care enough to remove the manpages package, they probably won't miss
undocumented(7).
Wouldn't it be better to just move undocumented(7) (it's 1415 bytes,
FWIW) to man-db? This way all users of man would have it.
Thinking a bit further ... symlinking to undocumented is often frowned
upon, because it muddles up the issue (and novice packagers often
conveniently think that it is a permanent solution), and sometimes
raises false expectations (i.e. I install a package, look at dpkg -L
output, think: fine, a manpage is provided). Sooo, why not patch the
man binary to issue a more helpful message?
I.e. if manpage FOO was sought, and FOO exists in {,/usr}/{,s}bin:
No manual entry for FOO
This is probably a bug you should report.
In the mean time, please try to find usage information through other
means -- try man undocumented if you are unsure.
--
Robbe
signature.ng
Re: Procedural clarification
Greg Wiley [EMAIL PROTECTED] writes: The question is: which do I do first, announce my intentions to debian-devel or submit a new main- tainer application? The application seems to want me to announce. Other docs seem to indicate that I should become a maintainer first. You can become a NM without having a package in Debian. Showing off a good package is a fine way, to demonstrate that you have the necessary skills, but it is this package need not be an official Debian one. OTOH, you don't have to be a Debian developer to contribute official packages. If you aren't, you need a sponsor who is a developer. S/he will check if your package is done right, and provide the stamp of approval so it can be uploaded into Debian. Nowadays, you also need an advocate who is a Debian develper, to get into the NM queue. Following from all this, I recommend: 1. Announce that you're willing to adopt package X, but that you'll need a sponsor. Don't forget to Cc: the WNPP bug for package X. 2. Wait until a sponsor contacts you. 3. Do the necessary work on package X, and send the results to your sponsor. Repeat until s/he is satisfied -- then your package will be uploaded by the sponsor. 4. Ask your sponsor whether s/he would advocate for you. If s/he is willing, apply for NM. -- Robbe signature.ng
g++ 3.0
I have a package (exult) using C++. It reportedly does not work very good on certain architectures when compiled with g++ 2.95, so I want to move it to g++ 3.0. I read on -devel that compiling packages with g++ 3 is problematic since they will not correctly link with C++ libraries built with an older compiler. I figure this will not be a problem for my package because it does not depend on any C++ libraries other than libstdc++, which should be ok. Normal C libraries are no bother, I assume. Is this correct? If yes, I'd like to have comments on my method: I build-depend on g++-3.0, and do CC=gcc-3.0 CXX=g++-3.0 ./configure ... in my rules. -- Robbe signature.ng
Re: missing file in my package
What DH_COMPAT are you using ? PD : tienes tu clave firmada ya ? On Sun, Jul 08, 2001 at 02:13:31PM +0200, Robert Millan wrote: Hello, I'm having some trouble in packaging a program called esms. It only consists of a single binary-all (perl) file that must go on /usr/bin/esms. The problem is that the package is created without it, here's a snapshot of an alienized package: bash-2.03$ tar -xvzf esms-0.9.0-2.tgz ./ ./usr/ ./usr/bin/ ./usr/share/ ./usr/share/doc/ ./usr/share/doc/esms/ ./usr/share/doc/esms/copyright ./usr/share/doc/esms/changelog.Debian.gz bash-2.03$ Here is the (IMHO) relevant part of my debian/rules file: install: build dh_testdir dh_testroot dh_clean -k dh_installdirs # Add here commands to install the package into debian/tmp. install -d debian/tmp/usr/bin install -m755 -o root -g root `pwd`/esms `pwd`/debian/tmp/usr/bin/esms If i missed some information let me know and i'll post it here. Thanks, -- Robert MillanDebian GNU (Hurd) user zeratul2 wanadoo eshttp://getyouriso.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: missing file in my package
On Mon, 9 Jul 2001 01:04:49 +0200, Eric Van Buggenhaut [EMAIL PROTECTED] wrote: What DH_COMPAT are you using ? I was using DH_COMPAT=2 as you told me in another question, now i've been told that when using the debian/tmp directory i need DH_COMPAT=1 (i noticed you are using debian/package_name directory). So don't worry it's working right now and i've finally made the package. Regards, -- Robert Millan Debian GNU (Hurd) user zeratul2 wanadoo es http://getyouriso.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: missing file in my package
On Mon, Jul 09, 2001 at 01:55:35AM +0200, Robert Millan wrote: On Mon, 9 Jul 2001 01:04:49 +0200, Eric Van Buggenhaut [EMAIL PROTECTED] wrote: What DH_COMPAT are you using ? I was using DH_COMPAT=2 as you told me in another question, now i've been told that when using the debian/tmp directory i need DH_COMPAT=1 (i noticed you are using debian/package_name directory). So don't worry it's working right now and i've finally made the package. This isn't your best move. You *should* use DH_COMPAT=2 and install the files in debian/package_name When this is corrected, I can have a look at your package and upload it. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
openacs docs version number
Hi, I recently adopted openacs package. Upstream FTP site provides 2 packages : openacs-3.2.5.tar.gz and openacs-3.2.5-docs.tar.gz. How should I version-number the doc package ? Would openacs-docs_1.0 be OK or shoud I try to stick to binaries package version for now and the future ? Thanks. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: undocumented(7)
On Sun, 08 Jul 2001 at 20:21:09 +0200, Robert Bihlmeyer wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
undocumented(7) is in the manpages package (Priority: important).
It seems sensible to allow users to remove this package without
breaking anything, and if they care enough to remove the manpages
package, they probably won't miss undocumented(7).
Wouldn't it be better to just move undocumented(7) (it's 1415 bytes,
FWIW) to man-db? This way all users of man would have it.
*sigh* There are multiple man browsers in Debian: gman, gnome-help,
konqueror, and tkman all provide man-browser, and coolman should. It's
inappropriate to put something used by all of them into man-db just
because it's the one most people use.
Thinking a bit further ... symlinking to undocumented is often frowned
upon, because it muddles up the issue (and novice packagers often
conveniently think that it is a permanent solution), and sometimes
raises false expectations (i.e. I install a package, look at dpkg -L
output, think: fine, a manpage is provided). Sooo, why not patch the
man binary to issue a more helpful message?
I.e. if manpage FOO was sought, and FOO exists in {,/usr}/{,s}bin:
No manual entry for FOO
This is probably a bug you should report.
In the mean time, please try to find usage information through other
means -- try man undocumented if you are unsure.
It seems a bit silly, because, well, that's what undocumented(7) says
except in less detail. It also seems like more cruft in the already
crufty man binary. Feel free to write a patch if you think it's useful,
though, but you'll need to get all manual browsers changed before policy
13.1 can properly be amended.
--
Colin Watson [[EMAIL PROTECTED]]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Procedural clarification
This is a multi-part message in MIME format. It has been signed conforming to RFC2015. You'll need PGP or GPG to check the signature. =_994626186-1074-2 Content-Type: text/plain; charset=us-ascii Greg Wiley [EMAIL PROTECTED] writes: The question is: which do I do first, announce my intentions to debian-devel or submit a new main- tainer application? The application seems to want me to announce. Other docs seem to indicate that I should become a maintainer first. You can become a NM without having a package in Debian. Showing off a good package is a fine way, to demonstrate that you have the necessary skills, but it is this package need not be an official Debian one. OTOH, you don't have to be a Debian developer to contribute official packages. If you aren't, you need a sponsor who is a developer. S/he will check if your package is done right, and provide the stamp of approval so it can be uploaded into Debian. Nowadays, you also need an advocate who is a Debian develper, to get into the NM queue. Following from all this, I recommend: 1. Announce that you're willing to adopt package X, but that you'll need a sponsor. Don't forget to Cc: the WNPP bug for package X. 1.5 You might use the sponsorship program in the meanwhile. Search for the link `sponsorship program' on http://www.debian.org/devel 2. Wait until a sponsor contacts you. 3. Do the necessary work on package X, and send the results to your sponsor. Repeat until s/he is satisfied -- then your package will be uploaded by the sponsor. 4. Ask your sponsor whether s/he would advocate for you. If s/he is willing, apply for NM. -- Robbe =_994626186-1074-2 Content-Type: application/pgp-signature; name=signature.ng Content-Disposition: inline; filename=signature.ng Content-Transfer-Encoding: 7bit -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SMqL8g21h7wYWrMRAhvvAJ9bWPugDiYz/lRdAWNTeg2BLoat0gCeKUhP 2gcZXbCREBvQ0R7dC+vGYGY= =1M5w -END PGP SIGNATURE- =_994626186-1074-2-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Shaul Karl [EMAIL PROTECTED] Hillel used to say: If I am not for myself who will be for me? Yet, if I am for myself only, what am I? And if not now, when? (Ethics Of The Fathers 1:14) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: undocumented(7)
Mark Brown [EMAIL PROTECTED] wrote: From undocumented(7): | This program, utility or function does not have a useful | manpage. Please do not report this as a bug, because this | has already been reported as a bug; when a manpage becomes But if undocumented(7) is unavailable, I don't see that message. I see No manual entry for foo, and then proceed to file a bug. It was only through further investigation that I realised the bug had already been filed and that the man page was really a dangling symlink. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C PGP signature
Re: g++ 3.0
On Sun, Jul 08, 2001 at 11:01:52PM +0200, Robert Bihlmeyer wrote: I read on -devel that compiling packages with g++ 3 is problematic since they will not correctly link with C++ libraries built with an older compiler. I figure this will not be a problem for my package because it does not depend on any C++ libraries other than libstdc++, which should be ok. Normal C libraries are no bother, I assume. Is this correct? If the problem occurs only on certain architectures, you may want to try it yourself on as many as possible before switching entirely to g++-3.0. On some Debian architectures, 3.0 is already the default compiler (see the source for gcc-defaults, I think). If those are the same architectures where your package has problems, then there is no problem for Debian. As long as it doesn't link against any other C++ libraries, it should work, yes. Whether or not this is a good idea, I'm not sure. There are issues with g++-3.0 other than ABI compatibility (such as debugging). It seems to be available on all platforms, though, so it might be worth a try if it turns out to be necessary. It might be wise to restrict the change to the problematic architectures, though. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openacs docs version number
Personally, I would use the source package's version # in this case. The docs may be fairly version-dependent (i.e. openacs 4.0 may change a great deal of things, and openacs-docs 4.0 would document the new interfaces), so sharing version numbers makes it much clearer... On Mon, Jul 09, 2001 at 02:16:43AM +0200, Eric Van Buggenhaut [EMAIL PROTECTED] spake forth: Hi, I recently adopted openacs package. Upstream FTP site provides 2 packages : openacs-3.2.5.tar.gz and openacs-3.2.5-docs.tar.gz. How should I version-number the doc package ? Would openacs-docs_1.0 be OK or shoud I try to stick to binaries package version for now and the future ? Thanks. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Mike Markley [EMAIL PROTECTED] GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 Behind every great man, there is a woman -- urging him on. - Harry Mudd, I, Mudd, stardate 4513.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: undocumented(7)
[ CC:'ed to Nicolás Lichtmaier as maintainer of manpages ] Matt Zimmerman [EMAIL PROTECTED] wrote: undocumented(7) is in the manpages package (Priority: important). It seems sensible to allow users to remove this package without breaking anything, and if they care enough to remove the manpages package, they probably won't miss undocumented(7). Actually, the reason I ask is because I *did* miss undocumented(7), without realising it. In fact, a bug almost got filed against an entirely unrelated package for not having man pages for its binaries, when in reality it had symlinks to undocumented(7), which didn't exist. I've decided that I agree with Colin Watson on this one: undocumented(7) should be in an Essential: yes package, probably base-files. Either that, or any package with a symlink to undocumented(7) should declare a Depends: on manpages. Anything else leaves dangling symlinks, which is broken. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgpFGDbckzNAa.pgp Description: PGP signature
missing file in my package
Hello, I'm having some trouble in packaging a program called esms. It only consists of a single binary-all (perl) file that must go on /usr/bin/esms. The problem is that the package is created without it, here's a snapshot of an alienized package: bash-2.03$ tar -xvzf esms-0.9.0-2.tgz ./ ./usr/ ./usr/bin/ ./usr/share/ ./usr/share/doc/ ./usr/share/doc/esms/ ./usr/share/doc/esms/copyright ./usr/share/doc/esms/changelog.Debian.gz bash-2.03$ Here is the (IMHO) relevant part of my debian/rules file: install: build dh_testdir dh_testroot dh_clean -k dh_installdirs # Add here commands to install the package into debian/tmp. install -d debian/tmp/usr/bin install -m755 -o root -g root `pwd`/esms `pwd`/debian/tmp/usr/bin/esms If i missed some information let me know and i'll post it here. Thanks, -- Robert MillanDebian GNU (Hurd) user zeratul2 wanadoo eshttp://getyouriso.org/
Re: missing file in my package
Robert Millan [EMAIL PROTECTED] wrote: I'm having some trouble in packaging a program called esms. It only consists of a single binary-all (perl) file that must go on /usr/bin/esms. The problem is that the package is created without it, here's a snapshot of an alienized package: [...] install: build dh_testdir dh_testroot dh_clean -k dh_installdirs # Add here commands to install the package into debian/tmp. install -d debian/tmp/usr/bin install -m755 -o root -g root `pwd`/esms `pwd`/debian/tmp/usr/bin/esms You aren't using DH_COMPAT=2 or 3, are you? When that is set, the various debhelper commands (like dh_installdocs, which is installing your documentation, and dh_builddeb, which calls dpkg to construct the .deb itself) use debian/package-name rather than debian/tmp. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Closing BUGS on a package's changelog
Gergely Nagy [EMAIL PROTECTED] wrote: Thus spoke Sergio Talens-Oliag [EMAIL PROTECTED] on 2001-07-03 11:02:12: * If this happens to me again, shoud I move all the 'Close' tags on the REJECTED package to the last version? I saw something like this in some packages: * Fixed in previous upload: Closes #xxx, #yyy, #zzz That made sense to me That makes no sense to me; it's just noise in the changelog (and it doesn't tell the submitter anything useful, since it doesn't say *how* the bugs were fixed ...). There have even been some uploads with no other purpose than to close some bugs, which just puts more load on the autobuilders for no reason. If you've already fixed something, just mail [EMAIL PROTECTED] about it. If people are looking through the history of old bugs in a package, they can always use http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=fooarchive=yes, since we don't expunge old bug reports any more. Personally, if an upload of mine was REJECTed, I'd just fix it and re-upload with the same version number. If this was inappropriate for some reason (e.g. I'd been pointing people at the version in incoming), I'd build with 'dpkg-buildpackage -vversion-before-the-REJECTed-one'. -- Colin Watson [EMAIL PROTECTED]
Re: undocumented(7)
On Sun, Jul 08, 2001 at 06:23:37PM +1000, Sam Couter wrote: Actually, the reason I ask is because I *did* miss undocumented(7), without realising it. In fact, a bug almost got filed against an entirely unrelated package for not having man pages for its binaries, when in reality it had symlinks to undocumented(7), which didn't exist. My humble opinion? Undocumented(7) is simply a crutch for lazy developers. File the bug! Write the missing manpage and attach it to the bug report. The sooner we can remove undocumented(7) without causing dangling links, the better debian will be. -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Re: Re: missing file in my package
On Sun, 08 Jul 2001 13:25:50 +0100, [EMAIL PROTECTED] (Colin Watson) wrote: You aren't using DH_COMPAT=2 or 3, are you? When that is set, the various debhelper commands (like dh_installdocs, which is installing your documentation, and dh_builddeb, which calls dpkg to construct the ..deb itself) use debian/package-name rather than debian/tmp. heh. as i remember, i was told to use DH_COMPAT=2 by someone who uses debian/package-name instead of debian/tmp :). thank you, -- Robert MillanDebian GNU (Hurd) user zeratul2 wanadoo eshttp://getyouriso.org/
sponsor package
Hello, I've packaged esms (esms.sourceforge.net), anyone could sponsor it? thanks, -- Robert MillanDebian GNU (Hurd) user zeratul2 wanadoo eshttp://getyouriso.org/
Re: undocumented(7)
On Sun, Jul 08, 2001 at 06:23:37PM +1000, Sam Couter wrote: Actually, the reason I ask is because I *did* miss undocumented(7), without realising it. In fact, a bug almost got filed against an entirely unrelated package for not having man pages for its binaries, when in reality it had symlinks to undocumented(7), which didn't exist. From undocumented(7): | This program, utility or function does not have a useful | manpage. Please do not report this as a bug, because this | has already been reported as a bug; when a manpage becomes -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgpOyxp72Ptnn.pgp Description: PGP signature
Makefile.in
Hello,
I'm modifiing a Makefile.in to got rid of the /usr/local but i have some
doubts.
Makefile.in
SHELL = @SHELL@
srcdir = @srcdir@
top_srcdir = @top_srcdir@
VPATH = @srcdir@
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
sbindir = @sbindir@
libexecdir = @libexecdir@
datadir = @datadir@
sysconfdir = @sysconfdir@
sharedstatedir = @sharedstatedir@
localstatedir = @localstatedir@
libdir = @libdir@
infodir = @infodir@
mandir = @mandir@
includedir = @includedir@
oldincludedir = /usr/include
--Makefile (after running ./configure)
SHELL = /bin/sh
srcdir = .
top_srcdir = .
prefix = /usr/local
exec_prefix = ${prefix}
bindir = ${exec_prefix}/bin
sbindir = ${exec_prefix}/sbin
libexecdir = ${exec_prefix}/libexec
datadir = ${prefix}/share
sysconfdir = ${prefix}/etc
sharedstatedir = ${prefix}/com
localstatedir = ${prefix}/var
libdir = ${exec_prefix}/lib
infodir = ${prefix}/info
mandir = ${prefix}/man
includedir = ${prefix}/include
oldincludedir = /usr/include
--
Looking at the Makefile* (relevant parts below), I believe that changing the
prefix line
to prefix = /usr will solve the problem for some files but others won't have
a place to go,
for example, the /usr/etc dir does not exist.
What should i do?
thanks,
--
Robert MillanDebian GNU (Hurd) user
zeratul2 wanadoo eshttp://getyouriso.org/
Re: missing file in my package
I just wanted to contribute a note: instead of alien'ing your package to get a listing of it's contents, use the 'dpkg -c' command on your deb. On Sun, Jul 08, 2001 at 02:13:31PM +0200, Robert Millan wrote: Hello, I'm having some trouble in packaging a program called esms. It only consists of a single binary-all (perl) file that must go on /usr/bin/esms. The problem is that the package is created without it, here's a snapshot of an alienized package: bash-2.03$ tar -xvzf esms-0.9.0-2.tgz ./ ./usr/ ./usr/bin/ ./usr/share/ ./usr/share/doc/ ./usr/share/doc/esms/ ./usr/share/doc/esms/copyright ./usr/share/doc/esms/changelog.Debian.gz bash-2.03$ -- ;; ;; Matthew Danish email: [EMAIL PROTECTED] ;; ;; OpenPGP public key available from:'finger [EMAIL PROTECTED]' ;; ;;
Re: Makefile.in
Use the --prefix=/usr option to ./configure
Then when running 'make install' do this instead:
'make install prefix=/path/to/temporary/directory'
On Sun, Jul 08, 2001 at 06:39:22PM +0200, Robert Millan wrote:
Hello,
I'm modifiing a Makefile.in to got rid of the /usr/local but i have some
doubts.
Makefile.in
SHELL = @SHELL@
srcdir = @srcdir@
top_srcdir = @top_srcdir@
VPATH = @srcdir@
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
sbindir = @sbindir@
libexecdir = @libexecdir@
datadir = @datadir@
sysconfdir = @sysconfdir@
sharedstatedir = @sharedstatedir@
localstatedir = @localstatedir@
libdir = @libdir@
infodir = @infodir@
mandir = @mandir@
includedir = @includedir@
oldincludedir = /usr/include
--Makefile (after running ./configure)
SHELL = /bin/sh
srcdir = .
top_srcdir = .
prefix = /usr/local
exec_prefix = ${prefix}
bindir = ${exec_prefix}/bin
sbindir = ${exec_prefix}/sbin
libexecdir = ${exec_prefix}/libexec
datadir = ${prefix}/share
sysconfdir = ${prefix}/etc
sharedstatedir = ${prefix}/com
localstatedir = ${prefix}/var
libdir = ${exec_prefix}/lib
infodir = ${prefix}/info
mandir = ${prefix}/man
includedir = ${prefix}/include
oldincludedir = /usr/include
--
Looking at the Makefile* (relevant parts below), I believe that changing the
prefix line
to prefix = /usr will solve the problem for some files but others won't
have a place to go,
for example, the /usr/etc dir does not exist.
What should i do?
thanks,
--
Robert MillanDebian GNU (Hurd) user
zeratul2 wanadoo eshttp://getyouriso.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
;;
;; Matthew Danish email: [EMAIL PROTECTED] ;;
;; OpenPGP public key available from:'finger [EMAIL PROTECTED]' ;;
;;
Re: Makefile.in
On Sun, Jul 08, 2001 at 12:51:31PM -0400, [EMAIL PROTECTED] wrote: Use the --prefix=/usr option to ./configure Then when running 'make install' do this instead: 'make install prefix=/path/to/temporary/directory' Also, set --mandir=/usr/share/man and --infodir=/usr/share/info, if applicable. And if you're installing things in /etc, set --sysconfdir=/etc. In general: don't be afraid to run ./configure --help nor to read the INSTALL file! -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Re: Re: Makefile.in
On Sun, 8 Jul 2001 12:51:31 -0400, [EMAIL PROTECTED] wrote: Use the --prefix=/usr option to ./configure Then when running 'make install' do this instead: 'make install prefix=/path/to/temporary/directory' On Sun, 8 Jul 2001 13:08:57 -0400, Steve M. Robbins [EMAIL PROTECTED] wrote: Also, set --mandir=/usr/share/man and --infodir=/usr/share/info, if applicable. And if you're installing things in /etc, set --sysconfdir=/etc. In general: don't be afraid to run ./configure --help nor to read the INSTALL file! i'm sorry, i forgot to say i don't want to install it but to make a package :) will changing the prefix = @prefix@ line to prefix = /usr do? --Makefile.in SHELL = @SHELL@ srcdir = @srcdir@ top_srcdir = @top_srcdir@ VPATH = @srcdir@ prefix = @prefix@ exec_prefix = @exec_prefix@ bindir = @bindir@ sbindir = @sbindir@ libexecdir = @libexecdir@ datadir = @datadir@ sysconfdir = @sysconfdir@ sharedstatedir = @sharedstatedir@ localstatedir = @localstatedir@ libdir = @libdir@ infodir = @infodir@ mandir = @mandir@ includedir = @includedir@ oldincludedir = /usr/include --- thanks, -- Robert MillanDebian GNU (Hurd) user zeratul2 wanadoo eshttp://getyouriso.org/
Re: Re: Makefile.in
On Sun, Jul 08, 2001 at 08:57:38PM +0200, Robert Millan wrote: On Sun, 8 Jul 2001 12:51:31 -0400, [EMAIL PROTECTED] wrote: Use the --prefix=/usr option to ./configure Then when running 'make install' do this instead: 'make install prefix=/path/to/temporary/directory' On Sun, 8 Jul 2001 13:08:57 -0400, Steve M. Robbins [EMAIL PROTECTED] wrote: Also, set --mandir=/usr/share/man and --infodir=/usr/share/info, if applicable. And if you're installing things in /etc, set --sysconfdir=/etc. In general: don't be afraid to run ./configure --help nor to read the INSTALL file! i'm sorry, i forgot to say i don't want to install it but to make a package :) Making a package involves installing it! You had better re-read the packaging manual. The New Maintainer's Guide http://www.debian.org/doc/maint-guide/ is quite good. Then have a look at debian/rules in a package that uses autoconf (e.g. isapnptools). will changing the prefix = @prefix@ line to prefix = /usr do? No. -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Re: Re: Re: Makefile.in
On Sun, 8 Jul 2001 15:06:31 -0400, Steve M. Robbins [EMAIL PROTECTED] wrote: Making a package involves installing it! You had better re-read the packaging manual. The New Maintainer's Guide http://www.debian.org/doc/maint-guide/ is quite good. But the maint-guide tells me to modify the Makefile.in file, in order to build the package with dpkg-buildpackage -rfakeroot later. I'd like to create a source package so i can compile it later for specific archs, does this procedure create a source package too? thank you, -- Robert MillanDebian GNU (Hurd) user zeratul2 wanadoo eshttp://getyouriso.org/
Re: undocumented(7)
[I think Colin reads this list, but CCing @packages to be sure.]
Matt Zimmerman [EMAIL PROTECTED] writes:
undocumented(7) is in the manpages package (Priority: important). It seems
sensible to allow users to remove this package without breaking anything, and
if they care enough to remove the manpages package, they probably won't miss
undocumented(7).
Wouldn't it be better to just move undocumented(7) (it's 1415 bytes,
FWIW) to man-db? This way all users of man would have it.
Thinking a bit further ... symlinking to undocumented is often frowned
upon, because it muddles up the issue (and novice packagers often
conveniently think that it is a permanent solution), and sometimes
raises false expectations (i.e. I install a package, look at dpkg -L
output, think: fine, a manpage is provided). Sooo, why not patch the
man binary to issue a more helpful message?
I.e. if manpage FOO was sought, and FOO exists in {,/usr}/{,s}bin:
No manual entry for FOO
This is probably a bug you should report.
In the mean time, please try to find usage information through other
means -- try man undocumented if you are unsure.
--
Robbe
signature.ng
Description: PGP signature
Re: Procedural clarification
Greg Wiley [EMAIL PROTECTED] writes: The question is: which do I do first, announce my intentions to debian-devel or submit a new main- tainer application? The application seems to want me to announce. Other docs seem to indicate that I should become a maintainer first. You can become a NM without having a package in Debian. Showing off a good package is a fine way, to demonstrate that you have the necessary skills, but it is this package need not be an official Debian one. OTOH, you don't have to be a Debian developer to contribute official packages. If you aren't, you need a sponsor who is a developer. S/he will check if your package is done right, and provide the stamp of approval so it can be uploaded into Debian. Nowadays, you also need an advocate who is a Debian develper, to get into the NM queue. Following from all this, I recommend: 1. Announce that you're willing to adopt package X, but that you'll need a sponsor. Don't forget to Cc: the WNPP bug for package X. 2. Wait until a sponsor contacts you. 3. Do the necessary work on package X, and send the results to your sponsor. Repeat until s/he is satisfied -- then your package will be uploaded by the sponsor. 4. Ask your sponsor whether s/he would advocate for you. If s/he is willing, apply for NM. -- Robbe signature.ng Description: PGP signature
g++ 3.0
I have a package (exult) using C++. It reportedly does not work very good on certain architectures when compiled with g++ 2.95, so I want to move it to g++ 3.0. I read on -devel that compiling packages with g++ 3 is problematic since they will not correctly link with C++ libraries built with an older compiler. I figure this will not be a problem for my package because it does not depend on any C++ libraries other than libstdc++, which should be ok. Normal C libraries are no bother, I assume. Is this correct? If yes, I'd like to have comments on my method: I build-depend on g++-3.0, and do CC=gcc-3.0 CXX=g++-3.0 ./configure ... in my rules. -- Robbe signature.ng Description: PGP signature
Re: missing file in my package
What DH_COMPAT are you using ? PD : tienes tu clave firmada ya ? On Sun, Jul 08, 2001 at 02:13:31PM +0200, Robert Millan wrote: Hello, I'm having some trouble in packaging a program called esms. It only consists of a single binary-all (perl) file that must go on /usr/bin/esms. The problem is that the package is created without it, here's a snapshot of an alienized package: bash-2.03$ tar -xvzf esms-0.9.0-2.tgz ./ ./usr/ ./usr/bin/ ./usr/share/ ./usr/share/doc/ ./usr/share/doc/esms/ ./usr/share/doc/esms/copyright ./usr/share/doc/esms/changelog.Debian.gz bash-2.03$ Here is the (IMHO) relevant part of my debian/rules file: install: build dh_testdir dh_testroot dh_clean -k dh_installdirs # Add here commands to install the package into debian/tmp. install -d debian/tmp/usr/bin install -m755 -o root -g root `pwd`/esms `pwd`/debian/tmp/usr/bin/esms If i missed some information let me know and i'll post it here. Thanks, -- Robert MillanDebian GNU (Hurd) user zeratul2 wanadoo eshttp://getyouriso.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: Re: missing file in my package
On Mon, 9 Jul 2001 01:04:49 +0200, Eric Van Buggenhaut [EMAIL PROTECTED] wrote: What DH_COMPAT are you using ? I was using DH_COMPAT=2 as you told me in another question, now i've been told that when using the debian/tmp directory i need DH_COMPAT=1 (i noticed you are using debian/package_name directory). So don't worry it's working right now and i've finally made the package. Regards, -- Robert Millan Debian GNU (Hurd) user zeratul2 wanadoo es http://getyouriso.org/
Re: Re: missing file in my package
On Mon, Jul 09, 2001 at 01:55:35AM +0200, Robert Millan wrote: On Mon, 9 Jul 2001 01:04:49 +0200, Eric Van Buggenhaut [EMAIL PROTECTED] wrote: What DH_COMPAT are you using ? I was using DH_COMPAT=2 as you told me in another question, now i've been told that when using the debian/tmp directory i need DH_COMPAT=1 (i noticed you are using debian/package_name directory). So don't worry it's working right now and i've finally made the package. This isn't your best move. You *should* use DH_COMPAT=2 and install the files in debian/package_name When this is corrected, I can have a look at your package and upload it. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
openacs docs version number
Hi, I recently adopted openacs package. Upstream FTP site provides 2 packages : openacs-3.2.5.tar.gz and openacs-3.2.5-docs.tar.gz. How should I version-number the doc package ? Would openacs-docs_1.0 be OK or shoud I try to stick to binaries package version for now and the future ? Thanks. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: Re: Re: Makefile.in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 08 July 2001 9:57 pm, Robert Millan wrote:
On Sun, 8 Jul 2001 15:06:31 -0400, Steve M. Robbins
[EMAIL PROTECTED] wrote:
Making a package involves installing it!
You had better re-read the packaging manual. The New Maintainer's
Guide http://www.debian.org/doc/maint-guide/ is quite good.
But the maint-guide tells me to modify the Makefile.in file, in order
to build the package with dpkg-buildpackage -rfakeroot later.
I'd like to create a source package so i can compile it later for
specific archs, does this procedure create a source package too?
thank you,
Looking at a sample debian./rules (this one from apt-spy which I have
passing familiarity with), the configure-stamp: target:
configure-stamp:
dh_testdir
./configure --program-transform-name=s/apt-sources/apt-spy/ \
- --prefix=/usr --mandir=\$${prefix}/share/man \
- --infodir=\$${prefix}/share/info
touch configure-stamp
Basically you do the ./configure (with associated options) *inside*
debian/rules. Do not edit or alter upstream makefiles if you can help
it at all would appear to be the rule of thumb. Obviously if there is
no other way to do something then you should do it in the makefile, but
I would say that in this case, passing options to ./configure should do
what you need. (./configure --help | less is a useful thing to do).
Hope that points in the right direction.
- --
Stephen Stafford
GPG public key on request
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7SPvQFwmY7Xa4pD0RAjseAJ4orsQAKvAE+XKZmxh3Ao6gyApUCQCgkfnW
oBXIUIrt39N8UPAPY623Plo=
=nof2
-END PGP SIGNATURE-
Re: undocumented(7)
On Sun, 08 Jul 2001 at 20:21:09 +0200, Robert Bihlmeyer wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
undocumented(7) is in the manpages package (Priority: important).
It seems sensible to allow users to remove this package without
breaking anything, and if they care enough to remove the manpages
package, they probably won't miss undocumented(7).
Wouldn't it be better to just move undocumented(7) (it's 1415 bytes,
FWIW) to man-db? This way all users of man would have it.
*sigh* There are multiple man browsers in Debian: gman, gnome-help,
konqueror, and tkman all provide man-browser, and coolman should. It's
inappropriate to put something used by all of them into man-db just
because it's the one most people use.
Thinking a bit further ... symlinking to undocumented is often frowned
upon, because it muddles up the issue (and novice packagers often
conveniently think that it is a permanent solution), and sometimes
raises false expectations (i.e. I install a package, look at dpkg -L
output, think: fine, a manpage is provided). Sooo, why not patch the
man binary to issue a more helpful message?
I.e. if manpage FOO was sought, and FOO exists in {,/usr}/{,s}bin:
No manual entry for FOO
This is probably a bug you should report.
In the mean time, please try to find usage information through other
means -- try man undocumented if you are unsure.
It seems a bit silly, because, well, that's what undocumented(7) says
except in less detail. It also seems like more cruft in the already
crufty man binary. Feel free to write a patch if you think it's useful,
though, but you'll need to get all manual browsers changed before policy
13.1 can properly be amended.
--
Colin Watson [EMAIL PROTECTED]
Re: Procedural clarification
This is a multi-part message in MIME format. It has been signed conforming to RFC2015. You'll need PGP or GPG to check the signature. =_994626186-1074-2 Content-Type: text/plain; charset=us-ascii Greg Wiley [EMAIL PROTECTED] writes: The question is: which do I do first, announce my intentions to debian-devel or submit a new main- tainer application? The application seems to want me to announce. Other docs seem to indicate that I should become a maintainer first. You can become a NM without having a package in Debian. Showing off a good package is a fine way, to demonstrate that you have the necessary skills, but it is this package need not be an official Debian one. OTOH, you don't have to be a Debian developer to contribute official packages. If you aren't, you need a sponsor who is a developer. S/he will check if your package is done right, and provide the stamp of approval so it can be uploaded into Debian. Nowadays, you also need an advocate who is a Debian develper, to get into the NM queue. Following from all this, I recommend: 1. Announce that you're willing to adopt package X, but that you'll need a sponsor. Don't forget to Cc: the WNPP bug for package X. 1.5 You might use the sponsorship program in the meanwhile. Search for the link `sponsorship program' on http://www.debian.org/devel 2. Wait until a sponsor contacts you. 3. Do the necessary work on package X, and send the results to your sponsor. Repeat until s/he is satisfied -- then your package will be uploaded by the sponsor. 4. Ask your sponsor whether s/he would advocate for you. If s/he is willing, apply for NM. -- Robbe =_994626186-1074-2 Content-Type: application/pgp-signature; name=signature.ng Content-Disposition: inline; filename=signature.ng Content-Transfer-Encoding: 7bit -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SMqL8g21h7wYWrMRAhvvAJ9bWPugDiYz/lRdAWNTeg2BLoat0gCeKUhP 2gcZXbCREBvQ0R7dC+vGYGY= =1M5w -END PGP SIGNATURE- =_994626186-1074-2-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Shaul Karl [EMAIL PROTECTED] Hillel used to say: If I am not for myself who will be for me? Yet, if I am for myself only, what am I? And if not now, when? (Ethics Of The Fathers 1:14)
Re: undocumented(7)
Mark Brown [EMAIL PROTECTED] wrote: From undocumented(7): | This program, utility or function does not have a useful | manpage. Please do not report this as a bug, because this | has already been reported as a bug; when a manpage becomes But if undocumented(7) is unavailable, I don't see that message. I see No manual entry for foo, and then proceed to file a bug. It was only through further investigation that I realised the bug had already been filed and that the man page was really a dangling symlink. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgptCpHeaLvPC.pgp Description: PGP signature
Re: g++ 3.0
On Sun, Jul 08, 2001 at 11:01:52PM +0200, Robert Bihlmeyer wrote: I read on -devel that compiling packages with g++ 3 is problematic since they will not correctly link with C++ libraries built with an older compiler. I figure this will not be a problem for my package because it does not depend on any C++ libraries other than libstdc++, which should be ok. Normal C libraries are no bother, I assume. Is this correct? If the problem occurs only on certain architectures, you may want to try it yourself on as many as possible before switching entirely to g++-3.0. On some Debian architectures, 3.0 is already the default compiler (see the source for gcc-defaults, I think). If those are the same architectures where your package has problems, then there is no problem for Debian. As long as it doesn't link against any other C++ libraries, it should work, yes. Whether or not this is a good idea, I'm not sure. There are issues with g++-3.0 other than ABI compatibility (such as debugging). It seems to be available on all platforms, though, so it might be worth a try if it turns out to be necessary. It might be wise to restrict the change to the problematic architectures, though. -- - mdz
Re: openacs docs version number
Personally, I would use the source package's version # in this case. The docs may be fairly version-dependent (i.e. openacs 4.0 may change a great deal of things, and openacs-docs 4.0 would document the new interfaces), so sharing version numbers makes it much clearer... On Mon, Jul 09, 2001 at 02:16:43AM +0200, Eric Van Buggenhaut [EMAIL PROTECTED] spake forth: Hi, I recently adopted openacs package. Upstream FTP site provides 2 packages : openacs-3.2.5.tar.gz and openacs-3.2.5-docs.tar.gz. How should I version-number the doc package ? Would openacs-docs_1.0 be OK or shoud I try to stick to binaries package version for now and the future ? Thanks. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Mike Markley [EMAIL PROTECTED] GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 Behind every great man, there is a woman -- urging him on. - Harry Mudd, I, Mudd, stardate 4513.3
