Re: ITP vexim
On Fri, Jan 27, 2006 at 10:09:56PM +0100, Daniel Knabl wrote: > Am Fri, 27 Jan 2006 13:24:49 -0500 schrieb Justin Pryzby > <[EMAIL PROTECTED]>: > > > Could you please build your package as nonnative, and preferrably > > pristine? Otherwise I don't know where to start looking at your work. > > > > nonnative means that an .orig.tar.gz of the expected name exists in > > the parent directory, and pristine means that the tarball is identical > > to upstreams (not just the contents). > > Sorry, my mistake. I had to remove CVS dirs from the tarball. Now this > should be correct. Thats not a sufficient reason to repack the tarball; it is more important that it is pristine (if applicable). Perhaps the clean target can remove them, and then you don't have to look at them nearly as much (instead, the "dpkg: foo was removed" warnings, though). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP vexim
On Fri, Jan 27, 2006 at 11:58:49PM +0100, Daniel Knabl wrote:
> Am Fri, 27 Jan 2006 16:21:47 -0500 schrieb [EMAIL PROTECTED]:
>
> > Thats not a sufficient reason to repack the tarball; it is more
> > important that it is pristine (if applicable). Perhaps the clean
> > target can remove them, and then you don't have to look at them nearly
> > as much (instead, the "dpkg: foo was removed" warnings, though).
>
> Would you suggest to simply do (in the clean target)
>
> find . -depth -name CVS -exec rm -r {} \;
>
> and not to care about the "blah was removed" messages?
Nearly all Debian packages should be pristine; if you can do that, you
should. If upstream *only* exists in CVS, then you can't really, and
you can run that command before creating your orig tarball. If
upstream has a real tarball, though, then please use it :)
OTOH, lintian will still warn "CVS dir in sourceball", so you might
not even both running such a command, and minimize your warnings..
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What should I do about unresponsive maintainer?
On Fri, Jan 27, 2006 at 10:18:42PM -0500, Matej Cepl wrote: > Hi, > > I know it is not question for this group, but maybe I would love to know > what will happen to me, if I will behave as a maintainer of wvdial, which > let bug# 316575 without response for 210 days :-). This is the realm of the QA group, which deals with MIA maintainers, package removals, and orphaned packages. In the case of a single forgotten bug, it makes sense to just email the maintainer again, unless you specifically check that they appear to be inactive, by checking other bugs on their packages, recent uploads, NMUs, etc. A helpful resource is: http://haydn.debian.org/~thuriaux-guest/qa/mia.html (a 2.3 MB html, be forewarned). In this case, the maintainer seems active (Last upload: 2006-01-22), although I'm a bit surprised by "rutebook 2002-06-20". I'll also note than it is essentially always useful to post a patch to the bug report :) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do if the upstream keeps debian directory in original tarball?
On Sat, Jan 28, 2006 at 07:02:26PM +0100, Thomas Viehmann wrote: > Mark Brown wrote: > > That's not their home page which is what they want: if they were happy > > for people to go elsewhere for their packages they wouldn't be doing > > things like building packages for distributions they don't even have > > installed. > > IME most projects are perfectly content to point to Debian for debs. > They're putting up the debs as a service and they'll happily ease it for > themselves and their users if the packages can be provided in a better > place. If they feel the need to do it themselves, make sure they have all 12 architectures, for each of unstable, testing, stable, and oldstable, and file bugs when packages aren't kept up to date. :) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch vs. quilt [was: Re: RFS: proxycheck -- link]
On Sun, Jan 29, 2006 at 11:39:17AM -0500, Kevin B. McCarty wrote: > Frank K?ster wrote: > > > There are also other alternatives to dpatch; one is Debian-specific and > > i keep forgetting its name, Are you thinking of dbs? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advocate needs
On Mon, Sep 03, 2007 at 06:15:24PM +0400, Alexander Rodin wrote: > Hi all! > I have develop program (http://qstardict.ylsoftware.com) and maintain > Debian package for them. Now I want to put them to Debian. Can anyone to > be my advocate? Hi Alexander, Where are the debian sources? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
review: qstardict (Re: Advocate needs)
On Mon, Sep 03, 2007 at 07:12:18PM +0400, Alexander Rodin wrote: > В Пнд, 03/09/2007 в 10:19 -0400, Justin Pryzby пишет: > > On Mon, Sep 03, 2007 at 06:15:24PM +0400, Alexander Rodin wrote: > > > Hi all! > > > I have develop program (http://qstardict.ylsoftware.com) and maintain > > > Debian package for them. Now I want to put them to Debian. Can anyone to > > > be my advocate? > > Hi Alexander, > > > > Where are the debian sources? > > > Hi, Justin! > There is a Debian sources: > http://qstardict.ylsoftware.com/files/qstardict-0.07-debian-sources.tar.bz2 . > But this have some problem: written by me manpage "qstardict.1" don't > installs... Some comments. You're the upstream author; why don't you include the manpage upstream instead of in the .diff.gz? I realize that manpages for graphical programs are difficult to write well. Does your program accept keystrokes? Does it have any other help file? Is debian/dirs really necessary? It's probably best if this is handled by upstream install scripts, and debian foo used only as a fallback. Your changelog has two "Initial release" entries. The second should (by convention) instead read "New upstream release.". Since you're the upstream author you can include sub-bullets with the major changes for that release. The copyright file should specify under which versions of the GPL the content is licensed and ideally include the full GPL header (but not the full GPL). doc-base isn't for listing manpage; see dh_installman for how to fix that. Section: universe/devel doesn't make sense for Debian. At least the manpage and "rules" files should probably have some of their comments removed. Perhaps not all of them though. The only advantage to not removing comments is to easily be able to diff to new templates... +install: build +binary-arch: build install I really wish the redundant dependancy on "build" was either not specified in the template or that someone would explain to me what purpose it serves. But I already reported it as bug #358722 and apparently knowbody nos. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: In-Program documentation
On Tue, Sep 04, 2007 at 10:37:21PM +0200, Patrick Schoenfeld wrote: > Hi there, > > I'am currently in progress of packaging password-gorilla, which is a > tcl/tk application. Well everything is fine so far, except that the > application contains menu items LICENSE and HELP which rely on files in > the source distribution, which I currently install with dh_installdocs. > So basically I need to make these files available to the tcl/tk scripts. > But how should I do this properly? > > 1) Variant 1: > I could install the files to /usr/share/doc, but not with dh_installdocs > so that they don't get compressed and then link them to the target > directory (/usr/share/password-gorilla). > > 2) Variant 2: > Install them to /usr/share/doc AND to the target directory. > > 3) Variant 3: > Install them only to the target directory. > > It seems to me as if variant 1 would be the only that makes sense. But > is this okay? Is there another way to do it? What would you recommend? It's a little known requirement that packages continue to work after /u/s/doc is removed. So it's not allowed to install required files there. You could do (2) or (3) with links *from* u/s/d though. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: In-Program documentation
On Tue, Sep 04, 2007 at 11:49:33PM +, Jörg Sommer wrote: > Hi Justin, > > Justin Pryzby <[EMAIL PROTECTED]> wrote: > > It's a little known requirement that packages continue to work after > > /u/s/doc is removed. So it's not allowed to install required files > > there. You could do (2) or (3) with links *from* u/s/d though. > > Where's this written? In the policy? All the packaging requirements and well-accepted recommendations are in policy or otherwise should be :) This one is 12.3: |Packages must not require the existence of any files in |`/usr/share/doc/' in order to function [1]. Any files that are |referenced by programs but are also useful as stand alone |documentation should be installed under `/usr/share//' with |symbolic links from `/usr/share/doc/'. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with --purge and reinstalling
On Wed, Sep 05, 2007 at 09:58:32PM +0200, Thibaut Paumard wrote: > Dear mentors, > > I'm maintaining the yorick-* packages. The source package is split into > yorick, yorick-data and yorick-dev. The conffiles are in the -data package. > However, yorick.postrm removes these files upon --purge. I guess I must > have been slightly offset from my head when I did this, but that's the > situation in Etch. conffiles shouldn't ever be modified, created, moved, or removed by any package except dpkg. > I just noticed a problem if a user does: > aptitude install yorick (installs yorick and yorick-data) > aptitude remove yorick (removes yorick and yorick-data) > dpkg --purge yorick (deletes /etc/yorick/*, which actually belongs to > yorick-data) > aptitude install yorick (installs yorick and yorick-data) > > When reinstalling yorick the conffiles are not installed! One needs to > purge y-data for these conffiles to get reinstalled. They're probably in etch's dpkg's "obsolete" state; use dpkg -s on those pacakges. > I can clearly see that there is a bug in my packages in that yorick.postrm > should certainly not remove files owned by yorick-data, but I don't > understand why the files are not reinstalled. That's the (obsolete) thing. Removal of conffiles is supposed to be preserved. > I also wonder how to fix this issue best: I guess /etc/yorick files should > belong in the package "yorick", not "yorick-data", but can I simply switch > the files from one package to the other? No. You have to remove the files in preinst if their md5sum matches the md5sum in dpkg's status database. Actually it's more complicated if you support dpkg rollbacks. You have to rename them in preinst (if they're unmodified), remove them in postinst (in the normal scenario when everything works), but rename them back to their original name in postrm abort-upgrade. All conditional on their existence, version checks, and md5sum checks. [0] Technically that might not be necessary if the files to be moved are identical between etch and lenny. Justin References [0] http://justinpryzby.com/debian/dpkg/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed copyright format
On Thu, Sep 06, 2007 at 01:58:31PM +0200, Manuel Prinz wrote: > Dear mentors, > > there has been some discussion going some time ago on about making the > copyright file machine-interpretable. I really like the idea and read > the proposal [1]. The new format looks clearer to me and I wonder > whether it's reasonable to already use it. > > There don't seem to be any tools using it right now, and it's not > policy. On the other hand, I really don't see any reason not to use it, > knowing that some adjustments have to be made if the format changes. > What are your thoughts on that? Is anyone using the new format already? Seems like a best-practice to me. Using the proposed format too is perhaps the only good way of finding problems or potential improvements. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help with -dbg packages for a library
On Fri, Aug 31, 2007 at 10:57:55AM -0400, Justin Pryzby wrote: > On Thu, Aug 30, 2007 at 09:29:45AM +0530, Kumar Appaiah wrote: > > Dear Debian Mentors, > > > > I have a specific question with regard to -dbg packages for > > libraries. My understanding of generating -dbg libraries is like this: > > > > 1. We build the package with CFLAGS or CXXFLAGS = -g -O2 (for > > optimization). > > > > 2. We call dh_strip while exluding the dbg package, to ensure that > > debugging sumbols are present there. > I think the suggestion is for all libraries to use dh_strip > --dbg-package or -k. BTW this is in bug #420540. > Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: irrlicht
On Thu, Sep 06, 2007 at 10:15:28AM -0700, Brandon wrote: > I'm not sure how to actually handle replacing the files. Is it ok to > put them into the orig.tar.gz? I'm sure the answer is in the policy > manual somewhere. The orig.tar.gz can't have any files introduced relative to upstream. > > * lintian complaining about missing soname > > I noticed that too. Not from lintian, but using executables compiled > against your library require the symlink that is only included in the > development library. I bet the fix is easy, but I don't really know > what it is. I bet it is a gcc option. -Wl,-soname,libfoo.so.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: > Dear mentors, > > I am looking for a sponsor for my package "gwyddion". > > * Package name: gwyddion > Version : 2.8-1 > Upstream Author : David Nečas (Yeti) <[EMAIL PROTECTED]>, Petr Klapetek > <[EMAIL PROTECTED]> > * URL : http://gwyddion.net/ > * License : GPL-v2+, and parts PD > Section : science > > It builds these binary packages: > gwyddion- Scanning Probe Microscopy (SPM) analysis software Neat :) > (Long) Annotations (=Request for Help/Comment/Explanation): > Furthermore there are lintian warnings, which I did not quieten. They are > about the libgwyddion2 package which contains several libraries and thus > doesn't match the SONAMES of them. What is current practice? Allow the > warning? Override it? Split the package (This seems useless to me)? Policy has this to say: |If you have several shared libraries built from the same source tree |you may lump them all together into a single shared library package, |provided that you change all of their sonames at once (so that you |don't get filename clashes if you try to install different versions of |the combined shared libraries package). The goal is that debs compiled/depending against any libgwyddion* libraries are always installable (well, the other goal is that there are only 2 versions of a library in the active archive at once). So you have to avoid the situation where libgwyddion2 includes: libxyza.so.1 and libxyzb.so.1, and the as-of-yet hypothetical libgwyddion3 includes libxyza.so.1 and libxyzb.so.2 (thus the new package name). In this case lib3 is required to Conflict on lib2 (or the other way around) since they're not actually co-installable. But then every package compiled against lib2 will end up effectively conflicting with every package compiled against lib3 since it's impossible to satisfy the packages of any 2 such packages. So I think the libraries should only be in the same package if they have the same soname. (Or, you can put them into a subdirectory of /usr/lib/ if they're not linked against directly and it's no problem). > And finally there is a duplicate depends of gwyddion on libgwyddion2, one > added by the debhelper scripts and one by me - should I override this, or > take away my hand-written dependency? I think you should drop the manually-added one since the automatic one will always be working with ELF dependency output. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Fri, Sep 07, 2007 at 05:20:56PM +0200, Jan Beyer wrote: > Many thanks for the quick response! > > On 09/07/2007 01:55 PM, Justin Pryzby wrote : > > On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: > >> Furthermore there are lintian warnings, which I did not quieten. They are > >> about the libgwyddion2 package which contains several libraries and thus > >> doesn't match the SONAMES of them. What is current practice? Allow the > > > So I think the libraries should only be in the same package if they > > have the same soname. (Or, you can put them into a subdirectory of > > /usr/lib/ if they're not linked against directly and it's no problem). > The point is, at least as upstream explained to me, that these libraries are > not particularly well split with regard to their contents. So no one will > link against just one or some of them. In fact, one often needs some modules > (which are in the gwyddion package) to build something reasonable. That's > why I/we (we=upstream+me) decided to put them together. > Concerning putting them into subdirectories: This would mean creating a > subdirectory for each library and putting it in there? Could I then keep > them all in one package? The directory would be named after the package. /usr/lib/libgwyddion2/* and either the public libraries or final binaries would need rpath to find them. (It still seems a grey area whether to add a soname and install the lib to /usr/lib or to use rpath for some things). > >> And finally there is a duplicate depends of gwyddion on libgwyddion2, one > >> added by the debhelper scripts and one by me - should I override this, or > >> take away my hand-written dependency? > > I think you should drop the manually-added one since the automatic one > > will always be working with ELF dependency output. > Should I force a versioned automatic dependency via dh_makeshlibs -V or > dh_makeshlibs -V 'libgwyddion2 (>=2.8)'? I think you have to bump the shlibs version whenever upstream adds a symbol. Unless you can show (by reading the diff) that a new upstream *doesn't* do this (or make incompatible changes), it's prolly safe to increment this at every new upstream. Otherwise an object compiled against a recent libgwyddion2 with new symbol would end up in a package with Depends: libgwyddion2 (>=X) where version X doesn't actually provide the symbol, and an app will crash whenever the symbol lookup is attempted. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian .packlist warning and debian/rules modification
On Sun, Sep 09, 2007 at 07:40:28PM +0200, Jeremiah Foster wrote: > I ran debuilder with lintian and received this output (amongst other > messages) > > E: libhtml-treebuilder-xpath-perl: package-installs-packlist > usr/lib/perl5/auto/HTML/TreeBuilder/XPath/.packlist > N: > N: Packages built using the perl MakeMaker package will have a file named > N: .packlist in them. Those files are useless, and (in some cases) have > N: the additional problem of creating an architecture-specific directory > N: name in an architecture-independent package. > N: > N: They can be suppressed by adding the following to debian/rules: > N: > N: find debian/tmp -type f -name .packlist | xargs rm -f > N: > N: -find debian/tmp/usr/lib/perl5 -type d -empty | xargs rmdir -p > N: > N: Or by telling MakeMaker to use vendor install dirs; consult a recent > N: version of perl policy. Perl 5.6.0-12 or higher supports this. > Below is an example of the output I would receive: > > > > find debian/tmp -type f -name .packlist | xargs -r rm -f > find: debian/tmp: No such file or directory > find debian/tmp -type d -empty | xargs -r rmdir -p > find: debian/tmp: No such file or directory > > > > What I did to finally get rid of this error was to change the command to > this: > > # remove .packlist files inserted by MakeMaker > find . -type f -name .packlist | xargs -r rm -f > I changed the directories find looks in because of the error message from > find saying: "No such file or directory" even though the .packlist file > existed. (I think that the directory debian/tmp was not being created.) Hi, The debhelper tools (dh_install) used to use debian/tmp but now (depending on DH_COMPAT) use debian/$package. So this is a small-ish lintian bug. You should probably do find ./debian/ instead of find . to avoid removing files from ./ except from ./debian/.. since a strict reading of policy requires that after the "clean" rule is run you have to end up in the same state as immediately after dpkg -x $dsc. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ario
On Mon, Sep 10, 2007 at 10:27:08AM +0900, Michal Čihař wrote: > Hi > > On Sun, 9 Sep 2007 23:35:40 +0200 > "Marc Pavot" <[EMAIL PROTECTED]> wrote: > > > I am looking for a sponsor for my package "ario". > [...] > > I would be glad if someone uploaded this package for me. > > Please fix following issues: > - there is no point of including empty README and NEWS as documentation But actually debhelper makes an exception and doesn't include empty docs in the binary package. I forget who/when/where this was pointed out to me, but the maintainer wanted their source package to DWTW even if upstream filled in the originally-empty docs files. Also you specify -pario to all the debhelper calls, but they all act by default on the first binary package anyway. Justin
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Sat, Sep 08, 2007 at 08:24:19PM +0200, Jan Beyer wrote: > Justin Pryzby schrieb am 07.09.2007 17:46 Uhr: > > On Fri, Sep 07, 2007 at 05:20:56PM +0200, Jan Beyer wrote: > >> On 09/07/2007 01:55 PM, Justin Pryzby wrote : > >>> On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: > >>>> And finally there is a duplicate depends of gwyddion on libgwyddion2, one > >>>> added by the debhelper scripts and one by me - should I override this, or > >>>> take away my hand-written dependency? > >>> I think you should drop the manually-added one since the automatic one > >>> will always be working with ELF dependency output. > >> Should I force a versioned automatic dependency via dh_makeshlibs -V or > >> dh_makeshlibs -V 'libgwyddion2 (>=2.8)'? > > I think you have to bump the shlibs version whenever upstream adds a > > symbol. Unless you can show (by reading the diff) that a new upstream > > *doesn't* do this (or make incompatible changes), it's prolly safe to > > increment this at every new upstream. > > > > Otherwise an object compiled against a recent libgwyddion2 with new > > symbol would end up in a package with Depends: libgwyddion2 (>=X) > > where version X doesn't actually provide the symbol, and an app will > > crash whenever the symbol lookup is attempted. > Then I'll use libxxxy-z (=a.b), which should be inserted by the -V option. -V should be using >=. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
On Tue, Sep 11, 2007 at 08:06:42PM +0200, Patrick Schoenfeld wrote: > Adeodato Simó schrieb: > > Your init.d script should *not* exit with status non-zero if the daemon > > was already stopped. You can do that either by passing --oknodo to > > start-stop-daemon, or by checking by hand if the return status is 1. > > *Not*, in any case, by appending "|| true", since that would hide the > > case when a real errors occurs and the daemon can't be stopped. > > Hm. If i think about this topic it appears to make sense to let > invoke-rc.d not fail (I actually do it like this), but I'm asking myself > the question why this is not formalized in the policy? > It would be a pro to take this into the policy, wouldn't it? It is 9.3.2: |The `init.d' scripts must ensure that they will behave sensibly if |invoked with `start' when the service is already running, or with |`stop' when it isn't, and that they don't kill unfortunately-named |user processes. The best way to achieve this is usually to use |`start-stop-daemon'. It's a very interesting question whether packages should inhibit starting a daemon that wasn't running when it would otherwise have been stopped. I guess the current state of affairs is that a manually-stopped daemon which is started at postinst time will cause a message to be printed and the admin can stop it again if he wants. I think the ideal situation is that a manually-stopped daemon would cause a message to be printed: "Not starting food: not stopped at preinst time" in the same style of messages that are shown with increasing consistency when things are not enabled in etc/default. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Are soname bumps required when library upgrades break compatibility?
On Tue, Sep 11, 2007 at 06:27:11PM -0700, Brandon wrote: > Thanks for your explanations guys. I get it now. A crash is serious, > whether or not the reason is documented in policy. If the crash is the > fault of the library, the library gets the RC bug. The statement was that a crash due to changes in a dependency is a severity:serious bug in that dependency. A crash is always a bug, but many are just severity:normal for non-core functionality or important for things that don't totally inhibit the package's utility. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor for multipipe
On Sun, Sep 16, 2007 at 04:32:13PM +0200, Christopher Zimmermann wrote: > Hi! > > I just packaged the small multipipe tool from > http://sourceforge.net/projects/multipipe. > > It can send its stdin to several other commands like this: > > cat blub |multipipe 'cat >/dev/null' 'less' 'wc' Neat. You can do something similar using bashisms: echo foo |tee >(sed s/^/x/) >(sed s/^/y/) >(sed s/^/z/) > I find this little tool very handy in many cases. Something like this > should be available in Debian. I have to agree :) > You can download the source package from > ftp://madroach.dyndns.org/multipipe/ Some comments: Your copyright file is incomplete (I think you know this). Ideally, debian/dirs:usr/bin isn't necessary since the upstream makefile should handle this. *some* debian/rules comments should go away. But you should also understand what eg. DH_VERBOSE, docbook-to-man, # dh_*, and the manpage macro comments do and try the relevant things once before getting rid of them. Your configure-stamp target seems to do nothing. You should understand why it was in the template and ultimately get rid of it. BTW tell your upstream that libc6 unistd.h already defines STDIN_FILENO and such, so main.c essentially just duplicates this. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Tue, Sep 18, 2007 at 11:19:04AM +0200, Jan Beyer wrote: > On 09/10/2007 06:40 PM, Justin Pryzby wrote : > >> Then I'll use libxxxy-z (=a.b), which should be inserted by the -V option. > > -V should be using >=. > Are you, Justin, willing to sponsor this package then, or should I retry > with an updated RFS? Sorry, not a DD, so I can't sponsor you. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443063: net-tools: configure-stamp does nothing
Package: net-tools Version: 1.60-17 Tags: patch Debbugs-Cc: debian-mentors@lists.debian.org X-Debbugs-Cc: debian-mentors@lists.debian.org X-Why: multipipe RFS had the same problem (template?) User: [EMAIL PROTECTED] Usertags: debian-specific configure: configure-stamp configure-stamp: dh_testdir touch configure-stamp ./debian/rules configure-stamp creates a file but otherwise does nothing. The utility of the stampfile is to avoid rerunning slow commands, so at best this fails to avoid a slow command. diff -u net-tools-1.60/debian/changelog net-tools-1.60/debian/changelog --- net-tools-1.60/debian/changelog +++ net-tools-1.60/debian/changelog @@ -1,3 +1,10 @@ +net-tools (1.60-17.1) unstable; urgency=low + + * Non-maintainer upload. + * ./debian/rules: Remove useless configure-stamp target. + + -- Justin Pryzby <[EMAIL PROTECTED]> Tue, 18 Sep 2007 07:22:04 -0400 + net-tools (1.60-17) unstable; urgency=medium * arp.c: bus error on sparc64 with latest gcc fixed. (Closes: Bug#340384) diff -u net-tools-1.60/debian/rules net-tools-1.60/debian/rules --- net-tools-1.60/debian/rules +++ net-tools-1.60/debian/rules @@ -8,12 +8,7 @@ # This is the debhelper compatability version to use. export DH_COMPAT=1 -configure: configure-stamp -configure-stamp: - dh_testdir - touch configure-stamp - -build: configure-stamp build-stamp +build: build-stamp build-stamp: dh_testdir cp debian/config.h config.h @@ -24,7 +19,7 @@ clean: dh_testdir dh_testroot - rm -f build-stamp configure-stamp + rm -f build-stamp -$(MAKE) clobber dh_clean diff -u net-tools-1.60/debian/changelog net-tools-1.60/debian/changelog --- net-tools-1.60/debian/changelog +++ net-tools-1.60/debian/changelog @@ -1,3 +1,10 @@ +net-tools (1.60-17.1) unstable; urgency=low + + * Non-maintainer upload. + * ./debian/rules: Remove useless configure-stamp target. + + -- Justin Pryzby <[EMAIL PROTECTED]> Tue, 18 Sep 2007 07:22:04 -0400 + net-tools (1.60-17) unstable; urgency=medium * arp.c: bus error on sparc64 with latest gcc fixed. (Closes: Bug#340384) diff -u net-tools-1.60/debian/rules net-tools-1.60/debian/rules --- net-tools-1.60/debian/rules +++ net-tools-1.60/debian/rules @@ -8,12 +8,7 @@ # This is the debhelper compatability version to use. export DH_COMPAT=1 -configure: configure-stamp -configure-stamp: - dh_testdir - touch configure-stamp - -build: configure-stamp build-stamp +build: build-stamp build-stamp: dh_testdir cp debian/config.h config.h @@ -24,7 +19,7 @@ clean: dh_testdir dh_testroot - rm -f build-stamp configure-stamp + rm -f build-stamp -$(MAKE) clobber dh_clean
Re: Extraeyes needed - Conflicts, Provides, Replaces don't seem to work
On Wed, Sep 19, 2007 at 10:18:24AM +0200, Turbo Fredriksson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Could someone take an ehey on this, I'm not seeing the problem... > > Laptop2/SARGE# apt-get install libglib-dev > Reading Package Lists... Done > Building Dependency Tree... Done > Note, selecting libglib1.2-dev instead of libglib-dev > You might want to run `apt-get -f install' to correct these: > The following packages have unmet dependencies: > util-linux: PreDepends: slang1a-utf8 (> 1.4.9dbs-4) > E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify > a solution). > I guess it's because *versioned* dependencies on virtual packages are never satisfied. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing transition stuff in debhelper scripts after which time?
On Tue, Sep 25, 2007 at 04:46:43AM +0200, Daniel Leidert wrote: > Hi, > > Today I stumbled over the question: After which time should transition > stuff be removed from the debhelper scripts. In this special case I'm > talking about install-sgmlcatalog calls in (e.g.) postinst scripts. Adam > Di Carlo announced the depreciation of install-sgmlcatalogs in 2001. > However, almost all related docbook* packages still contain this stuff. > So I'm wondering, how long one should wait before such obsolete stuff > can be removed? I mean, there is no requirement to support updates from > e.g. Woody to Lenny, right? I checked the Debian Social Contract and the > Policy manuals, but didn't find an information related to this topic. > Maybe I overlooked it? You can drop such things in uploads to unstable after they're included in a stable release. Upgrades across releases are not tested and are officially "not supported" though AFAIK the reasons are largely undocumented. I think it's roughly the same situation as for downgrades: . maintainer scripts may not support things; this is basically so maintainers are allowed to drop support for ancient things and not have unmanagably large and difficult to test, unmaintanble cruft; . Package control file; including in particular the dependency fields: Conflicts, Depends, Provides (?), Pre-Depend plus Replaces. Dependencies on versions earlier than [old]stable are often dropped. It's only unfortunate that control files afaik still don't support comments to document why the versions and things were there with which to being. . The package itself; eg. it might contain logic to upgrade the format of its datafiles but not for every historic version and bugs therein. Justin References [0] http://lists.debian.org/debian-mentors/2007/01/msg00241.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autoconfigurable package: how to build two configurations?
On Sun, Sep 23, 2007 at 06:50:02PM -0500, Steve M. Robbins wrote: > Hello, > > Are there any examples of a package that builds two binary packages, > each from a distinct run of "configure"? > > My specific case is soqt, which provides a Qt interface to Coin > (OpenInventor). There is a sentiment [1] that I provide packages for > Qt3 as well as packages for Qt4. I believe that I need to run > the autoconf-generated configure script twice and build each > configuration in its own build directory. > > I'd like to see a package that does this already. > Preferably, one that uses cdbs. The dev-ref (still) uses vim as an example afaik. A good goal would be to reduce duplication of code within the rules file. Justin References [0] http://lists.debian.org./debian-mentors/2007/05/msg00069.html
Re: Same source package, differents targets
On Mon, Oct 01, 2007 at 04:02:32PM +0200, Leopold Palomo-Avellaneda wrote: > Hi, > > I'm sorry if the question is a bit silly, but I have a conceptual doubt. I > would like to package a soft that with the _same_ source, provides different > packages but, this packages have different build dependencies and > incompatibles. I think you mean that you have multiple binary package, and the build deps for one of them conflict with the build deps of the other. Neat! Can you give specific detail of the package and dependencies? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reason for Failed build on some arch only
On Wed, Oct 03, 2007 at 06:52:43PM +0530, Kartik Mistry wrote: > Hi, > > My package Xosview is failed to build on (atleast) two arch with same > reason. Following are links from buildd. > > mipsel: > http://buildd.debian.org/fetch.cgi?pkg=xosview;ver=1.8.3%2Bdebian-2;arch=mipsel;stamp=1190303855 > > mips: > http://buildd.debian.org/fetch.cgi?pkg=xosview;ver=1.8.3%2Bdebian-2;arch=mips;stamp=1190807389 > > Can anyone please look at guide me to some point? No bug reported, but > it is safer to fix it before that :P I think this documents your options: /usr/share/doc/autotools-dev/README.Debian.gz Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unable to strip using dh_strip
On Tue, Oct 09, 2007 at 10:30:21PM -0700, varun_shrivastava wrote: > > hi >i am trying to build a package using debhelper scripts, but it gives an > error message > > > dh_installdirs -a > dh_install -a > dh_link -a > dh_compress -a > dh_strip -a > dh_fixperms -a > dh_makeshlibs -plibfreetype6 -V'libfreetype6 (>> 6.3.10)' > dh_shlibdeps -a > dh_installdeb -a > /scratchbox/tools/bin/install: `debian/libfreetype6/DEBIAN' exists but is > not a directory > dh_installdeb: command returned error code 256 > make: *** [binary-arch] Error 1 > > I m using scratchbox in order to build package, currently i am not cross > compiling. > > Now when i remove dh_strip -a command from the rules file , the package > builds successfully. > But running lintian shows unstripped binary error message. Can you set DH_DEBUG like at the head of the rulesfile and rerun? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unable to strip using dh_strip
On Wed, Oct 10, 2007 at 05:33:48AM -0700, varun_shrivastava wrote: > Justin Pryzby-43 wrote: > > Can you set DH_DEBUG like at the head of the rulesfile and rerun? > > i added line export DH_DEBUG=1 on top of rules file but o/p is same (no > debug kind of o/p displayed) > > then i uncommented a line which says export DH_VERBOSE=1 > the o/p is as shown Yeah that. > chmod 644 debian/libfreetype6/DEBIAN/shlibs > chown 0:0 debian/libfreetype6/DEBIAN/shlibs > dh_shlibdeps -a > dpkg-shlibdeps -Tdebian/libfreetype6.substvars > debian/libfreetype6/usr/local/lib/libfreetype.so.6.3.10 > dh_installdeb -a > install -o 0 -g 0 -d debian/libfreetype6-dev/DEBIAN > install -o 0 -g 0 -d debian/libfreetype6/DEBIAN > /scratchbox/tools/bin/install: `debian/libfreetype6/DEBIAN' exists but is > not a directory > dh_installdeb: command returned error code 256 > make: *** [binary-arch] Error 1 Well 2 things come to mind. Is scratchbox "install" compatibile with debhelper? Also ls -la debian/libfreetype6/DEBIAN Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
On Thu, Oct 11, 2007 at 12:51:26PM +0200, Daniel Leidert wrote: > Am Donnerstag, den 11.10.2007, 10:52 +0900 schrieb Charles Plessy: > about non-existing directories, like usr/share/dialign-t. You only need > to create the diretories first, if you e.g. use `install' instead of > dh_install or of you want to create links there. I guess this is handled too by install -D. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
On Thu, Oct 11, 2007 at 10:52:03AM +0900, Charles Plessy wrote: > Dear mentors, > > in a package I prepare, there is the following line in a source/Makefile: > > CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx CPPFLAGS is for the C PreProcessor. So it's supposed to have things like -Iinclude -DFOO=BAR. CFLAGS is for the C compiler itself, so it's supposed to have things like -O3 -funroll-loops -std=gnu99 -Wall -Wextra. But it only matters if you're using the implicit rules and the binaries are built from multiple source files or are otherwise compiled and linked in separate invocations. BTW there's LDFLAGS too for linker options like -Wl,-soname,libfoo.so.1 -Wl,-O2 (here it's assumed that LD=gcc thus the -Wl, thing). I think that Debian packages shouldn't have subarch-specific options on any arch, since the same binaries may/(have to be able to) be run on variation on that arch. In the case of i386, the binaries have to be able to run on a real 386 [0]. I think all the arch options here will (maybe) cause the binary to fail on such a machine. Justin [0] My understanding is that the packaged kernels don't support 386 but with a software emulation of some math instruction patched in, 386 is advertised as being supported with binary packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary-or-shlib-defines-rpath error message
On Thu, Oct 11, 2007 at 06:17:06AM -0700, varun_shrivastava wrote: > > hi > i am a newbee in packaging and trying out how to package some already > available source packages > > i am trying to pack jpeg62_6b, the package builds successfully but running Is this the same package that caused dh_strip errors? > lintian shows > "binary-or-shlib-defines-rpath ./usr/bin/cjpeg /usr/lib" > the message is same for all binaries in /usr/bin You shouldn't set rpath to /usr/lib since it's in the default search path. > can some one please explain the reason for this message? Debian considereds rpath to be inflexible. > Also while building the same package a warning message is being displayed by > dh_shlibdeps > here is the message:: > dpkg-shlibdeps -Tdebian/libjpeg62-utils.substvars > debian/libjpeg62-utils/usr/bin/cjpeg debian/libjpeg62-utils/usr/bin/djpeg > debian/libjpeg62-utils/usr/bin/rdjpgcom > debian/libjpeg62-utils/usr/bin/wrjpgcom > debian/libjpeg62-utils/usr/bin/jpegtran > dpkg-shlibdeps: warning: could not find path for libjpeg.so.62 You have to supply a ./debian/shlibs file in any package that includes public shared libraries (/usr/lib/*.so.*). It gets installed to /usr/lib/dpkg/info/ and searched by dh_shlibdeps when building packages to find on what package,version to add a dependency for a given objdump -p |grep -we NEEDED line. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary-or-shlib-defines-rpath error message
On Thu, Oct 11, 2007 at 10:35:30PM -0700, varun_shrivastava wrote: > Justin Pryzby-43 wrote: > > You shouldn't set rpath to /usr/lib since it's in the default search > > path. > > > I haven't set the path any where in the rules file. but i am trying to What I meant was "one should not set rpath to /usr/lib" or "rpath should not be set to /usr/lib". Is there some arguments to ./configure you can pass to inhibit setting rpath? Otherwise you'll have to munge the upstream build system to get rid of it. > Justin Pryzby-43 wrote: > > > > You have to supply a ./debian/shlibs file in any package that includes > > public shared libraries (/usr/lib/*.so.*). It gets installed to > > /usr/lib/dpkg/info/ and searched by dh_shlibdeps when building > > packages to find on what package,version to add a dependency for a > > given objdump -p |grep -we NEEDED line. > Do i need to provide .shlibs or shlibs.local file in debian > directory. packagename.shlibs is what gets installed to /v/l/d/i. shlibs.local is an additional thing read by dpkg-shlibdeps for cases when someone elses public library package doesn't include packagename.shlibs. In this case dpkg wouldn't otherwise be able to find the library package to add as a dependency. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How a package will determine the dependencies
On Thu, Nov 01, 2007 at 08:57:19AM -0700, varun_shrivastava wrote: > > hi > i have a library and want to package it > But it has a configuration option as --enable-debug=yes/no > > So i need to make 2 packages as > > 1) libinput0 > 2) libinput0-debug I think the recommended way to do this [0] is to build with debugging symbols then move the debugging symbols to a separate file, and associate the dbg files with the normal runtime files. Justin [0] see the developers' references and at least one bug against such. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-Linux files from source tarballs
On Thu, Nov 01, 2007 at 01:17:26PM -0600, Jordi Gutiérrez Hermoso wrote: > Hello, mentors. > > I'm currently working on Processing (#433270). > > Now, Processing distributes in its source tarball (well, not really a > source tarball at all, since it's necessary to get everything from > svn), some Windows .exes and some MacOSX-specific files too. > > Do these have to be removed from the source package that I make for Debian? I forget if it's policy or devref which prefers *not* removing them unless you're already using a nonpristine sourceball or it would save significant space, (with the justification that people might like to use the debian sources for nondebian things) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How a package will determine the dependencies
On Fri, Nov 02, 2007 at 08:13:22AM -0700, varun_shrivastava wrote: > Justin Pryzby-43 wrote: > > > > Do you mean it adds stuff within a #ifdef to use SDL? Why is it so > > huge? > > > yes it adds code not so huge under #ifdef SDL_ENABLE ... #endif > > Can we provide a virtual package libinput-virtual on which the applications > will depend and the virtual package can be libinput0 or libinput0-debug > depending on what is installed You could have libinput0-debug provides:libinput0. However I still think the best way is to compile with debugging symbols and move the symbols to separate files in /usr/lib/debug and separate -dbg package which is *just* the debugging syms. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How a package will determine the dependencies
On Thu, Nov 01, 2007 at 09:42:33PM -0700, varun_shrivastava wrote:
>
> hi
> actually the library uses g_log kind of debugging technique ie some #defines
> are there, so when log is enabled #defines get replaced by g_log(***), and
> when its disabled #defines get replaced by (void)0
>
> But i have a bigger problem thats the library has one more option of
> --enable-sdl=yes/no , I checked the source code and enabling it adds a huge
> amount of code to standard library.
Do you mean it adds stuff within a #ifdef to use SDL? Why is it so
huge?
Or do you mean it compiles a static copy of SDL? Don't do this; use a
{build,}dep on the shared library package instead.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-Linux files from source tarballs
On Thu, Nov 01, 2007 at 04:27:14PM -0600, Jordi Gutiérrez Hermoso wrote: > On 01/11/2007, Justin Pryzby <[EMAIL PROTECTED]> wrote: > > On Thu, Nov 01, 2007 at 01:17:26PM -0600, Jordi Gutiérrez Hermoso wrote: > > > Hello, mentors. > > > > > > I'm currently working on Processing (#433270). > > > > > > Now, Processing distributes in its source tarball (well, not really a > > > source tarball at all, since it's necessary to get everything from > > > svn), some Windows .exes and some MacOSX-specific files too. > > > > > > Do these have to be removed from the source package that I make for > > > Debian? > > > > I forget if it's policy or devref which prefers *not* removing them > > unless you're already using a nonpristine sourceball or it would save > > significant space, > > It would save 20 megs from the source package. Is that considerable > enough for their removal? That part isn't in policy :) Is that 20mb before or after compression? Since it's a source package, there's only one copy (per suite, perhaps with a couple extra copies for a couple days at a time [?], but not per architecture). If you do repackage, make sure to provide an get-orig-source target to retrieve (?), unpack, modify, and repack that (and the top level dir should have ".orig" appended). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How a package will determine the dependencies
On Mon, Nov 05, 2007 at 06:39:01AM -0800, varun_shrivastava wrote: > Justin Pryzby-43 wrote: > > > > On Fri, Nov 02, 2007 at 08:13:22AM -0700, varun_shrivastava wrote: > > You could have libinput0-debug provides:libinput0. > > > > However I still think the best way is to compile with debugging > > symbols and move the symbols to separate files in /usr/lib/debug and > > separate -dbg package which is *just* the debugging syms. > > thanks for reply > > do i have to make changes in Makefile or some thing else > please can you provide me some links or documents on how to separate debug > symbols from main library I already referenced the source: http://lists.debian.org/debian-mentors/2007/11/msg00012.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 03:59:44PM +0100, Bas Wijnen wrote: > On Thu, Nov 08, 2007 at 08:22:06PM +0530, Kumar Appaiah wrote: > > On Thu, Nov 08, 2007 at 03:24:40PM +0100, Bas Wijnen wrote: > > > I wouldn't do that. Repackaging is done to make the tarball complient > > > with our standards, not to beautify it. If this conversion is a good > > > idea (and I agree that it is), then that is an upstream issue, and it > > > should be fixed there. Asking them about it is a good idea, changing it > > > in the package is not IMO. > > > > I had to do this, because this caused some build failed for some > > reason (I don't recall, but my mentor asked me to do it). > > Making changes to make the build work is always good, of course. > However, when changes are made for the Debian package, this should be > done in a way which doesn't hide them. When a user sees a package where > the tarball is repackaged "because some files had to be removed", she's > not going to expect any changes other than the removal of some files. > For other changes, we have a nicely working patch system. In fact devref 6.7.8.2.2 discourages doing anything except removing files when repackaging. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#450608: debhelper: [DH_FIXPERMS] bin/* are updated with v5 too (Re: Executable's execute permission not getting set)
Package: debhelper
Version: 5.0.42
Severity: minor
Tags: patch
File: /usr/bin/dh_fixperms
User: [EMAIL PROTECTED]
Usertag: dh_fixperms
X-Debbugs-Cc: debian-mentors@lists.debian.org
On Thu, Nov 08, 2007 at 04:16:06PM +0100, Bernd Zeimetz wrote:
> Arnaud Fontaine wrote:
> >> "Bernd" == Bernd Zeimetz <[EMAIL PROTECTED]> writes:
> >
> > Hello,
> >
> > Bernd> if I understand dh_fixperms manpage correctly it does not
> > Bernd> 'fix' the permissions for bin directories anymore. So you
> > Bernd> just want to add a chmod 755 somewhere.
> >
> > However, dh_fixperms seems to fix the permissions for bin directories if
> > compat >= 4 according to the manpage ("It makes all files in bin/
> > directories, /usr/games/ and etc/init.d executable (v4 only)")
>
> v4 only sounds like compat ==4 imho. If not it should probably updated
> to since v4.
You're right:
| # v4 and up
| if (! compat(3)) {
| # Programs in the bin and init.d dirs should be executable..
| for my $dir (qw{usr/bin bin usr/sbin sbin usr/games etc/init.d}) {
--- /usr/bin/dh_fixperms
+++ /tmp/tmp.cCMEZ29704/dh_fixperms 2007-11-08 10:29:23.0 -0500
@@ -24,8 +24,8 @@
the permissions of all man pages to mode 644. It makes all files be owned
by root, and it removes group and other write permission from all files. It
removes execute permissions from any libraries that have it set. It makes
-all files in bin/ directories, /usr/games/ and etc/init.d executable (v4
-only). Finally, it removes the setuid and setgid bits from all files in the
+all files in bin/ directories, /usr/games/ and etc/init.d executable (since
+v4). Finally, it removes the setuid and setgid bits from all files in the
package.
=head1 OPTIONS
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote:
> postinst should use dpkg-statoverride instead of chown
Really? I thought this was an administrator's tool, and the postinst
should do something like
getent "$u" >/dev/null ||
adduser --system --group --home /var/... --shell /usr/sbin/nologin \
--disabled-{login,password} "$u"
dpkg-statoverride --list "$f" >/dev/null ||
chown "$u:$u" "$f"
If the statoverride datafile gets filled with all sorts of
maintainer's default package data then it instead requires some
heureustic to try to determine whether the admin did chmod to a
different user/group.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface)
On Fri, Nov 09, 2007 at 10:35:00AM +0930, Paul Wise wrote: > On Nov 9, 2007 9:43 AM, Justin Pryzby <[EMAIL PROTECTED]> wrote: > > > On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote: > > > postinst should use dpkg-statoverride instead of chown > > Really? I thought this was an administrator's tool, and the postinst > > should do something like > > I guess I meant "chowning blindly" instead of "chown". > > I do note that a few postinst files in my /var/lib/dpkg/info/ use > dpkg-statoverride rather than chown. > > I guess I should reread devref/policy. Policy mentions this in 10.9.1; it appears that it can be correct to do either dpkg-statoverride --update or use chown directly, as long as it's conditional on does dpkg-statoverride -l $f >/dev/null. I note that using chown doesn't add the file to the override data, which I argue is a good thing due to no ambiguity about who put it there. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dynamic users (Re: dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface))
On Fri, Nov 09, 2007 at 02:26:42PM -0500, Andres Mejia wrote:
> On Nov 9, 2007 5:24 AM, Michael Biebl <[EMAIL PROTECTED]> wrote:
> >
> > Am Donnerstag, den 08.11.2007, 20:31 -0500 schrieb Justin Pryzby:
> > > On Fri, Nov 09, 2007 at 10:35:00AM +0930, Paul Wise wrote:
> > > > On Nov 9, 2007 9:43 AM, Justin Pryzby <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote:
> > > > > > postinst should use dpkg-statoverride instead of chown
> > > > > Really? I thought this was an administrator's tool, and the postinst
> > > > > should do something like
> > > >
> > > > I guess I meant "chowning blindly" instead of "chown".
> > > >
> > > > I do note that a few postinst files in my /var/lib/dpkg/info/ use
> > > > dpkg-statoverride rather than chown.
> > > >
> > > > I guess I should reread devref/policy.
> > > Policy mentions this in 10.9.1; it appears that it can be correct to
> > > do either dpkg-statoverride --update or use chown directly, as long as
> > > it's conditional on does dpkg-statoverride -l $f >/dev/null.
> > >
> > > I note that using chown doesn't add the file to the override data,
> > > which I argue is a good thing due to no ambiguity about who put it
> > > there.
> >
> > I had the same issue myself, some days ago. I wasn't sure if using chown
> > or dpkg-statoverride in postinst was the correct way.
> > You argue for not using dpkg-statoverride, policy seems to recommend it
> > though. Asking on #debian-devel, the answers I got were, to use
> > dpkg-statoverride unless I have a very good reason not to.
> > I think one disadvantage of using chown in postinst is, that you have a
> > time frame between unpack and postinst, where the binary has the wrong
> > the permissions. With dpkg-statoverride, dpkg will take care that the
> > binary has always the correct permissions.
> > So this is a big advantage of using dpkg-statoverride.
> > Admittedly it would be nice, if policy was more precise in that matter.
>
> Thanks for the suggestions. I went ahead and made the changes. Here's
> the changelog for 0.10.0-5 of this package.
>
>[ Andres Mejia ]
>* Using deluser and delgroup commands to remove meditomb user and group.
>* Removed dependency on passwd.
>* Added --disabled-{login,password} for adduser in preinst.
BTW did you know that adduser --system adds a user *and* a group? For
system users only. {,} is a bashism of course.
Why do you remove the user/group? I think the suggestion is to leave
dynamic system ID's to avoid them being recreated with a different
(system) user which now has access to some stray files leftover from a
different package. If the admin wants to get rid of them, they can do
find / -user $u -o -group $u -ls at their convenience, or look in
obvious places or decide it's not worth the effort.
I think if you do use deluser, it should be in "purge" and not
"remove".
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Sun, Nov 25, 2007 at 09:01:50PM -0800, C.J. Adams-Collier wrote:
> is there something like a service-common package that provides a helper
> script like the following for services to source?
I think the current solution is "provide a template with dh_make",
which is somewhat more general since the init.sh might need to be
overhauled to be useful for some given app.
> I'm thinking that it would belong somewhere like
> /usr/share/service-common/init.sh. I have not tested the following yet, and
> I'm a sucky bash programmer.
>
> # Fully qualified paths to required programs
> START_STOP_DAEMON=/sbin/start-stop-daemon
> CAT=/bin/cat
> ECHO=/bin/echo
> . /etc/default/$SERVICE_NAME
In general, you'd want to test for the existance and only source it if
it's there.
> # Kill me on all errors
> set -e
Put this early as possible.
> # If the daemon binary does not exist, report the error and exit
> if [ ! -f $SERVICE_DAEMON ]; then
> fatal( "Service daemon, '$SERVICE_DAEMON' does not exist." )
> fi
Actually, this is usually:
[ -x $DAEMON ] || exit 0
since the conffiles (such as the initscript) are present after
removing (but not purging) the package, and this keeps them from
spewing noisy errors about the daemon not starting or such.
> # Make sure the RUNDIR exists with correct permissions
> if [ ! -d "$RUNDIR" ]; then
Any reason not to include the rundir in the pacakge? Then you don't
have to manually remove it in the initscripts.
> # Check whether we were configured to not start the services.
> check_for_no_start() {
> if [ "$SERVICE_DISABLED" = "yes" ]; then
This is probably a good idea to be generally and consistently
supported. OTOH removing the execute bit or renaming the daemon file
already works most (90%) of the time.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
interpretted scripts (Re: service helper package)
On Mon, Nov 26, 2007 at 02:13:42PM +, Stephen Gran wrote: > This one time, at band camp, Jörg Sommer said: > > > > Init scripts should not use Bash, they should be Posix Shell scripts! > > Not strictly true. A script written for use with #!/bin/sh should use > the POSIX superset allowed by policy. A script aimed at bsah should By "superset" of posix I guess you mean posix + echo -n. > just declare it's interpreter as #!/bin/bash. Generally, you don't need its > to do that, but you are allowed to. Do you mean because bash is the default sh? It's still required to declare the interpretter: | If a script requires non-POSIX features from the shell interpreter, | the appropriate shell must be specified in the first line of the | script (e.g., `#!/bin/bash') Justin
Re: interpretted scripts (Re: service helper package)
On Mon, Nov 26, 2007 at 03:53:33PM +, Stephen Gran wrote: > This one time, at band camp, Justin Pryzby said: > > On Mon, Nov 26, 2007 at 02:13:42PM +, Stephen Gran wrote: > > > This one time, at band camp, Jörg Sommer said: > > > > > > > > Init scripts should not use Bash, they should be Posix Shell scripts! > > > > > > Not strictly true. A script written for use with #!/bin/sh should use > > > the POSIX superset allowed by policy. A script aimed at bsah should > > By "superset" of posix I guess you mean posix + echo -n. > > IIRC policy also allows [ "$this" -a "$that" ] and [ "$this" -o "$that" ] > although I might be confused in thinking those aren't POSIX. -a and -o are XSI which AIUI is an (very common) extension of posix (see standards.7). dash allows them but posh does not. > > > just declare it's interpreter as #!/bin/bash. Generally, you don't need > > > to do that, but you are allowed to. > > Do you mean because bash is the default sh? > > No, I mean that bash specific features are not generally necessary in Ah, ok; I didn't think that could be right :) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Mon, Nov 26, 2007 at 04:51:38PM -0800, C.J. Adams-Collier wrote: > On Mon, 2007-11-26 at 12:32 +, Jörg Sommer wrote: > > C.J. Adams-Collier <[EMAIL PROTECTED]> wrote: > > > # Fully qualified paths to required programs > > > START_STOP_DAEMON=/sbin/start-stop-daemon > > > CAT=/bin/cat > > > ECHO=/bin/echo > > > > Why not use echo and cat? Calling echo this way the shell can't use the > > builtin echo command and must spawn a new process. > > Is there a test to determine whether there is a builtin for a given > command? If so, we could test for that and use it if it exists. > Otherwise, use the fully qualified version There's "type" and "command" and "which" and "whatis" (see the policy huge long bug about this things) but I don't know why you would use them at runtime (except I guess how debhelper does it with if [ "`which ... 2>/null`" ]; ...) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changelog-should-mention-nmu
On Wed, Dec 12, 2007 at 05:52:05PM +0100, chaica wrote: > Uploading my package on mentors.debian.net, I got this message: > > W: yougrabber source: changelog-should-mention-nmu > My package is the first debian package for this soft. My > debian/changelog is the following: > > yougrabber (0.29.2-1) unstable; urgency=low > > * Initial release. > > -- carl <[EMAIL PROTECTED]> Thu, 06 Dec 2007 11:42:20 +0100 > > Any idea what could be wrong? Thx. This is a clue: > N: Maybe you didn't intend this upload to be a NMU, in that case, > please > N: doublecheck that the most recent entry in the changelog is > N: byte-for-byte identical to the maintainer or one of the uploaders. What's in debian/control:Maintainer?
Re: Weired problem with apt-get -b source
On Tue, Dec 11, 2007 at 10:10:27PM -0800, iluvlinux wrote: > > steps i followed > 1> apt-get source > 2> cd - > 3> dpkg-buildpackage -rfakeroot > > above steps builds deb pkg with shared library while using "apt-get -b > source " don't. How does it fail? Are you using dpkg/unstable, which does -rfakeroot automatically? Are you specifying any dpkg build options via apt (-oBuild-Options=-rfakeroot)? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-ntp] - where does /etc/default/ntpdate come from?
On Tue, Dec 18, 2007 at 06:53:39PM +0100, D. Pathirana wrote: > Dear mentors! > > I am new in Debian Package Maintaining. I try to build some packages for > my own to get a feeling how everything works. I have read a few > docs[1][2] to find a solution for a specific problem that bugs me since > days now... > > I would have asked the pkg-ntp-maintainers list for help but Chapter 10 > of the Debian New Maintainers' Guide[3] tells me to ask here first.. I > hope it's correct and somebody can help... > > So here is my problem: > > I've been trying to figure out how the installation process of the > package "ntpdate" works. After installation the configuration file > "/etc/default/ntpdate" is created. But: I can not find any evidence of > it being used throughout the whole debian directory in the source-package. dpkg -L ntpdate |xargs grep -e /etc/default/ntpdate Also (not so useful in this case): find /var/lib/dpkg/info |xargs grep -we etc/default/ntpdate > > Actually there IS THE file in "debian/ntpdate.default" but is never > refered in the rules file or elsewhere. > > I believe it has something to do with .default suffix but I was not able > to find any docs about what and how it is going on. So where does the > magic happen? I just realized that you weren't asking where the file is used at runtime but rather at compile time. Check dh_installinit (debhelper uses lots of these kinds of input files). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnomecatalog
On Wed, Jan 09, 2008 at 07:14:50PM +0100, José L. Redrejo Rodríguez wrote: > El mié, 09-01-2008 a las 18:24 +0100, José Sánchez Moreno escribió: > > On mié, 2008-01-09 at 12:21 +, Neil Williams wrote: > > > On Wed, 2008-01-09 at 12:29 +0100, José Sánchez Moreno wrote: > > > > On Tue, Jan 08, 2008 at 08:02:02PM +0100, José Sánchez Moreno wrote: > > > > > Dear mentors, > > > > > > > > > > I am looking for a sponsor for my package "gnomecatalog". > > > > > > > > > > * Package name: gnomecatalog > > > > > Version : 0.3.1-1.0 > > > > > Hi José, just a couple of questions: > - Your postinst is maintaining some old debhelper generated code and it > should be deleted. In fact, you can test that this is all you need in > the file: > #!/bin/sh > #DEBHELPER# If the postinst can be generated from scratch by debhelper, then just remove it entirely. It's sufficiently intelligent to eg. add set -e in that case (I don't know if that would happen with a shebang+template maintscripts). Justin
Re: RFC: Exclude config.sub and config.guess from
On Mon, Feb 11, 2008 at 04:42:34PM +0100, David Paleino wrote: > Il giorno Mon, 11 Feb 2008 15:19:08 +0100 Daniel Leidert <[EMAIL PROTECTED]> > ha scritto: > > > Copy the config.* scripts after the clean target has been called (e.g. > > in the config.status target) then they are simply not part of the > > diff.gz. Of course they would be after a second build run. If you care > > and if you want to avoid this: preserve the original config.* scripts > > and put them back in the clean-target. This increases the whole > > debian/rules file for around 4 lines. > > > > This *is* much more easier than any other suggestion I read in this > > thread. > [1] I know that using "[ ! test ] || ..." is pretty awkward, but it > didn't work with "[ test ] &&". Maybe "&&" should be escaped somehow? > I don't really know. A set -e shell script doesn't terminate if a nonzero return value is a part of a conditional/test. However in a makefile, the exit status of the shell can be nonzero even if it was a due to a test "failing", so you have to use [ ! ] || and not the more readable [ ] &&, since the sh -c '' will still exit 1. For the same reason, you need to explicitly exit 0 at the end of some scripts: for a do [...] [ ] && foo done # Necessary due to the test exit 0 Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Writing get-orig-source targets to conform with policy
On Sat, Feb 16, 2008 at 11:10:01PM -0500, Andres Mejia wrote:
> Second question is regarding a get-orig-source target I have for the package
> mediatomb. It goes like:
> # Haven't found a way to use this without running it twice
> COMPUTED_CHECKSUM = $(shell md5sum $(MEDIATOMB_TARBALL) | cut -d ' ' -f 1)
> get-orig-source:
> ifeq ($(CORRECT_CHECKSUM),$(COMPUTED_CHECKSUM))
> The problem here is that the get-orig-source target has to be run
> twice before the checksum passes (unless you happen to have the file
> in the current directory already). Is there any way around this?
The reason is that $(shell ...) is evaluated by make before wget creates
the file (I think it happens at the beginning of the rule). Instead I
think you should either use a shell test:
[ "$md50" = "$md51" ] || { echo "$0: error: ..." >&2; exit 1; }
Or use a 2nd rule which creates the upstream file (using wget), and then
get-orig-source depends on that rule and does md5sum; tar xzf;
manipulate; tar czf.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maintainer script factorization
On Fri, Feb 22, 2008 at 07:07:54PM +0100, Martin Fuzzey wrote: > Hi all, > > frequently maintainer scripts modify the same files and to avoid duplication > of path names etc in all scripts I was wondering if they could be factorized > anywhere. > The obvious solution of installing something like > /usr/share/package/common.sh and sourcing it in the maintainer scripts > doesn't work as the package files may already have been removed. > > Any ideas or is this impossible? You can include some kind of common script and use .in files parsed as with #DEBHELPER# or such. Perhaps use cpp instead of sed for this, or someone will suggest a better way yet. ./debian/maintscript-common: # Begin debian/maintscript-common shell fragment [...] # End maintscript-common ./debian/postinst.in: #! /bin/sh # Postinstallation script for foo #MAINTSCRIPT-COMMON# [...] ./debian/rules: clean: dh_clean debian/postinst debian/preinst debian/postrm debian/prerm binary: [...] set -e; cd debian; for m in postinst preinst postrm prerm; \ do \ f='maintscript-common'; \ [ ! -e "$$m.in" ] && continue; \ exec <"$$m.in" >"$$m"; \ sed -e "s/^#MAINTSCRIPT-COMMON#$$//; T; r $$f"; \ done [...] dh_installdeb [...] Colin watson wrote about a scenario where he apparently needed to do this: http://lists.debian.org/debian-devel/2006/12/msg00647.html Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
list of public usertags?
Does there exist a list of "public" usertags in use? I'd like to see a big list of these, probably a good use of the wiki. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--warn-missing and dh_install?* (Re: Install files with debhelper or make install?)
On Sun, Mar 09, 2008 at 09:03:21PM -0300, Felipe Sateler wrote:
> >>> But I want to use dh_installman, dh_installexamples and the linke. I
> >>> don't want to do a big dh_install run. The goal is to use the helper
> >>> scripts to take the advantage of them.
Agreed, per the first paragraph of dh_install(1).
> > Does dh_install run dh_installman for the files in dh_install? I didn't
> > know this. I though dh_install installs only the files in package.install.
No. You might get comparable behavior with something like:
( cd debian/tmp && find ) |
grep -Fvxe "$(cd debian/libfoo0 && find)" \
-e "$(cd debian/libfoo-dev && find)"
For --list-missing, add: || [ $? -eq 1 ]
For --fail-missing, add: ; [ $? -eq 1 ]
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help needed regarding installation
On Mon, Apr 14, 2008 at 06:35:21PM +0100, Neil Williams wrote: > On Mon, 2008-04-14 at 17:13 +0500, Zainab Rehman wrote: It should be added that there's no need to apt-get source as a privileged user. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installing PEAR packages in an idempotent fashion
On Fri, Apr 18, 2008 at 05:13:29PM +0100, Colin Turner wrote:
> Hi,
>
> My package needs a Pear package, specifically Pear Log, it has php-pear
> in its dependencies.
>
> The big problem is installing the package itself in, I presume, the
> postinst script. My early tests were simply:
>
> pear -q install log
>
> but I found that when the package was installed this process would quit
> with an error second time around, stopping the script from being
> idempotent. At some stage this problem seemed to evaporate (maybe with
> lenny).
> Has anybody any words of wisdom to offer on how to handle pear module
> installations in an idempotent fashion?
You could read the source for "pear" and figure out under what
conditions it exits with an error, and avoid calling it in that case:
grep 'something' /path/somefile || pear -q install log.
You could also (perhaps) test in postinst the $2 value to see if the
package has been configured before (the earlier solution is better
IMO).
You could also test that, if it fails, it fails for that reason, and
allow that failure.
t=`tempfile`
trap 'rm -fv -- "$t"' EXIT
pear -q install log 2>"$tempfile" || {
ret=$?
grep -Fx "$the_error_message" >/dev/null "$t" || {
cat "$t"
exit $ret
}
}
rm -f -- "$t"
trap - EXIT
#Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
this bug/#436681- backuppc: Web interface password publicly visible
On Wed, Apr 23, 2008 at 11:22:01PM +0100, sadia jameel wrote: > hello dear > My name is sadia and i am student of MS(computer science). > i want some information relating to bug #436681 that has been fixed now. > > i am interesting in it and want to know these following questionsabout it: > 1- in which subpackage of "backuppc" this bug was present? The source package backuppc has only one binary package. > 2- what was the reason of this password publicaly visible? ISTM that the bug log has all the info on this. > 3-in which part of the code u have made changing inorder to fix this bug? > 4-what was the major changing that u have to do to resolve this bug? I'd suggest to retrieve the diff.gz files of the version suffering from the bug, and the diff.gz mentioned in the changelog that closes the bug (3.0.0-4), then run interdiff -z ./...1.diff.gz ./...-3.0.0-4.diff.gz. As it's the only change in the changelog, that's precisely what the output should be. On Wed, Apr 16 2008, 2008 at 14:22:51 -0700, BILAL wrote: [...] To get sources, run "apt-get source ". Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to detect an upgrade from an older version of a package
On Tue, Jul 15, 2008 at 03:26:53AM +0800, Thomas Goirand wrote: > Patrick Schoenfeld wrote: > > Additional (might be more to his interest, because he talked about his > > postinst) it says: > > > > " > > postinst configure most-recently-configured-version > > " > > > > If a package is upgraded the most-recently-configured-version is usually > > identical to old-version. It isn't if the configuration of the package > > already took place but the installation hasn't finished (half-installed > > state). That is as far as I understand it. Anyways using $2 as > > oldversion worked for me in every case so far. > > > > Regards, > > Patrick > > In fact, I was being stupid in my question, so I'm asking again. > > I think it's best option for me to know from what version I'm upgrading > from at the configure stage, so I can prompt a nice debconf dialog and ask: > > "Do you want libapache2-mod-log-sql-mysql to upgrade your apachelogs > database tables?" > > I think it's best this way, right? Then, how do I know that I'm > upgrading from version < 1.101 and that the upgraded is needed ??? Read /var/lib/dpkg/info/dpkg.postinst, which, when called with $1 = "configure", also is passed the most-recently configure version, if any, in $2. justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Changing of behavior: How to tell the user?
On Thu, Jul 17, 2008 at 06:14:51PM +0300, Eugene V. Lyubimkin wrote:
> Andreas Tscharner wrote:
> > Dear Mentors,
> > cvslockd is started every time. So I created a configuration file
> > /etc/defaults/cvsnt where an environment variable defines whether or not
> > the daemon gets started. I figured that there are probably more client
> > users than server users and set the default to no longer start cvslockd.
> >
> > My questions:
> > 1) Is this change of behavior desirable/do-able?
I like that change, as I typically install cvsnt and then
rm -fv /etc/rc?.d/S??cvsnt.
> > 2) Is /etc/default/cvsnt the right place to turn on/off the daemon at all?
I think so.
> > 3) How shall I inform the server users that they know that they have to
> > configure the file to get the lock daemon started again?
> for 3) - may be, Debian.NEWS and/or debconf message in postinst?
Another option is to create (only if it doesn't exist, and after doing
a version number comparison with dpkg --compare-versions to see if
this is a version where it should be created) /etc/defaults/cvsnt as a
non-conffile configuration file, with the value CVSNTD determined by:
. if it's an initial installation, "no";
. otherwise, detect if cvslockd is running with s-s-d:
postinst:
f=/etc/defaults/cvsnt
v=2.5.03.2382-3.3
[ ! -e "$f" ] && dpkg --compare-versions "$2" le "$v" && {
CVSNTD=no
[ -n "$2" ] && start-stop-daemon --quiet --stop --test -n cvslockd -x
/usr/bin/cvslockd && CVSNTD=yes
echo "Creating /etc/defaults/cvsnt with CVSNTD=$CVSNTD" >&2
echo "CVSNTD=$CVSNTD" >"$f"
}
Perhaps you could do something a bit more sophisticated, instead of
doing [ ! -e "$f" ] you could do:
grep '^[[:space:]]*CVSNTD' "$f" >/dev/null || {
dpkg --compare=-versions "$2" le "$v" && {
CVSNTD=no
[ -n "$2" ] && start-stop-daemon --quiet --stop --test -n
cvslockd -x /usr/bin/cvslockd && CVSNTD=yes
echo "Initializing /etc/defaults/cvsnt with CVSNTD=$CVSNTD" >&2
echo "CVSNTD=$CVSNTD" >>"$f"
}
}
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preferred way to do a chown on package's dirs ?
On Thu, Aug 07, 2008 at 03:12:42PM +0200, Olivier Berger wrote: > Hi. > > I'm not sure I can find authoritative information on how a packager > should change the ownership (chown) of a shipped directory. > > Of course this can be done in the package's postinst. As already noted, it *has* to be in the postinst if: . the user is a dynamic system user (100 install -m 750 -o www-data -g www-data -d > debian/whatever_package/var/lib/mypackage/somedir > or > chown -R www-data:www-data > debian/whatever_package/var/lib/mypackage/somedir If you call dh_fixperms afterwards, these changes will be lost. > When doing so, it seems that dpk-buildpackage -rfakeroot won't respect > that user definition (btw, that user may not exist on the machine the > package is build from, right ?). User www-data (and everything else with UID<100) is guaranteed to exist with globally constant UID on a Debian system. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preferred way to do a chown on package's dirs ?
On Fri, Aug 08, 2008 at 02:16:31PM +0200, Olivier Berger wrote: > Le jeudi 07 août 2008 à 07:49 -0700, Justin Pryzby a écrit : > > > If you change permissions in postinst, you should use > > dpkg-statoverride (see policy for an example). This guarantees that > > (for regular files) the new permissions are in place even when the > > package is upgraded, and not just chown()d afterwards, with some > > window of time with the wrong permissions. > > > > Hmmm... reading at the policy > (http://www.debian.org/doc/debian-policy/ch-files.html#s10.9.1) it seems > to me that it's a tool meant for system admins and not packagers... or > do I get it wrong ? I thought the same thing, until Michael pointed out that dpkg will respect the overriden mode/permissions even before the rename() to the ultimate filename: http://lists.debian.org/debian-mentors/2007/11/msg00117.html > If files are shipped as root:root and not yet belonging to the user, > during the install time-frame you describe, I'm not sure I can see a > risk there. Eg. if the admin installs something (screen?) SUID root using dpkg-statoverride, some active process that would normally have worked might fail with EPERM during that window. Or something whose SUID bit has been cleared by the admin might introduce a window allowing for some kind of privilege escalation. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package-uses-debhelper-but-lacks-build-depends ????
On Thu, Mar 16, 2006 at 02:27:13AM -0500, Yaroslav Halchenko wrote: > Dear All, > > I am in the process of packaging a new package toward closing ITP ;-) > and although I defined Build-Depends to depend on debhelper, lintian is > not happy anyways What is my problem??? > > binaries are from > http://itanix.rutgers.edu/rumba/dists/unstable/perspect/binary-i386/science/ > sources (and diff) > http://itanix.rutgers.edu/rumba/dists/unstable/perspect/source/science/ > > package pyepl > > lintian reports: > > E: pyepl source: package-uses-debhelper-but-lacks-build-depends > > grep debhelper debian/control > Build-Depends: debhelper (>= 4.0.0), . I guess its because your first "stanza" (the source paragraph) doesn't begin on the first line. > E: python2.4-pyepl: shlib-with-non-pic-code > usr/lib/python2.4/site-packages/pyepl/hardware/sound/_eplSound.so > E: python2.3-pyepl: shlib-with-non-pic-code > usr/lib/python2.3/site-packages/pyepl/hardware/sound/_eplSound.so > and that is a mistery as well... description of shlib-with-non-pic-code > doesn't really seem to provide an answer to what is happening -- I don't > see those switches in Makefiles... > anyways probably it is time to go to bad ;-))) The objects which compose the shared library "must" be compiled with -fPIC; policy 10.2: http://www.us.debian.org/doc/debian-policy/ch-files.html#s-libraries The rationale is that some architectures require this for compilation to succeed [0], and other archictectures experience considerable runtime slowdown in reprocessing [1]. Static libraries mustn't be compiled with -fPIC, since there is no relocation involved, and this would just add overhead to the code. This requires recompiling the object files for library packages which provide both .a and .so libs, for their -dev and runtime packages. Justin References [0] http://bugs.debian.org/severity:serious&include=subj:fPIC [1] http://people.redhat.com/drepper/dsohowto.pdf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adoption request for "tcsh -- TENEX C Shell, an enhanced version of Berkeley csh"
> On Fri, 2006-03-17 at 20:37 +0100, Martin Godisch wrote: > > On Fri, Mar 17, 2006 at 16:36:06 +0800, Cai, Wen Liang wrote: > > > > > I'm willing to adopt this package if you could give me a hand to > > > guide me in the initial period. I'm a software engineer focusing > > > on middleware and security fields. Most of my development jobs > > > are based on Linux/UNIX environment. > > > > You have to be a Debian developer or have to have a sponsor in > > order to maintain a package. Do you? If not, please ask at > > debian-mentors to find a sponsor there. On Sat, Mar 18, 2006 at 10:32:45AM +0800, Cai, Wen Liang wrote: > > Martin, > Thanks for your response. No, I'm neither a Debian developer nor having > a sponsor there. I'll send a request to debian-mentors for help. > > Debian folks, > Would anybody like to be my sponsor? I'm thinking of adopting tcsh > package from Martin. I have used FOSS for several years. And just want > to find a way to contribute back to the community. You'll have much better luck finding a sponsor for an existing package/update. I would suggest to prepare a new release of the package, and then reinquire; perhaps the old maintainer will agree to sponsor you, too. Justin (realizing that this sounds circular) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempting to adopt two packages
On Tue, Mar 21, 2006 at 05:54:09PM -0400, Felipe Sateler wrote: > Done some work, now I might be ready. > > Justin Pryzby wrote: > > On Fri, Mar 10, 2006 at 05:35:15PM -0300, Felipe Sateler wrote: > >> contact Matt, but so far I haven't received any response (mail was sent > >> on 11/01/06). I do know I have to file an ITA bug to each package, but I > > In the case of installwatch, you should retitle the 'O'rphan bug > > instead: http://packages.qa.debian.org/installwatch => #347469 > > > What you want to happen, is that anyone who has either of installwatch > > or checkinstall now, ends up with the new version of whatever the new > > packagename will be. Do it by setting > > > > Package: foo > > Replaces: bar > > Conflicts: bar > > > > The overloaded combination of Conflicts+Replaces means "this is the > > new name for package bar", so it will cause files in bar but not foo > > to be removed. > Done this too. However, I can't install it via dpkg, only through apt. dpkg > argues that it can't uninstall installwatch because checkinstall needs it. But checkinstall doesn't need it, right? You should probably drop that Depends .. You want to have Replaces+Conflicts, though. You probably also want to add Provides, or a dummy package with the name of the old Debian package which is now included in the new package, to force the new package to be installed. > > You might consider requesting uploads as an NMUs initially, though if > > it were a QA-owned package this would be a "QA upload" rather than an > > NMU. > Ok, I'll do that when I'm ready. However, I've got a new question. Package > directories (such as /usr/doc/ /usr/doc/ is now a policy violation; documentation must live in /usr/share/doc/. > or /usr/lib/) are to be > named after the Debian package or the real package? Note that although > checkinstall and installwatch come together, they are still two separate > packages (one includes the other). So the question really is: documentation > for _both_ installwatch and checkinstall go > into /usr/share/doc/checkinstall, or I make a new > directory /usr/share/installwatch? The installwatch library (which is not > intended to be shared) goes into /usr/lib/installwatch > or /usr/lib/checkinstall? So far, I've favored Debian package names. That makes sense to me too; /usr/share/installwatch smells like namespace polution, and asks for confusion if not collision someday. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/conf not installed
On Tue, Mar 21, 2006 at 10:56:44PM +0100, Gerber van der Graaf wrote: > I am trying to repair the libgpiv package I've build. The > libgpiv_0.3.2-1_i386.deb contains a configuration file /etc/gpiv.conf, > as reported by dpkg -c. Extracting the .deb to tmpdir/ (with dpkg -x) > gives tmpdir/etc/gpiv.conf, as expected. However, dpkg --install .deb or > installing with: "apt-get install libgpiv" (after uploading in a local > repository) does not install this file. On the other > side, /usr/lib/libgpiv.so libgpiv should not include a development symlink *.so, but rather *.so.*; libgpiv-dev should include that symlink. Also libgpiv should have some number in its name, indicating the library soversion. > is perfectly installed. The gpiv.conf file is > pointed by debian/libgpiv.files. I also tried to include it in > debian/conffiles Recent debhelpers (v3 and later) add to the conffiles list every file included in the .deb which is in /etc/ (but obviously not stuff created by maintainer scripts, which are not "conffiles" but more general "configuration files"). > , in order to warn in case of an upgrade. Can somebody > give me a hint where I have to look at or to search for in order to > repair this bug? Thanks, Gerber You probably have to purge the package and then reinstall it. Removal of a conffile is preserved across upgrades, since the behaviour of some packages might be influenced by the mere existence of some files. This is done automatically by dpkg for conffiles, and is a policy violation (I guess) for generalized configuration files. FYI dpkg is probably tracking that the conffile was once installed and not since purged with /var/lib/dpkg/status. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Checking if another package is upgraded at the same time
On Thu, Mar 23, 2006 at 12:11:59AM +0200, Kari Pahula wrote: > I'm maintaining two interrelated packages, crossfire-server and > crossfire-maps. The former depends on the latter. It is possible to > upgrade them separately, but upgrading the maps alone leads to > problems. The server runs as a daemon and will be more or less at an > inconsistent state if the maps are upgraded while it is running. So you want to have a one-way dependency (since you can have -maps installed without "causing problems"). -server should depend on -maps, perhaps (>=X-1), (<<[X+1]-1). The trailing -1 is the debian version, not a subtraction, but the [X+1] is subtraction: Depends: crossfire-maps (>=0.95.3), crossfire-maps (<<0.96) This assumes that the 3rd version component is for bugfixes, and doesn't break compatibility. > Restarting the server needs to be done when upgrading crossfire-maps. > But having one package to automatically cause another to run > /etc/init.d/foo restart is certain to surprise a number of users. > Using debconf to ask whether to abort install, install and restart or > just install sounds like a good idea to me. Overuse of debconf is discouraged; check the dict-bouvier and gazetterer packages for examples one one package restarting another packages daemon. Note that policy 9.3.3.2 "strongly recommends" using invoke-rc.d (when available) rather than running the init scripts directly. > But doing this leads to another slight problem when upgrading > crossfire-server and crossfire-maps at the same time. Namely, the > question in crossfire-maps is unnecessary in this case since upgrading > crossfire-server will restart the server anyway. So I'd like to have > crossfire-maps to simply go ahead and install the files if the server > is upgraded on the same run. Is there any reliable way to check if > the server is being upgraded in crossfire-maps' preinst? I think this is probably one of the questions that is indicitive of doing stuff the wrong way :) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf; unattended package installation; lvm2.
On Thu, Mar 23, 2006 at 03:07:53PM +0200, [EMAIL PROTECTED] wrote:
> 1) debconf talks about setting {false,true} flags to questions. Does
> the set of possible flags predefined or can I invent a flag of my
> own? For example, can I have an "install the package unattendedly"
> flag?
"noninteractively", and that would make the flag boolean (see
debconf-devel(7)).
> 2) The lvm2 deb doesn't have a config file in the sense of debconf
> config file. What subtle reasons might be for the lack of that file?
I believe the config script exists to allow most/all of the
"configuration" to happen immediately after package retrieval, rather
than spread out over the package unpack/postinst stage. By
"configuration", I mean "answering debconf questions", and not
"calling postinst configure" (which is what typically acts on the
results of the configuration values).
But I think the config script is optional; if it doesn't exist, then
all its logic is in the postinst script (well, in the case, the
preinst).
> 3) The lvm2 deb uses
>
> if ! dpkg --compare-versions $(uname -r) ge '2.6.12'; then
> db_fset lvm2/kernel seen false
> db_input critical lvm2/kernel || true
> db_go
> exit 1
> fi
>
> This prevents creating an nfsroot automatically here, since the
> machine on which the nfsroot is installed uses an older kernel
> version. In case upgrading the kernel is not acceptable, what
> other solutions are there?
I don't understand the details of this problem ..
> I thought about asking the lvm maintaner to add a low priority
> debconf question about unattended installation with a default
> of "false". The critical question from above would not be
> displayed when unattended installation would be set to "true".
> In that way only users that install unattendedly and know what
> they are doing would set it to "true". Am I right?
You are right that such a thing is possible, though it is perhaps not
the best approach..
> Am I correct that adding an unattended flag to the critical
> question won't help becuase one can not have a default value
> for a flag?
You can surely have a default value.
I would suggest to bring up the problem with the lvm maintainer, and
ask for some way to allow noninteractive installation. I don't know
anything about such things, but I'm guessing that setting "seen" to
"false" might prevents such things. You should surely read
"Unattended Package Installation" from debconf(7) though, since there
seem to be relevant environment variables you can set (especiall
DEBCONF_DB_OVERRIDE).
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Compiling a Gnome app / GTHREAD or XDamage error
On Thu, Mar 23, 2006 at 06:20:21PM +0100, Bastian Venthur wrote: > Hi, > > I'm currently working on a small GTK2 app and while trying to compile it > under a clean pbuilder environment, I get the following error during the > config phase: > > checking for GTHREAD... configure: error: Byzanz requires GThread-2.0 >= > and XDamage >= 1.0 to compile. > make: *** [config.status] Error 1 > > Currently my package build-depends on: debhelper (>= 4.0.0), > autotools-dev, libexpat1-dev, libxdamage-dev, libpanelappletmm-2.6-dev, > intltool, libgtk2.0-dev > > I guess the problem has something to do with GTHREAD, but I have no Idea > which package provides it or if it's already in my build-depends, why > config does not recognize it. > > The ubuntu counterfeit seems to use the same build-depends, but he uses > cdbs and it seems to work -- debian/rules is a three liner without any > special options, so I guess I have to add something to the config-options. > > Any idea? You can probably just run ldd on the result (compiled outside of pbuilder) to figure out what libraries are used, and then apt-file or packages.d.o to search for the package that includes it. Or perhaps check the configure script debug output (whatever it calls itself) to see whats missing. Note that the configure script could be buggy, and test for the existence of something which isn't actually needed by the rest of the compilation (this happened recently with the xlibs-dev transition). gthread is in the libglib2.0-dev package (note recent application-level bugs regarnding glib dynamic allocation, such as #358071). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Compiling a Gnome app / GTHREAD or XDamage error
On Thu, Mar 23, 2006 at 07:35:18PM +0100, Bastian Venthur wrote: > Laszlo Boszormenyi wrote: > > On Thu, 2006-03-23 at 18:20 +0100, Bastian Venthur wrote: > >> checking for GTHREAD... configure: error: Byzanz requires GThread-2.0 >= > >> and XDamage >= 1.0 to compile. > >> make: *** [config.status] Error 1 > >> > >> Currently my package build-depends on: debhelper (>= 4.0.0), > >> autotools-dev, libexpat1-dev, libxdamage-dev, libpanelappletmm-2.6-dev, > >> intltool, libgtk2.0-dev > > [...] > >> Any idea? > > There's a wonderful simple search place: http://packages.debian.org/ > > At the bottom, choose unstable and search for libgthread as keyword. > > It reveals that libglib2.0-dev contains: /usr/lib/libgthread-2.0.so > > The problem sits deeper! I've included this package before and received > the same error. I even took the ubuntu package and tried do build it in > a clean pbuilder environment and guess what? It fails exactly with the > same error. > > So something really strange is going here. Maybe a bug in one package in > my build-depends? > > > > Just a question: is it so poorly known that anyone can search for > > package contents? > > Nope, I know packages.d.o but I still was not *sure* which package was > missing. These might be useful (devscripts): - dpkg-depcheck, dpkg-genbuilddeps: determine the packages used during the build of a Debian package; useful for determining the Build-Depends control field needed [build-essential, strace] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Compiling a Gnome app / GTHREAD or XDamage error
On Thu, Mar 23, 2006 at 07:15:38PM +0100, Laszlo Boszormenyi wrote: > Just a question: is it so poorly known that anyone can search for > package contents? I don't know, but it seems to me that listing and searching files are intuitively obvious things that any package management system should do. Note that dpkg also allows you to preserve arbitrary files across upgrade (though it doesn't appear to let me know when the distribution file is updated, as with conffiles): dpkg-divert Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: checkinstall - installation tracker
On Fri, Mar 24, 2006 at 12:30:06AM -0400, Felipe Sateler wrote: > I have more or less made ready a new package for checkinstall and > installwatch (which are now only one package). The new packages are > available through debian.mentors.net [1] > Major differences from previous packages: > 1) Merged installwatch and checkinstall. > 2) Re-Debianized the package. Reasons: merging of the packages, and because > the original checkinstall debian/rules bypassed the checkinstall Makefile, > because it wasn't very good. My approach was rewriting the makefile > (changes sent upstream), and only doing additional work in debian/rules. Your first Closes entry isn't terminated with a closing/right parenthesis; not that it really matters. You need to include the years of copyright (if available). Your rules file is set up as if you produced both -arch and -indep packages, but that isn't the case. In particular, you don't need DH_OPTIONS at all. "useless use of cat" in the install target; you should probably just rely on the debhelper tools to do everything like: creating links compressing files creating directories installing files You have sed commands, which aren't necessarily bad, but you could probably just include the changes in the .diff.gz. binary depends on build and install, but install already depends on build. I don't know why the template is like this; I'm filing a bug now.. Your modified makefile might use install -s to install the library, rather than cp. BTW, did you ever figure out why dpkg wasn't allowing you to directly install the new package? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Including .so symlinks in non-dev package: policy violation?
On Fri, Mar 24, 2006 at 05:00:19PM +0200, Fabian Fagerholm wrote:
> On Fri, 2006-03-24 at 16:34 +0200, Fabian Fagerholm wrote:
> > The plugin .so's are not designed to be accessed directly. The purpose
> > is to access them through libsynfig, which is properly versioned. In a
> > sense, they differ from shared libraries ("libraries that are to be
> > shared between applications").
> >
> > Is it ok to include the unversioned symlinks for the plugin .so's in the
> > non-dev package (libsynfig0)?
>
> I forgot to mention that the plugins are shipped
> in /usr/lib/synfig/modules -- so the whole thing looks very much like
> the run-time support programs in policy 8.2, except in this case, the
> artifacts are shared objects, not executables.
Do you actually have to ship them as separate objects, or could you
conceivably link statically to them?
This is what Steve suggested here:
http://lists.debian.org/debian-mentors/2005/01/msg00465.html
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conflicting library names
On Fri, Mar 24, 2006 at 12:54:01PM +0200, Kari Pahula wrote: > I'm packaging libggtl (ITP #358659), which uses libsl (ITP #358657). > The latter is rather unfortunately named. The namespace of two letter > acronyms is rather crowded and there is already a /usr/lib/libsl0 in > libsl0-heimdal. To be precise, it is a file collision, not a directory: libsl0-heimdal: usr/lib/libsl.so.0 libsl0-heimdal: usr/lib/libsl.so.0.1.2 > What would be a sane way to handle this situation? I'm thinking of > just copying libsl into the package and linking statically to it and > to not package libsl at all. The obvious disadvantage to this is that the source package will be nonpristine (well, unless you use an embedded-style source package, which is like borderline-pristine or something). > Most of the uses of libsl are internal in libggtl, but some parts of > its API return libsl derived data structures. There would be some > need to have libsl at hand for users... Otherwise I would just take > the easy road and not bother packaging libsl at all. Perhaps you could install include files, including any from libsl, to /usr/include/ggtl/ (rather than cause more 2 letter collisions), and rename the library file to libggtl-sl? (And update the soname too of course). This means that some binaries won't run on different distributions, but there's no way around that anyway, right? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: howto pack python programs
On Sun, Mar 26, 2006 at 04:33:37PM +0200, Bastian Venthur wrote: > Hi Mentors, > > I'm currently working on a program written in python. The source-tree > looks like this: > > foo.py > bar.py > baz.py > ex1.py > ex2.py > ex3.py > > where ex*.py are executables and the others not. My question is, where > to put all these files and what should I do with the executables? > > My current idea is: > - copy all *.py into /usr/share/$PACKAGE/ > - create symlinks like > /u/s/p/ex1.py <- /usr/bin/ex1.py > /u/s/p/ex2.py <- /usr/bin/ex2.py > /u/s/p/ex3.py <- /usr/bin/ex3.py > > Is the location /usr/share/$PACKAGE OK? Looks good to me. > Should I create the symlinks > without the py-extension, like: > /usr/bin/ex1 -> /u/s/ex1.py The suggestion is that stuff in /usr/bin/ shouldn't have an extension on it, in case the implementation (but not the interface or behavior) changes. So /usr/bin/foo.sh might get rewritten as /usr/bin/foo.pl, which is a pain for people who hardcoded foo.sh into their scripts (whether they're scripts for Debian or not). /usr/bin/foo is preferred. > Next problem, lintian is complaining (W) about non-executable scripts in > /usr/share/$PACKAGE -- can I ignore this? If it is meant to be run directly, then it should be executable; otherwise, it should not. http://lists.debian.org/debian-mentors/2004/03/msg00077.html Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf able to ask multiple questions at once?
On Tue, Mar 28, 2006 at 01:02:49PM -0800, Steven Brown wrote: > debconf-devel mentions that it tries its best to ask multiple questions > per screen, but I've never seen that occur. Is there a way to get it to > ask that way, or maybe some alternate front end that does it? I want to > be sure my package acts sane in such a setting. > > I've added the state machine approach as it mentions so users can back > up, but it's rather bad if I ask more than one question per state, as > otherwise, it's not apparent to the user what "cancel" will actually do. > However, I can see how it would get annoying if debconf was able to > prompt with multiple questions at once and I've effectively serialized them. http://justinpryzby.com/iraf.noao.edu/irafconf.jpg dpkg-reconfigure debconf to change the default, or dpkg-reconfigure -f gnome to do it just once (Requires libqt-perl or libgnome2-perl). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question about CFLAGS modifiers to ./configure
On Thu, Mar 30, 2006 at 06:23:38PM +0200, Miriam Ruiz wrote: > Hi, > > 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. Are you talking about the combination of CFLAGS foo above, and libraries build and used by the package? man ld explains -z defs: Disallows undefined symbols in object files. Undefined symbols in shared libraries are still allowed. Note that some ./configure scripts recommend to be called with CFLAGS transposed, as in: ./configure --host=$(...) CFLAGS="$(CFLAGS)" Note also that -O2 should be used only if DEB_BUILD_OPTIONS!~noopt. What is the command, and error, when you try to use the libs, and those options? > Is it important to keep them? Could someone possibly explain to me > what they mean? You will probably have to use the examples from dh_shlibdeps to get proper dependencies on the shared libraries in that package, used by any binaries it creates. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question about CFLAGS modifiers to ./configure
On Thu, Mar 30, 2006 at 08:23:38PM +0100, Darren Salt wrote: > I demand that Miriam Ruiz may or may not have written... > > > 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) > > ... > > -Wl,-z,defs in CFLAGS causes warnings about unused linker flags. It belongs > in LDFLAGS. Good point :) This is #338990. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Adopt new package Wormux
"Bernhard R. Link" <[EMAIL PROTECTED]>: > * artefact <[EMAIL PROTECTED]> [060406 15:37]: > > I packaged some time ago a game, Wormux. This game is entirely covered > > by GPL license. I created the package a few months ago and released 3 > > versions since then, from upstream updates. For those who didn't look at the screenshots, this is a clone of the awesome game "worms", and I'm excited for the package :) > > There is an wnpp bug about the game : > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352064 > > I have now an account onto alioth and have some contacts with the > > pkg-games group. I recently imported the package sources at > > > > svn://svn.debian.org/svn/pkg-games/packages/wormux > > > > I am just waiting for a mentor... ;-) > > A mentor or sponsor? For a sponsor a URL with the source package would > be helpful. => http://svn.debian.org/wsvn/pkg-games/packages/wormux/trunk/debian/?rev=0&sc=0 I'm building the package to test now, but can't sponsor you :/ BTW, the -games repository looks like it will work wonderfully! I was about to ask if you had asked for a sponsor on the -devel-games list, but this seems to be nearly unused. BTW, it looks like your build-indep logic in ./debian/rules does nothing at all, except creating and removing the stamp file. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361253: ITP: zenoss -- Zenoss is a powerful, integrated, easy-to-use IT infrastructure monitoring software product.
On Fri, Apr 07, 2006 at 04:55:40PM +0200, Wolfgang Lonien wrote: > Javier Fern?ndez-Sanguino Pe?a wrote: > > On Fri, Apr 07, 2006 at 03:01:28PM +0200, Wolfgang Lonien wrote: > >> * Package name: zenoss > >> Version : x.y.z > > > > Version? > > Oh ooops - seems like my personal multitasking abilities were disabled > for a while... sorry. > > Since this will be my first package ever: how do I "correct" my bug > report 361253 against WNPP? Simply with: > > - Version : x.y.z > + Version : 0.19.3 Just mail the bug with a link to this thread, it isn't important. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to build packages from tarballs without makefiles
On Sun, Apr 09, 2006 at 01:20:06AM -0700, David Liontooth wrote: > Roberto C. Sanchez wrote: > >David Liontooth wrote: > > > >>I occasionally run into tarballs without a makefile. How do I turn those > >>into Debian packages? > >> > >>Here's an example -- otk_lib from http://otk.sourceforge.net/. > >> > >># tar zxvf otk_lib_0.47.tgz > >>otk_lib/gadget_lib.c > >>otk_lib/letter2vector2.c > >>otk_lib/otk_lib.c > >>otk_lib/Readme.txt > >>otk_lib/gadget_lib.h > >>otk_lib/otk_lib.h > >> > >>I rename the directory libotk-0.47, enter it, and run dh_make -s, > >>getting "Currently there is no top level Makefile." The Readme.txt says > >> > >>/* To Compile: Directive in code should detect environment and do the > >>right thing.*/ > >>/* > >>Unix/Linux: > >>*/ > >>/*cc -O -c -I/usr/X11R6/include otk_lib.c -o > >>otk.o */ > >>/*Link with:-lGLU -lGL -lXmu -lXext > >>-lX11 */ > >> > >>Do I put these into debian/rules? Where? > >> > >>I was hoping I could make a few changes and run fakeroot > >>dpkg-buildpackage. > >> > >>Dave > > > >I would just put those into the debian/rules. There is not enough there > >to justify a full-blown makefile in my mind. You could write a nice 5 line Makefile and send it upstream, or you could stuff the upstream README into debian/rules. > OK, that's good news, but I need a bit more help -- where do I add them > to rules? See policy for the required targets. Compiled sources are arch-dependendent. >CFLAGS = -Wall -g > > Can I add the "Link with" line to give You shouldn't; there are CPPFLAGS for the preprocessor, and LDFLAGS for the linker. > CFLAGS = -Wall -g -lGLU -lGL -lXmu -lXext -lX11 Use LDLIBS instead. > Does that work? Yes but.. > What about > > -O -c -I/usr/X11R6/include otk_lib.c -o -O is another CFLAG. make should take care of -c and -o automatically, from the rule database that knows how to compile .c to .o and .o to ELF. > Under "# Add here commands to compile the package." I just have > >$(MAKE) > > I don't know the syntax here. MAKE is a variable, $(MAKE) is the contents of that variable. You could run make -asdf -f ./debian/rules, and the "-asdf" would be preserved in the sub-make. You should read the gnu make manual: http://www.gnu.org/software/make/manual/make.html Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to build packages from tarballs without makefiles
On Sun, Apr 09, 2006 at 09:45:02AM -0500, Carlo Segre wrote: > On Sun, 9 Apr 2006, David Liontooth wrote: > > >Roberto C. Sanchez wrote: > >> > >>I would just put those into the debian/rules. There is not enough there > >>to justify a full-blown makefile in my mind. > >> > >OK, that's good news, but I need a bit more help -- where do I add them to > >rules? > > > > CFLAGS = -Wall -g > > > >Can I add the "Link with" line to give > > > > CFLAGS = -Wall -g -lGLU -lGL -lXmu -lXext -lX11 > > > >Does that work? What about > > > >-O -c -I/usr/X11R6/include otk_lib.c -o > > > >Under "# Add here commands to compile the package." I just have > > $(MAKE) > > > > Since there is no Makefile, you will need to explicitly replace the > $(MAKE) with the gcc or cc command with the options you want. Not true; make foo.o will create it from foo.c or foo.f or whatever, using values of CFLAGS FFLAGS CPPFLAGS or whatever is appropriate. make foo also works (assuming of course that the source file is called foo.something). > In the "install" section, again, you will need to replace the > $(MAKE) install with individual install commands to put the > libraries where they are supposed to go. True, afaik. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Doing RFS on -mentors
On Sun, Apr 09, 2006 at 08:52:02PM +0200, Nico Golde wrote: > Hi, > to make it as easy as possible for purspective package checkers > if you post an RFS on the -mentors list please put all parts > of the source package in a directory (FTP or HTTP). > > The reason why I write this is the wmforkplob RFS. > Don't put your package on a PHP site where the checker has > to download each file extra because its not possible to > access the directory on the webserver directly and disable > directory listing. > > Normally I use wget --mirror --no-parent to get the source > files. So if you do your RFS, enable directory listing on > your server (or in package directory), post the exact link > of every file in the mail so we can mark them and use wget > or upload them to http://sponsors.debian.net. And do whatever needs to be done so a .diff.gz shows up in my browser, rather than making me download it :) More seriously, this brings me to a practical reason to use non native packages (and of course pristine, where possible). These are not just theoretical things, but actively make things more difficult for me. 1. You don't have to upload the entire .orig.tar.gz on every Debian release. This has been mentioned occasionally, but I mention it again since it is probably the only really significant reason I have ever heard before. 2. It allows one to easily read .diff.gz on PQDO [0], which is set up such as to allow transparent decompression by the browser. When you hear OSS or whatever advertized as "peer reviewed", this is why. It allows me to tag bugs "upstream" if I can look briefly at the .diff.gz (or check the size, which is shown as a mouse "hover" title) and confirm that there aren't any relevant patches applied. It also lets me to other checks really easily, whereas I would otherwise have to :Nread and |gunzip in vim or whatever. Justin References [0] http://ftp.debian.org/debian/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.1-4.diff.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to build packages from tarballs without makefiles
On Mon, Apr 10, 2006 at 05:18:46PM +0100, Darren Salt wrote: > I demand that Carlo Segre may or may not have written... > > > On Sun, 9 Apr 2006, David Liontooth wrote: > [snip] > >> I need a bit more help -- where do I add them to rules? > > >> CFLAGS = -Wall -g > > >> Can I add the "Link with" line to give > > >> CFLAGS = -Wall -g -lGLU -lGL -lXmu -lXext -lX11 > > [snip] > > BTW, a library package may not be the best thing to learn packaging. A > > package which produces a single executable is much easier. > > ... and, since it's a library, you *must* add -fPIC to CFLAGS. ... and to LDFLAGS also: gcc.1 | -shared | Produce a shared object which can then be linked with other objects | to form an executable. Not all systems support this option. For | predictable results, you must also specify the same set of options | that were used to generate code (-fpic, -fPIC, or model suboptions) | when you specify this option.[1] (assuming it is a shared library of course) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wormux package
On Tue, Apr 11, 2006 at 08:50:23AM -0400, artefact wrote: > Le 11.04.2006 02:45, Eddy Petri??or a ??crit : > > >On 4/11/06, artefact <[EMAIL PROTECTED]> wrote: > > > >>Hi, > >>I recently asked for the adoption a new game named Wormux. > >>I fixed most of the issues people have found after I posted the mail. I > >>think you can reasonably test the package again. I gave too the address > >>of the upstream package on my personnal website because the official > >>wormux repository was down. As it is alive now, please note the real > > > >Could you please fix the (upstream) issues I have reported[1][2] and > >commit the updated ro.po file in the repo? > > > I think these issues have been fixed into the upstream version, but > since the tarball has been released, reflecting this changes in the > Debian package force us to release another version or to use a different > version between the official release and Debian package. Why? Debian being able to update independently from upstream is one of the (less convincing IMO) arguments for non native pacakges .. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
On Tue, Apr 11, 2006 at 12:40:20PM -0400, Felipe Sateler wrote: > Thijs Kinkhorst wrote: > > I doubt it. Debian users are used to find their configuration > > under /etc, because all packages do that. Even, users of any LSB/FHS > > compliant distro expect that. I can't think of a reason why someone > > would think that for "checkinstall" this would be different than for any > > of the thousands of other packages in Debian. > I'd think that too, but since checkinstall *does* install the files in such > places, a person that had been using checkinstall downloaded from upstream > would expect to find the files in the same places. OTOH, such a user might > be very unlikely. So, README.Debian is gone, and the package has ben > reuploaded. The accepted practice is to have a symlink in /usr (or wherever) which points to the relevant path in /etc. That way, the program doesn't have to be hacked, if thats complicated, and users can edit whichever path they want (assuming their editor doesn't break the link). This is even mentioned in policy. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: checkinstall
On Wed, Apr 12, 2006 at 01:48:59PM -0400, Felipe Sateler wrote: > Justin Pryzby wrote: > > The accepted practice is to have a symlink in /usr (or wherever) which > > points to the relevant path in /etc. That way, the program doesn't > > have to be hacked, if thats complicated, and users can edit whichever > > path they want (assuming their editor doesn't break the link). > But the symlink would be located at /usr/local, which can't be written by > packages. You're allowed to create empty directories in /usr/local/*/, but that is all (9.1.2.). Users should know or be able to figure out that the configuration files which a package, by default, installs to /usr/local/ might be in /usr/ instead, otherwise every package would need a README.Debian that documented this :) > > This is even mentioned in policy. > Where is that mentioned? I can't find it. 10.7.2. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Closing bugs fixed in experimental
On Thu, Apr 13, 2006 at 11:02:58PM +0200, Rafael Laboissiere wrote: > Is it acceptable to manually close a bug which is fixed in experimental > but not yet in unstable, especially when there are no plans regarding the > upload of the fixed version to unstable in the foreseeable future? I think so, yes, with a proper Version: header. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wormux package
On Mon, Apr 10, 2006 at 11:49:44PM -0400, artefact wrote: > Hi, > I recently asked for the adoption a new game named Wormux. > I fixed most of the issues people have found after I posted the mail. I > think you can reasonably test the package again. I gave too the address > of the upstream package on my personnal website because the official > wormux repository was down. As it is alive now, please note the real > address for the upstream: > http://download.gna.org/wormux/wormux-0.7.tar.gz > The package sources are located here: > > svn co svn://svn.debian.org/pkg-games/packages/wormux/trunk wormux Crap, I was going to respond to this last time.. Unfortunately, this program seems to have a massive memory leak, on the order of 1MB per turn. Unfortunately I don't have that many MB to spare. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about debian/copyright
On Wed, Apr 19, 2006 at 05:07:37PM +0200, Frank K?ster wrote: > Miriam Ruiz <[EMAIL PROTECTED]> wrote: > > > More concisely, is debian/copyright supposed to include the copyright and > > license of the contents of the binary package in which it is contained, or > > the > > source package from which it is generated? Take into account that the source > > package already contains the copyright notices related to the source > > distribution, right as upstream have included them. > > But the upstream information is not always easy to find. It's easy for > a simple package with one single license, but in that case you don't > need to distinguish between the source package's and the binary > packages' copyright files. > > In my opinion, if the copyright/licensing situation is complicated > enough that you consider putting only relevant parts into binary > packages' copyright files, there should also be a debian/copyright file > (or some of them, with easy to find names) in the source package that > describes what you, the Debian maintainer, know about upstream's > licensing and copyright information. > > If this is the case, I think it's a matter of judgement what to do with > the binary packages. Note that it's also a lot of work to keep split > copyright files up to date - you might want to rearrange the packaging > some day. > > If a software comes with some data included that might be useful for > others (like fonts) and is installed as a separate binary package (like > foo-xfonts), then it might really make sense to include in > /usr/share/doc/foo-xfonts/copyright only the information about these > data. And I don't see how this is against policy. And the ability to do so is made easy by dh_installdocs: If dh_installdocs is acting on multiple packages, debian/copyright files will be installed into all packages. However, if you need to have sepa- rate copyright files for different binary packages, you can use files named debian/package.copyright. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Q on fixed-in-experimental
On Thu, Apr 20, 2006 at 12:14:58AM +0100, Neil Williams wrote: > When a bug is tagged "fixed-in-experimental", does that bug number still > have to appear in debian/changelog for the next upload to unstable or > will the BTS be updated when the package in experimental is replaced? > > I know how to filter the BTS to show bugs with these tags, just > wondering if it's automated. fixed-in-experimental is just an informative tag, and doesn't have any functional consecquence; it is really obsoleted by versioning, which does. If you mail [EMAIL PROTECTED] with a Version: $v pseudoheader, where v is the version in experimental, and later upload to unstable a version "derived from" the version in experimental, the BTS will consider that bug fixed in sid, too. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is "stripping" in binary compilations ?
On Sun, Apr 23, 2006 at 01:25:20AM +0200, Maxim Vexler wrote: > Hello everyone. > > I'm reading the "New maintainer's guide". > > On page 28 (version 1.2.3,18 January2005) the author speaks about > `stripping' executable and the dh_strip(1) script. Surprisingly, no > where was the reader informed about the purpose of `striping'. Am I > supposed to know this as part of "basic knowledge" ? :) > If so where can I learn more about stripping I've tried to search > the Debian developers reference guide and the gcc online > documentations, as well as google but no useful information has > turned up. See man 1 strip, install -s, and dh_strip. > Is stripping important when packaging an application for debian ? It can reduce the size by a considerable amount, so Debian ELF objects are typically stripped of everything they don't need for normal runtime, including "comment" sections and debugging symbols (which are sometimes put into > How can I tell if an application was meant to be stripped by upstream ? If it is in any way "normal", you can just strip it, and it will just work. There are some strange ones that keep can't be stripped, because they keep critical information in some "comment" section or such. Debian makes this pretty trivial; the default dh_make output calls dh_strip at the appropriate time, and dh_strip even knows to do nothing if DEB_BUILD_OPTIONS=~nostrip, which allows testers/debuggers to trivially recompile the .debs *with* debugging information included, which would normally have been removed. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is "stripping" in binary compilations ?
> > How can I tell if an application was meant to be stripped by upstream ? > If it is in any way "normal", you can just strip it, and it will just > work. There are some strange ones that keep can't be stripped, > because they keep critical information in some "comment" section or > such. Aha, I was thinking of: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900 > Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: html2ps heads-up
On Sun, Apr 23, 2006 at 07:21:48PM -0700, Russ Allbery wrote: > Antony Gelberg <[EMAIL PROTECTED]> writes: > > > Okay, they build on pbuilder and are on m.d.n. > > > I would be grateful for a sponsor to have a look at, and hopefully, to > > upload the packages. > > It looks like there are several changes you made to the package that > aren't documented in debian/changelog. Please document all of your > changes there. > > --- html2ps-1.0b5/html2ps > +++ html2ps-1.0b5/html2ps > @@ -1,4 +1,4 @@ > -#! /usr/bin/perl > +#!/usr/bin/perl > > # This is html2ps version 1.0 beta5, an HTML-to-PostScript converter. > # Copyright (C) 1995-2005 Jan Karrman. > > Not that it matters for Debian, but this change actually reduces > portability. (Both versions are equivalent on Debian, which only uses > modern kernels.) Indeed; 4 byte #! / magic number. Some go bug policy to allow it rather than #!/bin/sh maintscripts. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting close to releasing my first .deb's... What's next?
On Mon, Apr 24, 2006 at 03:01:23PM -0700, Tyler MacDonald wrote: > > I'm working on creating .deb packages for one of my projects, with the > eventual goal of having it included in the debian distribution. > > I've browsed through the policy manual, new maintainers guide, etc, and I've > successfully created a "debian/" directory in my project that allows debuild > to produce the files here: > > http://www.crackerjack.net/mod_bt/experimental_debs/ > > These files aren't signed (yet). I know that's the next step. :-) But then, > what about after that Before I seek a sponsor I'd like to have all the > spit-n-polish done and have these packages as close to "perfect", but > there's a few issues I'm not sure how to deal with: > > 1. lintian complains that I don't have manpages for my executables. > This is because the project is still young and they haven't actually been > written yet. However, the executables aren't the meat of the project, > they're just nice-to-haves and some may disappear/get re-arranged. Is the > lack of manpages for these tools a blocker? I've noticed several packages > that get installed with a generic "no manpage was written for this" manpage, > can I just do that for now? You can write a single manpage that documents all the executables, and modify it as they come and go. dh_undocumented creates the "not yet documented" link, but this is depreciated. > 4. W: libbtt: non-dev-pkg-with-shlib-symlink usr/lib/libbtt.so.0.0.0 > usr/lib/libbtt.so > Should I care? Is it a public shared library? (Do other packages link to it?) If not, you can/should try to move it out of /usr/lib. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed with architectures getting ignored
On Tue, Apr 25, 2006 at 01:37:30PM +1000, Andree Leidenfrost wrote: > Dear mentors, > > My packages with explicit architecture lists don't get built by the > autobuilders. I have checked the Debian Policy, Developer's Reference > and New Mainatiner's Guide and believe that the following in the control > file should be valid and work: > > Architecture: amd64 i386 ia64 > > I upload the i386 and would expect amd64 and ia64 to be built by the > autobuilders. Alas, this is not the case. > > As an example, while p.q.d.o clearly acknowledges that the architectures > are amd64 i386 ia64 for my mindi package: > > http://packages.qa.debian.org/m/mindi.html > > p.d.o has only i386: > > http://packages.debian.org/unstable/utils/mindi > > The interesting thing is that amd64.debian.net has an amd64 version > (just not the latest, probably because of the recent transition?): > > http://amd64.debian.net/debian-amd64/pool/main/m/mindi/ > > I am aware that anything but 'any' for the architecture is frowned upon, > but I am not aware that I need to take any particular steps to get them > auto-built just on the specified architectures. (Just for the record, > the software in question is quite heavily tied to the IA32 architecture > and has recently been extended to IA64 but won't work on any other > architecture right at the moment.) > > It would be great if you could let me know what I am overlooking here > and what I need to do to get the other architectures built by the > autobuilders. Your package is listed in packages-arch-specific: http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak&rev=HEAD Which means that builds are never attempted. See the comments for who to ask for updates. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: spcaview : package review needed
On Tue, Apr 25, 2006 at 10:09:34PM +0200, Le_Vert wrote: > Le mardi 25 avril 2006 ?? 11:20 +0800, Paul Wise a ??crit : > > On Mon, 2006-04-24 at 23:48 +0200, Le_Vert wrote: > > > > > spcaview : package review needed > > > > The convention is RFC: package -- package description > > > > > http://www.le-vert.net/divers/debian-package/spcaview/spcaview_20051212-1.dsc > > I'm using dpatch right now, pretty nice, thanks :-) FYI many people are now starting to use quilt. > > * debian/watch: please add one (read uscan(1) for more info) > > Added. Looks great but is it usefull ? Can I receive an e-mail when my > package is no more up to date ? I don't think there is any .d.o service for this (yet). I have a wishlist bug against devscripts for a local cronjob example that will query DEHS to do this, though. I also have a 30 line "webdiff" script I'm running nightly against a couple pages, which I supposed could be used to do the same thing. > > E: spcaview source: debian-rules-missing-required-target binary-indep > > N: > > N: The debian/rules file for this package does not provide one of the > > N: required targets. All of build, binary, binary-arch, binary-indep, and > > N: clean must be provided, even if they don't do anything for this > > N: package. > > N: > > N: Refer to Policy Manual, section 4.8 for details. > > N: > > W: spcaview; 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. > > Binary-indep rule added. What's about the second one ? My lintian > doesn't give this warning (Etch). unstable does have a newer lintian; I don't know if thats the cause. You still know lintian -I, right? I guess ldd -u might help find the cause. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
