Re: ldconfig-symlink-missing-for-shlib error
On Thu, Jul 14, 2005 at 01:25:24AM -0400, kamaraju kusumanchi wrote: > I am trying to package fortranposix library. I produced some debian > packages but I am not satisfied with their quality. For example, when I do > $lintian -i libfortranposix0_0.1-1_i386.deb > E: libfortranposix0: ldconfig-symlink-missing-for-shlib > usr/lib/libfortranposix.so.0 usr/lib/libfortranposix.so.0.0.0 > libfortranposix.so.0 > N: > N: The package should not only include the shared library itself, but > N: also the symbolic link which ldconfig would produce. (This is > N: necessary, so that the link gets removed by dpkg automatically when > N: the package gets removed.) If the symlink is in the package, check > N: that the SONAME of the library matches the info in the shlibs file. > N: > N: Refer to Policy Manual, section 8.1 for details. > N: > I thought ldconfig automatically creates the necessary symbolic links > provided the postinst, postrm scripts invoke ldconfig properly. Please see Policy section 8.1. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: ldconfig-symlink-missing-for-shlib error
On Thu, Jul 14, 2005 at 04:18:15AM -0400, kamaraju kusumanchi wrote: > >Please see Policy section 8.1. > The error message already told me to do that. I ofcourse read this > incomprehensible 8.1 section of the debian-policy before posting my > question here. The wording in this section is so cryptic that it really > does not help attracting new maintainers. I mean, the maint-guide is so > good, but this debian-policy is not upto that. > Just yesterday, I posted for a clarification of the wording in 8.1.1 . > http://groups-beta.google.com/group/linux.debian.devel.mentors/browse_thread/thread/de6df3a594904f43/064f698ea912845c?hl=en#064f698ea912845c > May be I am not yet ready for packaging debian stuff... But I would like > to try anyway. > Can you tell me where in this section 8.1, does it say that the > maintainer has to create a symbolink for a runtime library package? The > thing that comes close is the following paragraph. > The run-time library package should include the symbolic link that ^^ > |ldconfig| would create for the shared libraries. ^ I'm sorry, I don't see any way that Policy could be rewritten to make the very first sentence that you quoted any clearer. > According to this paragraph ldconfig should take care of creating the > links. Other replies to this thread suggest that ldconfig is not used > for this purpose while packaging .debs. If that is correct, then section > 8.1 of policy has to be rewritten (since it conveys wrong information). The *package* should *include* the *symbolic link*. I think Policy is already very clear on this point. Policy doesn't care how you get the symlink *into* the package, if that's what you're asking; it only requires that the symlink provided by the package be the same one that ldconfig *would* create. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: [PHP] Standard placement of PHP libraries?
On Fri, Jul 29, 2005 at 05:58:13PM +0100, Neil McGovern wrote: > On Thu, Jul 28, 2005 at 06:22:43PM -0300, Jose Carlos do Nascimento wrote: > > Hi, all > > There was one policy for php libs ? > > This was last message that I found about this. > > http://lists.debian.org/debian-devel/2002/09/msg00109.html > > And about PEAR libs ? > Hi there, > We're currently hammering something out on the debian-webapps mailing > list. > See http://lists.debian.org/debian-webapps Why in God's name are you doing that? The charter for debian-webapps is web *application* packages, not "packages implemented in PHP or providing PHP bindings that may or may not be used by web application packages". debian-webapps is absolutely not the right forum for discussing PHP/PEAR library policy. AFAIK, none of the comaintainers of the actual PHP packages are subscribed to that list. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: [PHP] Standard placement of PHP libraries?
On Fri, Jul 29, 2005 at 07:54:22PM +0100, Neil McGovern wrote: > On Fri, Jul 29, 2005 at 10:51:47AM -0700, Steve Langasek wrote: > > On Fri, Jul 29, 2005 at 05:58:13PM +0100, Neil McGovern wrote: > > > On Thu, Jul 28, 2005 at 06:22:43PM -0300, Jose Carlos do Nascimento wrote: > > > > There was one policy for php libs ? > > > > And about PEAR libs ? > > > We're currently hammering something out on the debian-webapps mailing > > > list. > > Why in God's name are you doing that? The charter for debian-webapps is web > > *application* packages, not "packages implemented in PHP or providing PHP > > bindings that may or may not be used by web application packages". > I think it's because the list originally came from Bug #264069 [0] > ie: a suggestion for a php specific mailing list. > Probably also because there isn't any other place where it seems to be > happening. > I'm also not really sure where else it could belong. Uh, debian-devel would be the appropriate list for open development-related discussions that don't otherwise have an associated list. > >AFAIK, none of the comaintainers of the actual PHP packages > > are subscribed to that list. > However, the author and maintainer of dh-make-php [1] is :) That's all well and good, but a policy that doesn't have the backing of the maintainers of the engine that has to support it doesn't seem like it would be particularly useful. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: how to prevent binary incompatibilities with libraries (in reference to Bug#320029)
On Wed, Jul 27, 2005 at 10:28:39PM +1000, Mike Williams wrote:
> I need some help with finding a good resolution for Bug#320029.
> In summary, the current version of my 'librmagick-ruby' package was
> compiled against libmagick6-dev_6.0.6.x. It works nicely when run with
> libmagick6_6.0.6.x, but fails when libmagick6 is upgraded to the version
> currently in unstable (6.2.3.x).
> I have to admit that I don't understand the implications of the failure;
> does this mean that ABI compatibility has been broken, ie. that there's
> a bug in the libmagick6 package?
> My package currently Depends on libmagick6, sans version number. The
> bug reporter suggested that I depend on a specific version - a thought
> that had also occurred to me - but I'm not sure that it's the best thing
> to do. What do you think?
> I'm not sure how I'd inject a version-number into the libmagick6,
> wayway, since it's generated by ${shlibs:Depends}. That's another thing
> that confuses me: why does the generated dependency not include version
> info?
I vaguely remember that there was a problem before with the ImageMagick ABI
changing and causing precisely this error for some other package. If the
ABI has changed, the library package name *must* be changed; if that's so,
then this bug should be cloned and reassigned to libmagick6.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
Re: Problems with libraries and soname and python
On Sat, Aug 06, 2005 at 02:28:32PM +0200, Mattia Dongili wrote: > On Sat, Aug 06, 2005 at 01:01:12PM +0200, Ghe Rivero wrote: > [...] > > Apart of this, i also hve python bindings: > > python2.3-libsome: > > /usr/lib/python2.3/site-packages/libsomemodule.la > > /usr/lib/python2.3/site-packages/libsome.so > > And i have this on lintian: > > W: python2.3-libsome: package-name-doesnt-match-sonames libsomemodule.so > I have the same with cpufreqd, I think the warning in this cases > (/usr/lib/ with "architecture-dependent data exclusively > used by the application" -FHS 4.4-) should be suppressed. Such modules shouldn't actually have SONAMEs at all; perhaps fixing the build to not include an SONAME for something that isn't a shared library would make this warning go away. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Problems with libraries and soname and python
On Sat, Aug 06, 2005 at 08:52:24PM +0200, Mattia Dongili wrote: > On Sat, Aug 06, 2005 at 09:34:37AM -0700, Steve Langasek wrote: > > On Sat, Aug 06, 2005 at 02:28:32PM +0200, Mattia Dongili wrote: > > > On Sat, Aug 06, 2005 at 01:01:12PM +0200, Ghe Rivero wrote: > > > [...] > > > > Apart of this, i also hve python bindings: > > > > python2.3-libsome: > > > > /usr/lib/python2.3/site-packages/libsomemodule.la > > > > /usr/lib/python2.3/site-packages/libsome.so > > > > > > And i have this on lintian: > > > > > > W: python2.3-libsome: package-name-doesnt-match-sonames libsomemodule.so > > > > > I have the same with cpufreqd, I think the warning in this cases > > > (/usr/lib/ with "architecture-dependent data exclusively > > > used by the application" -FHS 4.4-) should be suppressed. > > > > Such modules shouldn't actually have SONAMEs at all; perhaps fixing the > > build to not include an SONAME for something that isn't a shared library > > would make this warning go away. > Ok, I've been reading docs for a while now... can anybody help on how to > avoid SONAME using libtool and friends? (I'm already giving it the > -module and -avoid-version flags but it still links with -Wl,-soname > -Wl,cpufreqd_blabla.so) If libtool is setting an SONAME when you build with -module, then I guess this would be a bug in the version of libtool you're using. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: pbuilder fails when looking for X / XOpenDisplay [solved]
On Thu, Aug 11, 2005 at 07:12:45AM -0400, Neil Roeth wrote: > On Aug 6, Rene Engelhard ([EMAIL PROTECTED]) wrote: > > Kevin Coyner wrote: > > > On Sat, Aug 06, 2005 at 06:21:22PM +0200, Lo???c Minier wrote.. > > > > I suggest you try understanding what the requirements are to > > > > build your package, this is usually achieved by reading the > > > > upstream INSTALL file or better: the configure.ac/in. You can > > > > then derive the needed build-deps. > > > I was missing xlibs-dev in the Source/Build-Depends part of my > > > control file. > > Use what you really need. It was already mentioned in this thread > > (libx11-dev). Don't use xlibs-dev, it's superfluous and a empty > > dummy package anyway... > I agree in principle, but that is easier said than done in some cases. I > tried to change a build dependency in the aplus-fsf package from xlibs-dev to > libx11-dev and it failed to build under pbuilder, just like the above. I > found some old messages that said the problem was that the autoconf macros > AC_PATH_X and AC_PATH_XTRA make assumptions that are no longer valid with the > split of all the X libs from xlibs-dev into the small components. Has anybody > figured out how to use just libx11-dev and make these macros work? Well, ironically enough, most of the answer is in the subject of this thread. The problem with AC_PATH_X is that it checks for a particular function which is provided by the Xt library, not by libX11. The fix for this is that AC_PATH_X takes optional arguments, telling it to check a different function/lib: AC_PATH_X([X11], [X11/Xlib.h], [XOpenDisplay(NULL)]) That should be enough to get AC_PATH_X working with libx11-dev only. The other option is to just add libxt-dev to your build deps. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I will move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: autotools during build
On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote: > I have some packages which use autotools. I thought it would be good to > compile as much as possible, so it is clear all the sources are correct. That > means including autoconf, of course. > However, linda doesn't agree with that: > W: gfpoken; Package Build-Depends on automake* or autoconf. > This package Build-Depends on automake* or autoconf. This is almost > never a good idea, as the package should run autoconf or automake on > the source tree before the source package is built. > lintian doesn't consider this to be a problem. > My question is: is linda correct and should I not run autoconf from > rules.make? Extrapolating that would mean that compilation is not needed at > all, if a precompiled version of the program is packaged in the source > tarball. That doesn't seem right to me. So if linda is right, then where is > the limit? Generated files which are included for portability reasons (such > as > configure) are ok, but others are not? The limit is between autogenerated sources that upstream ships in the tarball, and autogenerated sources that are expected to be built at build time. If you rerun autoconf/automake/libtool at package build-time, when you don't need to, what you get are large diffs against upstream every time a new version of the autotools becomes available. Aside from wasting (a little) space in the archive, that makes it harder for NMUers or passing developers to see what's going on in your package. The autotools-dev README.Debian is a good guide to these issues. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: autotools during build
On Fri, Aug 12, 2005 at 12:04:31PM +0200, Bas Wijnen wrote: > On Fri, Aug 12, 2005 at 02:12:57AM -0700, Steve Langasek wrote: > > On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote: > > > I have some packages which use autotools. I thought it would be good to > > > compile as much as possible, so it is clear all the sources are correct. > > > That > > > means including autoconf, of course. > > > However, linda doesn't agree with that: > > > W: gfpoken; Package Build-Depends on automake* or autoconf. > > > This package Build-Depends on automake* or autoconf. This is almost > > > never a good idea, as the package should run autoconf or automake on > > > the source tree before the source package is built. > > > lintian doesn't consider this to be a problem. > > > My question is: is linda correct and should I not run autoconf from > > > rules.make? Extrapolating that would mean that compilation is not needed > > > at > > > all, if a precompiled version of the program is packaged in the source > > > tarball. That doesn't seem right to me. So if linda is right, then > > > where is > > > the limit? Generated files which are included for portability reasons > > > (such as > > > configure) are ok, but others are not? > > The limit is between autogenerated sources that upstream ships in the > > tarball, and autogenerated sources that are expected to be built at build > > time. > That sounds like a good way to sneak non-free stuff into main. In fact, > gfpoken is a good example of that. The new upload doesn't use the original > artwork, because it had to be compiled with povray. However, the compiled > files were in the source tarball (in fact, the art source was in a different > tarball). Opinions vary wether it was needed to have art with a free > compiler, but that's because it's about art. If it would have been a piece of > C code, generated with a non-free compiler, then the package obviously > shouldn't be in main. However, if upstream (which could be the packager) has > pregenerated the files, then according to this rule there is no problem. That > doesn't seem right. Well, yes, you do need to know your packages, and take appropriate care that they meet the DFSG. But that doesn't mean having large auto-generated diffs against your upstream release is a good idea. In the case of upstream tarballs that contain binary object files that they shouldn't, at least, the usual practice is to remove them and re-roll the tarball. > > If you rerun autoconf/automake/libtool at package build-time, when you don't > > need to, what you get are large diffs against upstream every time a new > > version of the autotools becomes available. Aside from wasting (a little) > > space in the archive, that makes it harder for NMUers or passing developers > > to see what's going on in your package. > I noticed that, and "manually" removed all files generated by auto* in > debian/rules:clean. That way they get ignored for the diff. Hmm, I'm not really sure whether that fits with policy's intent regarding the effects of the debian/clean target. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: autotools during build
On Fri, Aug 12, 2005 at 01:50:33PM +0200, Daniel Leidert wrote: > > Aside from wasting (a little) > > space in the archive, that makes it harder for NMUers or passing developers > > to see what's going on in your package. > In this case, you could use dpatch to change things and then it is not > harder to see, what is going on. No, it just makes it hard to examine the differences between two versions using debdiff, rather than making it hard to look at the diff for a single version. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: autotools during build
On Fri, Aug 12, 2005 at 10:59:23AM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 12 Aug 2005, Steve Langasek wrote: > > On Fri, Aug 12, 2005 at 01:50:33PM +0200, Daniel Leidert wrote: > > > > Aside from wasting (a little) > > > > space in the archive, that makes it harder for NMUers or passing > > > > developers > > > > to see what's going on in your package. > > > In this case, you could use dpatch to change things and then it is not > > > harder to see, what is going on. > > No, it just makes it hard to examine the differences between two versions > > using debdiff, rather than making it hard to look at the diff for a single > > version. > Then we have a design problem with debdiff, don't we? Uh, no, it's a design issue with *dpatch*. > Anyway, for users of dpatch-like packaging methods, that is a non-issue. Unless you expect the release team to graciously accept an update to your package during a freeze. > Using Debian-packaged and fixed autotools (*especially* libtool and gettext) > instead of whatever upstream uses is almost always a very good idea in my > experience. Yes, making sure you have the Debian libtool fixes is a very good idea, but that's not the same thing as build-depending on autotools Just Because. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: G77 compiler install issue
On Fri, Aug 12, 2005 at 02:01:13PM -0400, Justin Pryzby wrote: > or, if it is on a "testing" box, debian-testing. Please, no. The debian-testing list exists for identifying upgrade issues for the next stable release -- this is not that. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: autotools during build
On Sat, Aug 13, 2005 at 01:13:11PM +0200, Armin Berres wrote: > Steve Langasek wrote: > > On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote: > > If you rerun autoconf/automake/libtool at package build-time, when you don't > > need to, what you get are large diffs against upstream every time a new > > version of the autotools becomes available. Aside from wasting (a little) > > space in the archive, that makes it harder for NMUers or passing developers > > to see what's going on in your package. > > The autotools-dev README.Debian is a good guide to these issues. > >From autotools-dev Readme.Debian: > "You have two good choices, and one bad choice for packaging upstream > source which uses automake and autoconf and contains generated files: > 1. Tolerate the big diff size, and run the autotools stuff before you > create the debian source package. This is what I usually do. > 2. Patch the autotools files (*.in, *.am) at build time, make sure all > the build dependencies are 100% correct (hint: conflicting with > autoconf2.13 is *always* a good idea if you're not using autoconf 2.13 > and automake 1.4). This means that the autobuilders will have to rerun > the entire thing, and so will the users, etc. > When you're doing a full dpatch-based packaging, this choice makes > sense. > 3. Live with whatever crap upstream used. You do *not* have this choice > if libtool is being used, BTW. And it is a bad choice IMHO, I'm yet to > see any distribution with better autoconf, automake, libtool and gettext > packages than Debian (and I do have a lot of experience on this)." > Most people proposed to use the 3. choice so far. According to above > document this is not a very good solution. Apparently. Ohwell, I'll defer to the autotools-dev maintainer, then, though I do stand by my comments about big diffs making it hard for third parties to know what's going on. I think Joey Hess's recommendation is the best of all, here. Though fwiw, build-conflicting with autoconf2.13 seems like overkill when one can just use AC_PREREQ([2.50]) in the configure.in. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [RFS-again] qterm: BBS client for X Window System written in Qt
On Thu, Aug 18, 2005 at 02:07:32PM +0800, LI Daobing wrote: > Version: 0.4.0pre2.ds.3-2 > Distribution: unstable > Urgency: low > Maintainer: LI Daobing <[EMAIL PROTECTED]> > Changed-By: LI Daobing <[EMAIL PROTECTED]> > Description: > qterm - BBS client for X Window System written in Qt > Changes: > qterm (0.4.0pre2.ds.3-2) unstable; urgency=low > . >* ABI transition >* debian/control: change Standards-Version to 3.6.2 > already uploaded to mentors.debian.net > $ lintian qterm_0.4.0pre2.ds.3-2_i386.changes > W: qterm: binary-without-manpage qterm > $ linda qterm_0.4.0pre2.ds.3-2_i386.changes > E: qterm; No manual page for binary qterm. > W: qterm; The command /usr/bin/qterm" > icon32x32="/usr/share/pixmaps/qterm_32x32.xpm" > icon16x16="/usr/share/pixmaps/qterm_16x16.xpm listed in a menu file > does not exist. I'll sponsor this upload. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFS: Plash: a shell and restricted environment for running programs with minimum authority
On Sat, Aug 20, 2005 at 11:47:51PM +0100, Mark Seaborn wrote: > "Roberto C. Sanchez" <[EMAIL PROTECTED]> wrote: > > On Sat, Aug 20, 2005 at 03:01:40PM +0100, Mark Seaborn wrote: > > > I'm looking for a sponsor for putting Plash into Debian. > > > The main page is: http://plash.beasts.org > > > and Debian packages are at: > > > http://www.cs.jhu.edu/~seaborn/plash/plash_1.11_i386.deb > > > http://savannah.nongnu.org/download/plash/plash_1.11.dsc > > > http://savannah.nongnu.org/download/plash/plash_1.11.tar.gz > > > (The Debian source package contains a copy of glibc 2.3.3, which is > > > 13Mb, but the source for Plash itself is only 200k.) > > Why? This is a sure-fire way to make sure a package is not accepted. > How else am I supposed to do it? It needs the glibc source to build. > Is there a way for a source package to use the contents of another > source package, such as Debian's existing glibc package? Even if > there was, this is not very helpful, because Debian includes glibc > 2.3.2. *Why* does it need the glibc source to build? Does it need *all* of the source, or is there some way to get its size down to a sane level? Why does it use a modified version of glibc, instead of intercepting library calls using an LD_PRELOADed wrapper? Is this because a user could unset the LD_PRELOAD variable to escape the environment? If that's the case, what happens if a user copies their own libc.so.6 into the chroot and tells the dynamic linker to use *that*? Including a full copy of glibc in this package also means that it will be affected by the same security holes that affect the main glibc package, and you say that it doesn't even use the same base version of glibc. I don't think the security team will go for this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFS: Conky - A lightweight, highly configurable system monitor based on Torsmo
On Thu, Sep 01, 2005 at 07:52:49PM +0100, Neil McGovern wrote: > On Thu, Sep 01, 2005 at 04:13:41PM +0200, Sven Mueller wrote: > > Jason Tan wrote on 01/09/2005 08:22: > > > We're on the BSD license only because torsmo, conky's predecessor, was > > > BSD. When we do Conky 2.x, which will be a complete rewrite almost from > > > scratch, it will be GPL 2. Let me know if you need any more information > > > or fixes or whatnot, and I'll try to take care of them soon. Thanks. > > BSD license is perfectly OK to go into main. Packages like lilo, mailx, > > mount, netpbm use it, too. > For future ref for anyone: > Yup, it's the BSD 3 clause licence, which is fine. > The 4 clause isn't, as it has teh 'advertising' clause in it. Uh, no, 4 clause BSD *is* allowed in main. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: pkg-config
On Sat, Sep 03, 2005 at 12:46:31PM +1000, skaller wrote: > Does Debian have a policy on use of pkg-config? > On my Ubuntu systems there are some *.pc files, but the set > is not only incomplete .. it isn't closed either. > Perhaps pkg-config files should be REQUIRED for Debian, > and the package names should agree with the Debian ones? Er... that's certainly not enforceable. > Pkgconfig is totally useless unless it is properly supported. > It's also not a very good program -- perhaps Debian can come > up with something better? Yes, pkg-config sucks. Unfortunately, there are a number of upstreams (e.g., GNOME) that are unlikely to be willing to make such a switch this late in the game. The current upstream for pkg-config is a Debian developer, even, but he's somewhat constrained by the loopy ideas that others in the community have about what pkg-config should be. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: pkg-config
On Sat, Sep 03, 2005 at 01:47:01PM +1000, skaller wrote: > On Fri, 2005-09-02 at 20:09 -0700, Steve Langasek wrote: > > On Sat, Sep 03, 2005 at 12:46:31PM +1000, skaller wrote: > > > Does Debian have a policy on use of pkg-config? > > > On my Ubuntu systems there are some *.pc files, but the set > > > is not only incomplete .. it isn't closed either. > > > Perhaps pkg-config files should be REQUIRED for Debian, > > > and the package names should agree with the Debian ones? > > Er... that's certainly not enforceable. > Sure it is. If they're not provided, then lintian fails > the package, and the sponsors refuse to upload it, > same as other policies. No, it's not. The .pc names are set by upstream and we should not diverge from them, and the package names are governed by Debian policy and may not match the names upstream has assigned to the .pc files. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: pkg-config
On Sat, Sep 03, 2005 at 11:54:55AM +0100, Neil Williams wrote: > On Saturday 03 September 2005 6:11 am, Steve Langasek wrote: > > No, it's not. The .pc names are set by upstream and we should not > > diverge from them, and the package names are governed by Debian policy > > and may not match the names upstream has assigned to the .pc files. > On that note, I'm upstream and co-maintainer for a library package that is > being overhauled. The upstream tarball is qof-0.6.0.tar.gz, the SONAME is > libqof1, the package libqof1 and I want libqof1 >= 0.6.0 as a dependency for > packages that use the library. > Currently, the .pc file is qof-1.pc which probably needs to be changed. > Taking this as an example, what *would* be the recommended name for the pc? > Should it include the SONAME at all? > Should it always use the lib prefix? > Is there any convention on these filenames, independent of any distro? At the present time and given the current state of the software I believe it is not in Debian's best interest that you ship a .pc file *at all* upstream, so I can't offer you any recommendations here. If there are any conventions at all, you'll probably have better luck finding out about them from pkg-config upstream, or from some group such as GNOME or KDE that packages enough libraries to have come up with guidelines about them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: linker and transition questions...
On Sat, Sep 03, 2005 at 01:21:28PM +0200, Romain Beauxis wrote: > I'm making a new package for kshutdown, and I've got the following linda > report: > W: kshutdown; Shared object /usr/bin/kshutdown is linked with version 6 and 5 > of libstdc++. > As the linking is dynamic, and I never set up anything about this, I don't > know what to do about that What does objdump -p $path/usr/bin/kshutdown | grep NEEDED show? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: linker and transition questions...
On Sun, Sep 04, 2005 at 12:13:47AM +0200, Romain Beauxis wrote: > Le Dimanche 4 Septembre 2005 00:12, Romain Beauxis a écrit : > > Le Samedi 3 Septembre 2005 22:56, Steve Langasek a écrit : > > > What does objdump -p $path/usr/bin/kshutdown | grep NEEDED show? > > > > -> I only see libstdc++.so.6 there... > But not there: > 0:12 [EMAIL PROTECTED] /tmp% ldd ./usr/bin/kshutdown | grep ++ > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6c42000) > libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb6a1f000) > Strange isn't it? No, not strange at all; that's what I expected to see. Can you send the full output of ldd ./usr/bin/kshutdown? We need to know what library on your system is still pulling in libstdc++5 to know whether or not it's a problem. The output of objdump -p *does* indicate that the binary is directly linked only against the correct version of libstdc++, so the possible explanations for the libstdc++.so.5 reference are: - you have an old version of a package on your system that exports a C++ ABI, and therefore you need to upgrade it and rebuild; - you have a package on your system that is implemented in C++ but exports only a C ABI, in which case you can upload as-is; - your package build-depends on a C++ lib that hasn't undergone the transition, in which case you need to wait until it transitions before rebuilding and uploading; or - your build environment has fully transitioned to g++-4.0, but the environment where you're running linda is not, in which case you can upload as-is as soon as you're able to verify this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: linker and transition questions...
On Sun, Sep 04, 2005 at 12:47:56AM +0200, Romain Beauxis wrote: > Le Dimanche 4 Septembre 2005 00:43, Kurt Roeckx a écrit : > > I'm guessing this is not the same chroot you build it in and is > > not a current sid version? > Well, I built it under a fresh pbuilder from this morning, and I run a half > baked sid due to lack of kde fresh packages against the last transition.. > like kshutdown ;) > Then, are the dependencies for the new packages taken all from pbuilder's > chroot? > Also, why ldd reports differents thins, I thought that lld would use exactly > what objdump show.. ldd traverses dependencies and reports all of the libraries that would be loaded into memory by ld. On Sun, Sep 04, 2005 at 12:59:06AM +0200, Romain Beauxis wrote: > Le Dimanche 4 Septembre 2005 00:45, Steve Langasek a écrit : > > - your build environment has fully transitioned to g++-4.0, but the > > environment where you're running linda is not, in which case you can > > upload as-is as soon as you're able to verify this. > That's it! > I allready built the package on a clean sid pbuilder chroot, so that was not > the previous cases... > By running login on pbuilder, and ldd I get: > duppy:/# ldd /usr/bin/kshutdown | grep ++ > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7e0f000) > So that seems allright! > Then the package is at: > http://www.cti.ecp.fr/~beauxir5/uploads/ > If anyone wants to have a look at it and sign/upload it - I'm no DD sorry.. > The changes from previous one are only new upstream bugfix release and watch > file added... I've looked over the package update, and for the most part it looks ok, but the new Portuguese translation that upstream included is quite buggy and I'm not willing to upload a package that introduces such bugs. Bugs I see after a quick review: - the .po file has been badly converted to UTF8 by someone who assumed pt_BR uses ISO-8859-2 encoding -- it doesn't, it uses ISO-8859-1. #: mmainwindow.cpp:625 msgid "5 minutes warning" msgstr "5 minutos aguardando" - "aguardando" means "waiting", not "warning" #: mstatstab.cpp:96 msgid "Re&fresh" msgstr "Re&iniciar" - refresh != restart? #: mschedulertab.cpp:44 msgid "Registere&d tasks:" msgstr "Registra&dor de tarefas:" - "Registrador" means something that is used for registering; this could be an ok translation in context, I don't know. #: msettingsdialog.cpp:430 msgid "C&ustom Message" msgstr "Mensagem P&adrão" - Padrão means "default", not "custom"... Perhaps you could get someone from debian-l10n-portuguese to provide a review of this file, or else disable it until a review is possible? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: pkg-config
On Sun, Sep 04, 2005 at 01:04:40AM +1000, skaller wrote: > On Sat, 2005-09-03 at 04:19 -0700, Steve Langasek wrote: > > At the present time and given the current state of the software I > > believe it is not in Debian's best interest that you ship a .pc file *at > > all* upstream > Interesting. Hmm. Can you explain in a bit more detail > why you think this is? pkg-config and libtool are both tools designed to facilitate portability to platforms which have inferior linkers, and in the process they duplicate information already provided by ELF libraries on GNU/Linux in a manner that makes dependency changes more rigid and fragile. http://people.debian.org/~vorlon/dependency-hell/ > It does seem 'contrary' in some way to Debian's policy > of things going in particular places .. yet people don't > always actually put them there .. :) I really have no idea what you're referring to here. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: pkg-config
On Sun, Sep 04, 2005 at 08:52:53AM +0100, Neil Williams wrote: > On Sunday 04 September 2005 7:13 am, Steve Langasek wrote: > > pkg-config and libtool are both tools designed to facilitate portability > > to platforms which have inferior linkers, and in the process they > > duplicate information already provided by ELF libraries on GNU/Linux in > > a manner that makes dependency changes more rigid and fragile. > > http://people.debian.org/~vorlon/dependency-hell/ > Nice presentation but I don't see what you would like upstream to do > to help. *Not* using pkg-config? Obviously there will be some for whom the portability to arcane and broken Unices is important, and there will be those who find the GNOME-style versioned include paths worthwhile, but if you don't fall into one of these two categories, not deploying .pc files that people will subsequently write their applications to depend on is much less painful for Debian. > Once libtool 1.6 is in unstable rather than experimental, then I can use that > - but that won't help that much because the target platform for most of my > code is still FC3 (not my decision). Actually, after that talk was written I found out that the patch in question had *not* been committed to libtool upstream. It is present in the Debian libtool packages, however, including the one in unstable. > I don't mind making a special case for GNU/Linux but not if that > actually only includes Debian. Er, there's nothing Debian-specific about the rationale, and nothing in this that would penalize users of Fedora or other GNU/Linux distros. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: pkg-config
On Sun, Sep 04, 2005 at 08:06:07PM +1000, skaller wrote:
> Reading your excellent article, you explain this
> (excuse me duplicating text from your article):
> "* Glibc[] support[s] transitive dependencies .."
> which if I understand correctly: supposed executable E required
> library A, and library A requires library B, then you can link
> with a command like:
> gcc E -lA
> and don't need to specify -lB.
Correct, for the case of dynamic linking.
> Now you say to use libtool, which prunes extraneous dependencies.
> I actually find libtool a superior pain .. it is complex to use
> and makes a real mess of build scripts ;( I need more convincing
> on this point (I understand the pruning dependencies ..)
Actually, this should be read as: *if* you are using libtool, use this
version that can handle pruning redundant dependencies. There's really
no reason to be using libtool in the first place unless you're concerned
about making your packages portable to as many OSes as possible; if
that's not a major consideration for you, save yourself the headache of
trying to integrate libtool. :)
> Then you say to use 'versioned symbols in all libraries depended
> on by other libs' .. which makes sense .. however I could use
> some education here: the example:
> http://people.debian.org/~vorlon/dependency-hell/img9.html
> doesn't make any sense to me. Can you explain what it is doing?
The first section,
HIDDEN {
local:
__*;
_rest*;
_save*;
}
is a workaround for certain architecture-specific symbols which must be
present in the library and must *not* be versioned (discovered by trial
and error); the solution is to declare them as local symbols only, so
they're present and unversioned but not exported.
The second part,
MIT_KRB5_17 {
global:
*;
}
specifies a symbol version to apply to all other exported symbols.
> And here:
> http://people.debian.org/~vorlon/dependency-hell/img10.html
> you have an example of use of the version script: the second
> case is headed
> libtool(Makefile.am)
Two examples: the first is how to use a linker script when calling gcc
directly, the second is how to set up a Makefile.am for a libtool-using
package to call it for you.
> > http://people.debian.org/~vorlon/dependency-hell/
> >
> > > It does seem 'contrary' in some way to Debian's policy
> > > of things going in particular places .. yet people don't
> > > always actually put them there .. :)
> >
> > I really have no idea what you're referring to here.
> On an arbitrary system, to use some libary K, you cannot just
> write -lK on your link command, because the library will only
> be sought in standard locations.. you need to add -Lpath so the
> linker can actually find the library.
> My commend meant 'Debian policy says to put libraries in /usr/lib'
> which means in theory you don't need any -L switches (more or less),
> however some packages don't conform to this policy, so you may still
> need -L switches: that's what I meant .. :)
Mmm, yes. Hopefully very few packages fall into that category.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: pkg-config
On Sun, Sep 04, 2005 at 11:22:33PM +1000, skaller wrote:
> On Sun, 2005-09-04 at 04:08 -0700, Steve Langasek wrote:
> > On Sun, Sep 04, 2005 at 08:06:07PM +1000, skaller wrote:
> > The second part,
> > MIT_KRB5_17 {
> > global:
> > *;
> > }
> > specifies a symbol version to apply to all other exported symbols.
> What is the effect of applying a symbol version? Does this change
> the symbol 'external name'? Or is it a separate attribute,
> in which case, how can a client of the library specify a particular
> symbol version?
Symbol versions are transparent to the application, but when present at
build time the linker binds references to that symbol to the specified
symbol version -- this allows the runtime linker to distinguish between
two different functions with the same name but different
implementations.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: linker and transition questions...
On Sun, Sep 04, 2005 at 03:37:52PM +0200, Romain Beauxis wrote: > Le Dimanche 4 Septembre 2005 06:52, Steve Langasek a écrit : > > I've looked over the package update, and for the most part it looks ok, > > but the new Portuguese translation that upstream included is quite buggy > > and I'm not willing to upload a package that introduces such bugs. > Hum... > Ok, thks for pointing me out those bugs. > In fact, I don't speak a word in portugues, so I cannot handle it myself. > But I've got friend who speaks protugues perfectly, so I'll ask him to > correct > it soon. > Then, I feel it should nevertheless be uploaded soon, as those bugs are: > -- not important during normal use, and will not prevent from using the soft, > even in pt_BR > -- related to an upstream file, so **should** be corrected there > -- Can be filled as the packages is uploaded, and be corected later Sorry, translation bugs are a sticking point for me. I believe that a bad translation is worse than no translation, and this is definitely a bad translation -- one that includes errors that could significantly impact the usability of the interface. You may be able to find someone else willing to sponsor the package as-is, but I am not. > On the other hand, waiting for a corection will by the mean time delay the > total transition for KDE and libstdc++. Yes, getting the RC bug fixed is important, but that has nothing to do with uploading a new upstream version of the package! The entire changelog for kshutdown 0.6.1 is: 2005/06/25 0.6.1 - NEW: Portuguese Brazilian language translation - FIXED: Possible "make install" error (thanks to Gregorio) So, er, the only substantive change between the last version, and this version, is that a buggy translation has been added. Yes, upstream bugs should be addressed upstream; but knowing that this bug is there in the new version, I don't see any reason why I would want to sponsor a 0.6.1-1 upload instead of an 0.6.0-3 upload (or, indeed, NMUing with an 0.6.0-2.1 upload). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [RFS] grace6: An XY plotting tool
On Wed, Sep 07, 2005 at 05:15:14PM +1000, Ben Finney wrote: > On 07-Sep-2005, Torsten Werner wrote: > > Christoph Berg schrieb: > > > Re: Li Daobing in <[EMAIL PROTECTED]> > > >>I want to adopt grace6[1]. > > >> > > >>[1] http://bugs.debian.org/307358 > The bug report that you submitted says "I request an adopter for the > grace6 package". While it would be polite for prospective adopters to > coordinate with the existing maintainer, it's not a breach of > ettiquette to fail to do this. Hmm, I'm afraid I have to disagree; I understand this to be a major difference between an RFA and an O, in that a maintainer submitting an RFA reserves the right to choose a successor. I'm surprised to hear that there's documentation which suggests otherwise. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [RFS] qterm: BBS client for X Window System written in Qt
On Tue, Sep 13, 2005 at 01:27:22PM +0800, LI Daobing wrote: > > * debian/rules: > > DEB_AUTO_UPDATE_DEBIAN_CONTROL := yes > > This sucks, the generated control file is ugly as hell (it does > > build-depend on build-essential, etc.). Please fix that. > I don't agree, at least it works. No, it doesn't. Packages have ended up with RC bugs before as a result of cdbs changing the build-dependencies of the package in one of the standard debian/rules targets, and I strongly discourage maintainers from using this misfeature of cdbs. And build-depending on build-essential is certainly wrong. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: ITP: libpam-require -- PAM module to allow and/or deny particular users and/or groups
On Wed, Sep 14, 2005 at 02:06:01PM +0200, Timo Weingärtner wrote: > retitle 262121 ITP: libpam-require -- PAM module to allow and/or deny > particular users and/or groups > owner 262121 ! > thanks > I want to become the maintainer for this new package. What does this PAM module do that can't already be done with pam_listfile or pam_group? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: ITP: libpam-require -- PAM module to allow and/or deny particular users and/or groups
On Wed, Sep 14, 2005 at 06:04:29PM +0100, Sam Morris wrote: > Steve Langasek wrote: > >>retitle 262121 ITP: libpam-require -- PAM module to allow and/or deny > >>particular users and/or groups > >>owner 262121 ! > >>thanks > >>I want to become the maintainer for this new package. > >What does this PAM module do that can't already be done with > >pam_listfile or pam_group? > Forgive my asking, but isn't pam_group used for granting group > membership to a user based on where/when they are logging in (from); and > pam_listfile used for authenticating based on the contents of a plain > text file, rather than the groups of which a user is a member? Overview of module This module provides group-settings based on the user's name and the terminal they are requesting a given service from. It takes note of the time of day. Yah, apparently. But pam_listfile seems to fit the bill rather closely, and between the two of them, they probably cover most things you would want to do with groups in PAM? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Dependencies and debconf configuration
On Sun, Sep 25, 2005 at 09:38:34AM +0200, Julien Valroff wrote: > As an exercise, I am trying to package as cleanly as possible bootsplash > 3.2 and a few themes. > I use debconf templates for the configuration. > Main bootsplash package depends on a given theme package, which depends > itself to bootsplash. I really don't know if it is a good idea, as this > leads to a few problems: > The configuration of bootsplash needs to have at least one theme > installed, ie. when I run 'dpkg -i bootsplash.deb > bootsplash-theme.deb' (depending on the order the packages are > configured), it happens that bootsplash is configured before the theme > is installed: the user has to run 'dpkg-reconfigure bootsplash' by hand. > * Is there any possibility to force the order of > configuration/installation when installing several packages together? Yes: package dependencies. > * The other way would be to make bootsplash-theme package _not_ depend > on bootsplash, I think it would force the theme to be installed before > the main bootsplash package is installed, is that right? But what would > then happen with aptitude that installs the recommended packages by > default? If bootsplash requires a theme to be installed in order for its postinst to complete successfully, then bootsplash must depend on the theme and the themes must not depend on bootsplash. If the package's debconf config script *also* can't do the right thing before the theme is unpacked, then the config script should exit without attempting to set any debconf variables. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Dependencies and debconf configuration
On Sun, Sep 25, 2005 at 12:21:58PM +0200, Julien Valroff wrote: > > If bootsplash requires a theme to be installed in order for its postinst to > > complete successfully, then bootsplash must depend on the theme and the > > themes must not depend on bootsplash. > Thanks, it works, at least with dpkg (I still have to check how synaptic > an aptitude behaves). Or you could read what policy says about the meaning of package dependencies. > > If the package's debconf config script *also* can't do the right thing > > before the theme is unpacked, then the config script should exit without > > attempting to set any debconf variables. > I am not sure to understand what you mean. Could you please explain > again? Package dependencies only affect postinst scripts. They don't affect preinst scripts or debconf config scripts; preinst script dependencies must be enforced with pre-dependencies, and config scripts must be resilient against being called before dependencies are installed because there is no package relationship that can be declared for config scripts. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: sponsership
On Tue, Oct 11, 2005 at 04:43:58PM -0400, Justin Pryzby wrote: > Okay, besides the usual chit-chat about this kind of sponsorship > (whatever it is), > Does anyone know why some messages come through the list without the > usual unsubscription trailer? Because they're MIME multipart. But please don't follow up to spam. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: what about confdirs?
On Fri, Oct 14, 2005 at 03:23:41PM +0300, Damyan Ivanov wrote: > Rakotomandimby Mihamina wrote: > >>There's no such thing as confdir - only "ordinary" directories containing > >>conffiles. > > It has nothing to do with my yum package, but how do you declare another > > directory outside /etc as a "configuration file container" ? > Just declare all your out-of-/etc conffiles as such in .conffiles > But better yet, move the files in question somewhere under /etc and put > symlinks to them in the directory where the software expects to find them. Best of all, fix the software to not look for its configuration outside of /etc, which is actually what the FHS requires. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: what about confdirs?
On Fri, Oct 14, 2005 at 12:57:23PM +0300, Damyan Ivanov wrote: > Rakotomandimby Mihamina wrote: > > I would like to know if I must list the configuration directories into > > 'conffiles'. > > > > I am trying to make a yum debian package. > > It has one "main" confioguration file: /etc/yum.conf > > and also have a /etc/yum.d/ directory. > > > > How should I write "conffiles" in order to manage it? > Nothing. Every file under /etc is automatically marked as conffile. See last > paragraph of dh_installdeb(1) Every file under /etc is automatically marked as a conffile *when using debhelper*. While most packagers are using debhelper these days, please be clear about this, as it is an optional helper package and not mandated by policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: upgrades skipping stable releases
On Sun, Oct 16, 2005 at 05:00:01PM +0200, Stefano Zacchiroli wrote: > On Sat, Oct 15, 2005 at 09:48:26PM +0200, Christoph Berg wrote: > > You can remove the transition package now; upgrades skipping a stable > > release are not supported. > Interesting, is this policy or just common practice in past releases? It's the release team's policy for sarge and etch. There's not enough testing to go around, and the release cycle is too long, to make skipping a stable release a realistic option. We actually know already that upgrades from woody to etch are not possible, because of a circular conflict/pre-depends in some essential packages that requires upgrading to sarge before upgrading to etch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: gcc best practices | problems
On Sat, Oct 29, 2005 at 02:22:15AM -0400, -.JavaManiac.- wrote: > well, my question is about gcc-4.0. > if i have a package that doesn't compile against gcc-4.0,what are my > choices??and what is the best ??,Build-Depends on gcc-3.4 or modify > the sourcecode to make it clean to gcc-4.0??. > Im really confused about it,if you can give me some light i will be > glad.Some added tips are welcome. If the package doesn't compile with gcc-4.0 because your code needs to be updated, you should fix your code. You should only depend on older compiler versions in the case of a bug in the current version (or in exceptional cases, such as a kernel or libc needing a particular compiler version because the package abuses the compiler). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: gcc best practices | problems
On Sat, Oct 29, 2005 at 09:12:27AM -0200, Henrique de Moraes Holschuh wrote: > On Sat, 29 Oct 2005, skaller wrote: > > compiler ABI changes (I believe that doesn't apply here since > > gcc 4.x uses same C ABI as gcc 3.4, not sure about C++ though) > There is a fatal C++ ABI change from 3.4 to 4.0. The ABI change is between 3.3 and 3.4, not 3.4 and 4.0. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Going nuts over debconf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Nov 03, 2005 at 10:32:07PM -0500, Peter S Galbraith wrote: > Problem summary: Using debconf and rc.d script hangs package installation > I am merging packages `powstatd' and `powstad-crypt' into a single new > `powstatd' package with encryption enabled. I wrote a debconf script > that displays a warning in certain cases when the configuration file must > be edited for the new package to continue working. > Upgrading to the new package works fine if the postinst script does not > start an rc.d process (e.g. because the package conffile doesn't enable > it). Upgrading hangs when the postinst process is started. This normally indicates that the process being started from the init script doesn't daemonize properly, and still has file descriptors open to debconf. The standard workaround for this is to call db_stop at the end of your postinst to force-detach the debconf daemon. - -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDattTKN6ufymYLloRAryuAJwIhwkgmXl7K9qgj949HXqAzgKinQCgp49s ADFBfkUcUJX8PMg39uom9/o= =6Fmo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depends: awk -- Is that required?
On Wed, Nov 09, 2005 at 06:43:51PM -0700, Bob Proulx wrote: > I need a clarification because I am confused. If I have a script that > uses awk do I need the package to "Depends: awk"? Or is awk like > basename where we are able to assume it is on the system without any > explicit dependencies? > I see that many packages do "Depends: awk". But awk is an alternative > and mawk is "Priority: required" so I would not think so. But gawk > provides awk and is "Priority: optional" but with a higher alternative > priority too and so that "required" mawk is almost never used. (I > always install gawk as awk for its better features.) > If the package used gawk specific features then the decision would be > easy. It would need to depend upon gawk. But it only uses basic awk > features and so any of the alternatives is sufficient. > Thanks for you knowledge in this. awk is "virtually essential": it can't be Essential: yes because that would prevent removing mawk in favor of gawk, but awk is a dependency of another essential package to ensure that you can use basic awk functionality without having to depend on it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Depends: awk -- Is that required?
On Wed, Nov 09, 2005 at 09:57:37PM -0500, Roberto C. Sanchez wrote: > On Wed, Nov 09, 2005 at 06:43:51PM -0700, Bob Proulx wrote: > > I need a clarification because I am confused. If I have a script that > > uses awk do I need the package to "Depends: awk"? Or is awk like > > basename where we are able to assume it is on the system without any > > explicit dependencies? > > I see that many packages do "Depends: awk". But awk is an alternative > > and mawk is "Priority: required" so I would not think so. But gawk > > provides awk and is "Priority: optional" but with a higher alternative > > priority too and so that "required" mawk is almost never used. (I > > always install gawk as awk for its better features.) > > If the package used gawk specific features then the decision would be > > easy. It would need to depend upon gawk. But it only uses basic awk > > features and so any of the alternatives is sufficient. > > Thanks for you knowledge in this. > I suspect that it is not necessary: > $ apt-cache show mawk |grep "Provides\|Priority" > Priority: required > Provides: awk Right conclusion, wrong rationale. A package being Priority: required does not excuse you from an explicit dependency. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Package that depends on ming
On Thu, Nov 10, 2005 at 12:29:27PM +0800, Paul Wise wrote: > > If it _depends_ upon libming, your program can't be shipped with Debian > > as long as libming is not in Debian. > It can be shipped in contrib though. contrib is for free packages with > dependencies (free or otherwise) that are not in debian. True, but uploading a package to contrib instead of main because you haven't *bothered* to package the deps is pretty lame. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [gmail] Re: sponsor quake3 quake3-data packages
On Thu, Nov 10, 2005 at 11:17:08AM -0500, Justin Pryzby wrote:
> On Thu, Nov 10, 2005 at 02:31:09PM +0100, Marc Leeman wrote:
> > > (most of these problems are probably inherited from the quake2
> > > packaging you used). You will have to fix most of these before
> > > someone should sponsor the package.
> > > W: quake3-data:
> > > possibly-insecure-handling-of-tmp-files-in-maintainer-script postinst:225
> > I use /tmp/ for the place to download the point and demo files. This
> > used to be /root/. Since I do not think temporary installs should be
> > dl'd there, I moved them to tmp. The extraction of the file is done in a
> > dir with tempfile. I could move this one level deeper and again use
> > tmpfile, but from a functional point of view, this does not change much,
> > especially since the warning only kicks in when the default from
> > templates is emptied out in the user interaction.
> Lintian is right, if for the wrong reason.
> tempdir() {
> _TEMPDIR=`tempfile --directory $1 --prefix quake3-data`
> # kill off fresh tempfile
> rm $_TEMPDIR
> mkdir $_TEMPDIR
> echo $_TEMPDIR
> }
> That is a tag + security race condition between rm and mkdir. You'll
> want to use mktemp -d instead.
It's darn broken, but it's not actually a security hole unless something
else makes bogus assumptions about the success of the tempfile function (or
unless it's not being run with set -e, like it's /supposed/ to...).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: problems with bug #338269
block 338269 by 336114 thanks On Sat, Nov 12, 2005 at 10:10:44AM +0100, Tommaso Moroni wrote: > I'm having some problems squashing this bug: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338269 > Since a couple of weeks ago knights was working without problems > I think it could be caused by some library which it depends on. > Do you have any advice about it? > Does anybody experienced a similar breakage? Probably bug #336114. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: change contro to make package not for 4 archs.
On Wed, Nov 16, 2005 at 06:07:05PM -0200, Jose Carlos do Nascimento wrote: > I have this bug opened > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337569 > but, I dont know how to change control file to create .deb just for > others archs than "alpha m68k mips". You do this by listing in your Architecture: field in debian/control all of the architectures for which the package *should* be built. (In this case, that's definitely the correct course of action because you have a dependency on a non-free package which is available for a finite, static set of architectures.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: change contro to make package not for 4 archs.
On Thu, Nov 17, 2005 at 12:18:03PM -0200, Jose Carlos do Nascimento wrote: > >You do this by listing in your Architecture: field in debian/control all of > >the architectures for which the package *should* be built. (In this case, > >that's definitely the correct course of action because you have a > >dependency > >on a non-free package which is available for a finite, static set of > >architectures.) > I did it, but and if Debian group create another arch ? like kfreebsd > or other ? > I will need to add these new archs, Why? Where will the distributed-net binaries for these archs come from? > I though "Architecture" support something like, > Architecture: any !alpha !m68k ... But that's not accurate. You don't support "all archs except for alpha and m68k", you support "all archs for which a distributed-net binary package is available". -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Problem with removing rc script
On Sun, Nov 27, 2005 at 11:09:07AM +0100, Bas Wijnen wrote: > Thank you for reporting this problem. > Hello mentors, > I received bug report #339387, and want to solve it in an elegant way. The > problem is that gnocatan-meta-server used to have an rc script to start it, > but now it's a transitional package (and the script moved with the rest to > pioneers-meta-server). Appearantly not having the scripts anymore is no > reason for dpkg to remove the symlinks. > So I should do that by hand. The question is how. The bug report suggests to > manually do it in the postinst, is that a good idea? Yes, it is. If the maintainer script itself is no longer present in the package, then simply calling "update-rc.d gnocatan-meta-server remove" in the postinst on upgrade from an affected version should be sufficient. > I was thinking of adding an empty script so it will be removed at package > purge. That way I would be sure debhelper can do all its magic, and I > would be more sure that the Right Thing(tm) is done. Except that this is the *wrong* thing; you don't want empty scripts on the system, you don't want symlinks for a known dead service to be left around when upgrading to the dummy package. Debhelper is a *helper*, not a replacement for making sound decisions about creating proper packages. > What is the usual way to solve this situation? The usual solution is to not provide such dummy packages at all... :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Two questions related to C++ ABI transition
Hello, On Fri, Dec 02, 2005 at 01:22:55AM -0600, Ming Hua wrote: > One package I maintain (libscim8 from scim) is going through the c2->c2a > C++ ABI transition. I have two questions about the dependency handling > in such a transition: > 1. Raised by my sponsor - Should I add g++ (>= 4.0.2-4) to the > Build-Depends? I did not do so, and my sponsor asked why not. The only > reason I could find was from the previous c102->c2 transition plan [1]: > "Please don't add build dependencies on g++ (>= 4.0) or build-essential > (>= 11)", there is no such instruction this time. > One thing I can think of is that adding g++ (>= 4.0) or (>= 4.0.2-4) > actually prevent building the package with g++-3.4, although they have > the same ABI as the g++-4.0. But that doesn't explain when I shouldn't > build-depend build-essential (>= 11). And I agree with my sponsor that > such dependency avoids accidently building them with wrong ABI. So can > somebody explain why such dependency is not desired? It's not desired because it's unnecessary: all of the buildds have been updated to use the new toolchain version, and adding this build-dependency would just make it harder for people to backport your package to a previous ABI version (hopefully changing the package name, of course). So to keep packaging simple, maintainers are encouraged not to add such build-dependencies. > 2. Once the library package is built with the new ABI, should I tighten > the build-dependency of the application packages that depend on the > transitioned library? Tightening the build-dependency will again ensure > that the package is built with the correct ABI, but it also makes the > package unbuildable in an old pre-transition environment even with the > old libraries. As the plan is to binNMU these application packages, it > seems a tightened build-dependecy is not urgent after all, but are they > preferred eventually? Not preferred at all; again, this complicates backporting of packages for those who have a reason to do so. Since your application does not *need* the new version of the library in order to be built, it helps certain use cases if you don't use the Build-Depends: field to specify the libraries that you *want* the package to build with. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: library naming problem
On Wed, Dec 21, 2005 at 01:20:31AM -0600, Peter Samuelson wrote: > [Steve Halasz] > > Hopefully we can manage to split the two APIs into different > > packages. But for now, how should I name the package when the ABI has > > changed, but the SONAME hasn't? > Splitting into two packages is indeed the best idea here. Well, you'd think so, except both the C and C++ libraries seem to be provided by the same library. (I thought this was what he was saying, so I checked the package in the archive -- one lib file.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Lintian error about missing debconf dependency (which is not missing)
On Wed, Dec 21, 2005 at 08:35:52PM +0100, Michael Hanke wrote:
> I'm preparing a package which uses debconf. When I run lintian on the
> package the following error is reported:
> E: arno-iptables-firewall: settitle-requires-versioned-depends config
> N:
> N: Debconf only supports the SETTITLE command as of version 1.3.22. To
> N: ensure upgrades work correctly, packages that use this new command
> N: should declare a dependency on that version of debconf.
> N:
> The strange thing is, that I have the following line in the control file:
> Depends: ${misc:Depends}, iptables (>=1.2.11), gawk, debconf (>=1.3.22) |
> debconf-2.0
> There is clearly a versioned debconf dependency. The above line is
> expanded to the following when building the package.
> Depends: debconf (>= 0.5) | debconf-2.0, iptables (>= 1.2.11), gawk, debconf
> (>= 1.3.22) | debconf-2.0
> Does anybody know where the problem is?
It's pretty likely that the lintian check is buggy in this case;
nevertheless, your depends: line is *also* buggy.
Depends: debconf (>= 0.5) | debconf-2.0, debconf (>= 1.3.22) | debconf-2.0
Reduces to
Depends: debconf (>= 1.3.22) | debconf-2.0
*but*, this in turn reduces to
Depends: debconf-2.0
because there are versions of debconf older than 1.3.22 which provide
debconf-2.0 (the Provides: was introduced in debconf 1.2.30), so they
satisfy the second branch of the dependency relationship when they
*shouldn't*.
If you depend on newer features than those guaranteed by the debconf-2.0
interface, you will need to depend on the providers of those features
explicitly, *without* an or on "debconf-2.0".
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: Lintian error about missing debconf dependency (which is not missing)
On Thu, Dec 22, 2005 at 09:36:57AM +0100, Michael Hanke wrote: > > If you depend on newer features than those guaranteed by the debconf-2.0 > > interface, you will need to depend on the providers of those features > > explicitly, *without* an or on "debconf-2.0". > Thanks. I did'nt realize this fact. So if I get you right the solution > would be to get rid of the debconf-2.0 dependency. If I do so lintian is > fine, but I guess Joey Hess is not: > http://lists.debian.org/debian-devel/2005/08/msg00136.html > (and follow-ups) > This post was the reason why I included this dependency in the first > place. > As the debconf-2.0 package's purpose is to allow transition to cdebconf, > is depending on cdebconf explicitely as an alternative to debconf an > option? How compatible are those 'alternatives' currently. Yes, the best solution available today would be to use Depends: debconf (>= 1.3.22) | cdebconf (>= ??) I don't know what minimum version of cdebconf (if any) you should specify to get support for settitle. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal for collaborative maintenance of packages
On Thu, Dec 29, 2005 at 03:43:59PM +1100, skaller wrote: > On Wed, 2005-12-28 at 23:50 -0200, Gustavo Franco wrote: > > > (...) > > > I wasn't addressing your point specifically. Instead, I'm raising > > > another one. The whole Debian system is a serious pain and an > > > impediment to cooperation. Ubuntu is not much better. > > > > > > I should not have to be a DD to commit to > > > the archive -- ANYONE should be able to commit perhaps with > > > some minimal registration requirements. > > > > > > This is how Wikipedia works and why it is successful. With minimal > > > fuss I have contributed some comments and a couple of changes. http://www.penny-arcade.com/comic/2005/12/16 > > There is no serious pain in how Debian and Ubuntu are handling their > > packages, IMHO. > How would YOU know??? You're a DD. I'm not. You have access > to resources .. I don't. But I am the one actually building > the software. I am not meaning to be rude: I'm pointing out that > insiders are NOT qualified to comment on how outsiders feel > about how easy it is for THEM to contribute. While insiders are not qualified to comment on how outsiders *feel* about the process, they are certainly the people to judge whether the *outcome* of the process is the correct one. Sorry, if you want Debian to make particular changes to make it easier to contribute, you're much better off arguing it in terms of the *benefits to the project* (and mitigation of the risks) than in terms of how it makes a set of possible contributors feel. And this... > I run Ubuntu .. I can't even test my own Debian package > on my own system. isn't a great argument that this is a low-risk change... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFS: directnet -- A serverless, mesh network instant messaging client
On Tue, Jan 03, 2006 at 07:49:35PM +, Ben Hutchings wrote: > Thijs Kinkhorst wrote: > > On Tue, January 3, 2006 09:47, Gregor Richards wrote: > > > I updated the package to 1.0.0. The version compare algorithm doesn't > > > like it ... it thinks that 1.0.0 is less than 1.0.0rc5 ... but that's not > > > how release candidates work :) > > That's indeed a caveat on the Debian version compare algorithm. When > > you're packaging a release candidate, you normally should watch out for > > adding 'rcN' to the version to avoid being able to update it to the real > > version later. > > What's done commonly is something like this: 0.9.9+1.0.0rc5, or for a > > higher version: 2.4.3+2.4.4rc1. > I believe this practice has been obsolete since the release of sarge. > dpkg now considers "~" to sort before anything, even a null string, so > you can use e.g. "1.0.0~rc5". You can't upload such a version to the Debian archive, so the older trick is not obsolete. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFS: elvis - powerful clone of the vi/ex text editor
On Mon, Jan 09, 2006 at 07:50:31PM -0800, Russ Allbery wrote: > Kapil Hari Paranjape <[EMAIL PROTECTED]> writes: > > I've prepared a new maintainer upload of elvis and it is available > > at > > http://www.imsc.res.in/~kapil/debian/elvis/elvis*4adopt3* > > (If someone agrees to sponsor this I will of course up the version to > > 2.2.0-5.) > This looks good to me. I'll sponsor it. Please go ahead and build a new > package with the 2.2.0-5 version number. > When you do that, you may want to move the configure patch introduced in > the last QA upload to a patch in debian/patches rather than having it be > just in the Debian .diff.gz. That way it would match all the other > modifications to the upstream code. > I recommend switching from the current manually-implemented patch system > to using dpatch, although you're certainly not required to do this and > I'll sponsor the package anyway. The advantage to using dpatch, even > though it may not gain you any additional functionality over what you have > now, is that more other people use it and it's one less thing about the > package for someone else who wants to work on it to figure out. For new deployment of patch systems, I would strongly encourage using quilt instead of dpatch. It has much better handling of patch dependencies than any of the others, and much more user friendly patch editing/creating capabilities. The xorg, glibc, and samba packages, for instance, are all using quilt today. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFS: elvis - powerful clone of the vi/ex text editor
On Mon, Jan 09, 2006 at 10:55:45PM -0800, Russ Allbery wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > For new deployment of patch systems, I would strongly encourage using > > quilt instead of dpatch. It has much better handling of patch > > dependencies than any of the others, and much more user friendly patch > > editing/creating capabilities. > > The xorg, glibc, and samba packages, for instance, are all using quilt > > today. > Oh, interesting. I'd been noticing it in use by large packages, but I > wasn't aware it was at the point where it was a reasonable alternative to > dpatch even for smaller ones. I'll have to take a closer look. Right, AFAICT the larger packages have been early adopters of quilt not because it's harder, but because they're the packages that have desperately needed something better :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFS: Kraptor and Kball
On Tue, Jan 10, 2006 at 11:35:01AM +0100, Miriam Ruiz wrote: > Kraptor and Kball are two games currently in debian repositories, > Kraptor is a classic shoot 'em up scroller game, where you must fight against > tons of bad dudes. > The game offers high speed action, with massive destruction and lots of fun. > Kraptor features a powerful engine for 2D shooter scroller games. > Massive destruction, powerful weapons, all that you always wanted in this kind > of games! > http://kraptor.sourceforge.net/ > KBall is a game of skill and reflexes, non violent, suitable for all ages. > The idea is to move a ball around the map, without falling, without running > out of time, and getting the prizes, in order to reach the exit. > The map has different traps, such as slides, pushers, jumps, falls, walls, > etc. > Maps are viewed from top view, and the walls and player's ball are real-time > rendered in beautiful 3D. > http://kball.sourceforge.net/ > New packages are temporarily available at http://baby.yi.org/packages/kronos/ > . It seems all my usual sponsors are quite busy right now, so if somebody has > the time for having a look and sponsoring them, you're welcome. Already uploaded kball, actually; you should've received some email about that by now. Looks like bug #345244 wasn't closed in the changelog, though, so I'll go close it by hand. Also, you might want to fix the broken debian/watch file that you added in -3, as it points to kraptor upstream... I'll take a look at kraptor as well, since it has a similar RC bug. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFS: Kraptor and Kball
On Tue, Jan 10, 2006 at 03:19:00AM -0800, Steve Langasek wrote: > Already uploaded kball, actually; you should've received some email about > that by now. Looks like bug #345244 wasn't closed in the changelog, though, > so I'll go close it by hand. Also, you might want to fix the broken > debian/watch file that you added in -3, as it points to kraptor upstream... > I'll take a look at kraptor as well, since it has a similar RC bug. ... and I see that kball's watch file ended up in the kraptor packaging. Whoops. If you'd care to fix this issue, and also document the closure of bug #345249 in the changelog, I can sponsor kraptor tomorrow. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFS: knmap -- Kde interface to nmap [uploaded]
On Fri, Jan 13, 2006 at 09:10:32PM +0100, Christoph Haas wrote: > On Friday 13 January 2006 19:40, Claudio Moratti wrote: > > On Friday 13 January 2006 15:48, Christoph Haas wrote: > > > debian/patches: [QUESTION/HINT] > > > You are changing a whole lot of the autoconf parts. Does this have > > > to do with some transitions going on? Usually just the config.guess > > > and config.sub are altered in Debian packages and those are directly > > > in the diff.gz (without the need to use dpatch). Just curious. > > My first sponsor, Florian Ernst, taught me about libtoolization... > > I relibtoolize every package, if necessary, in order to have a correct > > and minimal "Depencend" field... > > this is the reason ;-) > I thought I understood at least the reason to include diffs for a > config.guess and config.sub. But IMHO relibtooling is only needed when > certain libraries are in a state of transitions. There are *always* libraries in a state of transition in Debian. Using the Debian libtool means limiting those transitions to packages which have a valid reason for depending on the transitioning library, instead of giving us transitions that ripple through all the indirect reverse-dependencies. Just to be clear, relibtoolizing should only need to be a one-time thing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: How to add a localization *.po file to a package?
On Tue, Jan 17, 2006 at 12:43:25AM -0800, Stan Vasilyev wrote: > I'm the new maintainer for xdialog package. A user has submitted a new > localization file ca.po via the BTS. I'm trying to include this file in the > package. > In order for this file to compile into the package I need to change the > configure.in and add "ca" to ALL_LANGUES. Doing so breaks the package because > the make scripts run aclocal and automake and a lot of files get changed, > after which debuild complains that "unable to represent changes to foo, > binary contents changed". > How do I add a translation without modifying the configure.in? You don't. How about just forwarding it upstream instead? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: fixing a bug via NMU
On Tue, Jan 17, 2006 at 01:03:32PM +0100, Bjoern Boschman wrote: > I'd like to close on of the xlibs-dev bugs, but I've never done an NMU > before. This is because "NMU" stands for "non-maintainer upload", and you don't appear to be a DD, therefore it's not possible for you to upload -- non-maintainer or otherwise. A DD will have to upload the fix in question. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: fixing a bug via NMU
On Tue, Jan 17, 2006 at 01:55:27PM +0100, Frank Küster wrote: > Steve Langasek <[EMAIL PROTECTED]> wrote: > > On Tue, Jan 17, 2006 at 01:03:32PM +0100, Bjoern Boschman wrote: > >> I'd like to close on of the xlibs-dev bugs, but I've never done an NMU > >> before. > > This is because "NMU" stands for "non-maintainer upload", and you don't > > appear to be a DD, therefore it's not possible for you to upload -- > > non-maintainer or otherwise. A DD will have to upload the fix in question. > But see especially > http://lists.debian.org/debian-mentors/2006/01/msg00168.html Which is unnecessarily confusing use of the terminology. Amaya is the one doing the NMUs in this case; it happens that she is using patches prepared by NMs in the process. I don't think it's particularly appropriate to list the NM as the "maintainer" in the changelog, either, as they are *not* the party responsible for the upload (they can't be); though it's certainly appropriate to credit them in the changelog. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: How to close Bugs in experimental
On Wed, Jan 18, 2006 at 09:29:35AM -0200, Henrique de Moraes Holschuh wrote: > On Wed, 18 Jan 2006, Thijs Kinkhorst wrote: > > In a more general sense, it's important to note that the > > fixed-in-experimental tag is deprecated, and definately not necessary > It is kinda hard to consider it deprecated while DAK still sets it instead > of doing a proper job of issuing "notfound" commands to the BTS. You mean "close" commands... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: How to close Bugs in experimental
On Wed, Jan 18, 2006 at 10:00:01AM -0200, Henrique de Moraes Holschuh wrote: > On Wed, 18 Jan 2006, Steve Langasek wrote: > > On Wed, Jan 18, 2006 at 09:29:35AM -0200, Henrique de Moraes Holschuh wrote: > > > On Wed, 18 Jan 2006, Thijs Kinkhorst wrote: > > > > In a more general sense, it's important to note that the > > > > fixed-in-experimental tag is deprecated, and definately not necessary > > > > > It is kinda hard to consider it deprecated while DAK still sets it instead > > > of doing a proper job of issuing "notfound" commands to the BTS. > > You mean "close" commands... > No, as close commands ARE clearly deprecated as well, and not at all > equivalent to adding a tag. We are taliking about uploads to experimental, > after all. > AFAIK, [EMAIL PROTECTED] should be used for unstable uploads (it already is, I > think), and notfound commands to [EMAIL PROTECTED] should be used instead of > fixed-in-experimental tags. Wrong. notfound commands don't do anything that's at all useful here. You need close or -done (and yes, katie would implement this using -done, just as it already does for maintainer uploads to unstable). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: non-PIC problem
On Fri, Feb 03, 2006 at 05:28:15PM +0800, Paul Wise wrote: > I'm trying to get synfig (http://www.synfig.com) into debian, and there > is one last issue before I start harassing my sponsors/co-maintainers to > upload it. > Lintian complains about shlib-with-non-pic-code on one of the plugins, > and the main lib. I think the problem with the plugin is that it > statically links against libavcodec-dev and libavformat-dev (which don't > have associated shared libraries). Would it be ok to ignore/override > this error for this plugin? No, it would not. libavformat-dev/libavcodec-dev are arch: any; on the majority of our architectures, linking non-PIC code into a shlib *will* cause problems of one sort or another. The proper procedure is to request a _pic.a library from the ffmpeg maintainer that you can link against. > I've searched the build logs and the only object file compiled without > -fPIC is the embedded copy of libltdl statically linked into the > library. Does anyone have any advice for how to fix this? Link against the system libltdl instead of using a redundant bundled copy. The unixodbc package in sarge is an example of this, IIRC. > Is this going to require autoconf/automake changes? Yes, it should. (Probably only autoconf changes.) > What solution should I pursue with upstream that will allow them to keep > the libltdl copy for platforms where it is needed? I've never understood why people feel the need to bundle libltdl in their sources instead of just telling users to download & install it as a build-dependency. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Removing former conffiles
On Tue, Feb 07, 2006 at 11:47:49PM +0100, Bas Wijnen wrote: > On Tue, Feb 07, 2006 at 12:28:39AM -0800, Don Armstrong wrote: > > On Tue, 07 Feb 2006, Frank K?ster wrote: > > > Don Armstrong <[EMAIL PROTECTED]> wrote: > > > > Just a word of caution here: If the administrator has modified the > > > > file, you should not rename or move it, as they may know better > > > > than you what they're doing. A proper course of action would be > > > > warning them, and/or offering to remove the files in question via > > > > debconf. > > > If I know that the file will no longer be read at all, there's no > > > point in pretending that it still have an effect. Renaming it makes > > > this completely clear. > > Right. The problem is that it's not always easy to know if the file > > will no longer be read at all; you can't assume that the administrator > > has left in place your default configuration system. [Likewise for > > failure modes on the presence of an obsolete configuration file; > > unless you know for certain that it will fail, you should give the > > administrator some way to override your guess.] > The package is a dummy transition package. When this version of gnocatan is > installed, no gnocatan config files will be read at all anymore. It might > have been a good idea to try and convert it into a pioneers config file (the > new name of the package), but as long as the name includes "gnocatan", it's > not going to have any effect, since there are no binaries in the gnocatan-* > packages anymore (well, except this maintainer script). > Would that mean it's ok to remove it? Or should I better rename it so they > can use it to convert to a pioneers file by hand? Perhaps that's the best... > I could make a NEWS message about that as well. I think the right thing to do here is to simply remove it if we can determine that it's unmodified. Well, really, I think the right thing is for *dpkg* to remove it if it can determine that it's unmodified; this is bug #330256. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: bug pages and source packages
On Thu, Feb 09, 2006 at 08:14:59PM +0100, Norbert Preining wrote: > > When I go to > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=info > > it tells me > > ... to the source package texinfo's bug page ... > > But when I go to > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=texlive-base-bin > > I don't see te link to the source package. > > Furthermore, bugs in the binary packages from src=texlive-bin do *not* > > occur on the qa.debian.org/developer.php page. > E.g.: > Bug nr 352092 is reported to texlive-pdfetex, which is build from > texlive-bin source package. But on the bug page: > http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=texlive-bin > nothing mentions this bug! > > Is the reason for this that the texlive packages are in experimental and > > not in unstable? Yes. Since the package is not in unstable, it's not in the source<->binary map used by bugs.d.o. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: libcpufreq and the small libsysfs transition
On Sun, Feb 12, 2006 at 07:06:00PM +0100, Mattia Dongili wrote:
> I need a quick suggestion how to handle libcpufreq{0,-dev} within the
> libsysfs transition.
> Facts:
> - current cpufrequtils is compatible with both libsysfs1 and libsysfs2
> - the source package depends on libsysfs-dev >= 1.0.0
> - libcpufreq0 uses ${shlibs:Depends} to build dependencies
> Now, my understanding is that a binNMU is sufficient to rebuild binaries
> and fill the correct dependencies?
Looks like it to me.
> If so, is pinging about it [EMAIL PROTECTED] usually sufficient to
> ask request the binNMU?
Yes.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: libcpufreq and the small libsysfs transition
On Wed, Feb 15, 2006 at 07:47:11PM +0100, Mattia Dongili wrote:
> On Sun, Feb 12, 2006 at 02:19:08PM -0800, Steve Langasek wrote:
> > On Sun, Feb 12, 2006 at 07:06:00PM +0100, Mattia Dongili wrote:
> > > I need a quick suggestion how to handle libcpufreq{0,-dev} within the
> > > libsysfs transition.
> > > Facts:
> > > - current cpufrequtils is compatible with both libsysfs1 and libsysfs2
> > > - the source package depends on libsysfs-dev >= 1.0.0
> > > - libcpufreq0 uses ${shlibs:Depends} to build dependencies
> > > Now, my understanding is that a binNMU is sufficient to rebuild binaries
> > > and fill the correct dependencies?
> > Looks like it to me.
> > > If so, is pinging about it [EMAIL PROTECTED] usually sufficient to
> > > ask request the binNMU?
> > Yes.
> Ooops :)
> My mail was indended as just a "suggestion" on how to proceed, I was
> waiting the availability of libsysfs2 in sid before actually pinging
> debian-release@ for the binNMU.
> I did see that the package was rebuilt on 02/12 actually :)
> Apologies for not being clear enough...
Hmm... sloppy of me for not noticing. Well, let me know when libsysfs2
actually hits unstable then...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: RFC/RFS: PyKaraoke
On Thu, Feb 16, 2006 at 12:08:21AM +0100, Miriam Ruiz wrote: > > The pyc files are generated in the postinst, you won't see them in dpkg > > -L/-c output. > So, if you upgrade to a newer version of python, it won't work, as the > compiled files would not be regenerated. is that it? I guess I understand why > it cannot be run with python2.4 then. I hope someone finds a better solution > anyway :) Yeah, we've been working on it... discussion on debian-python over the past month or two. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Non-free firmware update data for a package in main?
Hi Neil, On Mon, Feb 27, 2006 at 09:29:04PM +, Neil Williams wrote: > A driver package intended for main may need to provide a non-free binary > firmware update for specific devices only. The firmware is volatile and needs > reloading each time the driver is initialised - but only if one of these > devices is being used. Other devices supported by the driver are NOT > affected. > Is the firmware binary just data? (Like an image?) What is the aim of this particular question? Under GR 2004-003, all contents of main must be free according to the DFSG, including images and other data; so if you're asking if it's ok to include a non-free binary blob in main that we don't have the right to modify, the answer is no. > Should the package be split so that the package containing the driver for > the unaffected devices can go into main? Yes, a package split sounds like it's needed. Note that this means splitting the source package, since you can't build binaries for both main and non-free from the same source. The driver itself sounds like it's perfectly suitable for main, only the optional firmware would need to be in non-free. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Naming of library -dev package
On Sun, Mar 19, 2006 at 11:01:10AM +0200, Fabian Fagerholm wrote: > Paul Wise and I are working on etl, and we've received a bug report > (#354069) about our choice of naming of etl-dev, the only binary package > this source package produces. > etl-dev is a header library -- it only contains C++ header files that > can be used at build time. We are working on two packages which will > build-depend on it. > Is the bug report (#354069) correct? Does policy really say that the > -dev package must be named lib-dev? To me, section 8.4 > seems to say that the name should be -dev. Since the name > of this library is etl, the name would be etl-dev. Can anyone clarify? The name "etl-dev" is fine. Prepending "lib" when there's nothing here named libetl is pointless. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: question about CFLAGS modifiers to ./configure
On Thu, Mar 30, 2006 at 06:23:38PM +0200, Miriam Ruiz wrote: > DebHelper uses by default (in the pre-made templates) "-Wl,-z,defs" in CFLAGS > when running ./configure > CFLAGS="-Wall -g -O2 -Wl,-z,defs" ./configure --host=$(DEB_HOST_GNU_TYPE) ... > I'm packaging a program (with some libraries in it) that won't compile with > them unless you explicitly modify Makefile.am files and add the libraries > (already included in the package but not installed in time of compilation), > which is not done by default. without those options it compiles and install > cleanly without problem with upstream's building system. > Is it important to keep them? Could someone possibly explain to me what they > mean? This is discussed in policy 10.2. If your libraries are failing to link when using -z,defs, that's a bug in those libraries; anything that references symbols from other libraries on the system needs to link against those libraries. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: question about CFLAGS modifiers to ./configure
On Fri, Mar 31, 2006 at 08:41:22AM +0200, Miriam Ruiz wrote: > --- Steve Langasek <[EMAIL PROTECTED]> escribió: > > This is discussed in policy 10.2. If your libraries are failing to link > > when using -z,defs, that's a bug in those libraries; anything that > > references symbols from other libraries on the system needs to link against > > those libraries. > Thanks, I have no clue why the linker gives errors then. I'll send the > reference to this conversation to upstream as I'm not sure to be able to fix > that myself properly. It might be helpful to you (and others) if you posted the full error messages here as well, and provided a link to a source package. Odds are good that your upstream won't understand the error message any better than you do. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: question about CFLAGS modifiers to ./configure
On Mon, Apr 03, 2006 at 10:33:21PM +0200, Miriam Ruiz wrote: > Thanks for your help, I have the ideas quite much clearer now. > It seems that libgnashserver depends on libgnashasobjs, and at the same time > libgnashasobjs depends on libgnashserver too, which is something quite wierd. > Is there a nice solution for this? I guess the right thing should be to tell > upstream to unify the libraries into one, is there any other solution I can > handle? Unifying the libs is the only way to do this cleanly, AFAIK. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: W: A binary links against a library it does not use symbols from
On Wed, Apr 19, 2006 at 05:45:38AM +1000, Matthew Palmer wrote: > On Tue, Apr 18, 2006 at 03:18:23PM +0200, Daniel Leidert wrote: > > W: winefish; A binary links against a library it does not use symbols from > > This package contains a binary that links against a library that is > > not in the Depends line. This may also be a bug in the library which > > does not have a shlibs file. > > My problem: How can I determine the library the warning is about? I > > build the package in my environment and in a pbuilder environment. Both > > show the same 'Depends:' line. And there is no FTBFS. So how could I > > determine the library? There are IIRC graphical tools to build a diagram > > with dependencies for a package, right? This could be one way. Do you > > know a better way? > ldd will tell you what libraries a binary links against; No, ldd will tell you what libraries are loaded into memory when running the binary. You want objdump -p | grep NEEDED instead. But it was established a few weeks ago that linda's check used ldd by mistake, and I haven't heard that it's been fixed yet. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Linda warnings about manpages in my packages
On Thu, Apr 20, 2006 at 09:30:52PM +0200, Raphael Hertzog wrote: > On Thu, 20 Apr 2006, Marco Bertorello wrote: > > denyhosts-python2.3 > > denyhosts-python2.4 > > denyhosts-common > > the binaries are stored in packages -python2.X but the manpage (common > > to alla packages) is stored in denyhosts-common. > Why would you have a binary in -python2.3 *and* in -python2.4 ? > And why can't you simply provide a single package an you make the choice > to use either python2.3 or python2.4 ? > I don't see the gain of having two versions of the same application just > to work with two different python version... (it's different for Python > modules because the user must be able to use the modules with the Python > version of its choice) denyhosts-python2.3/2.4 do contain a python module. If and when the Great Python Reorganization finally happens, this ought to be a single denyhosts package depending on python (>> 2.3), python (<< 2.5). In the meantime, the current packages have an RC bug, #361085, about the fact that denyhosts-comon *does* include a binary that tries to support both versions of python, but without appropriate dependencies to ensure a consistent python configuration. > If your application works with python2.3 (default python version for the > moment), then you use that and you're done. Once python2.4 is the default, > you update your package to work with python 2.4 and you're done. Since the package installs public modules, it seems to me that putting the modules and the app in a single package is the wrong solution. However, trying to make the application package auto-switch between two different versions of python is also the wrong solution. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Linda warnings about manpages in my packages
On Thu, Apr 20, 2006 at 10:34:04PM +0200, Raphael Hertzog wrote: > On Thu, 20 Apr 2006, Steve Langasek wrote: > > denyhosts-python2.3/2.4 do contain a python module. If and when the Great > > Python Reorganization finally happens, this ought to be a single denyhosts > > package depending on python (>> 2.3), python (<< 2.5). > This can already be done with python-support (provided that the code > isn't specific to a python version). Ah, in that case this would be my recommendation here... > > Since the package installs public modules, it seems to me that putting the > > modules and the app in a single package is the wrong solution. > We have plenty of modules which are packaged only for the current version > of python in Debian and it's not "wrong". This wouldn't be worse. The part I object to is including an app and a public module in a single package -- particularly one that happens to come with an init script as this one does. If it's a public module, it should be its own package. If it's not supposed to be a public module, it shouldn't be in a public directory, and then there's no reason to provide more packages than just the application package. > And the maintainer really needs to think if the modules are meant to be > public or not ... because I see no documentation of the modules, so I > wonder why we need to provide them for two python versions. Yes, agreed. > > In the meantime, the current packages have an RC bug, #361085, about the > > fact that denyhosts-comon *does* include a binary that tries to support both > > versions of python, but without appropriate dependencies to ensure a > > consistent python configuration. > Given the info that I've read here, if I were the maintainer I would have > a single package "denyhost" with everything packaged for the default > version. > If I wanted to provide the modules for another python version I would > use python-support. Agreed on both counts. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Linda warnings about manpages in my packages
On Sun, Apr 23, 2006 at 06:33:04PM -0500, Joe Wreschnig wrote: > On Thu, 2006-04-20 at 15:51 -0700, Steve Langasek wrote: > > If it's not supposed to be a public module, it shouldn't be in a public > > directory, and then there's no reason to provide more packages than just the > > application package. > FWIW, this is not the common attitude in the Python community; people > think it's a good idea to store application-specific modules and > extensions in the site directory, even if there's no API/ABI stability. > For example, I've had several requests for Quod Libet to install its > entire private module hierarchy there. You'll find that several programs > in Debian, such as gnome-menus, do this already. > Personally I think that's very stupid, and leads to 1) a false sense of > security about the stability of such APIs, and 2) a lax attitude towards > API compatibility in general in Python (since so many "public modules" > break all the time). Yes; putting libraries in public directories that aren't going to support a stable API/API for the lifetime of a release (be it Debian or python) is simply namespace pollution. It's unfortunate that every language community has to grow into an understanding of this the hard way. > If Debian is going to buck the trend here (and I think it should, and > thankfully does for many programs) a lot of packages are buggy. Well, I think "a lot of packages are buggy" is a pretty accurate assessment whether Debian adopts a blanket policy on this or not... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Problems with leftovers from unregistering alternatives
On Tue, Apr 25, 2006 at 12:15:57PM +, Sune Vuorela wrote: > I have just recieved a bug: #364742 - and piuparts is as always right. > Something fails in removing alternatives again. > /usr/share/icons/default/index.theme pointing into alternatives > # update-alternatives --display x-cursor-theme > x-cursor-theme - status is auto. > link currently points to > /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme > I have unregistered also that link with the alternatives, but trying > manually anyway: > [EMAIL PROTECTED]:/# update-alternatives --remove x-cursor-theme > /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme > [EMAIL PROTECTED]:/# update-alternatives --display x-cursor-theme > x-cursor-theme - status is manual. > link currently points to > /usr/share/icons/ComixCursors-Black-Large-Slim/index.theme > No versions available. > so that changed nothing. what does update-alternatives --list x-cursor-theme list in this case? It really looks to me like a u-a bug, not a bug in the calling maintainer script. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Problems with leftovers from unregistering alternatives
On Wed, Apr 26, 2006 at 05:38:22AM +, Sune Vuorela wrote: > On 2006-04-26, Steve Langasek <[EMAIL PROTECTED]> wrote: > > what does update-alternatives --list x-cursor-theme list in this case? > It shows nothing. > [EMAIL PROTECTED]:/# update-alternatives --list x-cursor-theme > [EMAIL PROTECTED]:/# Ok, if update-alternatives --list shows nothing, and symlinks are left in place on the filesystem, that sounds like a bug in u-a to me. > Except if I need to remove the alternatives links in the exact opposite > order of registering them. No, this shouldn't matter in the least. I've looked at the comixcursors maintainer scripts now, and I don't see any problems there at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFS: xlife - X11R7 changes
On Sun, Apr 30, 2006 at 10:44:16PM +0200, Lionel Elie Mamane wrote: > On Sun, Apr 30, 2006 at 10:21:49PM +0200, Lionel Elie Mamane wrote: > > On Sun, Apr 30, 2006 at 05:22:38PM +0200, Goswin von Brederlow wrote: > > > could someone sponsor xlife 5.0-7 for me please. It is just changes in > > > Build-Depends so it rebuilds against the new X11R7. > > > http://mrvn.homeip.net/xlife/ > > I'm on it. > I take that back: FTBFS: > mv -f Makefile Makefile.bak > imake -DUseInstalled -I/usr/lib/X11/config > Imakefile.c:39: error: Imake.tmpl: No such file or directory > imake: Exit code 1. > Stop. > make: *** [build-stamp] Error 1 This looks like you have the wrong version of xutils-dev. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: RFS: xlife - X11R7 changes
On Mon, May 01, 2006 at 03:04:29PM +0200, Lionel Elie Mamane wrote: > On Sun, Apr 30, 2006 at 08:33:49PM -0700, Russ Allbery wrote: > > Goswin von Brederlow <[EMAIL PROTECTED]> writes: > >> Steve Langasek <[EMAIL PROTECTED]> writes: > >>>> mv -f Makefile Makefile.bak > >>>> imake -DUseInstalled -I/usr/lib/X11/config > >>>> Imakefile.c:39: error: Imake.tmpl: No such file or directory > >>>> imake: Exit code 1. > >>>> Stop. > >>>> make: *** [build-stamp] Error 1 > >>> This looks like you have the wrong version of xutils-dev. > >> Is that a screwup of his systems or a missing versioned > >> Build-Depends on xutils-dev on my part? > > I'd say that the build-depends are fine and he just needs to upgrade > > to the current xutils-dev. The bad one never got out of unstable, > > I'm fairly sure. > I did an upgrade just before building the package, so I guess it is my > arch (sparc) lagging behind? Let's check... No, I have xutils-dev > 1:1.0.2-3, which packages.debian.org tells me is the latest for all > archs. > So the problem lies somewhere else. Do you have /usr/lib/X11/config/Imake.tmpl on this system? It actually looks like xutils-dev is missing a pre-depends on x11-common (>= 1:7.0.0). Did Imake.tmpl end up orphaned in /usr/X11R6/lib/X11/config instead? If so, just move that directory to /usr/lib/X11/config by hand to fix it up. (Well, unless you also have xviewg-dev installed, then you'll have to sort through by hand...) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [Debian-haskell] RFS: haskell-http
On Mon, May 01, 2006 at 10:50:02AM -0500, John Goerzen wrote: > On Thu, Apr 27, 2006 at 08:39:19PM +0200, Arjan Oosting wrote: > > > But when ghc6 6.4.2 hits unstable, all libghc6-* packages must be > > > rebuilt anyway. > > > That's also why you need to tighten up the existing ghc6 deps. See > > > http://urchin.earth.li/%7Eian/haskell-policy/haskell-policy.html/ch-libraries.html#s-library_impl_deps > > > for details. > > I know, but the Depends are strict enough. And when a new version of ghc6 > > hits unstable haske-http can be bin-NMU-ed. The package is setup that that > > should work. So no need for a new upload (and begging for sponsorship) > > then. > The problem is, with it as-is, you could get unpredictable results. One > platform might have a package that works only with GHC 6.4.1, while the > next has one that works only with 6.4.2, due to building it at different > times. I'm not really comfortable uploading it in this state. Are there auto-generated binary dependencies that reflect this, though? If so, I don't see any reason to worry about the prospect that a package *may* get built against the wrong ghc; if the package is binNMU-safe in the first place, then all it takes to fix this is a binNMU... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Non-english license and documents
On Mon, May 22, 2006 at 10:10:47PM +0200, Adam Borowski wrote: > On Mon, May 22, 2006 at 10:32:18PM +0800, Ying-Chun Liu wrote: > > Second, the javadoc documents coming with the source files are Japanese. > > Should I prune the documents or include them? How do I include them? > Please, keep them. Removing documentation is a disservice to the > users, even if only a part of them can read it. Only if an adequate > English version was available [1], pruning the Japanese docs would be > an option IMO (and only because ~99.9% of Japanese people have good > command of English). Wow, so the Japanese Debian developers we have that are reticent to communicate with the project in the English language are in the bottom .1% of the population? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: How can a non-DD fix broken packages?
On Tue, May 30, 2006 at 02:37:56PM -0400, Joe Smith wrote: > "Michael Tautschnig" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > That is a Serious bug, and is a FTBFS, so AIUI, it is RC. So it can be > filex in a NMU. However, According the the Developer's reference, only DD's > can NMU. If that is true, then sponsored NMU are not allowed. However, > tradition holds against this, as there have be numerous cases of sponsored > NMU's. There are no technical measures in place which *prohibit* developers from sponsoring NMUs. Nevertheless, the concept of a sponsored NMU is a broken one, because responsibility for the NMU lies with the uploader, not with the sponsoree. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: How can a non-DD fix broken packages?
On Tue, May 30, 2006 at 02:04:00PM -0700, Don Armstrong wrote: > On Tue, 30 May 2006, Bart Martens wrote: > > On Tue, May 30, 2006 at 12:03:19PM -0700, Steve Langasek wrote: > > > There are no technical measures in place which *prohibit* > > > developers from sponsoring NMUs. Nevertheless, the concept of a > > > sponsored NMU is a broken one, because responsibility for the NMU > > > lies with the uploader, not with the sponsoree. > > Does that mean that your opinion is that sponsored NMU's should be > > forbidden? I would regret that. It's not bad that someone in the NM > > queue also does NMU's to help fixing other packages. And I don't see > > a problem with responsability if the sponsor is aware of that > > responsability. > A sponsored NMU basically means taking the patch for the NMU just like > you would from a RC bug that had a patch, testing it just like you > would normally, and making the upload just as you would for any other > NMU. > Since you're responsible for the NMU anyway, there's really no > sponsoring going on; you're just using a pre-existing patch as the > basis of your NMU. The difference being that most of the time when someone "sponsors" an NMU, they're effectively shirking their own duty to follow up on the package and ensure that the NMU hasn't introduced any regressions. Often, they're shirking their duty to even check the correctness of the provided patch themselves. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: On the trail of Linux "DLL Hell"...
On Tue, Jun 06, 2006 at 11:17:58AM -0700, Redefined Horizons wrote: > Some of the mentors gave me a hand on a previous post where I asked > about packages with conflicting dependencies. I am now trying to track > down the problem, so I can solve it for myself and other Debian users. > (Its not a popular package, but there might be someone else pulling > there hair out over it...) > I think I've got a good handle on the concepts, but I'm still having > some trouble. I was hoping to provide some more specific details in an > effort to get a little more help. (I did download the Debian Policy > Manual, and I will give it a thorough reading through.) > I believe the package with the problem is "libsvn-javahl", which > provides a Java wrapper to SVN. When I select this package for > installation it tells me the following packages will be removed: > g++ > g++-3.3 > glade-gnome-2 > gnome-common > libc6-dev > libstdc++5-3.3-dev > libstlport4.6-dev > libtool > locales > openoffice.org-dev The issue is that you are trying to install an etch package onto a sarge system. We promise that this should always be possible (it's a release-critical bug if not), but there is *no* guarantee that doing so won't force the removal of other packages. If you want to keep these packages around while installing libsvn-javahl as well, I recommend one of two things: - do a dist-upgrade to etch first, then install libsvn-javahl - try to install libsvn-javahl on the same command line as the other packages listed above, forcing apt (aptitude or apt-get) to find a solution that lets you keep them all. This is definitely off-topic for -mentors, though; if you need further help, please see debian-user. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: ldconfig
On Fri, Jun 09, 2006 at 09:03:22PM +0200, Goswin von Brederlow wrote: > Bas Wijnen <[EMAIL PROTECTED]> writes: > > On Fri, Jun 09, 2006 at 06:13:49PM +0200, Goswin von Brederlow wrote: > >> The reason why the link should be included is so that the library can > >> already be used between unpacking and configuring (running ldconfig) the > >> package. > > And because if ldconfig creates the link, it isn't owned by the package and > > can't be removed when the package is removed. That would clutter the > > system, > > making piuparts angry. (Actually, it might miss it. But it's the kind of > > stuff it checks for. :-) ) > The ldconfig call in postrm removes the link, or the next install of a > library package. Or not? I don't think it does; at least, I've had bugs in packages before that didn't ship the ldconfig symlinks because of this problem. ldconfig only knows to create symlinks, it can't really know which dangling symlinks are its responsibility to remove. FWIW, questions of this level seem more appropriate for -devel than for -mentors; the -mentors subscribership doesn't tend to have the depth of experience to know about all the corner cases that might be relevant to something like this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Package does not build on ia64 and sparc
On Wed, Jun 14, 2006 at 09:01:30PM +0200, Benjamin Mesing wrote: > my package does not build on ia64 due to what seems to be dependency > problems: > /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install > debhelper libapt-front-dev libqt4-dev qt4-dev-tools docbook-to-man pkg-config > libmysqlclient15-dev > Reading Package Lists... > Building Dependency Tree... > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > libapt-front-dev: Depends: libtagcoll-dev (< 1.6) but 1.6.3-1 is to > be installed > E: Broken packages > apt-get failed. > Package installation failed > Full build log here: > http://buildd.debian.org/fetch.php?&pkg=packagesearch&ver=2.1&arch=ia64&stamp=1149912912&file=log&as=raw > Whom should I contact about this? The maintainer of > libtagcoll/libapt-front-dev or the porter team, since it works fine on > every other architecture. It works fine on every other architecture because the current version of libapt-front-dev is *built* on every other architecture. On ia64 it is not, it fails to build. So you should talk to the libapt-front maintainer, who should talk to the porters as needed. > It also does not build on sparc, where I was unable to determine the > reason from the build log: > http://buildd.debian.org/fetch.php?&pkg=packagesearch&ver=2.1&arch=sparc&stamp=1149339169&file=log&as=raw A wedged buildd config: apt was probably put on hold because the new version was SIGBUSing on sparc, and packagesearch naturally needs the current version of apt for building, so someone will need to un-hold apt on mrpurply. I'll talk to the admins. On Wed, Jun 14, 2006 at 03:45:08PM -0500, Carlo Segre wrote: > >It also does not build on sparc, where I was unable to determine the > >reason from the build log: > >http://buildd.debian.org/fetch.php?&pkg=packagesearch&ver=2.1&arch=sparc&stamp=1149339169&file=log&as=raw > Sparc is not keeping up. Sparc is keeping up quite well, it's just not currently considered a release candidate for reasons other than buildd power alone. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to correctly patch without cdbs?
On Mon, Jun 19, 2006 at 07:19:44PM -0400, Joe Smith wrote: > >That's pretty much it to activate dpatch support. You have to generate > >the individual patches (with any means confortable to you) and convert > >them into dpatch format. > Dpatch really needs better instuctions. No, you just need to not use dpatch and use quilt instead. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder on sarge
On Sun, Jul 09, 2006 at 12:31:34PM -0700, Tyler MacDonald wrote: > Michael Stevens <[EMAIL PROTECTED]> wrote: > > How do I setup pbuilder to manage this? when I try to just do > > 'pbuilder create', it gives the error: > > E: Couldn't download slang1a-utf8 > > pbuilder: debootstrap failed > > I've got it working using '--distribution sarge', which is nice for > > checking the builds-from-source part, but still no help getting things > > working with sid. Or do I need to actually install a machine with sid? > I have found that it is easier to have machines running each distro > you want to build against, but it shouldn't be neccessary. Try a > "--distribution etch" though; something that builds under etch should still > run under sid. The debootstrap package from sarge isn't capable of bootstrapping a current sid *or* etch environment due to changes to lib names made after the sarge release. This should be fixed so that the etch debootstrap will be capable of installing an etch+1 chroot regardless of lib changes, but for now you need to install the etch debootstrap on your sarge machine to be able to correctly bootstrap an etch or sid chroot. And no, you should *not* build against an etch chroot if the intent is to upload to unstable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shc -- #335278 broken packaging -- non-DD NMU prepared
On Fri, Jul 14, 2006 at 08:22:25AM +1200, Nigel Jones wrote: > >From memory, aren't NMU's (even more so, non-DD NMU's) only meant to > fix RC bugs? Not new upstream releases? > On 7/14/06, George Danchev <[EMAIL PROTECTED]> wrote: > >Yet another attempt to find a sponsor for the shc package. Fixes several > >RC-bugs as described by Frank Lichtenheld in #335278 buglog. Changes read: > > shc (3.8.6-1) unstable; urgency=low ^^^ This is the wrong version number for an NMU anyway. > > * add myself to uploaders ^^^ And this is totally inappropriate in an NMU. NMUs should always be limited to fixing bugs -- not making decisions that are exclusively the maintainer's to make, like accepting comaintainers... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shc -- #335278 broken packaging -- non-DD NMU prepared
On Fri, Jul 14, 2006 at 09:34:20AM +0300, George Danchev wrote: > Agreed. Fixed. There is no any chance for a comaintenance either, since the > maintainer has been MIA for almost 1 year now and these RC-bugs are left > unaddressed. Also seems he will not file a RFH, FRA, or O or ask for > comaintenance in a reasonable timeframe. What if I want to hijack the package > in favour of a better maintenance ? In that case, please consult the QA team for advice (and for formal MIA tracking). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Replace a package
On Mon, Aug 28, 2006 at 01:56:10PM +0200, Fabio Tranchitella wrote: > Il giorno lun, 28/08/2006 alle 13.23 +0200, Turbo Fredriksson ha > scritto: > > sasl2-bin depends on libldap2 (>= 2.1.17-1) > It doesn't work because the sasl2-bin dependency on libldap2 is > versioned. Relationships with virtual packages can't be versioned, so > your libldap2.2 doesn't satisfy the dependency. Besides which, having a libldap package from OpenLDAP 2.2 claim to provide libldap2 is broken in the extreme. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binNMU safe and ${binary:Version} or ${source:Version}
On Tue, Sep 12, 2006 at 03:56:01PM +0200, Daniel Leidert wrote:
> I currently try to understand, what I need to do to make my packages
> binNMU-safe (I package several libraries). For a package I want to put
> into Debian soon, I'm now trying to make it binNMU-safe. But what's
> behind this? I tried to find documentation that explains the phrase (I
> understand, wthat an binNMU is, but not, what binNMU exactly means for a
> package). But I didn't find anything. I e.g. saw the bug-report against
> xchat. But I don't understand, when I should use ${binary:Version}
> (gnome-vfs2) or ${source:Version} (suggested in the bug-report). So
> where can I find documentation about this?
In a binNMU, the arch: any packages are rebuilt, the arch: all packages are
not.
So if you want to declare a strict versioned dependency between two arch:
any packages in the same source, you would use ${binary:Version}.
If you want to declare a strict versioned dependency from an arch: any
package to an arch: all package in the same source, you would use
${source:Version}.
If you want to declare a strict versioned dependency from an arch: all
package to an arch: any package... don't do that, because it will break
under binNMUs. :)
The documentation for this probably belongs in debian-policy; current
versions of policy seem to mention Source-Version, though, not the new
substvars, and I'm not sure if anyone has submitted a patch for this?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binNMU safe and ${binary:Version} or ${source:Version}
On Thu, Sep 14, 2006 at 12:55:47PM +0200, Goswin von Brederlow wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > If you want to declare a strict versioned dependency from an arch: all > > package to an arch: any package... don't do that, because it will break > > under binNMUs. :) > I only know of one simple way to handle this: > arch:any provides any-package-1.2-3 > arch:all depends any-package-1.2-3 > Some people try to use > arch:all depends any-package (>= version), any-package (<< next-version) > The BIG problem is how to get the next-version. Say you have version > 1.2-3. A binNMU would be 1.2-3+b1, a security release would be > 1.2-3etch1 (unless there was a binNMU). In the Great Scheme, these were supposed to become 1.2-3+etch1 instead of 1.2-3etch1 so that security NMUs would sort higher than binNMUs... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binNMU safe and ${binary:Version} or ${source:Version}
On Fri, Sep 15, 2006 at 09:47:34AM -0300, Henrique de Moraes Holschuh wrote: > On Thu, 14 Sep 2006, Steve Langasek wrote: > > > The BIG problem is how to get the next-version. Say you have version > > > 1.2-3. A binNMU would be 1.2-3+b1, a security release would be > > > 1.2-3etch1 (unless there was a binNMU). > > In the Great Scheme, these were supposed to become 1.2-3+etch1 instead of > > 1.2-3etch1 so that security NMUs would sort higher than binNMUs... > And they didn't because? There simply has been no pressing need for it. Once etch is released, there will be a large number of released packages that have been binNMUed, so the security NMU naming scheme will need to adapt at that point. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depending on an essential package
On Mon, Sep 18, 2006 at 01:29:27PM +0200, Michael Biebl wrote: > if I add a dependency on util-linux because I need that /sbin/getty is > installed, why must this dependency be versioned? > If I simply add Depends: util-linux lintian complains loudly and issues > an error message: > depends-on-essential-package-without-using-version depends: util-linux > I could of course pick a random version number to make lintian happy, I > simply don't know which explicit version I should choose otherwise. As > said, the only requirement I have is that /sbin/getty is installed. > Should I simply ignore the lintian error? The error is, if you don't *need* a specific version of the package, you shouldn't depend on it at /all/. Essential means it's always available, so there's no reason for you to depend on it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
