Re: Bug#444514: marked as done (gpredict: FTBFS: error: 'GtkTooltips' undeclared)
On Sat, Oct 13, 2007 at 08:52:39PM +, Debian Bug Tracking System wrote:
> Changes:
> grig (0.7.2-1.1) unstable; urgency=low
> .
>* Non-maintainer upload.
>* Remove “-DGTK_DISABLE_DEPRECATED” from src/Makefile.{am,in} to avoid
> FTBFS
> due to the transition to Gtk 2.12 (Closes: #444514).
>* Move the menu section from “Apps/Hamradio” to “Applications/Amateur
> Radio”
> as part of the menu transition.
>* No longer ignore “make distclean” errors, per lintian.
>* Improve the copyright by adding the GPLv2 blurb, add a link to the exact
> location of the license, and add copyright years.
>* Also modify Makefile.{am,in} not to ship COPYING.
>* Add a “Homepage” field in the control file.
Thanks for your NMU Cyril. However I think the above is excessive for a
simple FTBFS NMU for an otherwise maintained package.
For example the Makefile.{am,in} COPYING change: this is purely
cosmetic. I disagree that your solution is the best; maintaining patches
to upstream sources is a nuisance, while fixing things up afterwards in
debian/rules is easier.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/share?
On Sat, May 30, 1998 at 03:56:42PM -0600, Marcelo E. Magallon wrote: > WindowMaker 0.15.0 has been released, and it contains a number of non > FSSTND complaint locations. > > It uses GNU autconf's pkgdata dir idea. That's means it puts things > in /usr/share/WindowMaker (in fact, I've seen quite a few packages > doing this, which is, IMO, against policy) I thought policy only said you couldn't put *files* in /usr/share, eg /usr/share/WindowMaker.somefile or something, but could (and must) make subdirectories like /usr/share/WindowMaker. Anything that's a conffile or configuration file belongs in /etc though. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/share?
On Mon, Jun 01, 1998 at 09:46:29AM -0600, Marcelo E. Magallon wrote: > Data files are located in /usr/share/WindowMaker, which I personally hate, > because it clutters /usr/share unnecessarelly. I'd be for something like > /usr/share/lib/package, i.e., moving things one level deepper. Well, lib is a misnomer though, and implies something architecture-dependent (which is what /usr/share is trying to avoid). /usr/share will be no more cluttered than /usr/lib, for example. OTOH, we are going to have /usr/share/doc as I understand it, which WILL be another layer. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug #16666 -- assigned to wrong package
On Thu, Jun 11, 1998 at 03:41:27PM -0500, Ted Whalen wrote: > Santiago Vila wrote: > > On Thu, 11 Jun 1998, Ted Whalen wrote: > > > This bug is assigned to my package, wm2, but as far as I can tell, it > > > has nothing to do with my package. Nor can I determine which package > > > it belongs to. Should I close it? > > > > Sometimes, people reassign bugs to other packages. From time to time, > > people make little mistakes when reassigning bugs (we are humans :-). > > Everything is "reversible" as long as the bug is not closed and > > forgotten. If this is the case, the history of the bug will tell you > > which was the package against which the bug was first reported. > > The trouble is that the package this bug was originally assigned to no > longer exists. The maintainer of wmlib-dev at the time was Neil A. > Rubin, who is now maintaining the Afterstep package. I'm not even > sure, from the bug, what version of wmlib-dev it refers to. Looking in the Packages files, it seems wmlib-dev has changed to libwmaker0-dev, so yes it's been incorrectly assigned to wm2, which as I understand it is completely unrelated to WindowMaker. Looking in the Packages file it seems it has been fixed anyway. Hamish (the originally submitter) -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help - deb-make/build
On Thu, Jun 18, 1998 at 05:04:11PM -0400, Jaldhar H. Vyas wrote: > > chown root /data/dupload/heyu/heyu-1.19/debian/tmp/usr/bin/heyu > > cp heyu.1 /data/dupload/heyu/heyu-1.19/debian/tmp/usr/man/man1 > > chmod 755 /data/dupload/heyu/heyu-1.19/debian/tmp/usr/man/man1/heyu.1 > ^ > > don't do this :-) Nor this. All paths must be relative if any one else is to be able to compile the source ever. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Did I get this right? (1st attempt at a package)
On Fri, Jun 19, 1998 at 08:07:02AM -0600, Neale Pickett wrote: > I've packaged the Internet JunkBuster (an anonymizing web proxy with > filtering http://www.junkbuster.com/>) and would appreciate it if > someone took a look at my packaging job. All the related files are at > http://people.lanl.gov/neale/debian/>. For the wary, here's the > output of "dpkg -L ijb": Well, if it works and it passes the lintian checks you should go ahead and upload it I think. The file listing looks ok. > While I'm posting, I can't figure out how to get the "build" program to > make me a diff file--I've modified the source and (I can only assume) I > need to have the diff file reflect my changes to the original code. If your upstream source file is called package_version.orig.tar.gz then build should call dpkg-source to build package_version-debversion.diff.gz package_version-debversion.dsc > Also, since NAS uses port 8000, I specified in the config file to use > port 8080. Should I instead patch the source code to make 8080 the > default? I think the configuration file should be enough, if it's clear that removing it from the configuration file will make it go back to 8000. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New release of iptraf
On Sat, Jun 20, 1998 at 10:31:44PM +0100, James Troup wrote: > Why not just have the file in /usr/doc/iptraf and run it from there in > the postinst? Well, /usr/doc is meant to be moving to /usr/share/doc with FHS, and /usr/share is meant to be for architecture-inspecific data. If I remember correctly, anyway. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New release of iptraf
On Tue, Jun 23, 1998 at 12:21:45PM +0100, James Troup wrote: > Hamish Moffatt <[EMAIL PROTECTED]> writes: > > On Sat, Jun 20, 1998 at 10:31:44PM +0100, James Troup wrote: > > > > > Why not just have the file in /usr/doc/iptraf and run it from > > > there in the postinst? > > > > Well, /usr/doc is meant to be moving to /usr/share/doc with FHS, and > > /usr/share is meant to be for architecture-inspecific data. > > It's a script isn't it? Scripts are rarely architecture-specific. I > agree /usr/doc/ is a less than optimal place for a conversion script > but my main point was that moving stuff around under dpkg's nose was > Evil and should be avoided, other than that, I'm not really too > bothered where it goes and so on. Well, if it's a script couldn't it just be imported into the postinst, at build time if necessary? I assumed it was a binary. If it's a script then /usr[/share]/doc should be fine. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New release of iptraf
On Tue, Jun 23, 1998 at 11:31:02PM +0200, Frederic Peters wrote: > If someone could tell me the /right/ place, please, do it. Marcelo suggested /usr/lib/iptraf, that sounds right to me. hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Definition: "Gold CD"
On Fri, Jun 26, 1998 at 10:45:05AM -0400, Tod Detre wrote: > I know that here in the US you can go to Sam's Club Membership > Warhouse(fairly common place) and buy 10 verbatium CDR blanks for ~$15. That doesn't sound very good. $15 US is $25 Australian, and you can get Kodak Digital Science discs for $2.30-$2.50 here without too much trouble (although many places sell them for $2.80-$3.00). And from what I hear Kodak discs are better than Verbatim. I use Kodak here. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debstd trouble with multi-binary package
On Mon, Jul 06, 1998 at 03:51:47PM -0400, Shaleh wrote: > depricated means that the item is accepted for now(mostly for > compatibility), but is expected to eventually disappear. The use of > libc5 is deprecated, everything is moving onto libc6. We no longer ship > a version of libc4. Hope that helps. Lack of libc4 is due to nobody uploading it, rather than a design decision; it is still deprecated. (I tried to build it but it would not build, problems with the dlltools commands; I did do the conversion to new source format but don't know if it worked because the upstream source doesn't build anyway. Perhaps I will try again for slink.) Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Version specific packages
On Wed, Jul 08, 1998 at 10:38:13AM -0400, Peter S Galbraith wrote:
> So `gri' would always point to the latest installed version, but
> `gri-VERSION' also existed and coexisted with prior versions. This is to
> protect the user from gri version incompatibilities after the user has
> spent a day tweaking a plot to look just right under a given version of
> gri.
It's done with libraries and the kernel already. This tends to produce
package names such as slang0.99.38-0.99.38-6; the package name
is slang0.99.38, the upstream version is 0.99.38, and the debian version
is 6. This allows slang0.99.34 (as in slang0.99.34-0.99.38-6) to coexist.
emacs does this, for example ({x,}emacs{19,20}), so it might be justified.
Ask on debian-policy to be sure.
Hamish
--
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Version specific packages
On Wed, Jul 08, 1998 at 12:34:46PM -0400, Peter S Galbraith wrote: > How about if I: > > - Package gri-2.1.17-1_i386.deb for general use. It would be overriden > by subsequent versions. > > - Package gri2.1.17-2.1.17_1_i386.deb for specific installs. > > If the package gets into Debian, then gri-2.1.17-1_i386.deb would be used > there, but I'd make packages like gri2.1.17-2.1.17_1_i386.deb available for > download at my ftp site (with a mention of that in /usr/doc/gri/). > > I suppose this is really a question for debian-policy? If you will only upload gri (rather than gri2.1.17) into Debian, then there is nothing to discuss -- just do it :-) You are free to make any local packages you want to and distribute them unofficially, although you own both pieces if something breaks. If you did want to upload multiple versions to run together then debian-policy would be appropriate. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#24513: mixed dependency: wm2 depends on libc6 and xlib6
On Mon, Jul 13, 1998 at 12:54:23PM -0500, Ted Whalen wrote: > Odd. Why didn't the bug-fixing wm2_3-3 go into frozen? Should I ask > to have wm2_4-1 moved into frozen now? Or should I rebuild a package > for version 3? Or should I reupload the deb, dsc, and diff for the NMU > wm2_3-3? I'm partial to moving the version from slink, as it /does/ > fix the bug, and there aren't any new features in wm2 version 4. That would be best -- my NMU had the wrong version number (should be wm2_3-2.1, rather than wm2_3-3) anyway. Hamish (oops :-) -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#24513: mixed dependency: wm2 depends on libc6 and xlib6
On Tue, Jul 14, 1998 at 07:16:09PM +0900, Keita Maehara wrote: > > Odd. Why didn't the bug-fixing wm2_3-3 go into frozen? Should I ask > > to have wm2_4-1 moved into frozen now? Or should I rebuild a package > > for version 3? Or should I reupload the deb, dsc, and diff for the NMU > > wm2_3-3? I'm partial to moving the version from slink, as it /does/ > > fix the bug, and there aren't any new features in wm2 version 4. > > changelog of wm2 says: > > > wm2 (3-3) unstable; urgency=low > > which means wm2_3-3 will go into unstable (mapped to slink) only. If > the package should go into frozen (mapped to hamm) as well as > unstable, it should be: > > > wm2 (3-3) frozen unstable; urgency=low What is the date on my upload (3-3)? I believe it was before the freeze. I am probably wrong, but appear not to have a copy of my own diff/dsc. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TCPQuota: postinst, postrm and Depends
On Tue, Aug 11, 1998 at 01:54:24PM +0100, Jules Bean wrote: > In any case, since the libdbd packages depend on the appropriate database > packages, I'm not sure that this is necessary. If package A depends on package B, which depends on package C, then A logically depends on C. However, if A specifically requires something from C, rather than accessing it via B, A *must* declare its dependency on C. Indirect dependencies are not allowed. This was discussed within the last two months. If A does not use part of C directly it should not depend on it, because B could legitimately change its implementation to not require C. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: lintian warnings
On Wed, Aug 26, 1998 at 07:00:16PM -0700, Turbo Fredriksson wrote: > There's a new version of tcpquota on the way, and I'm getting some warnings > from lintian... > > - s n i p - > [ttyp4.papadoc]$ lintian tcpquota_1.6.15-1_all.deb > W: tcpquota: executable-not-elf-or-script usr/lib/tcpquota/create_database.sql > W: tcpquota: setuid-binary usr/bin/tcp_masq_openhost 4755 root/root > W: tcpquota: wrong-name-for-upstream-changelog usr/doc/tcpquota/CHANGES > - s n i p - > > The 'create_database.sql' is a SQL dump, used for creating the database. Why is it executable though? You cannot just run it. > What should the changes file be named if CHANGES is not good enough? changelog[.gz] Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org pgpRw8XF30h0Q.pgp Description: PGP signature
Re: lintian warnings
On Wed, Aug 26, 1998 at 09:43:22PM -0400, Shaleh wrote: > The changelog is expected to be Changelog. Frankly I do not think we > should have to change the file's name just to appease Lintian. You don't have to change them to appease lintian -- you have to change them to meet Debian policy. lintian just checks that your package is policy-compliant. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: NMU: Incompatibility between dpkg-dev and developers-reference
On Thu, Oct 29, 1998 at 03:28:17PM +0100, Martin Schulze wrote: > in the archive. You have to use the same trick if you change the sub > distribution (main,non-free,non-us,contrib) with an upload. Indeed. I could have sworn it used to find it wherever it was though. I have been bitten by this a few times recently. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Maintaining a non-US package?
On Sat, Oct 31, 1998 at 06:48:51PM +1100, Chris Leishman wrote: > The postinst modifies the /etc/exports file to add a 2 lines as follows I don't know about /crypt etc; obviously the FSSTND/FHS doesn't exactly say anything about it. But modifying another package's configuration files (ie /etc/exports) is not allowed. Unless the nfs-server package provides a mechanism for you to add stuff to /etc/exports, you have to let the user do it. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org pgp7MOA3h28vE.pgp Description: PGP signature
libtool
I've just encountered libtool and the dreaded -rpath. How do I fix it so that it doesn't do it? There is a top level ./libtool script, and one of the subdirectories's Makefile.in specifies a -rpath parameter to libtool. When I removed the -rpath and the parameter in the Makefile.in, libtool complained that -rpath wasn't specified. thanks, Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: libtool
On Sat, Nov 21, 1998 at 02:14:36PM +1100, Hamish Moffatt wrote: > I've just encountered libtool and the dreaded -rpath. How do I fix > it so that it doesn't do it? > > There is a top level ./libtool script, and one of the subdirectories's > Makefile.in specifies a -rpath parameter to libtool. When I removed > the -rpath and the parameter in the Makefile.in, libtool complained > that -rpath wasn't specified. Found /usr/doc/lintian/libtool-workarounds.txt, trying it now. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: xwatch installed in correct section?
On Fri, Dec 11, 1998 at 02:42:45PM -0500, Peter S Galbraith wrote: > I received a bug report on xwatch which I can fix easily. > Here's a change to fix the wrong upload section at the same time > (or change contrib/utils to contrib/x11 and just live with it). > BTW, I wanted the package to be in utils because that's where > related or similar packages are (system monitoring). > > So... can anyone answer this for me? Thanks. > > I wrote: > > > Yesterday, I uploaded my first package, xwatch. > > I surprised to see it go in section x11. I just received this: The section in the control file is your suggestion for the section; the Debian archive administrators will override it as necessary. In this case, they changed it to contrib/x11, because it's an X program. (If you think this is bad, you might want to discuss it on debian-policy.) Your control file entry will not matter from now on, although it would be best if you changed it to say contrib/x11, because that's what people see if they do "dpkg-deb -I filename.deb" on your package. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: DESTDIR in a native distro. How ?
On Tue, Dec 15, 1998 at 03:18:52PM +0900, Ionutz Borcoman wrote: > How do I set the DESTDIR in my Makefile ? If a non-debian user will > download the package, he/she will want to install my program in > /usr/local. If he/she is a debian user, the deb package should be > created from the tar.gz and files moved to completely different places, > like /etc, /usr/X11R6 > > So which is the best way for solving this ? Perhaps you could do something like this in your makefile: PREFIX=/usr/local install: install mybinary $(PREFIX)/bin install mymanualpage.1 $(PREFIX)/man/man1 Then in your debian/rules file, you can do "make install PREFIX=/usr" Or more like "make install PREFIX=debian/tmp/usr" Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: DESTDIR in a native distro. How ?
On Tue, Dec 15, 1998 at 05:40:40PM +0900, Ionutz Borcoman wrote: > # Add here commands to compile the package. > $(MAKE) MY_DEBIAN_SYSTEM=1 > This way I get as much freedom as I want: > a. non-Debian users just give a make from the top dir. > b. Debian users give just dpkg-buildpackage. It looks ok. I cannot see any advantage over my example but that is up to you. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Trouble Building with Original Sources
On Sat, Dec 19, 1998 at 05:08:50PM -0600, Paul Serice wrote: > In the upper directory are the following files: > > crafty-16.2/crafty_16.2-1_i386.changes > crafty-16.2.orig.tar.gz crafty_16.2-1_i386.deb > crafty_16.2-1.dsc crafty_16.2-1_i386.upload > crafty_16.2-1.tar.gz > > The "crafty-16.2.orig.tar.gz" (with a hyphen) file existed before I ran > "build." I might have misread the "The New-Maintainer's Debian dpkg-source will not use the hyphenated one. Since the underscored one did not exist, dpkg-source built a new one, containing the debian directory as well. > When I try to build using "crafty_16.2.orig.tar.gz" (with an underscore > instead), I get the following error message. > > dpkg-source: building crafty using existing crafty_16.2.orig.tar.gz > dpkg-source: error: crafty_16.2.orig.tar.gz extracted into >1 directory > > After this error has stopped "build", a directory called > "crafty_16.2.orig.tar.gz.tmp-nest" exists in the upper directory with > the original source extracted into it. It thinks that the .orig.tar.gz has multiple top level directories, and it can't cope. I don't think there is any solution, except to unpack it, clean it up and repack it. Pristine source is preferred but sometimes changes are unavoidable. > Another thing that might be of interest is that the original tarball > unpacks to the current directory instead of creating its own > subdirectory. Perhaps that's the problem, but I think that is normally ok. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: No upstream version, et al
On Tue, Dec 29, 1998 at 01:14:08PM +0800, Anthony Wong wrote: > Q2: Currently I'm packaging a program that lets people install Newton > programs to their PDA from Linux. As this program requires access > permission to the serial ports, only root can use the program in > normal condition. But I also want the program can be used by common > users, so what should I do? Just inform people to add users to the > group 'dialout' in postinst? Or suid/sgid the program? Anyone in group dialout should be able to access the serial ports, so that seems like the best suggestion to me. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: question on interaction between net-base and replacement dae
On Thu, Jan 07, 1999 at 12:47:45PM +0100, Florian Hinzmann wrote: > On 06-Jan-99 Shaleh wrote: > > will package nicely because it is well written. My question is: how do I > > cope > > w/ the existing identd? I expect that users installing this would prefer it > > over identd. Is simply placing a call to update-inetd enough? > > I didn't investigate further, but here is the postinst of > wu-ftpd. It disables standard in.ftpd and adds his own > line to /etc/inetd.conf. Maybe you can take this example > as a start point and find some documentation about the > right and official way to do this. ;) It does what update-inetd does. Actually, since inetd.conf belongs to netbase, wu-ftp should call the provided modify script (update-inetd). However, since inetd.conf is not a conffile, I'm not sure this is technically a bug. Can anyone confirm? Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Some new largish packages: please comment
On Fri, Jan 15, 1999 at 10:06:28AM -0600, Marcelo E. Magallon wrote: > PS: Has somebody talked with the XEphem author to make it DFSG-free? What's > wrong with us in natural sciences? Why are we so infected by this "noone > will steal my work" metality? Why do we tend to write such stupid You think that's bad, look at ham radio software. It's not bad for Linux, but all the Windows stuff costs megabucks. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: /usr/X11R6/share?
On Sun, Jan 24, 1999 at 02:05:34PM +, Jules Bean wrote: > None of the arguments for keep /usr/X11R6 apply to /usr/share. None of the arguments for keeping /usr/X11R6 apply at all ;-) Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Lintian error: executable-in-usr-doc
On Sat, Jan 16, 1999 at 05:12:01PM -0800, Joey Hess wrote: > Peter S Galbraith wrote: > > So, can I let these example scripts be executable, or not? > > Examples should go in /usr/doc/examples/ . Lintian will not > complain about executables in that directory. It still complains about csh-considered-harmful, though. Personally, I think csh-considered-harmful is a purely personal decision and has no place in policy and therefore lintian. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Which targets are mandatory in debian/rules?
On Sun, Feb 07, 1999 at 10:43:47PM +, James Troup wrote: > No, the build target should be present and should do something, > i.e. build the package. Even if it only depends on the two other > build targets, it should still build stuff. No, section 3.2.1 of the packaging manual says that it is acceptable for the build target to do nothing. For some packages, notably ones where the same source tree is compiled in different ways to produce two binary packages, the build target does not make much sense. For these packages it is good enough to provide two (or more) targets (build-a and build-b or whatever) for each of the ways of building the package, and a build target that does nothing. The binary target will have to build the package in each of the possible ways and make the binary package out of each. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: dependencies problem
On Wed, Feb 10, 1999 at 12:01:56AM +0100, Josip Rodin wrote: > On Tue, Feb 09, 1999 at 02:39:53PM -0800, Joey Hess wrote: > > Yes, this is a common problem if you build a package with both a shared > > library and binaries in it. It's pretty harmless, but ugly, to leave it how > > it is. Your other choices are: It can be harmful. On the next build of the package, dpkg-shlibdeps gets the .shlib file from the installed version, and not the newly compiled version. If they differ, the dependencies of your new binaries package is incorrect. To fix this, I told dpkg-shlibdeps to use the new .shlib file as the local shlib file. The manuals say that the local file should only be used temporarily but there doesn't seem to be another way. I use: dh_shlibdeps -u -Ldebian/libgeda2/DEBIAN/shlibs Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Which targets are mandatory in debian/rules?
On Sun, Feb 14, 1999 at 12:12:26PM +, Jules Bean wrote: > And conversely, of course there is at least one technical reason to prefer > doing all the build in the 'build' target - the 'binary' target may be run > as root (more likely fakeroot, I admit, but possibly actual root). > > It seems to me that policy should be changed, here. This may bmean the build target ends up doing part of the binary target's work though. For example I have the packages sattrack and sattrack-x11, which are built from the same source. I hacked the Makefile so I can enable or disable the X support from debian/rules, but the whole thing needs to be cleaned out and rebuilt for whichever version. Hence I have a dummy `build' target. It already does weird stuff during building with objects in other directories... Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: splitting package
On Mon, Mar 15, 1999 at 09:48:21AM -0500, Randolph Chung wrote: > Another packaging question :) > > an upstream package contains both server and client programs. I'd like to > split them up into a server package and a client package. how do you do this > given one upstream source file? The client package is really just one file. > The reason to split it off is that the server package has many dependencies > that clients do not need/want. I think there may be some examples in /usr/doc/debhelper. You need to add a second binary package entry to debian/control, and have the debian/rules binary target make two subdirectories of debian/, one for each package, etc. debhelper makes it easy. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: /usr/bin or /usr/bin/X11
On Sun, Mar 21, 1999 at 10:12:05PM +0100, Marcus Brinkmann wrote: > The reason is following: > > * You don't need to do changes if later mutliple frontends are available. > * /usr/X11R6 is reserved for X server stuff, like servers, window-managers, > and things that come with X distribution. It should not be used for X > applications or clients. > > Unfortunately, this is not handled in a common and consistent way, but quite > a lot people prefer /usr/bin/ even for the X server stuff, too. I don't want > to argue about it, but it really makes sense for X applications which don't > come with the X distribution to stay in /usr/bin. I'm sure that we've discussed this before on debian-policy, and that policy currently says all X applications should install in /usr/X11R6/. I think this is very wrong, but that's what policy says. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: A package depends on a library built from the same source... how?
On Sat, Apr 10, 1999 at 09:33:04PM -0600, Marcelo E. Magallon wrote: > I've been bitten by this multiple times, and everytime I think > I've got it right, I find myself fixing it again. Package foo and > package libbar2 both come from source package foo. foo depends on > libbar2... how do I get it right the first time? Is there any > example _known_ to work. Basically the problem I have is with the > shlibs.local file, it looks like it's not read at all. It reads: > > libbar 2 libbar2 > > I use: > >LD_LIBRARY_PATH=`pwd`/debian/tmp/libbar2/usr/lib dpkg-shlibdeps > > but I can't get it to pick the right dependency of foo on libbar2 > unless I install libbar2... dpkg-shlibdeps looks in /var/lib/dpkg/info/*.shlibs; if the library package has just been built from the same upstream source, it will either see the old version, or nothing at all. Here's what I've been using: dh_makeshlibs -V dh_shlibdeps -u -Ldebian/libgeda2/DEBIAN/shlibs libgeda2 is the library package, built from the same source as geda, which is the general binaries package. The doco for dpkg-shlibdeps says that you should only use -L as a temporary measure, but since there doesn't seem to be another way .. You might still need the LD_LIBRARY_PATH if the library depends on any other non-default libraries. Hamish -- Hamish Moffatt VK3TYD. CCs of replies from mailing lists are welcome.
Re: version numbers
On Wed, May 12, 1999 at 08:19:18AM -0500, John Hasler wrote: > Mitch writes: > > Digit placement, (such as that used in 1.02) should not be used in a > > versioning scheme, because it places predetermined limits on the number > > of revisions that can happen within a given level. > > Not if a decimal point is inferred if and only if there is a leading zero. > > > Instead, dots (.) should be used to separate revision levels, and leading > > zeros within a level should be ignored within a numerical field. > > That will lead to confusion. The upstream maintainer put that zero there > for a reason (though maybe not a good one). I wouldn't do it myself, but I > have no trouble understanding his intent. > > In any case, both dpkg and the upstream author are beyond my control. > Do I have any recourse other than an epoch? Could you call it 1.10, rather than 1.1? Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Depends from any newsserver
On Fri, May 28, 1999 at 01:41:50PM +0100, Mark Brown wrote: > On Fri, May 28, 1999 at 01:14:05PM +0100, Matthias Kabel wrote: > > > How it is possible to handle this in the depends field, if there is > > no local newsserver newsflash is useless but it does not matter wich > > newsserver is running. > > There's the virtual package news-transport-system, but that may include > slightly more packages than you want - ifgate provides it, but IIRC > doesn't provide a news server. Also, cnews does not have an NNTP server built in; the nntp package provides that. An nntp-server virtual package could be worthwhile, perhaps. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome. pgpjtTbRAo0V6.pgp Description: PGP signature
Re: Library packages, libtool and automake.
On Mon, Jun 07, 1999 at 12:09:01PM -0600, James Bielman wrote: > Yeah, this is what dh_make generated: > > ./configure --prefix=/usr > -mkdir shared static > # > # First build the shared library > cd shared ; \ > $(MAKE) -f ../Makefile VPATH=".." srcdir=".." \ > CFLAGS="-O2 -fPIC -pipe" ; \ > gcc -shared -Wl,-soname,$(package).so.$(version_major) -o > $(package).so.$(version) `ls *.o` I used dh_make on a library once and it generated this. Then, I started over and did it by hand. I don't know why we can't trust the upstream Makefile to build the shared library, generally speaking. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Becoming a new developper
On Wed, Jun 23, 1999 at 01:31:41AM +0100, Julian Gilbey wrote: > wait ;) Seriously, though, it is quite reasonable to learn on the > job; it's what most of us do. Imagine a new maintainer test: Using only standard unix tools (no dh_make, debstd, or debhelper), package X11. You have 1 hour. :-) Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Becoming a new developper
On Wed, Jun 23, 1999 at 11:30:02AM +0200, Peter Makholm wrote: > Hamish Moffatt <[EMAIL PROTECTED]> writes: > > > Using only standard unix tools (no dh_make, debstd, or debhelper), > > package X11. You have 1 hour. > > As you please! > > Hmmm, is it ok if the build isn't finished after 1 hour? Yes, although good luck getting the debian/binary target right without a built copy :-) > Is vi a standard unix tool or should I use cat, tail and head? vi will be acceptable. Hamish :-) -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Autoconf question
On Sun, Jun 27, 1999 at 03:44:35PM -0400, Decklin Foster wrote:
> [EMAIL PROTECTED]@
> [EMAIL PROTECTED]@
> [EMAIL PROTECTED]@
> [EMAIL PROTECTED]@
> [EMAIL PROTECTED]@/share/icons
>
> and these variables are referred to elsewhere. My problem is that when
> the Makefile is generated, it comes out like:
>
> # Generated automatically from Makefile.in by configure.
> #
> prefix=/usr
> exec_prefix=${prefix}
> bindir=${exec_prefix}/bin
> mandir=${prefix}/man
> icondir=/usr/share/icons
Perhaps you could modifying the Makefile.in and other files to add a
@icondir@ much like @[EMAIL PROTECTED] Clearly, @bindir@ (etc) are being
filled in at runtime (of make) while icondir isn't.
However I suspect you should not be doing "make prefix=...";
you should make without overriding prefix, and just override it
during "make install". Or override DESTDIR during "make install",
if possible.
prefix can affect the program at runtime too. You don't want to hardcode
the temporary location into any executables.
Hamish
--
Hamish Moffatt VK3SB (ex-VK3TYD).
CCs of replies from mailing lists are welcome.
Re: Autoconf question
On Mon, Jun 28, 1999 at 08:18:26AM -0400, Decklin Foster wrote:
> Hamish Moffatt writes:
>
> > However I suspect you should not be doing "make prefix=...";
> > you should make without overriding prefix, and just override it
> > during "make install".
>
> This is what I'm doing, actually; after running 'make' normally to
> build the package, I run (from debian/rules, i haven't modifed it yet)
>
> # Add here commands to install the package into debian/tmp.
> $(MAKE) install prefix=`pwd`/debian/tmp/usr
>
> > prefix can affect the program at runtime too. You don't want to hardcode
> > the temporary location into any executables.
>
> I don't think this will cause problems with the binary, since $prefix
> is not changed during the first run of make, I get
> -DICONDIR=\"/usr/share/icons\" and so on when calling gcc. the
That should be fine.
> 'install' rule just includes making directories, copying files, etc.
> Am I correct? for now, I'll patch Makefile.in to use '${prefix}'
> instead of '@prefix@'.
That sounds like the correct fix.
Hamish
--
Hamish Moffatt VK3SB (ex-VK3TYD).
CCs of replies from mailing lists are welcome.
Re: rc.boot
On Mon, Jun 28, 1999 at 09:42:08PM -0500, John Hasler wrote: > Julian Gilbey writes: > > /etc/rc.boot is deprecated. > > >From debian-policy (2.5.1.0, current according to apt): > > 3.3.4. Boot-time initialization > --- > > There is another directory, `/etc/rc.boot', which contains scripts > which are run once per machine boot. This facility is provided for > initialization of hardware devices, cleaning up of leftover files, and > so forth. rc.boot was replaced by rcS.d. Julian was almost right; you should put the script in /etc/init.d, but not link it with update-rc.d like every other, only to rcS.d. Quite a few packages already do this so it should not be too hard to find examples. I did it in cnews for example (moved from rc.boot). Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Request for assistance: netbase manpages
On Mon, Jul 05, 1999 at 08:23:39PM +1000, Anthony Towns wrote: > What I was wondering was whether anyone here would like to write some > manpages for some of the programs in netbase. In particular manpages for: > > * ipautofw(8) (Bug#31379) > * ipmaddr(8) (Bug#33019) > * iptunnel(8) > * tracepath(8) > > * /etc/gateways(5) (Bug#23703) (documented somewhat in routed(8) > from netstd) > * /etc/hosts(5) (Bug#37832) networks(5) as well? Unfortunately I can't figure /etc/networks out. I can't work out how to specify the netmask (is it possible?). I have two networks, 203.14.18.0/25 and 203.14.18.128/25; the .0 network name works fine of course, but the .128 one does not. localnet203.63.216.16 hamishnet 203.14.18.0 peternet 203.14.18.128 Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome. pgp4ChdDgg6KR.pgp Description: PGP signature
Re: Request for assistance: netbase manpages
On Tue, Jul 06, 1999 at 12:27:12PM +1000, Hamish Moffatt wrote: > Unfortunately I can't figure /etc/networks out. I can't work out how > to specify the netmask (is it possible?). I have two networks, The impression I get from networks(5) on FreeBSD and Solaris is that it can't be done. The /etc/networks example on FreeBSD implies it can. Still waiting to see what happens on Linux. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome. pgpocEtaWFgxe.pgp Description: PGP signature
Re: Multiple binaries => multiple packages ?
On Sun, Jul 25, 1999 at 05:52:42PM -0400, Gopal Narayanan wrote: > i386-pc-linux-gnu-gnulibc2.1 : for libc2.1 > i386-pc-linux-gnulibc1 : for libc2.0 > i386-pc-linux-gnulibc1-static: static 2.0 > i686-pc-linux-gnu-gnulibc2.1 : 686-optimized for 2.1 > i686-pc-linux-gnulibc1-static: 686-optimized static for 2.0 > > Now, I did make an install package that would install the binaries > from the tarball that is put either in /tmp or $TMPDIR. My question is > - should I actually make 5 separate packages with different > dependencies or make one package with instructions to download the > correct tarball for their system. With the latter option, obviously if > someone with a slink system were to download the gnulibc2.1 version, > the program won't run. Based on this, it seems to me that I should > make 5 separate wrapper packages, and force dependencies > accordingly. Am I right? Well, potato is GLIBC 2.1. You don't really need to support anything else, so only two packages (686-optimised and non-optimised). Note that the gnulibc1 is NOT for libc2.0 as you have above -- it is for libc5. I think they should provide a glibc 2.0 (libc6.0) binary as well, but they don't. My slink system is running the libc5 binary because I don't want to upgrade to potato yet. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Multiple binaries => multiple packages ?
On Mon, Jul 26, 1999 at 09:51:51PM -0400, Gopal Narayanan wrote: > I haven't upgraded to potato either. Is there a machine that is > running potato that developers could use to test glibc 2.1 related > packages? I'm not sure. I thought master would be running potato (since Branden uses it to build X, or used to) but it doesn't seem to be. Perhaps pandora (might be slow to access from the USA though)? Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: strange multiple packages problem + question
On Tue, Jul 27, 1999 at 08:59:34PM -0500, Ardo van Rangelrooij wrote: > Source: libsgmls-perl > Section: text > Priority: optional > Maintainer: Ardo van Rangelrooij <[EMAIL PROTECTED]> > Standards-Version: 2.5.1.0 > ... > dh_gencontrol > dpkg-control: error: source package has two conflicting values - > libsgmls-perl and sgmlspl > dh_gencontrol: command returned error code > make: *** [binary-indep] Error 1 The source package name is libsgmls-perl; what is the package name at the top of the changelog? If they differ, you will get this error. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Bladeenc
On Sun, Aug 01, 1999 at 10:06:00PM -0300, Daniel H. Perez wrote: > * [990801 21:47] Daniel H. Perez ([EMAIL PROTECTED]) decia: > > Hi > > Is anybody working on Bladeenc? > Oops > yes someone else is working on bladeenc Can somebody please set up a cronjob to post ITPs for bladeenc? Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Bladeenc
On Tue, Aug 03, 1999 at 12:36:52AM -0500, Jeff Bachtel wrote: > Done. Any others I should set up while I'm at it? > > > Can somebody please set up a cronjob to post ITPs for bladeenc? Not off the top of my head! bladeenc in particular seems to come up every fortnight or so. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: multiple binary packages (again)
On Mon, Aug 16, 1999 at 06:11:59PM -0400, James Mastros wrote: > On Sun, Aug 15, 1999 at 01:55:33AM +0200, Domenico Andreoli wrote: > > On Sat, 14 Aug 1999, Raphael Hertzog wrote: > > > Apart from that, isn't there a non-US problem with the SSL support ? Take > > > care not to install in main something that could not be exported by US > > > residents. > > right, i have to break source in two anyway. i can't put source in main > > distribution that require some non-US packages, can i? > No, but you can put source in non-US/main that builds both main and > non-US/main binary packages. Can you? Isn't main supposed to be free standing? Clearly the source can't go in main, so the binaries can't either. xpdf and xpdf-i have the same .orig.tar.gz. Mind you, I wouldn't build them from the same source package even if I could; too hard to apply the -i patches during build. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: BTS questions
On Wed, Sep 01, 1999 at 11:17:04PM +, David Coe wrote: > 1) http://www.debian.org/Bugs/Developer says: > > A developer who receives a bug from the tracking > system, or sees it on debian-bugs-dist, and takes > responsibility for it should hit Reply in their > favourite mailreader, and then edit the To field > to say [EMAIL PROTECTED] instead of > [EMAIL PROTECTED] (nnn-close is provided as an alias for > nnn-done). > > Taken literally, that means I should close bug reports as soon as I > acknowledge having received them; but that seems wrong to me. Am I > misinterpreting the above? I also noticed that the ``Unanswered When it says `takes responsibility for it', it means fix (rather than acknowledge and agree to fix in the future). It's slightly awkward wording. You should not close the bug report until you have uploaded the package AND you have received email from dinstall notifying you that it has been installed in the archive. > Should I really close (`take up') each bug as soon as I accept > responsibility for (eventually) fixing it? No. It is a good idea (IMHO) to send a short note back to the submitter once you recieve the initial report just to acknowledge that you received it -- I always send a thanks if nothing else. But the BTS doesn't record this as being anything special. > So how small is "small"? Of course I will make note of the > availability of the example file, if it's too large to include in the > BTS. Don't know sorry. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Which section for wmMatrix?
On Sat, Sep 11, 1999 at 11:49:56PM +0200, Michael-John Turner wrote: > I've packaged wmMatrix, a WindowMaker dock app that displays The Matrix > (from the film of the same name). One thing I'm a little unsure about > is where to put it. It naturally goes in x11 as it is an X app, but > one could also argue for graphics as it is eye candy (like Cthugha, > which is in graphics). I see that wmmand, which displays the Mandelbrot > set in a dock app, is in games but xfractint is in graphics. Aaargh! > > Anyone got a definitive answer on this one? The Section in the control file is really just a suggestion to the archive maintainers -- the actual section for the package is determined by the override file on master, rather than the section in your package. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Need help with shlibs.local
On Sun, Sep 12, 1999 at 05:04:47PM -0400, Adam Di Carlo wrote: > "Marcelo E. Magallon" <[EMAIL PROTECTED]> writes: > > > this is driving me nuts and I want to fix it once and for > > all. wmaker (src) builds several binary packages, among them, > > libwraster1 and libwraster1-dev. The wmaker packages (wmaker, > > wmaker-gnome and wmaker-kde) all should depends on libwraster1, with > > proper versioning if necessary. Sometimes that means it should > > depend on the libwraster1 version that is being built, not the one > > installed on the system. Now, my problem is, everytime I think I got > > this right, I realize it isn't the case. Do you know of any source > > package in this situation that's got this right? > > jade. Check that out. > > It's more complex than it really should be to do this properly Oh well. I used to use something like dpkg-shlibdeps -Ldebian/tmp-library/DEBIAN/shlibs (or whatever the exact filename is). This worked rather well, although the documentation says that -L is for temporary use only. From memory when I asked about this on this list a few months back, this seemed to be the best solution. Upstream has since separated the library and binary sources, so I don't have an example on hand. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: new maintainer in Australia
On Thu, Sep 23, 1999 at 03:08:57AM +0800, Paul Harris wrote: > is the waiting list really bad? i live in Perth, Australia, which is about > as far from anywhere as you can get... what should i use for scannable id? > passport? is there _ANY_ developer in Western Australia? am I the first? > (wow that would be cool). You're welcome to drop over to Melbourne and get your key signed, there's quite a few of us here :-) Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: How to modify /etc/services?
On Sun, Sep 26, 1999 at 05:18:31PM +0200, Radovan Garabik wrote: > On Sat, Sep 25, 1999 at 04:29:26PM -0700, Seth R Arnold wrote: > > If I am not mistaken, since it is a conffile for netstd, other packages are > > forbidden from doing anything with it? I think the proper response is: get > > Maintainer: Anthony Towns <[EMAIL PROTECTED]> to include your service in > > /etc/services, then your package depends on a specific version of netstd. > > > > [how did I do? :] > > > > As for an actual method, probably making a tmp file of what you would like > > to add to it, copying the existing one someplace, then catting the two of > > them back together to /etc/services. > > you can use > update-inetd --file /etc/services --add 'name port/tcp # comment' > > however, be aware that /etc/services can be overwritten when you upgrade > netstd. update-inetd allows you to do this but policy does not! Look in /var/lib/dpkg/info/netbase.conffiles -- /etc/services is a conffile of netbase and *no package* may modify it from their maintainer scripts (and that includes netbase itself). update-inetd actually allows you to modify any file you like. That doesn't mean you should though. thanks Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: protocol: closing bugs
On Fri, Oct 08, 1999 at 01:23:22PM -0700, Sean 'Shaleh' Perry wrote: > That said, yes, I would keep them open until potato is released. I thought protocol was to close bugs fixed in the latest upload, even though they are not fixed in stable? I suspect the BTS would have many more entries if we couldn't close bug reports until a new release is made. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: protocol: closing bugs
On Tue, Oct 12, 1999 at 12:51:34PM +1000, Brian May wrote: > On Mon, Oct 11, 1999 at 05:44:33PM +1000, Hamish Moffatt wrote: > > On Fri, Oct 08, 1999 at 01:23:22PM -0700, Sean 'Shaleh' Perry wrote: > > > That said, yes, I would keep them open until potato is released. > > > > I thought protocol was to close bugs fixed in the latest upload, > > even though they are not fixed in stable? I suspect the BTS > > would have many more entries if we couldn't close bug reports > > until a new release is made. > > Please see my wishlist bug #46434 against bugs.debian.org. This seems a reasonable proposal. I haven't had much trouble with bug reports against slink versions here, but I imagine for bigger packages it could be a nightmare. Leaving them open without special information about versions would make a maintainer's bug list unmanagable though. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: arch-specific binary-only rebuild
On Tue, Oct 19, 1999 at 12:17:53PM -0400, Peter S Galbraith wrote: > The changelog will not appear in all the binary packages produced > since I won't be uploading a new diff.gz to propagate a new > changelog. If it's a new binary version, it should have source to go with it. And you can't reupload the binary package without a new version number. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: package needs rgb.txt
On Tue, Oct 19, 1999 at 10:08:14AM -0700, Seth R Arnold wrote: > Peter, as a user, I would be upset if a package included its own version of > rgb.txt... but then you do have to worry about those systems that want > clients but no server.. I say depend. What's unusual about that? I only routinely run an X server on one box here, but it's useful to run X programs on some others around the place at times. Those machines have no need for an X server. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: arch-specific binary-only rebuild
On Thu, Oct 21, 1999 at 10:31:06AM -0400, Peter S Galbraith wrote: > Hamish Moffatt wrote: > > > On Tue, Oct 19, 1999 at 12:17:53PM -0400, Peter S Galbraith wrote: > > > The changelog will not appear in all the binary packages produced > > > since I won't be uploading a new diff.gz to propagate a new > > > changelog. > > > > If it's a new binary version, it should have source to go with it. > > And you can't reupload the binary package without a new version number. > > No, it's a recompile-only of the source package. > > For instance, ``foo_1.3-1'' would be numbered ``foo_1.3-1.0.1''. > No new .diff.gz is uploaded. But then 1.0.1 is a new version, and should have .dsc and .diff.gz to go with it. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: arch-specific binary-only rebuild
On Tue, Oct 26, 1999 at 05:29:27PM +0200, Santiago Vila wrote: > Oh. Come on. I think Peter is allowed to do a binary-only NMU of his > own package, like everybody else :-) > > This numbering scheme and its purpose is documented in the Developer's > Reference. Being the rationale the same (i.e. to not force a recompile on > every arch), I don't see a good reason why others are allowed to do this > when doing a binary-only NMU and Peter should not be. Hmm, OK I forgot that policy allowed this. Can't say I like it much though. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: Policy 3.0.0 and /usr/X11R6/man ?
On Fri, Oct 29, 1999 at 12:30:19PM -0400, Peter S Galbraith wrote: > Roland Rosenfeld wrote: > > > The problem here seems to be, that some people want to place all X > > dependent programs under /usr/X11R6 while others mean that only the > > X11 core should be under /usr/X11R6 > > BTW, I decide to place xwatch in /usr/X11R6 beacuse it has an > app-defaults file. It would be strange to put a bianry in > /usr/bin and yet have the file /usr/X11R6/lib/X11/app-defaults/XWatch > wouldn't it? > > Perhaps I was wrong. It's the only package I have with stuff > under /usr/X11R6/. It's up to you -- I use /usr/bin for everything. /usr/X11R6 should be disbanded, imho. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: Confusion about package naming -- please help!
On Mon, Dec 13, 1999 at 03:23:28AM +, Chris Rutter wrote: > I'm slightly mystified, in my newsbieship, as to what this means. > > The source archive is `mLib-1.6.1.tar.gz', and it unpacks into a directory > called `mLib-1.6.1'. I suppose `dpkg-source' is supposed to rename that > to `mlib-1.6.1' or something when the source archive is extracted. > > So -- what should my source directory be called? What should my packages > be called? What should the `Package:' field contain? As Antti-Juhani says, use lowercase. It doesn't matter what directory the .orig.tar.gz unpacks to; dpkg-source will cope. Don't extract it, rename it, and recreate the .orig.tar.gz just to fix the directory name; it's better to use "pristine source" -- meaning the exact .tar.gz provided by the upstream author (renamed of course to .orig.tar.gz). Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: Confusion about package naming -- please help!
On Mon, Dec 13, 1999 at 02:13:39PM +, Chris Rutter wrote: > On Mon, 13 Dec 1999, Hamish Moffatt wrote: > > > As Antti-Juhani says, use lowercase. It doesn't matter what directory > > the .orig.tar.gz unpacks to; dpkg-source will cope. Don't extract it, > > rename it, and recreate the .orig.tar.gz just to fix the directory name; > > it's better to use "pristine source" -- meaning the exact .tar.gz > > provided by the upstream author (renamed of course to .orig.tar.gz). > > I'm probably being thick, but I don't see how to do this -- if I re- > created the .orig.tar.gz file with lowercase names instead, then I > wouldn't be using the pristine source, would I? Exactly. That's what I mean -- don't recreate it :-) > Is there some incantation to dpkg-buildpackage to tell it what the > name of the original source directory is (i.e. not `mlib-1.6.1.orig' > but `mLib-1.6.1.orig')? dpkg-source (called by dpkg-buildpackage) will work it out for itself. Don't worry about it. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: Confusion about package naming -- please help!
On Tue, Dec 14, 1999 at 01:25:09AM +, Peter Maydell wrote: > What should you do if the upstream tarball includes ick like FIFOs, > random junk files and binaries? I tried just using the true upstream > tarball but dpkg-buildpackage took exception both to the FIFO in the > upstream source and to the fact that some of the changes between the > debian-patched tree and the upstream were removal of files... > (The Debian Packaging Manual specifically says that you can only make > certain changes in the 'Debianisation diff' which seems to me to imply > that you have to modify the orig.tar.gz in these cases.) > > [This was just for a deb I was building for my own private use, so I didn't > greatly care -- I just created a cleaned-up orig.tar.gz. But I'm curious > about what the Right Thing would have been.] I think repacking the .tar.gz is quite reasonable in this case. You have no other solution really. And be sure to flame^H^H^H^H^H politely suggest to the upstream author that they not ship fifos in the .tar.gz. Hamish -- Hamish Moffatt Mobile: +61 412 011 176 [EMAIL PROTECTED] Rising Software Australia Pty. Ltd.http://www.risingsoftware.com/ Phone: +61 3 9894 4788Fax: +61 3 9894 3362USA: 1 888 667 7839
Re: how orig should orig.tar.gz be?
On Mon, Jan 03, 2000 at 12:11:59PM +0100, Christian T. Steigies wrote: > stuff, etc). I am speaking about "normal" packages. I am allways using the > upstream source, renaming it to orig.tar.gz and the diffs are created > relative to this source. Now for reference I looked into other packages for > reference and noted that some people repackage the upstream source, where it > is not necessary. Easily notable when you look at the owner and group of the > orig source. > > Is this ok, prefered or not prefered? I allways understood the docs (and > policy and whatever, which I obviously did not read in every detail, so > please do not answer "debian-policy" or "debian-packaging manual") that the > original upstream source should be used whenever possible. I know that ie > xfree does it differently, but this is probably since xfree contains several > upstream source files and uses a very clever concept of applying patches. > But it seems every source package I am looking at now is repacked, are all > my packages wrong? > > Please help us resolve this dispute, I'd really like to know what is correct. As original as possible is preferred. It is necessary to repack the original source if it contains binaries, pipes, or other things which upset diff/dpkg-source. Adam Heath has a new source packaging system where the .orig.tar.gz contains the real upstream source (unchanged) plus a series of upstream patches. The rules files unpacks the source, applies the patches, etc. This seems a reasonable exception to the rule, since the real pristine source IS in there. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: how orig should orig.tar.gz be?
On Mon, Jan 03, 2000 at 01:10:31PM +0100, Bart Schuller wrote: > cp /somewhere/foo-2.23.tar.gz foo-2.23.orig.tar.gz Should be foo_2.23.orig.tar.gz. Cheers Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: ITP: libsdlmixer1.0
On Wed, Jan 19, 2000 at 11:29:44AM +0100, Christian T. Steigies wrote: > You mean http://www.debian.org/~cts/sdlmixer1.0/ > libsdl-mixer-dev_1.0.3-1_i386.deb > libsdl-mixer1.0_1.0.3-1_i386.deb Yep, that would be fine. > instead of http://www.debian.org/~cts/sdlmixer/ > libsdl-mixer1.0-dev_1.0.3-1_i386.deb > libsdl-mixer1.0_1.0.3-1_i386.deb > ? > > As I understand it, this implies if ever a new version (1.1, 1.2) should > come out, it would no longer be possible to build new packages with the 1.0 > libraries only with the new one? This is desired? AFAIK gtk uses a different > approach (even SDL, where SDL mixer is based uppon). Yes, that's desired. There's rarely a good reason to build with an old version. Usually, all packages using the library are recompiled and the old one removed (-dev and library itself). If you want to continue to support it, then make a seperate dev package later. The advantage of not putting the version in the -dev name is automatic upgrades to the latest development environment for developers, as Michael said. > The problem I see is similar to what we are having with ncurses5 right now. > ncruses4-dev vanished, but some maintainers built packages with it. Can not > be recompiled for other arches now... and its set in the Build-Depends, so > this is a problem for porters... but then, the bug reports should urge the > maintainers to switch :-) ncurses4's dev stuff could reappear in a new -dev if it's really needed. It's better to migrate the stuff to the new version. Cheers Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: Binary Changes Drill
On Fri, Jan 21, 2000 at 10:32:16AM +0100, Martin Bialasinski wrote: > gifs are binary files, and diff can't cope with it. > I had the same thing with a png image. > > encode the image with uuencode Ugh. I guess it would work though. The other alternative is non-pristine source. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: patching an original tarball
On Tue, Jan 25, 2000 at 04:48:57PM -0800, Seth R Arnold wrote: > My gut feeling is, after patching the upstream tarball with an upstream > patch, it is still prinstine -- but that is my gut feeling. No, that wouldn't be pristine -- it's not as it was downloaded from the upstream author, which is the whole point (IMHO). Admittedly the upstream patch doesn't belong in the Debian .diff.gz file either, but it should be only a temporary situation until the next upstream version. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: patching an original tarball
On Wed, Jan 26, 2000 at 01:08:52PM +0100, Jordi wrote: > > Admittedly the upstream patch doesn't belong in the Debian .diff.gz > > file either, but it should be only a temporary situation until the next > > upstream version. > > If nano-0.7.4-2 (the patched version) is admitted into frozen, I hope it > would be the last upstream version for Potato, so it would be a long > temporary situation. What do I do then? Just patch and recompile? Place a > note somewhere? Well, I meant temporary in terms of number of versions, rather than number of days. You can make a note if you like. In most cases, the sources probably won't be used again after release so it doesn't really matter. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: shlibdeps warning ?!
On Mon, Feb 07, 2000 at 04:49:47PM +0100, Christian Hammers wrote: > I don't understand the following error that was produced by > dpkg-shlibdeps when I was compiling mysql: > > dpkg-shlibdeps: warning: unable to find dependency information for shared > library libpthread (soname 0, path /lib/libpthread.so.0, dependency field > Depends) > > "dpkg --search" and the www.debian.org page told me that it belongs to > libc6 which is definetly installed. (libc6-dev, too) > > Any thoughts ? Check /var/lib/dpkg/info/libc6.shlibs; make sure libpthread is listed. Of course it should be; if not there may be a libc6 bug. The .shlib files are used by dpkg-shlibdeps. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: rejected package
On Mon, Feb 07, 2000 at 11:14:13PM -0600, Lonnie Sauter wrote: > I do not understand why my package was rejected. I look in the > directory /REJECT and this is what I found: > > [ 23:08:16 : master : /home/Debian/ftp/private/project/Incoming/REJECT > ] > (67) $ more sysutils_1.3.6.1_i386.reason > Rejected: > sysutils_1.3.6.1_i386.changes: Unknown Format `' Hard to say since you have deleted it and uploaded a new version now. We needed to see the .changes file as it was on master. By the way, your files in incoming on master are mode 600; the files I just uploaded (with dupload using scp) are 644. That's a little antisocial -- and perhaps dupload can't read your files and gives up, hence the error. Unless dinstall runs as root, it can't read your files -- and I don't even have to check to be pretty sure it doesn't run as root. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: Smail Config
On Tue, Feb 08, 2000 at 09:15:04AM -0500, Jason Taylor wrote: > I have recently setup a Debian box and I want to stop smail from being > used as an open relay. I haven't been able to find any documentation that > tells me how to do this, I of course could be looking in the wrong place. If > someone could point me in the right direction that would be great, thank > you. Jason, The correct mailing list for this query is debian-user; the debian-mentors list is for mentoring of new developers. You might want to consider changing your mail transfer agent to exim instead of smail. exim is similar but much easier to configure. I can't remember how to stop relaying on smail but could help with exim. I have already converted all my machines from smail to exim. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: Looking for sponsor
Rick, On Tue, Feb 08, 2000 at 08:39:00PM -0800, Rick Younie wrote: > I got Joey Hess's opinion before I started that since general > programs didn't link to the libs it was ok to tell dh_make they > were (s)ingle. Only regina-rexx can use the libs and they have > to stay in step with it. > > The only problem lintian has with the two function packages is > 'useless call to ldconfig' after install/remove but regina > needs this to find the libs so I think these warnings are ok. > The headline clicker is lintian clean. Actually, it's quite right; there is no need to call ldconfig. Your library is just called /usr/lib/librexxtk.so. Usually your library should be called librexxtk.so.major.minor, and ldconfig will make a symlink from that to librexxtk.so.major. The problem is that your library has no soname. That's generally bad. There are other libraries with just .so names that do still have sonames.. actually, lintian doesn't know that your .so file even IS a shared library. You need to modify the linking command in the makefile. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: bug report to a slink version
On Sat, Feb 12, 2000 at 01:38:10PM +0100, Christian Hammers wrote: > I've just got a bug report to the slink(!) version of mysql-server. > (It didn't create a socket directory in some cases...) > > As I took over the mysql-server packages in early potato I probably fixed > that bug but should I now just close the bug as if it had been reported > to an old potato version or should I build a fixed slink version and > upload it to distribution "stable" ? No, it is not possible to update stable (except for security or Y2K fixes). If it is already fixed, you can close it. If not, fix it! :-) Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: setgid in /var/cache
On Sun, Feb 13, 2000 at 06:52:12AM -0600, Paul Serice wrote: > I have a package that needs files under /var/cache to be setgid. The > files are for Crafty to allow it to "learn" chess as it plays. Part > of the installation is that I install all that Crafty has learned from > all of its user's across the internet. Then as Crafty plays locally, > it makes additions to these files under /var/cache. > > I have built a Debian package that produces files with the right > ownerships and permissions if I use "--extract" on the package, but > after installation, the ownership is set root.root and permissions > are 644. > > Is dpkg preventing my scheme? I can't see why dpkg would prevent it. Can you make your sources and/or deb files available for download? Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: pks_0.9.4 - looking for sponsor
On Mon, Feb 14, 2000 at 07:05:51PM +0100, Simon Richter wrote: > - The package doesn't build in a fakeroot environment: > > dh_fixperms > chown: debian/tmp/usr/share/man/man8/kvcv.8.gz: Operation not permitted > chown: debian/tmp/usr/share/man/man8/kxa.8.gz: Operation not permitted > chown: debian/tmp/usr/share/man/man8/pgpdump.8.gz: Operation not permitted > chown: debian/tmp/usr/share/man/man8/pks-mail.sh.8.gz: Operation not That looks like you just didn't run it in fakeroot -- it's not required to run fakeroot itself. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: prerm failed for scanlogd?
On Thu, Feb 17, 2000 at 02:48:53PM +0100, Michael Vogt wrote: > # Automatically added by dh_installdocs > if [ \( "$1" = "upgrade" -o "$1" = "remove" \) -a -L /usr/doc/scanlogd ]; then > rm -f /usr/doc/scanlogd > fi > # End automatically added section > # Automatically added by dh_installinit > /etc/init.d/scanlogd stop > # End automatically added section > -8<-- > If there is no prerm, it just uses this one. But this is sh, I use tcsh. > My solution is to add a prerm file, that has a "#!/bin/sh" on top. > What do you think? Is this a bug in debhelper? Or is it documented somewhere? I don't think that's it -- a script without a #! line will run with /bin/sh anyway. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: need to force dinstall to use a new .orig.tar.gz
On Mon, Feb 21, 2000 at 03:09:19PM -0500, Will Lowe wrote: > I uploaded a new version of fsviewer a while back, and got this from > dinstall: > > > Rejected: md5sum for > > dists/potato/main/source/x11/fsviewer_0.2.3.orig.tar.gz doesn't match > > fsviewer_0.2.3-2.dsc. Rejected: md5sum for > > dists/woody/main/source/x11/fsviewer_0.2.3.orig.tar.gz doesn't match > > fsviewer_0.2.3-2.dsc. > > I uploaded a new .orig.tar.gz file to take care of this (the old one > actually wasn't correct), but dinstall isn't installing it. Why? Your .changes file must say you are uploading the .orig.tar.gz else dinstall has no reason to look for it. I think the option to dpkg-buildpackage is -sa or similar. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: Source will NOT be uploaded? (fwd)
On Fri, Feb 25, 2000 at 07:42:08PM -0500, Rich Sahlender wrote: > Sean 'Shaleh' Perry wrote: > > is your debian version 1? as in source--1.deb? A source upload is > > only created for the 1 (maybe also 0, I forget) release. > > Ah, that must be it. No, it was orphaned and I just picked it up. The last > source upload by prior maintainer was at -1x something. I guess one MUST > use -sa on first build as new maintainer if it's only for patches and not > a major revision. I didn't see that in the docs anywhere and didn't > understand why I needed -sa if I didn't use -b for binary only. Why do you need to upload the original source code again in this case? Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: Source will NOT be uploaded? (fwd)
On Fri, Feb 25, 2000 at 11:03:21PM +0100, Jordi wrote: > Also, it contains the new upstream source, tarred and unpacked: > amcl-0.7.0amcl-0.7.0.tar.gz > > With this files, I do a dpkg-buildpackage -rfakeroot from amcl-0.7.0/, which > builds an amcl_0.7.0-1.tar.gz and ends with a: > dpkg-buildpackage: Debian-specific package; upload is full source > > I don't know what's going on with this. My other packages create an > amcl_0.7.0.orig.tar.gz when I build them. The rules in amcl is nearly > identical to those other packages. .orig.tar.gz isn't built by the tools. You should rename the amcl-0.7.0.tar.gz you downloaded to amcl_0.7.0.orig.tar.gz yourself. dpkg-buildpackage says it's a Debian-specific package because it can't find the .orig.tar.gz. It assumes there is no upstream source, so it builds you a .tar.gz and a .dsc -- instead of the usual .orig.tar.gz, .diff.gz and .dsc combination. > Also, I get this lintian error, which I think is a bug: > E: amcl: manpage-for-x11-binary-in-wrong-directory usr/X11R6/bin/amcl > usr/share/man/man1/amcl.1x.gz > The policy states that _any_ manual goes into share, no /usr/X11R6/man. Am I > right? I don't know. But here's a simple fix -- put your binary in /usr/bin instead of /usr/X11R6/bin. Policy and the FHS do not say that all X clients go in /usr/X11R6, only that the standard components do. I put all of my binaries in /usr/bin, even for X programs. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome.
Re: some problems...
On Sat, Apr 01, 2000 at 12:40:40PM +0200, E.L. Willighagen wrote: > > Sorry, besided the problems i want to post here, is seem to have some problem > with my "mail" program as well... my excuses for the duplicate versions... Egon, Fire away with your questions, here on the list if you can. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: lynx in ip-up: no terminal
On Wed, May 24, 2000 at 04:34:54PM +0200, T.Pospisek's MailLists wrote: > On Wed, 24 May 2000, Justin Penney wrote: > > > lynx is nearly always installed and used by default in many scripts. (e.g. > > dhs.org update scripts etc.) > > It's just that lynx is a viewer. wget is a page fetch-program and for that > reason "might" be better adapted for the task. lynx has only just started doing this. I filed a bug report this morning. "lynx -dump" should not need a terminal. It is convenient to dump the rendered output to stdout; wget just retrieves and does not render. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: FHS query
On Thu, Jun 15, 2000 at 01:15:46AM +0100, John O Sullivan wrote: > Hi, > Can anyone tell me if I'd be breaking any rules by packaging this > software and placing the binaries and data files under /opt/empire? Yep, you would be breaking all the rules. :-) /opt is reserved for the system admin's use (for third party packages usually); Debian, being the OS vendor, can't touch it. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Find the display
On Thu, Aug 10, 2000 at 11:39:49PM +0200, Christian Marillat wrote: > # restart sawfish > if [ `pidof sawfish` ]; then >sawfish-client -display :0.0 -f restart > fi This is completely broken because you cannot be sure the user is on :0.0 -- perhaps they are not even on the console. X is a network protocol, after all. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Find the display
On Thu, Aug 10, 2000 at 07:28:24PM +0200, Christian Marillat wrote: > I need to restart sawfish, because sawfish crash each times a user upgrade > sawfish. unstable is unstable... And experimental is in project/experimental. Consider it. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Find the display
On Sat, Aug 12, 2000 at 01:11:57AM +0200, Christian Marillat wrote: > echo " WARNIG - WARNIG - WARNIG - WARNIG - WARNIG - WARNIG" I suggest you spelling WARNING correctly! Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Section of deb packages not in Debian
On Mon, Aug 14, 2000 at 03:01:19PM +0200, [EMAIL PROTECTED] wrote: > include your bugfixes. If the upstream author doesn't like debian he > might not include the debian dir, but that should allways patch I can't see how having an upstream debian dir is anything but a nuisance. It will always be out of date -- at the very least you will need to update the debian/changelog when building the package. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: a bit policy, a bit devel [was: Re: Find the display]
On Tue, Aug 15, 2000 at 03:15:04AM +0200, [EMAIL PROTECTED] wrote: > Yeah, I hate perl. Its easy to create bugs and hard to fix them. You can do that in any language. Perl is no different to C in that regard. Recently I've been programming a lot in Tcl; too many inconsistencies to be a good language IMHO. > Several times I had the problems that I upgraded via network and sshd > got stoped and I got kicked out. But I wasn't stupid, so i upgraded > the system in a screen session. But then some stupid packages pops up > and asks me to press return, so sshd wil not start up again and I have > to drive over to the system. I have never seen sshd be stopped during an upgrade. I do all my upgrades via ssh. And if something like ssh does go down, there's always a dialup modem line. I've kept one on a remotely deployed machine of mine just for this reason. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: a bit policy, a bit devel [was: Re: Find the display]
On Wed, Aug 16, 2000 at 11:52:41AM +0200, Bernhard R. Link wrote: > The whole state debconf is best described as "prototype". I'm not very > experienced in perl, so I never saw a perl-program before that is so much > less readable than a bad C-code. Perl can be readable or obfuscated. The language lets you do either, and that's a good thing. (Trust me, I use VHDL daily and it's very verbose; sometimes I like nice terse Perl.) The language is not at fault, the programmers who use it badly are. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: a bit policy, a bit devel [was: Re: Find the display]
On Wed, Aug 16, 2000 at 05:08:38PM +0200, Marius Vollmer wrote: > Hamish Moffatt <[EMAIL PROTECTED]> writes: > > > The language is not at fault, the programmers who use it badly are. > > Especially the programmers who choose bad languages in the first place. If there is such a thing, Perl is not one of them. I suspect that the Perl haters here have not tried properly to write Perl code decently. I wrote about 10,000 lines of it for a project earlier in the year and the readability is fine. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: a bit policy, a bit devel [was: Re: Find the display]
On Sat, Aug 19, 2000 at 05:56:31PM +0200, [EMAIL PROTECTED] wrote: > Lets see, some regular used feature in Perlk is to use the return > value of a funktion thats stored in $_ or somthing. Sure, you CAN do that in Perl, but you don't have to. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: dh_installmanpages: used -p but got man pages in other package too?
On Thu, Aug 31, 2000 at 11:38:15AM +0300, Shaul Karl wrote: > Although I have used > -p nut > I got the man pages in the nut-cgi build dir too. Doesn't this contradicts > dh_installmanpages and debhelper man pages? > > [11:34:10 nut-0.44.1]$ grep -A12 "dh_installmanpages -N nut-doc -p nut" Try -Nnut-doc -pnut; no spaces. debhelper(1) does not show any spaces. You should only need -pnut, and not -Nnut-doc. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Accepted ways when upstream author insists on using MANPATH env var?
On Fri, Sep 08, 2000 at 08:57:47AM +0300, Shaul Karl wrote:
> This state of affairs contradicts section 3.9 of the policy.
>
> My current solution is to patch the programe with a conditional setting of
> the
> MANPATH:
>
> if {![info exists env(MANPATH)] || [string equal [string trim $env(MANPATH)]
> ""]} {
> set env(MANPATH) [ exec /usr/bin/manpath ];}
>
> What are the acceptable ways to handle similar situations? Is there a better
> way other then using /usr/bin/manpath?
That sounds like a good solution. We should make modifications
to programs to make them work within the Debian environment;
that's where Debian adds value versus compiling from source IMHO.
Regards
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Question on "Bug#74171: recommends nonexistent package"
On Sat, Oct 07, 2000 at 08:06:48AM +0200, Simon Richter wrote: > On Sat, 7 Oct 2000, Chanop Silpa-Anan wrote: > > > Hi, should this bug be at important severity? I don't think so! > > Yes and no. Not for the reason Brian wrote, but you could argue whether > depending on nonexistant packages is an important bug. It wasn't a dependence (which IS an important bug), but only a recommendation. I got a bug about a suggestion! I don't think this is an important bug. That dselect treats recommends so highly is a bug in dselect, not in the packages which make recommendations. Again there was no discussion of this mass bug-filing campaign on debian-devel, as Debian's policy and manuals require. (Unless I missed it and the discussion, which I doubt.) Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Installing files in /etc
On Sat, Oct 21, 2000 at 05:39:08PM +0200, Josip Rodin wrote: > On Fri, Oct 20, 2000 at 12:16:21PM -0600, Wesley W. Terpstra wrote: > > debian/rules: > > make install DESTDIR=`pwd`/debian/tmp > > BTW s/`pwd`/$(CURDIR)/ Why not just make install DESTDIR=debian/tmp ? I've never understood why an absolute path is needed for that command. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
