Re: Packaging with CMake
Jose Luis Blanco [EMAIL PROTECTED] writes: If your question is how to build a Debian package... I don't know about any standard procedure. I had to do such one package and I created a dummy configure scripts which in turn calls cmake with some proper variables set. Apart from that configure, the rest is using the standard Debian packaging tools. If anyone knows about a more elegant way than the dummy configure file, I'd be also interested in it :-) Why not take the commands in your dummy configure script and just put them directly into debian/rules? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Perl testing (prove) dependencies
Peter Pentchev [EMAIL PROTECTED] writes: Now, since confget already depends on debhelper which obviously pulls in most of Perl, may I just make use of that, or should I add an explicit build dependency on perl | libtest-harness-perl, just in case the build mechanism changes at some point in the future? It's always a good idea to add an explicit dependency for anything that you use, even if it's pulled in by some other dependency, unless the *definition* of that other dependency is that it will always pull in what you're looking for. Since providing Perl isn't a function of debhelper, you should depend on it explicitly if you use it. This isn't just in case the build system changes. It's also documentation. It's useful to humans to have complete build dependencies, even if a computer doesn't care. perl | libtest-harness-perl probably isn't necessary, though. Just listing perl is fine, unless you are trying to support backports to a verison of the perl package before Test::Harness was added to core. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian policy, a problem or a misunderstand ?
Eduardo M KALINOWSKI [EMAIL PROTECTED] writes: They are confusing indeed. It would be better if it was written ... that they exit with a zero return status if everything went well. Comments, your could a wishlist bug be filled suggesting this wording change? No need, I just changed this in Policy's Git repository. It will be in the next release. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting -m64 at the right time and place.
Charles Plessy [EMAIL PROTECTED] writes:
Would the following patch make sense?
diff --git a/configure.ac b/configure.ac
index ad2f1e6..4f2993a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,10 +23,7 @@ case ${host_cpu}-${host_os} in
AC_COMPILE_IFELSE([AC_LANG_PROGRAM], [ext_CFLAGS=-m64],
[]);;
esac;;
*)
-AC_MSG_CHECKING([if gcc accepts -m64])
-CFLAGS=-m64
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM], [ext_CFLAGS=-m64;
AC_MSG_RESULT([yes])],
-
[ext_CFLAGS=-D_FILE_OFFSET_BITS=64; AC_MSG_RESULT([no])]);;
+ext_CFLAGS=-D_FILE_OFFSET_BITS=64;;
esac
AC_ARG_ENABLE(experimental, [ --enable-experimental enable experimental
features],
[ext_CFLAGS=${ext_CFLAGS}
-DMAQ_SHOW_EXPERIMENTAL], [])
The above change is probably fine, but the ideal solution would be for
upstream to stop trying to code this directly and instead use the Autoconf
macro provided for this purpose. AC_SYS_LARGEFILE will add to CFLAGS
whatever flags are needed to enable large files. (Unfortunately, since
upstream is using ext_CFLAGS instead of CFLAGS, you may not be able to
just delete upstream's Autoconf code and add that macro.)
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xinha
Raphael Geissert [EMAIL PROTECTED] writes: Build-Depends: debhelper (= 6.0.7~) what is that tilde doing there? (lintian should probably warn about it) It allows the package to build with backports of debhelper 6.0.7. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: webcpp
Cyril Brulebois k...@debian.org writes: Raphael Geissert atomo64+deb...@gmail.com (11/12/2008): 1) ancient-libtool is about porting, is there an FTBFS bug open? Said otherwise: is there an arch where there is an actual FTBFS? ancient-libtool was added at the explicit request of the porters because they were seeing obscure bugs and issues on some architectures unless a current version of libtool was used. These sorts of bugs unfortunately are the kind that can be hidden or cause weird failures. I really think this one should be fixed. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: furl
Jonathan Wiltshire deb...@jwiltshire.org.uk writes: More fundamentally: What does furl do that other packages can't? We already have curl, lynx, wget and even telnet can be used to dump headers. Can you justify having this package in the archive? Also, HEAD from the libwww-perl package, which is designed for exactly this purpose. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Arch:all package depending on package that isn't Arch:any
Kevin Glynn kevin.gl...@gmail.com writes: This is in reference to serious bug#511184. The mozart package can only be built for 32 bit architectures, so its arch line is: Architecture: hppa i386 m68k mipsel mips powerpc sparc s390 arm armeb armel kfreebsd-i386 Its standard library (package mozart-stdlib) contains only architecture independent files, and its control file has: Package: mozart-stdlib Architecture: all Depends: mozart (= 1.3.0) As bug 511184 points out mozart-stdlib is arch: all but uninstallable on (e.g.) amd64. I can't find clear guidance from the developer's reference or policy (apologies if I've overlooked this). I see three options: 1. Leave as is (its been like this for years and years). Not installing on amd64 is reasonable. This feels like the right option to me. I don't think this is an RC bug. There are other examples of this in the archive (openafs-modules-source, for instance, which while installable on mipsel is completely useless on that platform since it won't compile and there's no userspace). Adding an explicit architecture to the package wastes archive space by duplicating the package on all 32-bit platforms. It would be nice if there were some way of telling the archive software not to include this package in the archive index on the platforms it doesn't support, though. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
Ben Finney ben+deb...@benfinney.id.au writes: I never invoke ‘dpkg-genchanges’ manually; that's done by ‘dpkg-buildpackage’, which in turn is usually invoked by something else (e.g. ‘pbuilder’ or ‘bzr-buildpackage’ etc.) Is there a normal way to have ‘dpkg-genchanges’ always understand “include all entries newer than what's currently in Debian”? Most of the helpers that sit in front of dpkg-buildpackage will pass the -v option all the way through or have some way of doing so, probably for precisely this reason. git-buildpackage passes all unknown options to debuild, for example, which then passes it along to dpkg-buildpackage and from there to dpkg-genchanges. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
Ben Finney ben+deb...@benfinney.id.au writes: Okay. So is there a normal way to have the ‘-v’ option during a run set to “include all entries newer than what's currently in Debian”? Or do I have to remember to set it manually each time I add a new release and build? I have to look it up for my packages, but you could script something fairly easily via a wrapper around whatever package building tool that you use. Something like: #!/bin/sh set -e package=`dpkg-parsechangelog | grep ^Source: | cut -f 2 -d ' '` current=`apt-cache showsrc $package | grep ^Version: | cut -f 2 -d ' ' \ | sort -r | head -n 1` if [ -n $current ] ; then git-buildpackage -v$current $@ else git-buildpackage -v0 $@ fi This assumes apt-cache showsrc will find packages in unstable and experimental. If it won't, you may have to do something more complicated (grep-dctrl would probably help). The sort there isn't entirely correct; you really want to do a dpkg version comparison. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
Cyril Brulebois k...@debian.org writes:
Ben Finney ben+deb...@benfinney.id.au (19/01/2009):
latest_debian_version=$(rmadison --suite ${suitename} ${packagename} \
| cut -d'|' -f 2 | sed -e 's/^[[:space:]]+//')
Beware, you need to limit that to the source (in case there's a binary
built that has the same name, and in case there are some archs out of
sync), e.g.:
| $ rmadison --suite unstable guile-1.6
| guile-1.6 |1.6.8-6 | unstable | hppa, m68k, sparc
| guile-1.6 | 1.6.8-6.1 | unstable | source, alpha, amd64, arm, armel,
hurd-i386, i386, ia64, mips, mipsel, powerpc, s390
It would be great to get this into debuild as an option, so that you could
pass it some flag and it would do this work to figure out the last Debian
version and include all the changelog entries to that point.
Maybe someone (Ben, perhaps?) could open a wishlist bug against devscripts
with the final version of the code?
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dh 7 broken by design?
Helmut Grohne hel...@subdivi.de writes: So will the new minimal example look like the following then? #/usr/bin/make -Bf %: dh $@ If the -B flag is necessary, this will require a change in Debian Policy; currently, the above arguably violates a must. I'm inclined to think this isn't the right solution, since it also breaks invoking debian/rules as a makefile instead of as an executable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dh 7 broken by design?
Helmut Grohne hel...@subdivi.de writes: On Tue, Feb 17, 2009 at 07:40:41PM -0500, Joey Hess wrote: Helmut Grohne wrote: So will the new minimal example look like the following then? #/usr/bin/make -Bf %: dh $@ Yes, that's how it's looking now. You should then take Russ Allbery's comment into account: On Tue, Feb 17, 2009 at 02:06:09PM -0800, Russ Allbery wrote: If the -B flag is necessary, this will require a change in Debian Policy; currently, the above arguably violates a must. I'm inclined to think this isn't the right solution, since it also breaks invoking debian/rules as a makefile instead of as an executable. We probably need a different solution for this. :-/ I really think this is a bug in make. We can change Policy if we have to. Arguably that line complies with Policy, but it feels icky to me; Policy's requirement that debian/rules be a makefile to me means that you should be able to use it as a makefile, which means not requiring special make flags. Policy also currently says: It must start with the line #!/usr/bin/make -f, so that it can be invoked by saying its name rather than invoking make explicitly. but that's a bit more nit-picky. More to the point, though, declaring a target as .PHONY shouldn't, I think, cause it to not be processed by pattern rules. That really feels like a bug in make that should be fixed in make, and then debhelper can just depend on a fixed version of make. I'd much rather see that approach than adding a workaround by adding -B. You still then have to list the rules as .PHONY in the minimal makefile, which is annoying, but you only have to do that if your particular package has files by those names. Right now, rather than changing dh, I'd recommend that people who have packages that have such files just not use the dh 7 minimal makefile and instead spell out the necessary rule. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dh 7 broken by design?
Joey Hess jo...@debian.org writes: Russ Allbery wrote: I really think this is a bug in make. Probably, but who knows. It could just be a misfeature on which ghod knows what somehow depends. .PHONY: precompiled-binary-we-cannot-regenerate-with-gcc.o It feels like the next step is to ask make upstream whether they think this is a bug that can be fixed. If so, great, and we can move forward with that approach. If not, we can pursue the alternatives. But it seems like it would be worthwhile to ask. Given that you can achieve the same goal in a much more straightforward and traditional manner (I think) with: precompiled-binary-we-cannot-regenerate-with-gcc.o: it feels like an unintentional side effect of an internal implementation to me. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libpam-paperauth
Luke Faraone l...@faraone.cc writes: On Wed, Mar 4, 2009 at 6:05 AM, Kapil Hari Paranjape ka...@imsc.res.inwrote: On Fri, 27 Feb 2009, Luke Faraone wrote: I am looking for a sponsor for my package libpam-paperauth. Generally looks good. However, it fails to build from source. The pbuilder build returned the following error: /usr/bin/ld: pam_ppp_so-pam_ppp.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC pam_ppp_so-pam_ppp.o: could not read symbols: Bad value Very strange. It builds fine here; any idea why that could be the case? The above is a problem with non-PIC code in a shared library. If you're building on i386, you won't see those problems because i386 permits this (with a performance penalty). You need to build on amd64 or another platform where shared libraries require PIC to see the problem. Lintian should also warn about this, though, even on i386. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: best practice for updating inetd.conf with a user-chosen port?
Eric Cooper e...@cmu.edu writes: Regarding the other thread in -devel about the future of inetd: in my case I found it very sensible to jettison all the code for opening sockets, binding ports, handling IPv6, handling tcp-wrappers, daemonizing processes, etc. and punt it to inetd. Since apt clients keep their connections open for many multiple, the performance hit is negligible. Yeah, I disagree with the idea that inetd is a bad choice for new programs. Writing a standalone daemon requires a fair bit of networking knowledge and work, particularly if you also want to support IPv6, and inetd can already do all that for you. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: substvar-source-version-is-deprecated
Jaromír Mikeš mira.mi...@seznam.cz writes:
having this warning message from lintian.
Even I was qooqling a lot I didn't found clear answer how to repair it.
lintian -i says:
The package uses the now deprecated ${Source-Version} substvar, which has
misleading semantics. Please switch to ${binary:Version} or
${source:Version} as appropriate (introduced in dpkg 1.13.19, released
with etch). Support for ${Source-Version} may be removed from dpkg-dev
in the future.
Is that still unclear?
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Fixing old-fsf-address-in-copyright-file
Ben Finney ben+deb...@benfinney.id.au writes: Do you agree with Eduardo's argument below: Eduardo M KALINOWSKI edua...@kalinowski.com.br writes: IANAL, but I don't think the address is part of the license. I believe the address can be changed to reflect the correct information, if the rest of the license information is kept. The address is part of the “you should have received a copy of the GPL, if not write to the FSF” text. Either that text is part of the text that must be in ‘debian/copyright’ verbatim, by policy; or it is not. So far as I can tell from the GPL 2 and GPL 3, Eduardo is correct and the address portion is not part of the notices that the GPL requires be maintained. If it is not required to be verbatim in ‘debian/copyright’, then why include it at all? I don't see any reason to do so at the moment. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
Chow Loong Jin hyper...@gmail.com writes: Regarding the DFSG-compliance of this .jar, I've looked through the DFSG, and don't see where this could be a problem. DFSG mainly prohibits distribution of binaries without sources. This is a binary with the source, but cannot be compiled due to a non-free build-dependency. That would mean it should go into contrib, which is for DFSG-free things that can't be built or used without non-free bits. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
Chow Loong Jin hyper...@gmail.com writes: On Thu, 2009-03-26 at 10:53 -0700, Russ Allbery wrote: That would mean it should go into contrib, which is for DFSG-free things that can't be built or used without non-free bits. I'm actually considering using a postinst script to tell the user that there is a .jar that they need to download and upload to their phone, and possibly wget it as well. Either that or put details about this in README.Debian. Supposing I do either one of the above, would it still go into contrib, or can it go into main? It's kind of an edge case since it sounds like the software on the Debian side is completely functional without the JAR and the JAR is instead for the remote system. We package servers for which we don't package a client, and you could argue that this is a similar situation. I'd personally tend to say that, doing the above and assuming my characterization is correct, it would be okay to put that in main. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why the maintainer bother to use set -e instead of #!/bin/sh -e for all maintainer scripts?
e2xbegqsdyt21hfc e2xbegqsdyt21...@yahoo.com writes: $ zcat /usr/share/doc/libkrb53/changelog.Debian.gz | grep 'Use set' * Use set -e instead of #!/bin/sh -e for all maintainer scripts. $ Why bother? What difference does it make? set -e is always honored; -e on the #! line is only honored if the script is run as a regular executable, not explicitly with sh. Normally it makes no difference; the exception is if you run the test manually while debugging it. The reason why Lintian added a (pedantic) tag for this is that when you're debugging a postinst script and you run it with sh -x /var/lib/dpkg/info/foo.postinst, and then it doesn't exit on error, it's surprising and can be dangerous. It's an unusual situation, which is why it's only tagged with --pedantic. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: double slash
Jaromír Mikeš mira.mi...@seznam.cz writes: I am building library with four packages. And I need to spread installed files to packages using packagename.install files. I have a problem here with this. I notice that install process yielding files like: /tmp/buildd/slv2-0.6.2/debian/slv2/usr/include//slv2/pluginclass.h Can be double slash behind include problem? As mentioned already, this isn't a problem. If you were curious why it's happening, it's generally because upstream has written their makefiles to install files into: $(DESTDIR)/$(prefix) instead of: $(DESTDIR)$(prefix) I used to write my makefiles that way too. It's hard to shake the feeling that there should be a slash in there. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: double slash
Chow Loong Jin hyper...@gmail.com writes: Looking at where the extra / is, I'd think more like: pkgincludedir = $(includedir)/slv2 rather than pkgincludedir = $(includedir)slv2 Oh, hm, good point. In that case, it is a little odd that $(includedir) has a trailing slash. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: kio-ftps (updated package)
Laurent Léonard laur...@open-minds.org writes: I agree with that. My question only concerns thx +dfsgX versioning instead of a simple +dfsg suffix in this case where there is only 1 documentation file dropped for DFSG reason. Given that +dfsg1 sorts after +dfsg anyway, I think it's fine to omit the version number if you expect not to need it. I plan on starting to omit the version number after dfsg in the next upstream release for some of my repackaged source packages where the repackaging has been stable for quite some time. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: docutils-writer-manpage 0.1~svn.r5690-2, urgency=medium
Ben Finney ben+deb...@benfinney.id.au writes: Piotr Ożarowski pi...@debian.org writes: * lintian 2.2.9 only informs about extended-description-is-probably-too-short, please remove all overrides Aren't we supposed to release packages that are lintian clean, even to the ‘info’ level? I would tend to add overrides for info-level tags. It's only pedantic tags that I recommend against overriding. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian question
Charlie Smotherman cj...@cableone.net writes: The file that lintian is complaining about is usr/share/ampache/www/modules/getid3/module.archive.gzip.php As you can see the file clearly does not end with .gz but instead it ends in php. This file is not compressed with gzip but instead adds gzip functionality to the app. It's a bug in Lintian (already reported, will be fixed in the next release). Would an override of this Lintian warning be appropriate? We (the Lintian developers) would rather you not add overrides for Lintian bugs, since you'll just have to remove the override again and in some cases it can hide other problems that are real. We in turn try to fix bugs quickly, although I've been swamped lately so the pace of releases has dropped. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: questions regarding libmimelib1 as seperate source package
Jonas Meurer jo...@freesources.org writes: - I bumbed the library version to 1.1.4 and kept soname libmimelib.so.1 from the libmimelib1c2a package. The source changes I made where simple strlcpy() - strncpy() migration, so a soname bump should not be necessary. Just to double-check, you added explicit nul termination for all strings as an additional line of code when making that change, correct? (I personally prefer to ship a replacement strlcpy function rather than using strncpy, since the strncpy semantics are rather broken.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: questions regarding libmimelib1 as seperate source package
Jonas Meurer jo...@freesources.org writes: Unfortunately ron discovered a far worse issue. The way str[ln]cat() is used in mimelib makes it very error-prone to buffer overflows: #define SEND_BUFFER_SIZE 1024 ... mSendBuffer = new char[SEND_BUFFER_SIZE]; ... strlcpy(mSendBuffer, PASS , SEND_BUFFER_SIZE); strlcat(mSendBuffer, aPasswd, SEND_BUFFER_SIZE); strlcat(mSendBuffer, \r\n, SEND_BUFFER_SIZE); this without any santising code for aPasswd causes mSendBuffer to be overflowable for at least strlen(PASS ) + strlen(\r\n). That code is safe from a buffer overflow perspective using strlcpy and strlcat, but may not end the buffer with \r\n. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: questions regarding libmimelib1 as seperate source package
Jonas Meurer jo...@freesources.org writes: But in that case I've a simple question: if I put both defines into a seperate c source file strl___.c, how do I teach the autotools to use this file when compiling nntp.cpp, pop.cpp and uuencode.cpp? AC_REPLACE_FUNCS([strlcpy strlcat]) in configure.ac and then include LTLIBOBJS in the list of objects that go into the shared library in your Makefile.am. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question about README.source
Laurent Léonard laur...@open-minds.org writes: I didn't found any standard template for DFSG and various files removing for README.source, so can I use the following generic sentence ? The following files were removed from the original source tree: CMakeLists.txt~ ftp.cpp~ ftp.h~ ftp.protocol~ README~ rfc4217.txt I'd put that information in debian/copyright instead. (What you have sounds fine, or you could just say that you removed rfc4217.txt for DFSG reasons and, since you were repackaging the source anyway, removed all *~ files.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: mimelib 1.1.2 packages: strlcpy/strlcat vs. strcpy/strcat
Aljoscha Lautenbach aljoscha.lautenb...@gmail.com writes: A simple grep -r 'size_t strlcpy' in the source directory of the kernel shows that the function is indeed defined for the kernel in $source/include/linux/string.h and is implemented in $source/lib/string.c. That unfortunately doesn't help unless you're writing kernel modules. That's an implementation inside the kernel only for code running inside the kernel; it isn't available to normal programs. I just provide replacement implementations of strlcpy and strlcat with all of the software I write that ends up needing to use it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Documenting new upstream version in ‘debian /changelog’
Ryan Niebur ryanrya...@gmail.com writes: On Tue, Apr 28, 2009 at 11:31:35AM +1000, Ben Finney wrote: I wholeheartedly agree with this, and would go further: even if there are no Debian BTS reports to close, you should *still* give the highlights of a new upstream version in the ‘debian/changelog’. I'm utterly uninformed by a bare “New upstream release.”; of course it's a new upstream release, I can already see that from the version number. This is a changelog, tell me *what changed* in this new upstream version. I don't see the need for this. For most packages upstream's changelog is installed in /usr/share/doc/$PACKAGE/, which will (hopefully) explain all you need to know. The upstream changelog isn't displayed by apt-listchanges, so is much, much less useful. It's also often pretty bad, either including way more details than the average user cares about or including almost nothing. I'm with Ben; I try to summarize major changes for all of my packages that are likely to affect users in the Debian changelog. I don't always manage, but I try. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On the quest for automated QA checks
Rogério Brito rbr...@ime.usp.br writes: * for instance deprecated debhelper programs should generate a big fat warning and, while they don't do that, detecting them. Lintian should catch this already, although we may not have the most recent ones. If you know which are missing, please file a wishlist lintian bug. * seeing if the rules file has the maintainer overriding, say, CFLAGS and LDFLAGS. This is hard to analyze properly. The package should not be relying on environment variables set by dpkg-buildpackage, since then debian/rules build doesn't work. * seeing if a given package providing a library has the -dev package containing the soname in the name of the package (e.g., libfoo0-dev). This is sometimes the right thing to do, sometimes not. * seeing if the package would benefit from LDFLAGS like --as-needed or -z,defs in the linking stages. IMO, --as-needed is never a good idea. It's fairly hard to check except by analyzing a build log whether the package is using -z,defs, and it can be very hard to add that sort of flag to the upstream build system. * seeing if the package properly doesn't have unnecessary dependencies. Really, really hard to check in an automated way. * seeing if a -dev package has libc6-dev as one of its dependencies (it seems that the current lintian from unstable doesn't catch this). It should; please file a bug against lintian. * seeing if the long description passes a spell checker test (running ispell or whatever). Lots and lots of false positives for this. I don't think it's worth it. * seeing if the files in the debian directory have trailing whitespaces. Eh, really? I've never understood why people care about this. That being said, there's already a wishlist bug against Lintian to check for this at the --pedantic level. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On the quest for automated QA checks
Rogério Brito rbr...@ime.usp.br writes: I'd like to make it clear that I'm just brainstorming here and that at this stage, I'm not really concerned with the feasibility of the ideas. I'm just doing a what if thing. Oh, sure, totally understood. On May 02 2009, Russ Allbery wrote: Lintian should catch this already, although we may not have the most recent ones. If you know which are missing, please file a wishlist lintian bug. dh_movefiles doesn't seem to be catched, from tests of today. I don't know if lintian is really the proper place to put those tests, but it wouldn't hurt, even though I think that debhelper should generate such things. Ah, yes, that isn't deprecated, strictly speaking, but yeah, we should probably say something about that. Please do file a bug for that! I think Lintian's a good place to put such warnings. We already do so for several other deprecated debhelper programs. This is hard to analyze properly. The package should not be relying on environment variables set by dpkg-buildpackage, since then debian/rules build doesn't work. Hummm, I'm not sure that I get it, but it seems to me that dpkg-buildpackage already does that, doesn't it? It seems to pass flags like -O2 -Wall, if I'm not mistaken... Please *do* correct me if I am wrong. dpkg-buildpackage does, but I wish it didn't because people then assume that debian/rules can always rely on those variables being set. It can't, because building the package by calling debian/rules build directly is also valid, and is a pretty common thing to do for debugging and while working on problems. Or at least it can't right now; there's some discussion of changing that (and I owe Raphael a reply about that). * seeing if a given package providing a library has the -dev package containing the soname in the name of the package (e.g., libfoo0-dev). This is sometimes the right thing to do, sometimes not. I know, I know. Just putting a very low priority thing to lintian could be done... This one's hard -- it's part of a set of tags that one really wants to present once for the initial packaging in sort of an are you really sure way but then not show again. This is the place where I think something on mentors may make a ton of sense, or some way of putting a mode into Lintian for check my non-uploaded package. Let me restate here that I'm just brainstorming. Perhaps lintian could have a category of tests labelled expensive tests, where the person running lintian would be willing to run also a compilation thing in a chroot/virtual machine/whatever environment. I wonder if the easy way to do this would be to write something (this wouldn't be Lintian) that analyzes a build log for interesting issues. * seeing if the long description passes a spell checker test (running ispell or whatever). Lots and lots of false positives for this. I don't think it's worth it. This could be in the expensive category of tests, I think. Yeah, but this one I think you'll find is, in practice, pretty much unusable except maybe as a hint to someone who's willing to scan through all of the product names, people's names, partial URLs, command names, and so forth. Package descriptions are really horrible cases for conventional spell checking. Oh, perhaps, doing a licensecheck call could be a good thing, if only to let the maintainer know what is happening and that Debian *does* care about this. Yes. I think running licensecheck for mentors uploads would be great. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian clean?
Luca Niccoli lultimou...@gmail.com writes: Maybe write something like: [Check the package with lintian --pedantic and explain the reason for warnings and errors or state that is clean] I suppose it makes sense to recommend --pedantic if that's what all the mentors are using, but just to be clear from the Lintian dev perspective, we're totally okay with people deciding --pedantic is way too much and not bothering. My feeling is that there are perfectly reasonable Debian packages that aren't pedantic-clean (hell, many of my own aren't), and justifying all the --pedantic tags can be a little annoying. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian clean?
Patrick Matthäi pmatth...@debian.org writes: Russ Allbery schrieb: Given that anyone can upload packages to mentors, this seems like a fairly worrisome security risk. Why that? It may be implemented as the current Debian buildd network. OpenSuSE is also providing such a buildd service for their users, but yeah, we need more buildd servers for that (if the pkgs should be realy build for every arch). Builds are conventionally done as root under sbuild, and you can break out of chroots when you're root, thus enabling an attacker to upload a package that compromises the security of the buildd. Even if we implement a fakeroot-based build server, you're giving essentially random people on the Internet control over a local account on a system, and there are a lot of local root exploits. That's a pretty heavy security commitment for the system. You'd at least want to use SELinux pretty heavily, I'd think. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian clean?
Paul Wise p...@debian.org writes: I'd like a buildd network for mentors so we can check for FTBFS, lintian warnings etc on other architectures. Given that anyone can upload packages to mentors, this seems like a fairly worrisome security risk. I'd like to see our main archive require binary packages but throw them away so I'd like to have mentors do something similar. This seems like a good idea to me too. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gnus -- A versatile news and mail reader for Emacsen
Tommi Vainikainen thv+deb...@iki.fi writes: a short time ago I noticed that the world's best mail and newsreader, Gnus, is up for adoption. I'd be willing to become maintainer of this package. I've been using Gnus for ten years, and for a couple of last years I've already been using self-compiled version of Gnus to fix compatibility with GNU Emacs 22 (with patches from BTS). I've prepared now packages for latest upstream release, and uploaded that to mentors. Just to double-check: did you already know the background on this? The gnus Debian package is not really recommended for most users. Most users of Gnus are probably better off not installing the gnus Debian package and instead using the version that comes with Emacs. There was some discussion of whether the package should just be removed, although there is some merit to keeping a package of the newer code available to people who specifically need newer versions. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: change glib-config to pkgconfig in configure.in
Eduardo M KALINOWSKI edua...@kalinowski.com.br writes:
There is an easier way, you can use the PKG_CHECK_MODULES macro:
PKG_CHECK_MODULES(PKGNAME, glib)
This checks for pkg-config, checks that glib is installed, and sets the
variables PKGNAME_CFLAGS and PKGNAME_LIBS to the necessary flags and
libraries. Then you can, for example, call
AC_SUBST(PKGNAME_CFLAGS)
AC_SUBST(PKGNAME_LIBS)
and access the flags in ${PKGNAME_CFLAGS} and ${PKGNAME_LIBS} in the Makefile.
General rule of thumb with anything Autoconf-related: always quote
everything. Therefore, better to say:
PKG_CHECK_MODULES([PKGNAME], [glib])
AC_SUBST([PKGNAME_CFLAGS])
AC_SUBST([PKGNAME_LIBS])
It doesn't matter until one day it does and you get bizarre and obscure
error messages and corrupted shell scripts and spend hours trying to
figure out why.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gnus -- A versatile news and mail reader for Emacsen
Rogério Brito rbr...@ime.usp.br writes: On May 11 2009, Russ Allbery wrote: Just to double-check: did you already know the background on this? The gnus Debian package is not really recommended for most users. Most users of Gnus are probably better off not installing the gnus Debian package and instead using the version that comes with Emacs. Could any of you give a brief comment regarding what is the rationale? The version that ships with Emacs is more stable (often very stable, which can be a drawback, but I've rarely had any trouble with it). It sometimes also has some Emacs-specific fixes that haven't made it into a separate Gnus release yet, since Gnus releases separate from Emacs are fairly rare these days. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to get rid of dir-or-file-in-var-run?
markus schnalke mei...@marmaro.de writes: I maintain masqmail, a mail transfer agent. It stores files in /var/run. Now I have this lintian warning: dir-or-file-in-var-run. Unfortunately, I dont know how to get the warning disappear. I checked the init script. It creates the /var/run/masqmail on startup. Also comments and changelog entries state that one former maintainer worked on exactly the issue (/var/run being a temp file system). Now, I also removed the `/var/run/masqmail' line from debian/dirs, but still the lintian warning appears. Check the contents of your package. For some reason, the package still contains the directory even though you've removed it from debian/dirs. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Both dpkg-source -x foo.dsc and lintian seems to ignore trustedkeys.gpg keyring
José Manuel Santamaría Lema panfa...@gmail.com writes:
A few hours ago, after upgrading my system, I got a new warning from lintian
in my packages (I'm not on debian-maintainers.gpg keyring):
$ lintian -i -I subtitlecomposer_0.5.2-1.dsc
I: subtitlecomposer source: tar-errors-from-source gpgv: Signature made Tue
May 19 00:51:58 2009 CEST using DSA key ID 5F99C10F
This is a bug in Lintian that will be fixed thusly in the next release.
Sorry about that.
--- a/checks/cruft
+++ b/checks/cruft
@@ -158,7 +158,7 @@ for my $file (keys %ERRORS) {
# after some other error.
next if /^Record size =/;
next if /^Skipping to next header/;
-next if /^gpg: /;
+next if /^gpgv?: /;
next if /^secmem usage: /;
next if /^Exiting with failure status due to previous errors/;
tag $tag, $_;
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: how to check for binary compability?
Jonas Meurer jo...@freesources.org writes: At packaging mimelib1 from standalone-source I patched the sources to use strncpy/strncat instead of strlcpy/strlcpy along with several other changes. Now I tried to check for binary compability with libmimelib1c2a packages from kdepim 3.5.9 sources. To do that, I compared the output of 'objdump -T /usr/lib/libmimelib.so.1 | grep \\.text | cut -b62-' Unfortunately there are differences. Now I simply don't know if these differences render the package binary incompatible, or whether they don't matter at all. Additions do not break binary compatibility in shared libraries, so the only concern is with the removals: -strlcpy -mkstemps -strlcat -_ZN8DwStringixEm The new version of the library is no longer exporting its internal portability functions. This is good -- libraries should not export unrelated symbols. However, if any of its dependencies happened to depend on those internal symbols (using the versions provided by the library lazily rather than providing their own), you would break them. I don't have a good feel for how likely that is for this particular library. In general, removal of internal symbols that were never part of the public API is often done without a bump in the SONAME and just fixing any dependent packages that break, but ideally it's nice to know what might break. Debian Developers with access to the Lintian lab on gluck can search through the objdump output for clues, although we don't have a simple script to do that. I'm not sure what to recommend to people who don't have access to a fully populated Lintian lab. More concerning is the last symbol removal, which indicates that the library has removed: DwString::operator[](unsigned long) which was present in the previous version. Is this also an internal symbol or was it part of the published API? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: how to check for binary compability?
Jonas Meurer jo...@freesources.org writes: so only one question remains for me: do I need to bump the soname or at least provide a symbols file for added library symbols? or can I simply ignore them as well? You should not bump the SONAME. You should bump the shlibs dependency (as generated by dh_makeshlibs if you're using debhelper) to the new version of the package, though, since binaries built against the new library might not work with the old library. You could also provide a symbols file with appropriate version numbers for when each symbol was introduced, but symbols files are optional (and can be tricky with C++ since the symbol names can vary per architecture). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ITR: febootstrap
Y Giridhar Appaji Nag app...@debian.org writes: Comments: - in debian/control, Section should be admin (not devel) and priority should be optional (not extra). Hm, why would you increase the priority to optional? This seems like an extra thing to me -- only people with specific needs who already knows it exists are likely to want to use this package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ITR: febootstrap
Y Giridhar Appaji Nag app...@debian.org writes: I read that part of policy (only likely to be useful if you already know what they are) as there is an optional package that has been built out of the same source package, but this one is built for special needs of that package. My understanding was that this was largely for packages that conflict with those in = optional. OK, I looked at debootstrap and cdebootstrap, while the former is extra the latter is optional. As a maintainer of policy, what do you think? I use extra for anything that I consider to be for special use, obscure, or otherwise probably not worth listing with all the other packages in its section for the casual browser looking for interesting packages. So, for instance, funky old Kerberos v4 compatibility packages I consider extra, or a new but currently mostly unused SASL implementation, or Shishi (an interesting Kerberos implementation, but 99% of users will want either MIT or Heimdal instead). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ITR: febootstrap
Y Giridhar Appaji Nag app...@debian.org writes: I agree with this particular example. But I could argue if would reasonbly want to install Kerberos if I Didn't know what it was. I've not seen ftp-master enforce the distinction between optional and extra, not even in the cases where it is very clearly defined in policy i.e. extra contains all packages that conflict with others with required, important, standard or optional priorities. And in case of Packages must not depend on packages with lower priority values (excluding build-time dependencies).. Look at the Debcheck pages. I am not sure if enforcing extra in cases other than conflicts, Depends: on lower priority and very clear specialised requirements (elinks-lite, debug symbols etc.) gains us much. Oh, yes, I agree. I wouldn't go to people in general and ask them to make their packages priority: extra. I was only questioning because you'd said to raise the priority from extra to optional, and this didn't seem like a package where we'd want to make a special effort to move it into optional. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problem with dpkg-shlibdeps
Frank Küster fr...@debian.org writes: No, I've found out now (Use the source, conveniently dpkg-shlibdeps is a Perl script): I was the DEBIAN directory in the package directory which was missing, and which made dpkg-shlibdeps _think_ that it wasn't a package directory. Simply calling dh_installdeb before dh_shlibdeps fixed it; it wasn't me who wrote that debian/rules and I have no idea whether it used to work. It looks like dh runs dh_shlibdeps before dh_installdeb, so I would have expected more people to run into this. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problem with dpkg-shlibdeps
Frank Küster fr...@debian.org writes: Maybe some other tool usually also creates DEBIAN, but not in my case? I'm really confused by this too, since the calling sequence for a binary build also runs dh_makeshlibs before running dh_installdeb, dh_makeshlibs seems to assume that the DEBIAN directory already exists (I can't find a mkdir anywhere and it writes to the shlibs file there), and I can't figure out where earlier in the calling sequence the DEBIAN directory would be made. Clearly I'm missing something -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: segment
Rail Aliev r...@i-rs.ru writes: I am looking for a sponsor for my package segment. * Package name: segment Version : 1.2.2~svn44-1 Upstream Author : Jarek Lipski loomch...@rootnode.net * URL : http://segment.sourceforge.net/ * License : MIT Section : java It builds these binary packages: libsegment-java - Rule based text splitting library For this and the other RFS that you just sent, you should use the same source package name as the binary package name when the source package generates only one binary package. You should do this even if upstream calls the source package something else. It makes many things in Debian more straightforward and less confusing for users and software. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ah
Harry Rickards hricka...@l33tmyst.com writes: Even after removing the \, I still get: W: ah: manpage-has-bad-whatis-entry usr/share/man/man1/ah.1.gz ah.1.gz in the deb archive that you pointed to at the beginning of this thread is a pure text file that's just formatted vaguely like the output of nroff. The man page installed in /usr/share/man/man1 must actually be written in *roff. Maybe you accidentally installed the output rather than the man page source? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Specifying ia32-libs in control when on a 64 bit Debian/Ubuntu?
Ignacio Valdes ival...@hal-pc.org writes: It would seem a simple solution but I've searched and searched and have not found one. Is there no resolution for this? The solution is to generate multiple packages, one for each architecture. This is the normal way in which Debian packages are built. The problem you're running into is that you want to reuse the same binary package on multiple architectures, which is not a standard way of creating Debian packages. The tools therefore have not been enhanced to add features to support that (since Debian as a project doesn't much care about that use case). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Generating lintian-overrides file?
Patrick Matthäi pmatth...@debian.org writes: Erik de Castro Lopo schrieb: I'm packaging something with has an installable file called License.hi which is not a license file, but gets caught by the extra-license-file lintian warning. I can add a pkgname.lintian-override file, but the path in the override file has the package version number embedded in it. Is there some way I can autogenerate this lintian-override file? Yes, as stated in the last answers. But you may also report it against the lintian package as false positive. What *is* the content of the file? In other words, more fundamentally, why is it there and what does it do? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Generating lintian-overrides file?
Erik de Castro Lopo mle+deb...@mega-nerd.com writes: Russ Allbery wrote: What *is* the content of the file? In other words, more fundamentally, why is it there and what does it do? Its a haskell interface definition file. When ghc6 compiles the Haskell source code file License.hs it generates an object file and the itnerface file License.hi. In the package I'm working on License.hs specifies the license of a Hackage/Cabal package. See: http://hackage.haskell.org/packages/archive/Cabal/1.4.0.1/doc/html/Distribution-License.html Yeah, that sounds like a good Lintian exception. As a haskell hacker, I thought you may have recognised that :-). I think you may be confusing me with someone else. :) I've never used Haskell, I'm afraid. (Mostly just due to lack of time.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Generating lintian-overrides file?
Erik de Castro Lopo mle+deb...@mega-nerd.com writes: Russ Allbery wrote: Yeah, that sounds like a good Lintian exception. I see no good reason to make lintian aware of this particular exception. It might however make sense to make lintian ignore any file named license* if that file is a binary file. We have a ton of exceptions already by file extension, so it's trivial to add another one. Given your description of an *.hi file, I have a hard time imagining anything named copyright.hi or license.hi will be anything other than a false positive. I think you may be confusing me with someone else. :) Ooops, yes. It was a Brandon S. with your surname. Sorry about that :-). Ah, yeah, that happens. :) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libapache2-mod-authnz-external
Hai Zaar haiz...@haizaar.com writes: On Fri, Jun 26, 2009 at 8:24 PM, LI Daobinglidaob...@gmail.com wrote: E: libapache2-mod-authnz-external: duplicate-conffile /etc/apache2/mods-available/authnz_external.load Finished running lintian. How can I fix this? I just have this line in libapache2-mod-authnz-external.install file: debian/authnz_external.load etc/apache2/mods-available And after building the package, conf file appears twice: $ cat libapache2-mod-authnz-external/DEBIAN/conffiles /etc/apache2/mods-available/authnz_external.load /etc/apache2/mods-available/authnz_external.load windlord:~ lintian-info -t duplicate-conffile N: duplicate-conffile N: N: The file is listed more than once in your debian/conffiles file. N: Usually, this is because debhelper (dh_installdeb, compat level 3 or N: higher) will add any files in your package located in /etc N: automatically to the list of conffiles, so if you do that manually N: too, you'll get duplicates. N: N: Severity: important, Certainty: certain Does that help any? Usually this means you have a conffiles configuration file in your packaging directory that you don't want because debhelper is handling it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libapache2-mod-authnz-external
Hai Zaar haiz...@haizaar.com writes: I think, first, the file is added to conf files because its listed in package.install file. Then, after its installed to etc, its added again. The question is How do I install conf files using package.install files? Just listing it in *.install will not cause this problem. There's something else wrong. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libapache2-mod-authnz-external
Hai Zaar haiz...@haizaar.com writes: May be you can look at the package and give me a hint please? http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libapache2-mod-authnz-external There is really nothing complicated there. I suspect the problem is that your rules file is running all the debhelper commands twice. You only have one architecture-dependent package, but you have both populated binary-arch and binary-indep targets and your binary-indep target actually calls all the debhelper commands with the flag for building architecture-dependent packages. So you're running everything multiple times, particularly since they both depend on install and install in turn doesn't create a stamp file. I think you should toss out that debian/rules file and start again from a debhelper template, either rules.arch or rules.tiny with an override to handle the build. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: iulib (3rd attempt)
Nick Leverton n...@leverton.org writes: First, you call dh_quilt_unpatch from your clean target, however this command is provided by quilt which is not part of build-essential. Pbuilder only auto-installs the dependencies after cleaning the package - but it will not do this as the clean fails. You might fix this by doing dh_quilt_unpatch || true in your clean. This advice seems wrong to me. You need to have Build-Depends installed in order to be able to run the clean target, and you do not want to proceed with the build if the clean target fails. You can end up with extraneous junk in the *.diff.gz that may cause build problems. This sounds like a problem with your local build environment, not with the package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: roxterm (new maintainer, 1.15.1-1 ready for sponsored release)
Jonathan Wiltshire deb...@jwiltshire.org.uk writes: I may be wrong, but you should probably test in your postinst what apt wants you to do (install, upgrade, abort etc). See /usr/share/debhelper/dh_make/debian/postinst.ex for an example. The summary at the top is useful. Blindly using 'update-alternatives --install' isn't very helpful in some circumstances. Your prerm script does do this check. Not that anyone gets this right in practice, but I think calling update-alternatives unconditionally in postinst is the correct way to handle the error rollback cases. You don't want to call it unconditionally in prerm because you don't want to call it on upgrade normally, but there isn't a similar case for postinst. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Installing server software in /opt not good?
Ignacio Valdes ivald...@gmail.com writes: Hi, I have a .deb that installs a reliable and well tested server that we want to eventually get into a apt-get repository. Right now it installs nearly everything into opt with a well-defined directory structure. Will that preclude it from being accepted into an apt-get repository? It will preclude it from being uploaded to Debian proper. It will not preclude it from being available from a private apt repository. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Can't open man1/optin.so: No such file or directory
George Danchev danc...@spnet.net writes: There is no easy way for dh_installman to guess that optin.so as found in source directory is actually a manpage content meant for inclusion, so you should take the control yourself and install that files in place from debian/rules either by copying it or by calling dh_install + binary_package.install file containing something as follows: path/to/optin.so usr/share/man/man1 However there are two issues here: * optin.so should not be compressed since it is referenced to by other manpages as `optin.so' as I see it, thus you should also call dh_compess - Xoption.so -Xgenin.so and so on... in order to prevent that. * lintian would later complain that your package actually provides an uncompressed manpages, since optin.so and friends are left in place uncompressed as they are referenced that way. You can of course override this, however I don't think that populating /usr/share/man/man1/ with random named uncompressed files meant for inclusion is a sane way to go or at least that would need a discussion and conventions agreed upon. A better solution would to include compressed manpage files, however I'm not sure if that is at all possible. Another option would be to install the extra man page data into a /usr/share/package directory and then modify the man page to include it via its full path instead of expecting it to live in the man directory alongside the man pages. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: magicfilter (updated package)
Rogério Brito rbr...@ime.usp.br writes: |* Fix magicfilter dj550c truncates with dj670c (sometimes): | no problems printing the attached file and marked unreproducible for | almost 7 years. (Closes: #33666) |* magicfilter works fine with Linux = 2.6. (Closes: #250715) Did something change about the magicfilter package in this new release that fixes these two bugs? If not, they don't belong in debian/changelog. debian/changelog is for documenting *changes* to the package. It is not a general bug-closing service. Bugs that you're closing without changes to the package should instead be closed by mailing nnn-d...@bugs.debian.org. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: magicfilter (updated package)
Rogério Brito rbr...@ime.usp.br writes: I have one off-topic comment: I've seen some well known maintainers do some things without the rigor that mentors apply to prospective maintainers. Yes. It's a little frustrating. Wouldn't it be the case to require said maintainers to shape up their skills so that their packages improve and, as a side effect, the quality of the overall distribution increases? It would be nice (modulo disagreements within the project about best practices). However, Debian doesn't really have a mechanism to do so at present. Anyway, back to my package in question, the sources are again fixed at mentors.d.n, which can be found at: dget http://mentors.debian.net/debian/pool/main/m/magicfilter/magicfilter_1.2-62.dsc It looks like there's an accidental change to the timestamp for the previous release in debian/changelog: @@ -12,7 +23,7 @@ from a homebrew build to a debhelper + quilt package management (and this will take care of some lintian warnings of the pedantic level). - -- Rogério Brito rbr...@ime.usp.br Thu, 07 May 2009 03:44:17 -0300 + -- Rogério Brito rbr...@ime.usp.br Sun, 02 Aug 2009 16:28:18 -0300 magicfilter (1.2-60.1) unstable; urgency=low Please upload again with that fixed and I'll sponsor this. Thank you for your work on the package! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: magicfilter (updated package)
Rogério Brito rbr...@ime.usp.br writes: On Aug 03 2009, Russ Allbery wrote: Rogério Brito rbr...@ime.usp.br writes: I have one off-topic comment: I've seen some well known maintainers do some things without the rigor that mentors apply to prospective maintainers. Yes. It's a little frustrating. Frustrating is indeed the right word. I see some weaknesses in the way that Debian is currently structured and I think that I will write a longer e-mail about that (things that are easily changed). Let's hope that I have the energy for that. Code review is well-known to significantly improve quality. People who need sponsored uploads get code review by the sponsor, so those packages end up being of higher quality. Full Debian developers aren't required to seek code review, so on average the packages are of lower quality. Code review takes a lot of time, so requiring it for every package in Debian probably isn't feasible. But it's the code review of the sponsoring process that results in most of the quality improvements. Team-based packaging also gets at least some code review, particularly if committed patches are sent to the team mailing list. Ooops. Fixed. The updated sources are again at the same address. Uploaded. Thank you! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ognl
Matthew Johnson mj...@debian.org writes: I don't like: * 5. Products derived from this software may not be called * OpenSymphony *or OGNL, nor may OpenSymphony or OGNL appear in their *name, without prior written permission of the OpenSymphony *Group. since we are, arguably, distributing a derivative work and if we ever patch it then we certainly are. I've CC'd debian-legal to get slightly wider comments on the matter. For debian-legal readers, the full licence is below. I really dislike that license clause as well, but the PHP license also has that clause and it's in main. So it doesn't appear to make the package non-free in the opinion of the ftp-masters. It looks like OpenSymphony just copied the PHP license (which is a shame, since it's a crappy license). Here's the equivalent clause in the PHP license: 4. Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from gr...@php.net. You may indicate that your software works in conjunction with PHP by saying Foo for PHP instead of calling it PHP Foo or phpfoo -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Package uploaded with UNRELEASED distribution.
Charles Plessy ple...@debian.org writes: Very good point. So only the changelog is borken. I built the package with its UNRELEASED changelog with sbuild, which puts the schroot's name in the Distribution field of the changes control file. The inconsistency with the changelog went unnoticed by our tools. Luckily, the package was really intended for upload. I will fix the changelog at the next upload, the error does not seem to be disruptive. We had a specific request for Lintian to not warn about UNRELEASED as the distribution so that people could run it on each build and know that any output meant a problem. Unfortunately, that creates the possibility for something like this to happen, since dput and dupload only look at the *.changes file and don't care about what's in the changelog, and Lintian's architecture makes it very hard for it to see a mismatch between the *.changes file and the package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Package uploaded with UNRELEASED distribution.
Michal Čihař ni...@debian.org writes: Russ Allbery r...@debian.org napsal(a): We had a specific request for Lintian to not warn about UNRELEASED as the distribution so that people could run it on each build and know that any output meant a problem. Unfortunately, that creates the possibility for something like this to happen, since dput and dupload only look at the *.changes file and don't care about what's in the changelog, and Lintian's architecture makes it very hard for it to see a mismatch between the *.changes file and the package. Well for this case it would be enough to catch mismatch in changes which did contain untable as distribution, but UNRELEASED in the changes entry. Not sure how useful such check would be though. The difficulty is that Lintian checks binary packages, source packages, and changes files in isolation from each other, so there's no way in Lintian in its current architecture to recognize mismatches between two different types of package or between the *.changes file and one of the packages. No part of Lintian has the data from both at the same time. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Package uploaded with UNRELEASED distribution.
Mike Hommey m...@glandium.org writes: He meant that in this particular case, the UNRELEASED and unstabler discrepancy *is* in the .changes file. See http://packages.qa.debian.org/v/velvet/news/20090819T133220Z.html Yeah, Charles also pointed that out to me. I get it now -- that's definitely enough to write a Lintian check. I'll file a bug so that I don't forget. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: acct (updated package)
Mathieu Trudel-Lapierre mathieu...@gmail.com writes: I am looking for a sponsor for the new version 6.5.1-1 of my package acct. It builds these binary packages: acct - The GNU Accounting utilities for process and login accounting The package still shows two lintian errors on the binary package: E: acct: info-document-missing-dir-section usr/share/info/accounting.info.gz E: acct: info-document-missing-dir-entry usr/share/info/accounting.info.gz And I am not quite sure how to fix them. since upstream ships that file (I've tried modifying the texi source, something else is going wrong). I suspect that the upstream makefiles don't rebuild the info documents by default. That's not uncommon. Check to see if there's an additional makefile target that will do so (and build-depend on texinfo, of course). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Appropriate warning when removing important package
Jeremy Leibs le...@willowgarage.com writes: My initial workaround was to just add Essential: yes to the ros-conficts control file so that now users get a much more serious warning when they try to install a package that conflicts with it. However, this feels like a misuse of essential. Is there a preferred way to present an appropriate warning to people when a particularly important package is about to be removed? If I were you, I'd use Essential. That's basically what it's for, and in this sort of situation for a custom package for a local environment, I think it would create the impact you want with the least customization to Debian required. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian pickiness and packaging improvements
Raphael Geissert geiss...@debian.org writes: Pedantic tags are Lintian at its most pickiest and include checks for particular Debian packaging styles, *checks that are very frequently wrong*, and checks that many people disagree with. Expect false positives and Lintian tags that you don't consider useful if you use this option. Adding overrides for pedantic tags is probably not worth the effort. As the person who pushed and introduced pedantic support I always felt a bit hesitant regarding the highlighted statement, maybe I should bring this up on the lintian mailing list and ask Russ for his reasons behind it (maybe what he wanted to express could be paraphrased). If a check is wrong I don't think it should belong to the pedantic category, IMHO. Yeah, maybe we should drop that. I think what I was intending is already covered by checks that many people disagree with. wild-guess certainty doesn't make checks pendantic, only downgrades them to info. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian pickiness and packaging improvements
Rogério Brito rbr...@ime.usp.br writes: On Oct 22 2009, Raphael Geissert wrote: Manoj Srivastava wrote: I also think that style issues should not be a part of even Pedantic checks. If a package is using a different, and arguably better style, then lintian should keep its nose out. If there's a better style I guess nobody would object to consider recommend it or at least make sure lintian doesn't complain about it. Couldn't we have a category of warning/checks that is labelled stylistic? That was actually most of the point of pedantic. Minor possible bugs that aren't stylistic belong in info instead. That's why both of them are suppressed by default. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian pickiness and packaging improvements
Rogério Brito rbr...@ime.usp.br writes: On Oct 29 2009, Russ Allbery wrote: That was actually most of the point of pedantic. Minor possible bugs that aren't stylistic belong in info instead. That's why both of them are suppressed by default. OK. Nice. Please keep them there. We can just treat them as pedantic and not recommend them by default. (I actually like them there). Yeah, it's worth remembering that part of the history of pedantic was to add a new classification for tags that I, as a Lintian maintainer, was not willing to always fix even in my *own* packages. We had a lot of demand in bug reports for adding some additional checks, often repeated requests for the same checks, so I didn't want to drop them entirely, but I also didn't want to bother people with them who weren't explicitly asking for them. There are a few pedantic tags that I routinely ignore, usually because I can't easily do anything about them (like no-upstream-changelog). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A libtool and automake question (for developing fuppes)
Robert Massaioli robe...@cse.unsw.edu.au writes: Recently I tried to build fuppes UPnP Media Server (http://fuppes.ulrich-voelkel.de/) but I came across the following error: bin/sed: can't read /usr/lib/libogg.la: No such file or directory libtool: link: `/usr/lib/libogg.la' is not a valid libtool archive Usually libtool should just cope transparently and you don't need to do anything. The case when it doesn't, and what I suspect you're running into, is when what you're building depends on some other library that does have an *.la file, and that *.la file in turn references the (no longer present) libogg.la file. This happened to a lot of packages because the removal of libogg.la wasn't as well-coordinated as it could have been, so the first step would be to make sure that you're completely up-to-date on all the dev packages that you're using. If that still doesn't work, reporting here what libraries your program is trying to link against should help in narrowing it down. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: (non-)upstream changelog
Pietro Battiston too...@email.it writes: Do you suggest me to: - patch the changelog/introduce a new one, and then install it, or - in debian/changelog, after New upstream release, list all of those changes? I always summarize major changes in a new upstream release in debian/changelog whether upstream provides its own changelog or not. It seems polite and I know as a user it makes debian/changelog more useful to me than a bunch of bare New upstream release lines when trying to track down when something might have changed. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Lintian experimental tags (was: RFS: ampache (updated package))
Raphael Geissert geiss...@debian.org writes: Well, experimental checks are not to be considered irrelevant chatter, hence my question. The current experimental checks are: Tag: spelling-error-in-binary Severity: normal Certainty: wild-guess It is based on the output of strings(1) so it can't tell for sure whether a string is actually displayed or it is just a symbol or something else, or whether it is really an error or not (although it is pretty accurate in most cases). I've removed the experimental tag on this for the next release of Lintian. I think it's reasonably mature, and the certainty is wild-guess, which is about right. I changed the severity to minor, since by definition in our BTS spelling errors are minor bugs. minor/wild-guess will make this an info-level tag. Tag: template-uses-unsplit-choices Severity: normal Certainty: possible Erm, IIRC this one should no longer be marked as experimental ever since lenny was released. Will no longer be experimental in the next upload. Tag: embedded-pear-module Severity: normal Certainty: possible PEAR modules are a bit tricky to detect properly without making it too specific, in which case the check itself wouldn't be of much use. Left experimental for the time being. Tag: shlib-calls-exit Severity: wishlist Certainty: possible There's no way for lintian to tell whether the usage of exit or _exit is correct at all in the shared library, and it is based only by looking at the symbols. I'm considering removing this one entirely. It has very serious false positive problems due to generic helper libraries that could call exit but never use that code path in the library code. We have this because it's something that rpmlint checks, but most of the cases of it that I've seen are actually wrong or at least not interesting. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian pickiness and packaging improvements
Manoj Srivastava sriva...@debian.org writes: Ah. I have a few of those. For example, take this warning from Lintian: description-synopsis-might-not-be-phrased-properly This is not policy, but dev-ref, Fixed the cross-reference, which was simply wrong. and when it was proposed, it was argued that if we had a non clause, the front ends can make it look nicer, by completing the sentence, adding the period, etc, (perhaps by showing Package is a short description . That was around 6 years or so ago. [...] And why is this a warning as opposed to an informational message? How is the package impacted by having a gosh darned period in the short description? This is the same level of impairment as the other non info warnings? seriously? Thisis not a severity normal bug. It is not even a severity wishlist bug. It is a style issue. I think an argument could be made that it's a severity: minor bug from a consistency perspective, but not normal. I've therefore now downgraded it to severity: minor, which I think more accurately represents how important it is. Since it's also certainty: possible, this downgrades it to an info-level tag. Things like that are why I take every lintian warning with a huge grain of salt. Any others? :) Ideally, Errors should correlate to important+ bugs, and must violations, I think, warnings are bugs (minor and normal) and should violations, and everything wishlist ought to be a informational message. Style things belong in experimental. And, to give credit where it is due, the majority of the tags are listed at their proper severity. But by no means all of them are. Style things belong in pedantic, unless they're fairly widely agreed-on, in which case they belong as severity: minor. In general, though, I agree with the above. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Man and UTF-8.
Ben Finney ben+deb...@benfinney.id.au writes: Jakub Wilk uba...@users.sf.net writes: * Nicolas Alvarez nicolas.alva...@gmail.com, 2009-11-17, 13:45: And sometimes annoying. I have seen command examples in manpages that used fancy Unicode quotes, and didn't work when copied and pasted into a shell. Blame the one who wrote a buggy manpage, not groff. No, I really do think it's reasonable to blame the system in this instance. One should not need to go through contortions to get a common characters like an apostrophe (U+0027 APOSTROPHE) or the typographic quotation marks (U+2018, U+2019) to behave as themselves. You would have needed to take it up with Joseph Ossanna and Brian Kernighan, since *roff has worked this way since the beginning of the formatting language. At the time, this was reasonably standard practice. Note that TeX does the same thing with '', and therefore texinfo also has the same sort of behavior. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Man and UTF-8.
Roger Leigh rle...@codelibre.net writes: Ye gods, that's nasty. Should be removed IMO, since '`' is not and never was an opening single quotation mark. It is in the *roff language, similar to how '' is an opening or closing quotation mark in TeX. Just because most of the characters in *roff have some resemblence to similar characters in normal ASCII text, that doesn't mean they mean the same thing. *roff is a formatting language, not ASCII text with a few special commands, and it's important to be aware of that while writing in it. *roff is 33 years old. It doesn't work the way that it would if it were designed today. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Man and UTF-8.
Ben Finney ben+deb...@benfinney.id.au writes: Russ Allbery r...@debian.org writes: You would have needed to take it up with Joseph Ossanna and Brian Kernighan, since *roff has worked this way since the beginning of the formatting language. Note that “blame the makers of groff” is *not* what I'm saying; they make their decisions in the context of their times, and I'm fine with that. Sure, I understand. I just wanted to mention. (Also, it's not groff -- groff is a specific implementation of the language which is much newer than the underlying language. Just to be pedantic.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Man and UTF-8.
Rogério Brito rbr...@ime.usp.br writes: With TeX, BTW, we have some extensions (or even reimplementations) that allow us to type things in UTF-8 directly, instead of using escape sequences like in older TeX (e.g., Rogério instead of Rog\'erio, in utf-8 or in latin1, though some care should be taken to avoid clashes between different encodings used in the same file). This should actually work with current versions of groff as well, but I haven't experimented with it a lot myself, so I don't know what problem Charles is running into. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Writing manpages
Rogério Brito rbr...@ime.usp.br writes: OK, since the project strongly advises for the availability of manpages (and I love manpages), comes the question: what do you people use to type manpages? POD. But then, I wrote the tools that convert POD to *roff, so I would. The best so far that I found seems to be Perl's pod format. At least, the markup doesn't pollute my view. Yup. :) And there's a nice Emacs mode for POD that does coloration and whatnot. (There is for *roff as well, but I hate typing *roff directly.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian changelog vs upstream changelog
Jonathan Wiltshire deb...@jwiltshire.org.uk writes: On Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney wrote: Rather, it would be good to have a facility similar to the way the Debian changelog is currently available: have the upstream changelog published in a predictable location by package name. Where the changelog is already part of the source package and has a sensible name, and the package calls dh_installchangelogs, it's already installed as /usr/share/doc/*/changelog and the Debian changelog as changelog.Debian. The only unpredictable part of that is whether upstream enclosed one in the first place. In order for apt-listchanges to do its nice summary, though, you need two features: a consistent location *and* a consistent format, so that you can show only the changes from the currently installed version. The second part is rather hard for arbitrary upstream changelogs. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: weak-library-dev-dependency is there a lintian bug ?
Felipe Sateler fsate...@gmail.com writes:
On Tue, 2009-12-01 at 16:43 +0100, Picca Frédéric-Emmanuel wrote:
Hello I am developping a package for the tango control system.
the upstream tango-7.1.1.tar.gz contain in fact a sub package.
in the configure.in there is a
AC_CONGIF_SUBDIRS(blablabla...)
this sub package provide a librairy but the version number is taken from its
AC_INIT with this line in the debian/rule file:
LOG4TANGO_VERSION := $(shell egrep AC_INIT lib/cpp/log4tango/configure.in |
cut -f 2 -d ' ' | cut -f 1 -d ',')
DEB_NOREVISION_VERSION := $(shell dpkg-parsechangelog | egrep '^Version:' |
cut -f 2 -d ' ' | cut -f 2 -d '-')
for now the version is 4.0.3-1 != (= ${binary:Version})
You want the debian package version, not the library version. So I think
lintian is correct here: liblog4tango4 version will be ${binary:Version}
(something like 7.1.1-1), not 4.0.3-1.
Unless you are doing something _really_ weird and changing the version
per-binary?
If you're changing the version per-binary (some packages do this), then
you will need a Lintian override since Lintian doesn't understand that.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Updated packages: alien-arena, alien-arena-server, alien-arena-data (request for mentor)
maxxed...@comcast.net writes: The Alien Arena packages have gone un-updated for quite some time now, and appear un-maintained. See these most-recent commits: http://svn.debian.org/wsvn/pkg-games/packages/trunk/?rev=10361sc=1 http://svn.debian.org/wsvn/pkg-games/packages/trunk/?rev=10363sc=1 Alien Arena's development moves pretty fast, and the version currently in the repositories (v. 7.0) no longer accurately represents the game. Furthermore, I am fairly active in the game community and I am in a position to take some of the patches currently in the Debian package, and push them upstream. Finally, I have done some work on the game engine myself, and I should be qualified to fix most bugs in the game and push those fixes upstream. I am also willing to maintain these packages. 7.33 is coming out in a few weeks and when it does, I will make packaging it a top priority. I have packaged version 7.32 and the packages are available on this page: http://meliaserlow.dyndns.tv:8000/pkg/ (It's hosted on my home server, so don't hammer it too hard. ;) ) If anyone could help me get these into the repositories that would be really great and it would be grateful. It seems like the best first step would be for you to offer to join the pkg-games team for the purposes of maintaining those packages, thus potentially providing you with direct commit access to their repository and letting you take over the existing packaging. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Man pages and UTF-8
Ben Finney [EMAIL PROTECTED] writes: That sounds like a bug. I was under the impression that the default encoding of everything in lenny was supposed to be UTF-8. The last time I checked, this didn't work for man pages. If it does now and we can just install man pages in UTF-8, that's great, but a quick test seems to indicate it still doesn't work even if you run groff -T utf8 in a UTF-8 locale. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
David Given [EMAIL PROTECTED] writes: What, then, should I be doing? Is it legitimate to include UTF-8 in my man page and assume that it'll be fixed (some day)? This seems... un-Debian-like. Is there an alternative way of representing Unicode in troff that might work better? Of course, a perfectly viable solution is to simply not put non-ASCII characters in my man page, but this seems kinda cheating. Particularly since I went out of my way to ask the author how to spell his name in kanji... Fixing UTF-8 support in man pages is a Debian-wide project that's going to require a fair bit of coordination and will require tracking down and dealing with all of the man pages that currently use legacy encodings (at least that aren't in some locale with a different charset default). I think it's more than you could be expected to tackle for your package, although it's something that we need to do at some point once groff is ready. In the meantime, your options are: * Install the man page into a locale that's defined to have UTF-8 input. As near as I can tell, the way the current setup works is that certain locales in the man tree are defined to have certain charsets. I'm not sure where that code is, though. And it sounds like that doesn't work for your situation. * Rewrite the man page to use named character escapes instead of raw UTF-8 input. See the groff_char(7) man page for more details. However, I don't know if this will work for Asian characters. It's the best solution for European characters, but a quick skim doesn't show a way to enter an arbitrary UTF-8 code point. So, not good. :/ It might be worth raising this on debian-devel, since it's been a sore point in UTF-8 support for a while. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
Ben Finney [EMAIL PROTECTED] writes: Okay. That doesn't mean it's not a bug; it simply points out where the bug *is*. (Assuming, of course, that I'm correct in saying lenny is supposed to support UTF-8 throughout, and that failure to do so is a bug.) Yes, I think you're right. It's just a difficult bug to fix. I think the bug is in groff, although it's possible that groff is now sufficiently in touch with UTF-8 that it's just a man-db problem. But I doubt that. The previous information I'd gotten about this is that groff's handling of multibyte characters needed to be reworked entirely. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
Adam Borowski [EMAIL PROTECTED] writes: Issues to fix = A. man output B. groff processing C. man input Fixes for A. and B. are mostly local to man-db, fixing C. would be a Debian-wide issue. What I was trying to get at earlier is that I believe groff can't handle UTF-8 input. So fixing B, if I'm correct, is certainly not local to man-db. I believe that fixing groff to handle multibyte character sets property is a substantial amount of work. I've heard rumors from time to time that upstream intended to do this for 2.0, but the work is mostly stalled. groff can apparently produce UTF-8 *output*, but I think the encodings of all of its input at the moment are in other character sets. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
Adam Borowski [EMAIL PROTECTED] writes: The current Debian groff can produce UTF-8 output only for a narrow range of characters, ones which happen to be present in 8 bit charsets. It cannot handle UTF-8 input at all; on the other hand, Red Hat's version seem to be working just fine. Yeah, I wonder if those were the UTF-8 patches that upstream rejected a while back for reasons that I didn't entirely follow. Okay, your analysis matches what I thought was going on. However, David Given seems to be seeing something else where some man pages are already encoded in UTF-8. So I guess I'm confused as to what's going on and what the current status is. If our groff really can handle UTF-8 input and is doing so for some locales, I'd love to declare all regular man pages are in UTF-8 and be done with it; that's a change that we can probably make without backward compatibility issues right now, since currently those code points are disallowed. I'd love to see this dealt with for lenny. I just don't know how realistic that is. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: stripping by upstream
Kevin Coyner [EMAIL PROTECTED] writes: Such is the case with my packages. Upstream does strip in the Makefile. Aside from editing the Makefile using dpatch, is there anything else that is easily done to correct this? I know this seems straightforward, but I just wanted to ask before I start editing upstream where before it was left untouched. If upstream does something nice like use a STRIP variable to hold the path to strip, you can run: make install STRIP=: in your debian/rules (or make, whichever is appropriate). You can use similar tricks to remove -s from install if upstream puts such things into makefile variables. If they don't, you have to patch the Makefile. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
David Given [EMAIL PROTECTED] writes: Wll... unfortunately man-db uses ISO-8859-1 for C and POSIX locales, so transcoding would be required. You do get lintian warnings if you try to use ISO 8859-1 characters in man pages currently. Unfortunately, a lot of people just ignore those warnings. (One of the reasons for them is precisely to ease this transition.) Further investigation reveals that man-db seems to transcode UTF-8 to ISO-8859-1 before passing it to groff. Oh, so we lose if we have characters in UTF-8 that can't be represented in ISO 8859-1. Bleh. That explains why we are where we are. Thank you very much for the analysis! It hadn't occurred to me that man-db would be transcoding things on the way in, and now I understand much better what's going on. It's all a bit of a maze, unfortunately, and I could have misunderstood things. But that MULTIBYTE_GROFF #define looks interesting. It *might* be possible to crudely hack it to work by using the nippon device and the EUC-JP encoding for man pages written in UTF-8. I don't know what the coverage of EUC-JP is like compared to UTF-8, but there might be mileage there. Alternatively, ascii8 is supposed to be eight-bit clean, and might suffice... I'm pretty sure that the MULTIBYTE_GROFF stuff is what didn't work quite right and what upstream wasn't entirely happy with. I think it was developed for some specific Asian encodings and works okay for them, but possibly not for arbitrary UTF-8. I wonder if that's what Red Hat uses or if they transcode as well and just lose on man pages that contain non-European characters. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RHS: libterm-ansicolor-ruby
The Fungi [EMAIL PROTECTED] writes: Of course, I can't imagine an ANSI library would be anything more than a few dozen string constant definitions, unless you wanted routines to recognize and condense inefficient ANSI sequences into something denser, consisting of fewer characters (most the ANSI art apps create some extremely verbose/pedantic strings which can be distilled quite a lot). I'm amused to see this idea show up as a Ruby library. I and another person wrote the Term::ANSIColor Perl module after a comp.lang.perl.misc discussion many years ago, and indeed, it's mostly just a set of definitions, but it's handy to be able to do things like: $string = colored ($string, 'white on_blue'); so there's some glue and a few functions. From the name, it wouldn't surprise me if the Ruby module works similarly (I haven't looked at it). For a one-off module that we put together on a whim, the Perl module has been amazingly popular, seems to be used all over the place, and is now included in Perl core, so there's some indication that people really do like having this sort of functionality. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
Adam Borowski [EMAIL PROTECTED] writes:
Any such description file would work only as long as you hard-code any
fonts, and somehow provide them for any potential reader. Without this,
wcwidth() is as good as you can get for fixed-width fonts. For
comparison, Red Hat makes a wild assumption that everything u0800..u
is doublewide.
The correct thing to do is to use the information from the latest version
of the Asian character width property table:
http://www.unicode.org/Public/UNIDATA/EastAsianWidth.txt
For more information about this area of Unicode, see:
http://unicode.org/reports/tr11/
u0800..u is a bad approximation that misses several ranges and is
actually wrong for most of the range up to u1100. For another
application, I use the approximation of:
our @WIDE = qw(\x{2E80}-\x{303E} \x{3041}-\x{33FF} \x{4E00}-\x{9FBB}
\x{AC00}-\x{D7A3} \x{FF01}-\x{FF60});
but even that is not a particularly good approximation compared to using
the real table.
My guess is that wcwidth's answer is based on the latest version of that
table at the time that glibc released, although I'd have to double-check
to be sure.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unable to build gdb from source
Justin Pryzby [EMAIL PROTECTED] writes: You're apparently trying to build in downloaded packages source/. It contains a space which the make build system didn't handle. IMHO it's a bug, but I suspect many package have similar problems. I supose somebody wants to rebuild the archive and find out? It's a bug that's annoying to try to fix and probably not worth the effort. make *really* doesn't like spaces in filenames in various contexts. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RHS: libterm-ansicolor-ruby
Thomas Dickey [EMAIL PROTECTED] writes: (no point in hardcoding a few dozen string definitions, unless one _likes_ the nasty comments that people make when they read the code ;-) On the contrary, providing ANSI X3.64 / ECMA-048 / ISO 6429 control sequences in a library seems entirely reasonable to me. It is a standard, and it's not like they change or are system-dependent. Yes, there are terminals that don't implement those standards. How many of them are used by anyone other than hobbyists as part of computer archeology? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RHS: libterm-ansicolor-ruby
The Fungi [EMAIL PROTECTED] writes: On Wed, Aug 15, 2007 at 12:38:07PM -0700, Russ Allbery wrote: Thomas Dickey [EMAIL PROTECTED] writes: (no point in hardcoding a few dozen string definitions, unless one _likes_ the nasty comments that people make when they read the code ;-) I took Thomas's comment to mean that it *should* be in a library (or at least abstracted somewhere reusable), rather than hardcoded into your apps. Sounds like violent agreement to me. ;) Ah, yes, you're probably right. :) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xawtv (updated package)
Nelson A. de Oliveira [EMAIL PROTECTED] writes: I: xawtv: possible-non-posix-code-in-maintainer-script config:15 'test -c /dev/.devfsd -o ' I: xawtv: possible-non-posix-code-in-maintainer-script postinst:15 'test -c /dev/.devfsd -o -c /dev/video0 -o ' You can ignore these; they'll go away with the next release of Policy. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License issues with md5deep
Julian Andres Klode [EMAIL PROTECTED] writes: Giovanni Mascellani wrote: This file is surely GPL and not in the public domain. Isn't illegal to link GPL object code with other non-GPL object code and don't distribute it as GPL? In other words, because of only this GPL file, all the package should be GPL licensed, isn't it? I think, it's a GPL violation. The problem is that you cannot relicense the public domain parts under the GPL, because they can not be copyrighted. No, not at all. The only requirement of the GPL is that the work as a whole be covered by the GPL, which means that you have to be able to create a combined derivative work licensed under the GPL. Since public domain puts no restrictions whatsoever on what you do with licenses, it's quite safe to combine GPL code with public domain code into one work, which as a whole is then covered by the GPL. The individual public domain pieces continue to be in the public domain if extracted and used separately. The README says: This program is a work of the US Government. In accordance with 17 USC 105, copyright protection is not available for any work of the US Government. Lawyer to English translation: This program is PUBLIC DOMAIN. Not only is this program not copyrighted, but IT CANNOT BE COPYRIGHTED BY ANYBODY AT ANY TIME UNDER ANY CIRCUMSTANCES. This is sort of true and sort of not. That code itself is not covered by copyright, but any derivative work that you create from it is still covered by your copyright. And that's fine. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
