Re: debian/watch file and berlios
On Tue, Nov 21, 2006 at 12:43:33PM -0500, Justin Pryzby wrote: > On Mon, Nov 20, 2006 at 11:21:45AM +0100, Andreas Bresser wrote: > > Hello, > > > > The upstream-author of my package "spe" uploaded a new release on > > berlios.de (on sourceforge is still the old version), so I changed the > > debian/watch-file from sf.net to berlios: > > version=3 > > opts=downloadurlmangle=s/prdownload/download/ \ > > http://developer.berlios.de/project/showfiles.php?group_id=4161 \ > > http://prdownload.berlios.de/python/SPE-(.*)-wx.*\.tar\.gz > > > > but this does not work: > > > > ~/debian/spe2/spe-0.8.2a+repack$ uscan > > spe: Newer version (0.8.3.c) available on remote site: > > http://download.berlios.de/python/SPE-0.8.3.c-wx2.6.1.0.tar.gz > > (local version is 0.8.2a+repack) > > uscan warning: In directory ., downloading > > http://download.berlios.de/python/SPE-0.8.3.c-wx2.6.1.0.tar.gz failed: > > 403 Forbidden > > > > when I try to download this file directly with "wget" it works: > Berlios apparently rejects based on User-Agent. > > wget -q --header 'User-Agent: libwww-perl/5.805' > 'http://developer.berlios.de/project/showfiles.php?group_id=4161' >/dev/null > ; echo $? > 1 > > wget -q 'http://developer.berlios.de/project/showfiles.php?group_id=4161' > >/dev/null ; echo $? > 0 This was fixed in devscripts 2.9.24, and was bug#397354. Do you still observe this erroneous behaviuur with the latest devscripts? > I also note the following strange headers sent by uscan, observed with > ethereal^Wwireshark: > > Connection: TE, close > TE: deflate,gzip;q=0.3 Not a clue, sorry. > Problems aside, I think you will want something like: > version=3 > http://developer.berlios.de/project/showfiles.php?group_id=4161 > SPE-(.*)-wx.*\.tar\.gz Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/watch file and berlios
On Wed, Nov 22, 2006 at 11:17:29AM -0500, Justin Pryzby wrote: > On Wed, Nov 22, 2006 at 01:46:37PM +0100, Andreas Bresser wrote: > > Hi, > > > > so is it enought when I update my package manually using uupdate and > > create a watch file that looks like you suggested? > > (because that line does not work): > Well, until uscan gets fixed, or an upload to sf.net is made, it won't do > anything useful, as you note. > > I think there are 2 problems: > > - Berlios apparently rejects based on User-Agent. Fixed in 2.9.24, I believe. > - Strange headers sent by uscan, observed with wireshark Not a clue. Ideas or suggestions welcome. It's something to do with libwww-perl, I guess :/ Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/watch and different action than `uupdate'
On Sun, Aug 26, 2007 at 07:10:17PM +0200, Daniel Leidert wrote: > > 2) Is it possible to use a different action than uupdate, e.g. `fakeroot > > debian/rules get-orig-source'? > > And this too. Seems to be impossible atm. Would be a nice-to-have for > me. $ cat debian/get-source #! /bin/sh fakeroot debian/rules get-orig-source $ cat debian/watch http://.../.../pkg-(.*).tar.gz debian debian/get-source Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/watch and different action than `uupdate'
On Mon, Aug 27, 2007 at 12:30:41AM +0200, Daniel Leidert wrote: > > > > 2) Is it possible to use a different action than uupdate, e.g. `fakeroot > > > > debian/rules get-orig-source'? > > Nice idea. Unfortunately > > uscan --force-download > > does not call the script. Instead it tries to get the archive I'm > testing for - but that's not, what I want - the get-orig-source gets the > necessary archives, merges them and creates the source tarball. Is the > problem, that the above idea fails, related to the fact, that I'm using > version 3 of the debian/watch format? It may also call the script; at present, uscan assumes that the user wishes to download the new archive *before* running the update action. I wonder whether the best way around this one would be to have a new option "nodownload" or something like that? Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
lintian
People keep mentioning lintian. Where can I find it? I looked in devscripts, but it was not there (even though the package description mentions a non-existent deblint program). I searched through Contents-i386 on hamm, with no success. Help?! Thanks, Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND
Policy concerning emacs lisp files
Is there any standard policy concerning the installing of emacs lisp files contained in a package? Having looked in the /usr/share/emacs and /usr/lib/emacsen-common trees, it seems to me that most packages install their .el files under /usr/share/emacs/site-lisp and their compiled .elc files under /usr/share/emacs/$flavor/site-lisp, and the compilation is controlled by /usr/lib/emacsen-common/packages/install/$package. Am I right? Is this written down anywhere? If not, it should be! Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Lintian error message
Help! I just ran lintian on my first package and got the error: E: cweb source: newer-standards-version 2.5.0 How do I go about figuring out where the problem might lie? How can I get lintian to give me more information? Any help appreciated! Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Lintian error message
> Help! I just ran lintian on my first package and got the error: > > E: cweb source: newer-standards-version 2.5.0 > > How do I go about figuring out where the problem might lie? How can I > get lintian to give me more information? > > Any help appreciated! > >Julian OK, I've sussed it: lintian 0.9.3 doesn't know about Debian Standards version 2.5.0.0. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Lintian error message
> On Thu, Nov 12, 1998 at 04:20:35PM +0000, Julian Gilbey wrote: > > Help! I just ran lintian on my first package and got the error: > > > > E: cweb source: newer-standards-version 2.5.0 > > Hmm. I haven't seen you announce taking over cweb. I was thinking of > doing the same. Are you taking cweb-latex too? Have you considered > cwebx (CWEB enhanced for ISO/ANSI C)? I contacted the former maintainer and WNPP, and the New Maintainers announcement of a couple of weeks ago listed me as taking over cweb, cweb-latex and sgb. I was thinking about announcing my intention of packaging cwebx on debian-devel once I'd figured out how to package cweb (which I've just done). If I didn't announce my intention to the right place, please accept my apologies and let me know where I should do so in future so that I don't offend anyone. Thanks!! 8-) (Incidentally, the Developer's Reference only talks about mailing [EMAIL PROTECTED]) > > How do I go about figuring out where the problem might lie? How can I > > get lintian to give me more information? > > Try the -i option (IIRC, as I am not on a Debian box now). I did -- it didn't help. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Source code location?
I am trying to repackage a new upstream Stanford GraphBase (sgb). I
would like to include the source code in the .deb package, as the
value of the included programs is really as a demonstration of what
the library code can do (libgb), and the documentation of the library
is in its literate source code.
So here's the question: where do I place the CWEB source code? Do I
put it in:
o /usr/share/sgb although the use of /usr/share is not particularly
well documented, or
o /usr/lib/sgb, especially as /usr/lib/sgb/data is where the
datasets for the library are stored, or
o /usr/doc/sgb/examples, since they are somewhere between examples
and the documentation?
My gut feeling is to go for /usr/lib/sgb, but I would like advice
before I proceed.
Thanks,
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey Email: [EMAIL PROTECTED]
Dept of Mathematical Sciences, Queen Mary & Westfield College,
Mile End Road, London E1 4NS, ENGLAND
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Source code location?
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Julian > Gilbey) writes: > > > I am trying to repackage a new upstream Stanford GraphBase (sgb). I > > would like to include the source code in the .deb package, as the > > value of the included programs is really as a demonstration of what > > the library code can do (libgb), and the documentation of the > > library is in its literate source code. > > Hmm. Interesting. So how do you use it? You *extend* the library? > Or you just read about it? ;) You use the library as any library by linking it to your code. However, imagine if some library had no independent documentation other than well documented source code. And I mean SO well documented that it's a pleasure to read, and even enjoy. That's what the SGB library is like. (In fact, it's so readable that it's been published as a book. Being written in CWEB means that you can create TeXable output from the source code, which can be pretty-printed.) > > So here's the question: where do I place the CWEB source code? Do I > > put it in: > > > o /usr/share/sgb although the use of /usr/share is not particularly > > well documented, or > > It's documented in the FHS standard, > http://www.pathname.com/fhs/>, which is not officially sanctioned > by policy, but, nevertheless, is the right place for architecture > independant *data* files (or scripts). No, it is required by policy (section 3.1.1, version 2.5.0.0). > My gut feeling would be under /usr/doc/sgb/examples, I suppose. OK, I'll go for that, thanks. Would it be out of order to include a symlink /usr/doc/sgb/src -> /usr/doc/sgb/examples? I hope not. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Source code location?
> Adam Di Carlo wrote: > > > > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Julian Gilbey) writes: > > >[Me] > > >> Hmm. Interesting. So how do you use it? You *extend* the library? > > >> Or you just read about it? ;) > > > > > [...] (In fact, it's so readable that it's > > > been published as a book. Being written in CWEB means that you can > > > create TeXable output from the source code, which can be > > > pretty-printed.) > > My 'crucial questions' would be: > - is the amount of documentation (prose) significantly larger > than >that of code (apparently, otherwise there would not be the > book) Compiled code = 300kb approx Source code = 850 kb approx Source code - comments/documentation = 240kb approx The included documentation therefore accounts for the majority of the source code. > - what can be done without non-standard processing steps > - can it be built with just make > - can user read it without knowing literate programming, > should there be a ready made html version available Good questions. My intention was to provide the compiled libraries as standard, along with the compiled demo programs, and to provide the source code in addition as documentation. Building requires CWEB in addition to make. The code is not too difficult to read, but CWEB + TeX make it beautiful. > - what the installer expects to happen > - since this is a binary package user must be prepared to have > some binaries and documentation, but he [ha, ha!] is not > necessarily expecting anything in /usr/src, it may be e.g. > a link to separate partition, which is nearly full > (I used to have this), and when the partition gets full your > installation goes haywire Aargh, I hadn't considered this problem. > > Yes, I'm familiar with the concept of literate programming. Nice to > > see a nice real world example. My *practical* objection w/ literate > > programming is that programmers generally don't write the best > > documentation. ;) > > Only rarely can a programmer, or anybody else, create > documentation > of such caliber that the same documentation is good for creating > the > software, maintaining it and using it. Also the maintainer has the > added burden of having to consider the structure of both the > documentation > and the sw at the same time when doing changes. However, experience has taught me, surprisingly, that it actually turns out to be *easier* to maintain code like this than with traditional models. It's also significantly easier for other people to read and modify if it's well written than normal well-written code. I point to TeX as a very good example: the very fact that we now have a really good UN*X version of TeX (Karl Berry's web2c system), the existence of extensions such as e-TeX, pdfTeX, Omega, etc., is in no small part due to the ease of reading and understanding such a complex, interwoven piece of software as TeX. Of course, Knuth is no ordinary programmer! ;-) > > >> My gut feeling would be under /usr/doc/sgb/examples, I suppose. > > > > > OK, I'll go for that, thanks. Would it be out of order to include a > > > symlink /usr/doc/sgb/src -> /usr/doc/sgb/examples? I hope not. > > > > Sounds good to me... why not! > > > > Also, another ok suggestion: /usr/src/sgb, and symlink > > /usr/doc/sgb/src -> ../../src/sgb > > > > It really come down to the "principle of least suprise". > > I would have the symlink the other way, create it in postinst, > and silently accept if no link could be created I think that's even better. Back to the drawing board Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Source code location?
> > My 'crucial questions' would be: > > - is the amount of documentation (prose) significantly larger > > than > >that of code (apparently, otherwise there would not be the > > book) > > Compiled code = 300kb approx > Source code = 850 kb approx > Source code - comments/documentation = 240kb approx > > The included documentation therefore accounts for the majority of the > source code. Actually, would it make sense to introduce a new package, sgb-src or sgb-doc (preferred), which would contain the sources? Among other things, it would mean that changes in the package wouldn't require users to download the (unchanged) upstream sources again, and those who have the book wouldn't need to download the sources. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Checking if directory is empty in postrm
> However, a new question arises. Will this work in all cases: > > rmdir $LDIR 2>/dev/null && grep -v $LDIR $LDSOCONF >$tmpfile && mv $tmpfile > $LDSOCONF || true > rm $tempfile # just in case the mv failed, or grep failed partly > > Or is there any trap door I miss? What if you have a directory LDIR=/etc/foo/bar but there is another directory called /etc/foo/barbar in $LDSOCONF? Maybe you should change the grep command to: grep -v "^$LDIR\$" $LDSOCONF so that you match the entire line. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Rebuild process
> I just received my first bug report, and I would appreciate it if someone
> could list the steps I need to take (doesn't seem to be documented anywhere).
> Obviously the first step is to reply to the bug-report with "-done", but then
Erm, no -- see below.
> what? I fix the bug (which was due to my superior packaging
> skills). Do I just
> do dh_make? Will that automagically increase the build number?
> Basically, what
> steps go between responding to the bug report and uploading the
> fixed package?
>
> One problem I have found is the overlap of commands, which causes at least me
> some confusion as to what program I am supposed to be using (ie deb-make and
> dh_make).
The first step is to look at your package. I presume that you have
the original sources, your diffs etc. in an organised manner which
allows you to build the current .deb and other files required for
uploading yourself? If not, then I recommend the following. (I
assume you are packaging foobar, upstream version 1.1, Debian revision
3, and you are preparing to release version 4.) Many more details can
be found in the various new maintainer guides at
http://www.debian.org/devel (I think that's it).
(1) Create the directory /usr/local/src/Packages/foobar. (You may
well need to be root to do this, but then you can chown the
Packages directory to yourself. None of the rest needs to be done
as root.)
(2) In this directory, place foobar_1.1.orig.tar.gz and
foobar_1.1-3.diff.gz. (foobar_1.1.orig.tar.gz should untar into
the directory foobar-1.1.orig.)
(3) Untar the archive into the directory foobar-1.1.orig using the
command: tar zxpvf foobar_1.1.orig.tar.gz
then rename the directory with: mv foobar-1.1.orig foobar-1.1
(4) Apply the diffs:
cd foobar-1.1
zcat ../foobar_1.1-3.diff.gz | patch -p1
Now check that it's all working by running the command:
dpkg-buildpackage -rfakeroot
from within the foobar-1.1 directory. (You have got fakeroot, don't
you? If not, then get it!!)
Once you've got this far, you can then start patching and releasing
fixed code, as follows:
(1) Fix the bug in the foobar-1.1 directory.
(2) Describe your change in a new entry at the top of the
debian/changelog file. Make sure it's your email address at the
end of the new changelog! You can either do this by running the
debchange (aka: dch) command, or by using the
debian-changelog-mode of emacs. (You may need to change /lib/ to
/share/ in /etc/emacs/site-start.d/50dpkg-dev.el for this to work
-- it's buggy.) Use a comment like: closes: Bug #n in the
changelog, so that people know why you've closed it.
(3) Run dpkg-buildpackage -rfakeroot again -- this should create
foobar_1.1-4_i386.deb and foobar_1.1-4.{diff.gz,dsc,changes} in
the parent directory (assuming you are running on an Intel x86
processor).
(4) cd .. and then run: lintian foobar_1.1-4.changes. If there are
any errors (shown with E: and non-zero exit code; don't worry
about E: newer-standards-version if it comes up), go back to step
(1) again.
(5) Run the dupload command: dupload --to master foobar_1.1-4.changes
(replacing master as appropriate).
(6) When you have received the acknowledgement that the uploaded
package has been installed into the archive, you may close the bug
by mailing [EMAIL PROTECTED], but not before.
[NB: hopefully, the bug closing will be done automatically by the
package installation program on master (dinstall) in the near future
if a closes: type comment is placed in the changelog. I am
working on that one.]
HTH,
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey Email: [EMAIL PROTECTED]
Dept of Mathematical Sciences, Queen Mary & Westfield College,
Mile End Road, London E1 4NS, ENGLAND
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Rebuild process
> One problem I have found is the overlap of commands, which causes at least me
> some confusion as to what program I am supposed to be using (ie deb-make and
> dh_make).
Forgot this bit. Both deb-make and dh_make are used to turn an
upstream source into a Debian package, so are used only when the
package is first packaged. After that, the rest of the debhelper
package becomes much more useful. Also, deb-make is sort of
deprecated in favour of dh_make; have a look at the debhelper package
as well if you haven't already.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey Email: [EMAIL PROTECTED]
Dept of Mathematical Sciences, Queen Mary & Westfield College,
Mile End Road, London E1 4NS, ENGLAND
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Rebuild process
> I'm a new maintainer too... Instead of steps 3 and 4 below, can't > you simply do: > > $ dpkg-source -x foobar_1.1-3.dsc > > ? Yes, forgot that!! ;-) (I'm also relatively new to this game!) Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Rebuild process
> [EMAIL PROTECTED] (Julian Gilbey) writes: > > > (4) cd .. and then run: lintian foobar_1.1-4.changes. If there are > > any errors (shown with E: and non-zero exit code; don't worry > > about E: newer-standards-version if it comes up), go back to step > > (1) again. > > Eh, you forgot something rather important... > > (4a) Install the package and test it to make sure you didn't break >anything. Erm, yes, forgot that bit!! You must check that you can do the following successfully, and that the package works after you have done each one: (a) Upgrade from the previous version and from the version in hamm. (b) Downgrade back again. (c) Install the package as a new package (i.e., with no previous version installed). Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: My `Section' and `Priority' lines have gone missing?
> > I just noticed that my packages don't show `Section' and `Priority' lines > when you do `dpkg -s xwatch` like other packages do. > > I didn't add `Section' and `Priority' lines for the binary package > (because deb-make didn't put it in initially): Note that deb-make is deprecated. Have a look at the debhelper and dh-make packages instead. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: My `Section' and `Priority' lines have gone missing?
> On Thu, Dec 17, 1998 at 06:33:59PM +0000, Julian Gilbey wrote: > > > I didn't add `Section' and `Priority' lines for the binary package > > > (because deb-make didn't put it in initially): > > > > Note that deb-make is deprecated. Have a look at the debhelper and > > dh-make packages instead. > > Don't say that where Santiago can here you.. => He's rather defensive > about his package. It's not been depreciated, just that many perfer > debhelper. But that's what it says on http://www.debian.org/devel/ Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: off topic/learning C
Here's a practical example of writing, compiling and executing a piece
of C code on a Debian system:
/tmp/myhello.c
==
#include
int main()
{
printf("Hello world!\n");
return 0;
}
Comiling and running
/tmp$ gcc -o myhello myhello.c
/tmp$ ./myhello
Hello world!
/tmp$
If that doesn't work, let me know. The gcc program has many options,
which you can find out about using the info reader.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey Email: [EMAIL PROTECTED]
Dept of Mathematical Sciences, Queen Mary & Westfield College,
Mile End Road, London E1 4NS, ENGLAND
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: pgp problem for package signing
> I have sent my application to become a maintainer off with a pgp user id of > 'John C. Travers' I didn't want to include an e-mail address as this woul > surely change during my time at debian, however when packaging the > dpkg-buildpackage script expects 'John Travers <[EMAIL PROTECTED]>' and > chucks out an error message... how do I get around this? > > thanks for help... travs. You could always add a PGP user id of "John C. Travers <[EMAIL PROTECTED]>" (or whatever your Debian email is) to your key, using pgp -ke, and send it to [EMAIL PROTECTED] Then make sure your debian/changelog entry ends with the @debian.org address, and use that in the control file as well. In that way, even if all of your other email addresses change in the process, your debian one will remain as long as you are with the project. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: PGP signing packages
> Hi, > > As I was building a Debian package, dpkg-buildpackage asked me to sign the > .dsc and .changes file. Well it tried anyway. My problem is that I am > using pgp5 and but dpkg-buildpackage seems to want to use pgp2 or gpg for > the signing. I tried linking secring.pkr to secring.pgp and the same with > pubring but pgp2 complained about unsupported packets. Does anyone have > any info on how to get dpkg-buildpackage to work with pgp5? Simple answer: don't. Debian currently works with PGP 2.6.x and is moving over to GNU PG. Please install the pgp package, copy the ~/.pgp/secring.pgp to ~/.pgp/secring.skr and see whether it works. It should do. It's much easier than trying to hack dpkg-buildpackage to work with pgp5, which Debian is moving away from anyway. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary & Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: packaging from root account
> It is much safer to not be root. Install libtricks and use > 'debuild -rfakeroot' to build your packages. In fact, debuild will automatically use fakeroot if you have it installed, and die if not (and you are not running as root, and don't specify an alternative -r... option). So read: Install libtricks and run debuild to build your package. See debuild(1) for more details Julian (devscripts maintainer) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Question about conflicts
> Question for dpkg gurus: > > It is technically possible to make package A to conflict with releases of > B earlier than "p" and also with all releases of B between "r" and "s" > but not with release "q" of B (where p < q < r < s)? > > Thanks. Could you not simply say that your package conflicts with all versions <= s and be done with it? Assuming that a working version >s exists, this would surely be the easiest way? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: /usr/bin or /usr/bin/X11
> On Sat, Mar 20, 1999 at 05:44:11PM -0500, Will Lowe wrote:
> > > debmake decided to run configure --prefix=/usr, should i add a
> > > --bindir=/usr/bin/X11 argument to it?
> > use "--prefix=/usr/X11R6", and that'll get rid of the need for --bindir
> > and all the rest.
>
> but that would put data in /usr/X11R6/share and that would be bad..
So either use --prefix=/usr/X11R6 and whichever individual configure
options necessary for dealing with the problems of /usr/X11R6/share
etc., or do it the other way around.
[debmake v. dh_make stuff]
dh_make is based on debmake, but they are now separately maintained,
and dh_make is still experimental.
All that dh_make does (essentially) is to to create a debian/
directory which will allow creation of a Debian package using
debhelper scripts. You would do better, IMHO, to just copy the
appropriate debhelper example debian/rules file (from
/usr/doc/debhelper/examples) and create whatever other files you need
-- you can always look in /usr/lib/debhelper/dh_make/debian for
example files.
Remember that the debhelper scripts are inserted in the
{pre,post}{inst,rm} wherever you put #DEBHELPER#.
Also, as >50% of Debian packages now use debhelper, you should be in
safe hands.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer. [EMAIL PROTECTED]
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Debian Developer Certificate?
> On Sat, 20 Mar 1999, Konstantinos Margaritis wrote: > > > (Don't know if it's the right list, but here goes) > > Jobs -esp. jobs that pay good- are hard to find, and I was > > wondering, since > > being a Debian Developer can only be a Good Thing (TM) for my CV, > > is there any > > way I can get something like an official certificate of this? > > AFAIK there are > > not many around the world (500-1000? there are only a couple of us here in > > Greece) and it is certainly a proof of some knowledge of the > > subject. Maybe I > > could get me a higher salary from this :) > > We don't have a certification scheme - but it's not hard to prove. You're > in the keyring.. And if you look at the web pages (can't remember exactly where: have a look for something about Who is behind Debian?, maybe on the developer pages of www.debian.org), there is a list of the packages maintained by the various developers. Just point your potential employers at that page ;-) Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: cvs-buildpackage archives .orig.tar.gz
> I have a question about cvs-buildpackage. > > I was surprised to see that all of the upstream .orig.tar.gz is > injected into my CVS repository. I was expecting that the CVS > repository would only hold those files modified or added for the > debian build (only those files for which there are entries in the > .diff.gz file). It is meaningless to have a CVS repository which only stores modified files: how would you know whether it was modified? Only by unpacking the .orig.tar.gz and then comparing. A lot of work. The standard (and IMHO wise) way of doing things is that the upstream version of a package is stored in the CVS tree with the tag upstream_version_ and the Debianised version is stored with tag debian_version_-. The advantages for a single release do not seem to be worthwhile on the surface, but when a new upstream release is made, it can easily be imported into the CVS tree and you can check which things have changed between releases, and so understand how to modify your old diffs to work with the new source if they don't immediately. And you don't need to keep multiple .orig.tar.gz files around for this purpose -- it's all stored in the CVS tree. You couldn't possibly have this flexibility if you only stored the Debian diffs. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: "install" running recursively..?
> Alexander Koch wrote: > > I have a source which has "samples/admin/" as a dir. > > Now I want to have a simple > > install -m 644 samples/* $(tmp)/usr/doc/$(pkg)/examples > > without touching the admin/ subdir at all. > > > > All I get is: > > |install: `samples/adm' is a directory > > |make: *** [binary-arch] Error 1 > > > > Any hints? How to make that one recursively? > > I doubt if `install' can be tought to work recursively, but you could do > something like this: > > for file in `find samples -type f`; do \ > install -m 644 file $(tmp)/usr/doc/$(pkg)/examples; \ > done > > which should do the trick as well (I didn't test it :/ ). Assuming that this is in a Makefile (as hinted by $(pkg), you want this to read (remembering initial tabs): for file in `find samples -type f`; do \ install -m 644 $$file $(tmp)/usr/doc/$(pkg)/examples; \ done with a *double* dollar before file. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: images in diff files ?!
> But now: How do I put the additional Debian-Logo (only 2k) into the > diff file ???Can I rely on the sharutils package though it is only > "standard" and not "essential" ? You should just be able to use dpkg-source, which will place any files you have added to the original source tree into the diff. This is how all of the files in debian/ are handled. If you do use sharutils for something, then: You can basically use anything (in main) that you like to create and compile the package, so long as - the package Depends: on anything needed at runtime, and - (suggestion:) you explain in the README.Debian file what extra packages are needed to compile the packages. We don't yet, AFAIK, have a Source-Depends: field, but eventually this info would go there if the building depended upon it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: images in diff files ?!
> Julian Gilbey <[EMAIL PROTECTED]> writes: > > > > But now: How do I put the additional Debian-Logo (only 2k) into the > > > diff file ???Can I rely on the sharutils package though it is only > > > "standard" and not "essential" ? > > > > You should just be able to use dpkg-source, which will place any > > files you have added to the original source tree into the diff. > > Not binary files. Oops. What was done in one of the packages I inherited was for the binary file to be uuencoded before creating the diffs etc., and in the build process, it was uudecoded. I presume the sharutils idea was similar. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Linux for Khmer
[cc'd to -user] > I need to develop Linux for Khmer (Cambodia). Need help please! > Please reply to [EMAIL PROTECTED] or [EMAIL PROTECTED] Please ask questions like this on debian-user, where you will probably receive more useful help. Debian-mentors is for helping new developers learn how to package software. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: secure temporary directory
> hi, > > I would like to package an app, that needs a 700 tmp directory. > Where should I put it ? > /var/myapp/tmp looks good, but I'm not sure. In /var/run/myapp would be sensible *if* it is root creating the directory. (Note that /var/spool differs from /var/run in that the former will be preserved across system reboots whereas the latter won't, and is intended for spooled data to be processed later.) Alternatively, use one of the secure methods for creating a directory in /tmp, depending upon the language in which you are writing the code. As far as I know, once a directory is created mode 700 in /tmp (*not* in a non-trusted subdirectory thereof, however), its contents are secure and readable only by the owner. There have been discussions about this before -- you might want to check the mailing list archives from the last couple of months, perhaps in -mentors, perhaps in -devel. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: PGP and Debian question
> Sorry if this has been asked before but is there currently any way for a > Debian user to verify the authenticity of a .deb file using PGP without > having the source? When a package is built, the .changes and the .dsc > file is signed which allows dinstall to verify it but is there any support > in apt, dpkg, or Debian in general for a detached PGP signature on the > .deb file itself provided that the user has the Debian-keyring package > installed? Yes, it is an issue which is currently being talked about. At present, there is no way to confirm the authenticity of a .deb, but it is absolutely necessary. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
dpkg: .deb should contain authentication data
Package: dpkg Version: 1.4.0.34 Severity: Important (Important as it is a security issue that has been brought up recently in several contexts, and we know that mirrors can be compromised.) .debs should have an extra component in the ar archive which are PGP-signed MD5 sums (or equivalent) of the other two sections of the .deb archive (control and data). Dpkg (or dpkg-deb?) should create this part when asked to, in a way to be decided, and should be able to check it if asked to. Less urgent is a way of enabling users to confirm these PGP signatures before installing the packages. There is the obvious DFSG problem of making dpkg depend on PGP -- this may actually be a very good opportunity to begin working towards GnuPG by having the signatures be GnuPG ones. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Packages with symlinks and CVS
I have a package which I am trying to Debianise. The upstream source contains lots of symlinks. I usually use the CVS suite to do my packaging, but by default, CVS does not handle symlinks. I am loathe to set the PreservePermissions config file flag, as that will be far more wide-reaching than I want. Does anyone have any suggestions of how this can be handled gracefully? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Packages with symlinks and CVS
> >> "JG" == Julian Gilbey <[EMAIL PROTECTED]> writes: > > JG> contains lots of symlinks. I usually use the CVS suite to do my > JG> packaging, but by default, CVS does not handle symlinks. > > But it can be configured to creat them on export and checkout > > Here is what I do for wxftp. > > I have a executable script CVSROOT/wxftp > > #!/bin/sh > set -e > echo >&2 `pwd` > (cd $1/help; test -f index.html || ln -s wxftp.html index.html; ) > [...] That's OK, except that this package currently has 258 symlinks, and both the number and details are likely to change on a fairly regular basis. The thought of keeping that up to date is quite terrifying. There must surely be a better way? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: version numbers
> Chrony-1.1 is out and I've packaged it to replace chrony-1.02 only to find > that dpkg claims that 1.1 < 1.02. What should I do? If they're going to use digit placement like this, so that the next version is likely to be called chrony-1.11 or something, you could always number this version as 1.10 for Debian purposes, placing a note in appropriate places. It might be worth pointing this problem out to the upstream authors, suggesting that if the `2' in 1.02 is like a patch level, then 1.0.2 would be much better, for then it is obvious that 1.1.0 comes after 1.0.2, both to a person and a machine. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: version numbers
> I wrote: > > I am also just a bit astonished by the notion that 1.1 < 1.02. > > Ben Collins writes: > > Numerically this is the same as saying 1.1 < 1.2 or 1.01 < 1.02. Dpkg > > The leading zero is clearly intended to imply a decimal point. This is in > no way incompatible with the kernel numbering system. Erm, by extension, we would have 1.11 < 1.2 if the "." is interpreted as a decimal point, but 1.11 > 1.2 if it is a major/minor separator. So what will you do when the upstream authors then have version 1.11, 1.12 followed by version 1.2? There is no leading zero here to help. So you have a choice: either bug the upstream authors to change their numbering scheme to something standard (how do I know whether 1.7 is the latest and 1.11 is antiquated or vice versa using their scheme?), or use the suggestion below. But *don't* try changing dpkg on this one. > This is irrelevant, though. Dpkg is not going to change, and the upstream > author has made his decisions. Must I use an epoch? Alternatives have been suggested, such as using a version number of 1.10, especially as this is being interpreted as a decimal point, so 1.1 and 1.10 are the same numerically! Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: version numbers
> I wrote: > > The leading zero is clearly intended to imply a decimal point. > > Julian Gilbey writes: > > Erm, by extension, we would have 1.11 < 1.2 if the "." is interpreted as > > a decimal point, but 1.11 > 1.2 if it is a major/minor separator. > > I said nothing about interpreting the '.' as a decimal point. True, but you did seem to be suggesting that dpkg should treat a leading zero in a special way. > > So what will you do when the upstream authors then have version 1.11, > > 1.12 followed by version 1.2? There is no leading zero here to help. > > No leading zero, therefor no implied decimal point. No problem. Yes problem: your upstream authors will think of 1.12 as prior to 1.2, dpkg will think the reverse is true. > > But *don't* try changing dpkg on this one. > > I have no intention whatsoever of attempting to change dpkg in any way. Sorry, I wasn't clear: I meant that dpkg should not be changed. Too much could go wrong. > > Alternatives have been suggested, such as using a version number of 1.10, > > especially as this is being interpreted as a decimal point, so 1.1 and > > 1.10 are the same numerically! > > But it isn't, and they aren't. It looks as if the consensus is that this > is what I have to do anyway, though. See my other post for a suggestion of how epochs could be used here in a relatively clean way. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: version numbers
> Anthony Fok writes: > > Anyway, Brian White suggested me to use 1.10 instead of 1.1 in order to > > avoid the epoch. And lo and behold, it worked! > > Oh, I already know it will work. It may confuse the users, though. > > > Not too pretty, but prettier than epoch. > > Why? Because when version 1.11 is followed by version 1.2 you will have to change the epoch again, and so on. And also, the epoch is not displayed in many contexts, so it may not be obvious to users that the version numbers are, actually, increasing. Another possibility is the following. Increase the epoch at this point to 1 (so you would have version 1:1.1), but from now on use a triple version number, thus: this release will be 1:1.1.0 or 1:1.1, the next minor upgrade will be 1:1.1.1 (and *not* 1:1.11), the next major release will be 1:1.2.0 and so forth. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: version numbers
> On Thu, May 13, 1999 at 01:31:52AM +0100, Julian Gilbey wrote: > > Another possibility is the following. Increase the epoch at this > > point to 1 (so you would have version 1:1.1), but from now on use a > > triple version number, thus: this release will be 1:1.1.0 or 1:1.1, > > the next minor upgrade will be 1:1.1.1 (and *not* 1:1.11), the next > > major release will be 1:1.2.0 and so forth. > Exactly what I meant; thank you. > -=- James Mastros Apologies -- I've been seeing so many emails about this question that I probably saw yours and later it finally clicked that this was the right thing to do without realising that I'd seen it before. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Building from a source package
> On Fri, May 14, 1999 at 09:21:46PM +1200, Alex King wrote: > > I have a feeling this may be a silly question, but here goes... > > > > How do I build a binary package from a debian source package? > > > > I have downloaded the source package, and unpacked it with dpkg-source, but > > how do I make the .deb from it? > > > > I need to recompile the package (samba) with a compile time setting changed > > (MAX_OPEN_CONNECTIONS). This is really urgent, any tips greatly > > appreciated. > second way : > > use the package dbuild, very nice, install it and then run : Third way: use the debuild program in the devscripts package (which you are advised to download from unstable -- much improved version). Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Package renaming?
> > b) Add this to your control file: > > > > Conflicts: gtksamba > > Profides: gtksamba > > Replaces: gtksamba > > > > If you use the same config file it will be preserved by dpkg, if not, > > save it in the preinst script. > > > > > My initial thought is to treat it as a new package, then orphan and > > > remove the two older packages. > > > > No, that's sick. > > You are suggesting that potato be released containing three different > packages (which are really the same package)? > > gtksamba, gtksamba-gnome, gnosamba > > Adding the Conflicts:, Provides:, and Replaces: line makes perfect sense, > but I'm confused why you would be against removing the two older packages > from the archive (eventually... but before release). I think Joey was complaining about the language: "orphan and remove": this package is not a totally new package, rather it replaces the others. So you upload your new package, which conflicts, provides and replaces the old ones, and then file a bug against ftp.debian.org asking for removal of the old packages. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Library packages, libtool and automake.
> Hi. I've been trying to Debianize a library I've written, which > uses autoconf, automake, and libtool to compile the shared library. When I > try to do it the straightforward way, debian/rules dies with the following: You haven't actually said what the straightforward way is > make[1]: Entering directory > `/home/staff/jamesjb/Devel/accounting/libaccounting-0.1/shared' > /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I. -O2 > -fPIC -pipe -c ../int-string-map.c > ./libtool: ./libtool: No such file or directory [...] > Is there an easy way to do this, with libtool or does it require elaborate > hacking of debian/rules? I did edit the Makefile.in to replace ./libtool > with > $(srcdir)/libtool, but it seems that will not be enough. Firstly, are you able to configure and compile it when doing so directly (i.e., not via debian/rules)? I presume that if you are using automake and autoconf, then you want to have something like this in debian/rules (assuming you are using debhelper, which you are, aren't you?!): build: build-stamp build-stamp: dh_testdir CFLAGS='-O2 -g' ./configure --prefix=/usr [...other options] make touch build-stamp Is this what you are doing? If you are using automake, you mustn't change Makefile.in explicitly, or your changes will be lost. Perhaps you could post your configure.in, Makefile.am and debian/rules for perusal if the above doesn't help? Or give a URL from where they can be downloaded. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Library packages, libtool and automake.
> Ahh, sorry. I just used dh_make and told it to debianize as a library. OK. > > Firstly, are you able to configure and compile it when doing so > > directly (i.e., not via debian/rules)? > > Yes, that works fine. Good. > 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` > [...] > > Since this tries to link *.o into the shared library itself, this is why I > assumed it's not going to work out-of-the box with libtool. Basically, I > just need help getting the debian/rules right. :) OK. I have never used libtool myself, but I would assume that if you do, the code to generate the shared or static libraries ought to be within the autoconf/automake input files? For example, the kpathsea library autoconf has options --enable-shared, --enable-static. You could perhaps look there to see how it's done. (In teTeX package.) And your best bet is to find a package which uses libtool and see how it does it. Or hopefully there'll be someone on this list who knows. > > Perhaps you could post your configure.in, Makefile.am and debian/rules > > for perusal if the above doesn't help? Or give a URL from where they > > can be downloaded. > > Sure. Go to http://www.tailrecursion.com/libaccounting/ Sorry to not be more helpful :( Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Old bugs, which cannot be reproduced
Package: doc-debian Version: 1.9.3 > ([EMAIL PROTECTED] is a handy, though undocumented, way to > reach a bug's submitter.) Oops, this ought to be documented! Are there any other obvious missing BTS commands? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Upgrading to a new upstream maintainer version
> I've already packaged a deb of epkg but there's a new upstream maintainer > version. > Must I remake entirely the package or I have just to do anything that will > keep the changelog... ? If the changes upstream are relatively minor, you should be able to get away with the following (assuming that the current Debian version is 0.3.0-7 and that the new upstream version is 0.3.1; change the numbers appropriately): ~/Work $ ls epkg-0.3.0/ epkg_0.3.0.orig.tar.gz epkg_0.3.1.orig.tar.gz epkg_0.3.0-7.dsc epkg_0.3.0-7.diff.gz epkg_0.3.0-7_i386.deb where the epkg_0.3.1.orig.tar.gz is the new upstream source which conveniently unpacks into epkg-0.3.1/. ~/Work $ tar zxpvf epkg_0.3.1.orig.tar.gz# to unpack the new # upstream version ~/Work $ cd epkg-0.3.1 ~/Work $ zcat ../epkg_0.3.0.diff.gz | patch -p1 This patches the new source with the Debian diffs used for the last version. Then resolve any conflicts, and a "New upstream release" type line to the changelog and try rebuilding the package. This is automated by uupdate(1) in the devscripts package. (I'd recommend using the potato version, not the slink version.) Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Becoming a new developper
> I intend to become a new developper but I've a problem. > I have succefully (lintian says me only one error related to the man page) > packaged gwget, a GTK+ frontend for wget but I'm not an expert in DEB. > packaging for now. Sounds OK. > Is it morally - or policy - correct to become a new developper and > learn more > about DEB packaging if needed for other packages ? Given that it can take several months to have the application processed, it is quite reasonable to apply now and to learn during the wait ;) Seriously, though, it is quite reasonable to learn on the job; it's what most of us do. > Can I upload my DEB to my homepage to allow you testing the package and > reporting errors to me ? > So, How to make a apt compliant hierarchy on my homepage area ? Yes. Just put it on the page and announce it here for testing. Make sure to make the source available too! And you should just be able to put the package in a given location and testers will be able to download it directly. If you want it to be APT-friendly, you'll probably have to make a Packages file using dpkg-scanpackages. Never done it -- can't give more advice. HTH, Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Becoming a new developper
> >> > ar can't create .debs > >> > >> Er, why not? .debs are just ar archives with an empty file, > >> control.tar(.gz)? and data.tar(.gz)? in- you can certainly *read* > >>.debs with ar... > > > >There are some magic numbers involved afaik. > > It's simpler than that, it's the filenames in the archive, ar adds > them with a trailing slash, dpkg-deb does not. > I was able to produce a .deb with ar that dpkg-deb could read by > editing the archive with emacs to replace the / in each member name > with a space. Hey -- who said you were allowed to use emacs?! Next, you'll be wanting to use Perl as well... ;-) Long live ed! Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Autoconf question
> I am attempting to package a program that includes some icons. in
> Makefile.in, it has the following:
>
> [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
>
> So, when the package build process runs make with the argument
> 'prefix=/home/decklin/devel/xap/xap-0.7.7/debian/tmp', it has no
> effect on $icondir and make attempts to install the icons in
> /usr/share/icons. I am using fakeroot, which could be a problem.
> Am I missing something silly here?
You could change the icondir line in Makefile.in to read
icondir=${prefix}/share/icons
and your problem will be solved. Seems like it's a bug in the
Makefile.in.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: rc.boot
> pppconfig-1.9beta2.0 includes scripts that can swap in a resolv.conf > appropriate for the selected provider and swap the original back when ppp > goes down. Because a crash while ppp is up could leave the wrong file in > place I want to install a cleanup script in /etc/rc.boot. Lintian > disapproves of this: > > E: pppconfig: package-installs-into-etc-rc.boot etc/rc.boot/0dns-init > > What should I do? Is there some tool I must use to install a script in > rc.boot? /etc/rc.boot is deprecated. Install the script in /etc/init.d and use update-rc.d to install the necessary symlink into the right /etc/rc?.d directories. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: rc.boot
> On 28-Jun-99 John Hasler wrote: > > pppconfig-1.9beta2.0 includes scripts that can swap in a resolv.conf > > appropriate for the selected provider and swap the original back when ppp > > goes down. Because a crash while ppp is up could leave the wrong file in > > place I want to install a cleanup script in /etc/rc.boot. Lintian > > disapproves of this: > > > > E: pppconfig: package-installs-into-etc-rc.boot etc/rc.boot/0dns-init > > > > What should I do? Is there some tool I must use to install a script in > > rc.boot? > > > > rcS.d is the correct place. No it isn't. /etc/init.d is the correct place, with a symlink from /etc/rcS.d. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: rc.boot
> 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. > > For example, the `kbd' package provides a script here for initialising > the keyboard layout and console font and mode. > > The files in `/etc/rc.boot' should _not_ be links into > `/etc/init.d'--they should be the scripts themselves. > > `rc.boot' should _not_ be used for starting general-purpose daemons > and similar activities. This should be done using the `rc.d' > scheme, above, so that the services can be started and stopped cleanly > when the runlevel changes or the machine is to be shut down or > rebooted. > > Where is this deprecation documented? It's currently an accepted policy amendment and will appear in the next revision of policy. Check out the debian-policy bug report for details. rc.boot(5) is also explicit on this point. > > Install the script in /etc/init.d... > > 3.3.2. Writing the scripts > -- > > Packages can and should place scripts in `/etc/init.d' to start or > stop services at boot time or during a change of runlevel. > > I'm not starting or stopping any services. This script should run *only* > at boot, not when the runlevel changes. That's OK. Still put the script in /etc/init.d and use something like: postinst: update-rc.d dns-clean start 30 S . postrm:update-rc.d dns-clean remove Don't put the script itself in /etc/rcS.d: it will cause all sorts of problems if, for example, someone changes to the single rc file version (can't remember which package it's in). Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: rc.boot
> 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). Careful! You *must* use update-rc.d to install the symlink into /etc/rcS.d (with the correct options of course, as I've already posted). If you try to do things manually, you could end up hosing someone's system if they are using the file-rc package. You mustn't assume that the update-rc.d program works in the same way on all system setups. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: question about version number
[Charset iso-8859-1 unsupported, filtering to ASCII...] > Hello, > > I packaged a program that had 1.52 as upstream version number. Debian > version number was 1.5.2-1 That's a relief! > Now there is a new version upstream version numbered 1.6. > > Should I number it 1.6-1 or 1.6.0-1? Either would be fine. When version 1.61 is released and packaged as 1.6.1, the 1.6.1 will be regarded as newer than both 1.6 and 1.6.0. Check the Debian Packaging manual section 5 for details. > I hope this question is not too stupid. If it is please point me to the > appropiate documentation. To use a wrong version number without asking is stupid. Asking isn't. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: dh_suidregister
> Hi, > how do I use dh_suidregister correctly? > I was trying (using dh_make and co) with > dh_suidregister usr/bin/moon-buggy > but the the file is installed as root.root, which is bad AFAIK. > I couldnt find any option to set to change the user/group. > So I want the binary to be suid games and not root. Can it be done with > dh_suidregister or do I have to create the postinst by hand (shiver)? > Or should I just leave out the suid bit? No shared score files then... Firstly, it should be setgid games, not setuid games. See section 5.10 of policy (version 3.0.0.0). Secondly, dh_suidregister works by looking through your debian/tmp tree for setuid/setgid files. So you build the package with the required program being owned by root.games and having permissions 2755, and then dh_suidmanager will work perfectly. HTH, Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
-fPIC
[Sent to -mentors and -perl; I am not sure which is appropriate.] I have been working on creating a (binary) Perl module, and have noticed that by default, it will compile with a -fpic flag rather than a -fPIC one. Should I therefore append something like: CC=gcc CCCDLFLAGS=-fPIC to my make command in debian/rules? If so, would it be worth noting this in the Perl policy? Also, I presume that the shared libraries should then be stripped. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: new-maintainer@debian.org dead?
> [EMAIL PROTECTED] (Karl M. Hegbloom) writes: > > > Can you please try and fix `fakeroot' for us? > > And how without being maintainer should I upload any changes? Announce it on this list and ask for someone to do an NMU. You would be forever thanked for getting it working. (And it would be a good plus point for your application!) Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: things broke when I went to dpkg-dev 1.4.1.6
> On Mon, Aug 16, 1999 at 11:06:48PM +0200, Martin Bialasinski wrote: > > cv-buildpackage -rfakeroot broke, and Manoj advised to use > > -r"fakeroot --". Maybe this is the same problem with > > dpkg-buildpackage. > > Not maybe. It *is*. > > Another workaround is to define the environment variable POSIXLY_CORRECT. But be careful, as that could cause all manner of other problems where the non-POSIX behaviour is assumed. (Just consider echo -n, for example) Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: postinst?
> Hi,
> I am building a package, using debhelper scripts. Now I have to call a
> program (to create a score file with defined ownership) from the postinst.
> In the docs I found something about autoscript, but it seems I can not call
> it from debian rules. So how do I add a programm call in postinst using
> debhelper? (I could probably write the postinst myself, but I dont want to).
All that debhelper will do is to place appropriate lines in the
postinst to handle "standard" things such as info file installation,
window manager installation, suidregister and so forth. As soon as
you want to do something package-specific, you have to write your own
postinst. Incidentally, for debhelper to put *anything* in a
maintainer script ({pre,post}{inst,rm}), you need to have at least the
following minimal script:
#! /bin/sh
#DEBHELPER#
I don't believe that debhelper will create the script otherwise.
For your particular problem, you probably want something like (note
that this does nothing except change the timestamp if the file already
exists):
postinst:
-
#! /bin/sh
if [ "$1" = configure ]
then
if [ -d /var/games ]; then DIR=/var/games; else DIR=/var/lib/games; fi
touch $DIR/mylog
chown root.games $DIR/mylog
chmod 664 $DIR/mylog
fi
postrm:
---
#! /bin/sh
if [ "$1" = purge ]
then
if [ -d /var/games ]
then rm /var/games/mylog
else rm /var/lib/games/mylog
fi
fi
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: postinst?
> Hi,
> On Thu, 2 Sep 1999, Julian Gilbey wrote:
>
> > All that debhelper will do is to place appropriate lines in the
> > postinst to handle "standard" things such as info file installation,
> > window manager installation, suidregister and so forth. As soon as
> > you want to do something package-specific, you have to write your own
> > postinst. Incidentally, for debhelper to put *anything* in a
> What a pitty... right now I get a postinst.debhelper which contains:
> # Automatically added by dh_installmenu
> if test -x /usr/bin/update-menus ; then update-menus ; fi
> # End automatically added section
> and maybe more for sgid files.
Ah, so you then need to have #DEBHELPER# lines in your scripts.
> > maintainer script ({pre,post}{inst,rm}), you need to have at least the
> > following minimal script:
>
> > #! /bin/sh
> >
> > #DEBHELPER#
> >
> > I don't believe that debhelper will create the script otherwise.
> I have to put that into postinst and postrm? Then the update-menu and sgid
> stuff will be added by debhelper? Good then. Will try at home (can we have
> something like this in the documentation, as an example please?
And, if necessary, preinst and prerm. Have a look at which scripts
debhelper creates (like postinst.debhelper) in the debian/ directory.
> > postinst:
> > -
> > #! /bin/sh
> > if [ "$1" = configure ]
> > then
> > if [ -d /var/games ]; then DIR=/var/games; else DIR=/var/lib/games; fi
> > touch $DIR/mylog
> > chown root.games $DIR/mylog
> > chmod 664 $DIR/mylog
> > fi
> >
> > postrm:
> > ---
> > #! /bin/sh
> > if [ "$1" = purge ]
> > then
> > if [ -d /var/games ]
> > then rm /var/games/mylog
> > else rm /var/lib/games/mylog
> > fi
> > fi
> Thanks for the example, but I see no #DEBHELPER# ? I just add it after
> /bin/sh before my "private" script?
Yes, either that or at the end. Or somewhere else.
Have a look at section 6 of the packaging manual which explains how
the scripts are executed for a better understanding of what's going
on.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Dummy package question using apt-get source
> Dummy package question. > > So I build a package with debuild and all seems well. > > I dupload it to unstable, and the package seems well. > > I can install it from unstable, to my local machineok. > > It works fine...but when I try to apt-get source ean13 --compile > > I get the source unpacked fine, but the script dies with > dpkg --build debian/tmp .. > dpkg-deb: building package `ean13' in `../ean13_0.4-3_i386.deb'. > dpkg-genchanges -b > dpkg-genchanges: > binary-only upload - not > including any source code > dpkg-buildpackage: no source included in upload It looks like the script has completed quite happily. You should surely find that you now have a file ../ean13_0.4-3_i386.deb present? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: one on one help
> Thank you for your time. I am new to the debian word but I do have > a server in place. I would like to learn more about the system > such as trouble shooting, up keep of the system. I am running > version 1.3 right now and Have had no problems for over 100 > days. Hello John! The best places to go for help are the debian-user@lists.debian.org mailing list and #debian on irc.debian.org. Please note that debian-mentors@lists.debian.org is for new maintainers to receive help in creating packages. Have you considered upgrading to Debian 2.1 which was released many months ago? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: postinst?
> On Thu, Sep 02, 1999 at 02:27:51PM +0100, Julian Gilbey wrote:
> > Incidentally, for debhelper to put *anything* in a maintainer script
> > ({pre,post}{inst,rm}), you need to have at least the following minimal
> > script:
> >
> > #! /bin/sh
> >
> > #DEBHELPER#
> >
> > I don't believe that debhelper will create the script otherwise.
>
> It will. If you don't have postinst, but dh_* scripts create
> postinst.debhelper, dh_installdeb will copy that to
> debian/tmp/DEBIAN/postinst . Same goes for other p* scripts.
Isn't Joey wonderful?! He's thought of almost everything
Debhelper is simply fantastic.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: postinst?
> On Thu, 2 Sep 1999 14:27:51 +0100 (BST), Julian Gilbey > <[EMAIL PROTECTED]> said: > > > > postinst: > > - > > #! /bin/sh > > One is supposed to use the -e switch here, or to set it from inside. Oops, forgot that in my hurry! Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Semi-retiring: All (ok, some) packages must go!
I guess it would make sense for me to take this one, as I need to do some work on fvwm in the next couple of weeks anyway. (I'm meant to be the maintainer, but life just keeps getting in the way :) John: I'll probably email you on and off about what's going on as I begin to look at it soon. Julian >*** I wrote this a couple of years ago. The code is a mess, >but it was pretty stable. It is getting out of sync with >fvwm, but I don't know how much, since I don't use fvwm any >longer. The code is a mess, but I can help interpret if >someone wants to get it in shape for the latest fvwm. > Package: fvwmconf > Priority: optional > Section: x11 > Installed-Size: 411 > Maintainer: John Lapeyre <[EMAIL PROTECTED]> > Architecture: all > Version: 0.19-5 > Depends: perl-tk, fvwm2 (<< 2.2) | fvwm (>= 2.2) > Recommends: imagemagick | netpbm, imagemagick | xv > Size: 91110 > Description: Real-time interactive configuration of fvwm2. > Fvwmconf works only with fvwm2 (which is called fvwm > in Debian 2.2 and later). > This package allows users to interactively configure the > window manager fvwm2. It requires fvwm2, perl, perltk. > Colors, fonts, images, etc., can be browsed and applied > to decorations drawn on application windows. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Phone call to become debian maintainer
> The web page on becoming a debian maintainer states that my identity has to > be verified by mail, and that i will get a phone call after hours. > [...] If you intend to be a developer, *please* subscribe to debian-announce and debian-devel-announce. These are low-volume *important* lists. It was just announced by Wichert, I think in his capacity as Debian Project Leader (DPL), that new-maintainer is currently being revamped. There will be an announcement explaining the new system fairly soon, I would guess. This should answer your questions about the phone call. (I would assume, BTW, that the phone call will happen at a sensible time for you.) Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Phone call to become debian maintainer
> > Not at all. It is as mentioned, to verify your intentions, and to get a > > view on your personality - "Yes, I understand" vs. "Yeah, Ok, whatever." > > Okay, but where does this phone number go (how it it used)? I am > interested in becoming a Debian maintainer some day, but I don't want my > phone # posted all over the net, nor do I want anyone phoning me about > maintainer stuff, other than the verification call. It is used purely by the NM team to verify that you exist and that you understand and agree to follow the DFSG (Debian Free Software Guidelines). If you wish to make your phone number available to other developers, you can do so at https://db.debian.org/ once you are a developer. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: lintian: unknown-section unknown-priority
> True, but programs may intentionally ignore case. From the > packaging manual: > > 4.1. Syntax of control files > > > . . . > > Field names are not case-sensitive, but it is usual to capitalise the > fields using mixed case as shown below. > > . . . > > I have interpreted `fields' to refer to the _contents_ of the > fields, not the `Field names', but I see it could be interpreted > otherwise. Ah, an ambiguous phrase in the packaging manual. Will be corrected: s/fields/field names/. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Is there a policy on `task-' packages?
> I've searched all the docs I can find and trolled through the Debian > website, but I haven't seen any mention of `task-' as a prefix for a > package name. Does it have a specific meaning, and is there a policy? No policy yet. But they are intended as metapackages which contain no code, but depend on those packages necessary to do certain tasks. As an example, task-c-dev for development in C depends on task-devel-common, c-compiler, ... and suggests task-debug, a literate programming tool, Thus installing task-c-dev will ensure that you have all necessary packages for compiling a C program, and will suggest others that might be helpful. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: duplicate manpage
> Hello, > > After further testing, I managed to clear out some of the problems with the > package. > > One remains, though. > > I setup rules to exec configure, with --mandir=/usr/X11R6/man, and manpage > sufix=1x, in the Makefile. The result for this is a debian package with an > aterm.1x in /usr/X11R6/man/man1, and another "aterm.1" in > /usr/share/man/man1. I don't know why I get this second man page around, but > I guess it's something in the rules file. I've tried many, but cannot get > rid of it. The manpage should live in /usr/X11R6/man. If you're getting two copies as you say, you could try and trace it as follows: # Build the package, keeping a log debuild -us -uc 2>&1 | tee ../build.log less ../build.log # Then search for usr/share/man/man1 within the log That might give you some hints as to what is happening. If that doesn't help, just rm -f the extra copy just before you finally build the package. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: [A try again . . .] Mail Server
> Dear Mentor List; 'debian-mentors' is for technical help for packaging software for the Debian distribution. 'debian-user' is for usage questions. I am copying your mail there. You will probably get much more help from them. Julian > I would like to apologize for my previous mail where I placed redhat > instead of debian, I do ask for forgiveness. I currently use RedHat, but > I have been asked to migrate the services to a Debian environment. Now, > I use debian as a workstation, but have never tried as a server. That is > why I seek guidance, and unfortunatly, that is why my email address > begins with "redhat", due to my past situation. In the end, all boils > down to me being a new systems engineer in this area under debian, so I > would like to have some help. > > Much Respect > > John Smith [Original message follows:] Hello List ! Sorry for all the mystery and anonimatum. I am a person who is very interested in using redhat as my servers. I will need to mount a mail server with a backup mail server using fault tolerant systems. I want to use debian for this. I hope that my questions, or the way I form them don't bother you. Thanks in advance.My question is : 1. What is the best mail software for Redhat ? INFO : The mail server has to be SMTP / POP3 and WILL have a very nasty load of users. 2. What would be the best platform for this server ? INFO : We currently have COMPAQ Proliant's ranging from the 1600 to 7000 (Dual Processors). 3. What would be the best kernel for a vast majority of user load ? INFO : I am looking at 14.000 users, sending and recieving mail 4. What kind of software would be the best for fault tolerant systems ? INFO : If server A falls down, then server B takes over. Best Regards John Smith
Re: Questions about making package more conformant to Debian Policy...
> I am the maintainer of the powertweak package. I have the package in a > decent enough shape that I want to make the package more conformant to the > Debian Policy manual. Powertweak (http://linux.powertweak.com/) is a > software that tweaks various pieces of hardware for optimum / increased > performance. > > Here are my questions: > > * The upsteream author is placing the powertweak binary under /sbin. > Should I change this to /usr/sbin? Isn't /sbin the place for system > binaries? Not critical for fixing a broken system => in /usr/sbin. Section 3.10 of the FHS contains: /sbin typically contains binaries essential for booting the system in addition to the binaries in /bin. Anything executed after /usr is known to be mounted (when there are no problems) should be placed into /usr/sbin. > * Powertweak is not a daemon. It can be run either at boot time or by > root. Currently I have a rc script under /etc/init.d to run powertweak on > start-up. The policy manual says in section 3.3.4: > > "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." > > Does this mean that I should place my script under /etc/rc.boot instead of > /etc/init.d? In the soon-to-be-released debian-policy 3.1.0.0, it explains that: - the script itself lives in /etc/init.d - symlinks should be made from /etc/rcS.d/S??script -> /etc/init.d/script and from /etc/rc[06].d/K??script -> /etc/init.d/script or whatever is appropriate, *using the update-rc.d script* in the postinst/postrm maintainer scripts - /etc/rc.boot is obsolete Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
ANN: Remote package signing
After two people mentioned the need for a program to sign remote .changes/.dsc files devscripts 2.4.0 contained debrsign, this assumes that you are working on the machine where the build happened and you want to sign on a remote, SSH-accessible machine. But if the converse happens, where the remote machine did the build, one would need to copy the files over manually, use debsign (formerly known as signchanges) to sign them and then copy them back. I have just uploaded devscripts 2.4.1 in which debsign has a new option: -r [EMAIL PROTECTED] This will automate the process of copying the files from the remote machine, signing them locally and copying them back. Enjoy! Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Signing remote packages (again)
> Hi, > I need to upload some packages but don't have access to any current potato. > Could someone take me through signing packages built in remote machines > again? Please include me in the CC as I am not currently subscribed to the > list. > > Thanks, > Luis. Download and install the current potato devscripts. It should work fine on a slink system, except that you will need to modify your /etc/manpath.config to include /usr/share/man if you want to read the manpages. Then you can run debsign -r [EMAIL PROTECTED] build/foobar/foobar_1.3_alpha.changes HTH, Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: tcl8.0/tk8.0 and tcl8.2/tk8.2 at the same time?
On Mon, Nov 15, 1999 at 09:35:01AM -0800, [EMAIL PROTECTED] wrote: > On Sat, 13 Nov 1999 13:09:35 +0200 > Tommi Virtanen <[EMAIL PROTECTED]> wrote: > > > Does the requested mean that he would like me to split the package > > into lavaps-tcl8.0 and lavaps-tcl8.2, or can tcl8.2 somehow > > provide tcl8.0 compability? > > Almost anything anything that runs under Tcl8.0 will run under > Tcl8.2. I suspect your dependency should not be on Tcl8.0 but on > Tcl >= 8.0. You mean tcl8.0 | tcl8.2, or perhaps tclsh if you can use tcl7.6. But we don't yet have versioned Provides AFAIK, so you can't yet say tclsh (>= 8.0). Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Upgrading packages?
On Sun, Nov 21, 1999 at 08:34:09PM +0100, peter karlsson wrote: > However, the uupdate reported a problem, complaining that 0.6 is less than > 0.52, which was the previous version. I "fixed" this by changing the version > number to 0.60, is that the correct way of doing it? 6 < 52. See the packaging manual, section 5. Your solution seems reasonable if the intention is that 0.52 < 0.6. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: setgid stuff
On Tue, Nov 23, 1999 at 02:47:31PM +0100, peter karlsson wrote: > Peter S Galbraith: > > > Can debhelper do this? Yes, see the man page for dh_suidregister > > I can't figure it out. I have created a debian/suid file: > > ===[ cut ]=== > jwhois /usr/bin/jwhois root users 2755 > ===[ cut ]=== No. Do the following in debian/rules: chmod 2755 /usr/bin/jwhois # at some later point dh_suidregister # and later still dh_fixperms Now you have three possibilities for what to do next: (1) Nothing. dh_suidregister will search for any files which have their suid or sgid bits set and register them. (2) Create a debian/suid file with the single line /usr/bin/jwhois (3) Specify this on the dh_suidregister command line, so replace the line in debian/rules with: dh_suidregister /usr/bin/jwhois HTH, Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: setgid stuff
On Tue, Nov 23, 1999 at 08:32:39PM +0100, peter karlsson wrote: > Julian Gilbey: > > > chmod 2755 /usr/bin/jwhois > > I can't seem to get this (+chown) past. I'm creating the package using > fakeroot, which might be the problem. fakeroot shouldn't have a problem with this. What error messages are you getting when you try to chown/chmod? I think, BTW, that I meant: chmod 2755 debian/tmp/usr/bin/jwhois That could be the problem (And change debian/tmp to whatever is appropriate.) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: setgid stuff
On Wed, Nov 24, 1999 at 10:09:53PM +0100, peter karlsson wrote: > I do have it pointing to debian/tmp. The output doesn't list any errors: > > > chmod 2755 debian/tmp/usr/bin/jwhois > chgrp users debian/tmp/usr/bin/jwhois > [...] > dh_suidregister /usr/bin/jwhois What's the [...]? What do you see if you do ls -l debian/tmp/usr/bin/jwhois *immediately* before dh_suidregister? Is something in [...] (such as dh_fixperms) changing the permissions? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: setgid stuff
On Thu, Nov 25, 1999 at 12:58:17PM +0100, peter karlsson wrote: > Julian Gilbey: > > > Is something in [...] (such as dh_fixperms) changing the permissions? > > Ah! dh_fixperms did indeed fiddle with the permissions, after moving the > chmod downwards it works just fine. Thanks! I quote from my inital message on the subject: > No. Do the following in debian/rules: > chmod 2755 /usr/bin/jwhois > # at some later point > dh_suidregister > # and later still > dh_fixperms Note the dh_fixperms is at the end of this sequence, and must be: Debian packages should not ship with any special bits set (except for symlinks and directories). Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
debhelper: dh_fixperms should come after dh_suidregister (was: Re: setgid stuff)
Package: debhelper Version: 2.0.74 On Sat, Nov 27, 1999 at 12:26:50PM +1100, Brian May wrote: > >>>>> "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes: > > Julian> Note the dh_fixperms is at the end of this sequence, and > Julian> must be: Debian packages should not ship with any special > Julian> bits set (except for symlinks and directories). > > The slink version of debhelper puts "dh_fixperms" before > "dh_suidregister": > > dh_fixperms -a > dh_suidregister -a > > I hope this has been fixed in the potato version... No it hasn't (at least not in the examples). Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: debhelper: dh_fixperms should come after dh_suidregister (was: Re: setgid stuff)
On Sat, Nov 27, 1999 at 02:57:45PM -0800, Jim Lynch wrote: > Hi, > > and -no-. > > If you put fixperms after suidregister, you undo its work. Also, fixperms > establishes a "perm baseline" that you modify by adding calls to chown and > chmod after fixperms and before suidregister. You make this change, you break > that. It works nicely :) Don't break it :) It's not broken, and this is not > a fix. Ah, I see. I jumped too quickly. Am closing this "bug" report. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: debhelper: dh_fixperms should come after dh_suidregister (was: Re: setgid stuff)
> With all due respect, I think you misunderstood the problem. > > The problem here is that "dh_fixperms" runs *before* "dh_suidregister". > This is how dh_make, from slink does it. I have heard potato > might be that same. > > 1. dh_fixperms removes the setuid bit. > > 2. dh_suidregister fails to register the program, since the setuid > bit was already removed. dh_suidregister cannot remove the > suid bit, as it was already removed. >From the example /usr/(share/)doc/debhelper/examples/rules in potato: [...] dh_fixperms # You may want to make some executables suid here. dh_suidregister [...] The comment is part of the example Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: debhelper: dh_fixperms should come after dh_suidregister (was: Re: setgid stuff)
On Sun, Nov 28, 1999 at 12:13:55PM +1100, Brian May wrote: > My observation (nothing more/less, however, probably a good idea > in general): > > This means that it is the debian maintainer's decision to have a > SetUID program, not the upstream maintainer (as dh_fixperms overrides > anything set by the upstream Makefile). > > At least, the Debian maintainer must be aware of programs that are > SetUID. It's a good point, and yes, a package maintainer *must* be aware of every setuid/setgid program in their package. Each one presents a potential security risk, and must be checked out: which user/group should this executable run as? Does it really need to be setuid/setgid? And so on. (For /bin/su the answer is yes, for /usr/X11R6/bin/xlock, the answer would be no now that we have a PAMified xlock.) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Lintian: pkg-without-shlibs-has-shlibs-control-file
On Mon, Nov 29, 1999 at 09:58:55PM -0500, Ben Darnell wrote: > debian/rules to not run dh_shlibdeps on the -dev package, but it didn't > fix it. Also, I made a mistake in my previous report - the > pkg-without-shlibs-has-shlibs-control-file error occurs in both the > wxgtk2.1 and wxgtk2.1-dev packages. The main packages has a .so file; > -dev just has symlinks to them. The main package should have the /usr/lib/libwx_gtk-2.1.so.11.0.0 and /usr/lib/libwx_gtk-2.1.so.11, and the -dev package should have the /usr/lib/libwx_gtk-2.1.so symlink. See the packaging manual, section 12. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: dh_shlibdeps warnings
On Tue, Nov 30, 1999 at 06:58:24PM -0600, Laurence J Lane wrote: > This isn't a grave problem, but warnings in my packages tend to > disturb me. I have a package that will be split into bins, libs, > and a dev. dh_shlibdeps always gives a warning about the ldd > output from the libs when they're not already installed, in the > ld.so path. > > When I try "dh_shlibdeps -ldebian/libepplet0/usr/lib", I get this: > > dpkg-shlibdeps: warning: unknown output from ldd on > `debian/epplets/usr/bin/E-Mountbox.epplet': `libepplet.so.0 => > debian/libepplet0/usr/lib/libepplet.so.0 (0x40019000)' You can get rid of this warning by using dh_shlibdeps -l`pwd`/debian/libepplet0/usr/lib for then the directory name will be absolute (and dpkg-shlibdeps expects this). You will, however, replace the warnings with other warnings about being unable to locate the package containing /usr/local/.../debian/libepplet0/usr/lib/libepplet.so.0. Can't win! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: What is a NMU-fixed-outstanding bug ?
On Thu, Dec 02, 1999 at 10:41:10PM +0100, Christian Hammers wrote: > Subject says all. It is something to worry about ? > I guess it's because I'm listed as "Christian Hammers" but mail > as Christian Hammers. How can I change this ? The latest release > has the maintainer right without quotes. "NMU fixed bug" is a bug with severity "fixed". dinstall sets the severity of a bug to "fixed" if it is closed by an upload where the Maintainer field of the .changes file (usually deduced from the changelog) is different from the Maintainer field of the control file of the package. "Different" is a string comparison, I believe. To close a bug, send a meaningful message to [EMAIL PROTECTED] See /usr/doc/debian/bug-maint-info.txt for more information. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: portsentry´s dirs and permissions
[Please set your line length to <=72 characters per line!] On Mon, Dec 06, 1999 at 10:55:43AM +0100, Guido Guenther wrote: > Hi, > I´m still on that portsentry package and unsure about the proper directories > and permissions for some files, any comments greatly appreciated: > - upstream sets the configuration files 600, I changed that to 644 > - Currently I put all state-enigne & log-files into /var/lib/portsentry. To my > understanding of the policy the portsentry.blocked.* (state engine) files > should go into /var/state/portsentry and the log-file portsentry.history > into /var/log/. Right? Should portsentry.history then be renamed to > portsentry.log? Which version of policy do you have? From 3.1.0.0 onwards, policy contained the FHS 2.1 pre-3 draft, which has deprecated /var/state in favour of /var/lib. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: How to handle multiple versions of binaries
On Sun, Dec 12, 1999 at 05:13:27PM -0800, [EMAIL PROTECTED] wrote: > > Also, if the minimal game dataset does need to be customized before use, > > /usr/share/doc//examples sounds right to me -- throwing them in > > /usr/lib/ and requiring customization Just Seems Wrong -- they > > really *are* examples. > Thing is, the dataset will be copied in under > /usr/local/games/// > and a local configuration file generated there. That's why putting it > under documentation looked wrong to me. [See also below] Your package should make no assumptions about the existence of /usr/local; it's entirely at the discretion of the sysadmin what to put there. *If* there is an appropriate file there, it should be used in preference/addition to the one in /usr, but your package must function perfectly without it. Configuration files *must* go in /etc and be marked as conffiles or otherwise handled carefully (see policy (version >= 3.1.0.0) section 4.7). Your program cannot assume that /usr/(share/)doc exists. If it needs to read these configuration files, they should go in /usr/share/ or /usr/lib/ or /etc (or /etc/) depending on whether they are locally configurable and if not, then whether they are architecture independent. Have a look at the FHS (/usr/share/doc/debian-policy/fhs/fhs*) for details of this. > > > The script to start the server by hand will go in /usr/bin/, and can also > > > be started automatically at runlevel. I would like to place the ELF > > > binaries under /usr/lib/ Yes, that's correct. > > > I've read through the packaging manual, and might be a little confused, > > > but it didn't seem quite clear on just where to put these. > > > If /usr/lib/ isn't the right place, where is? They need to be > > > somewhere not on PATH and under a subdir. You need to also look at policy, in the debian-policy package, and at the Filesystem Hierarchy Standard, found in the debian-policy package. Easy, isn't it?! > > > Also, I will be packaging up a minimal game dataset for the server, and I > > > want to have a script the admin can use to copy it somewhere under > > > /usr/local/games and customise it. Where should I install the sample > > > dataset? The manual seems to indicate /usr/share/doc//examples, > > > but that doesn't seem right to me in this case. My gut feeling is > > > /usr/lib// because it isn't meant to be > > > used before customisation. If the dataset is architecture independent, as it probably is if it is modifiable, then you should be using /usr/share/ and /usr/local/share/ rather than the lib directories. What happens if the sysadmin installs the package and isn't interested in customising it for the users? Is there a default dataset? Is there a search path to look through? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: How to handle multiple versions of binaries
On Sun, Dec 12, 1999 at 11:34:23PM -0800, [EMAIL PROTECTED] wrote: > Disclaimer: IATTIMS ?? > On Mon, 13 Dec 1999, Julian Gilbey wrote: > > Your package should make no assumptions about the existence of > > /usr/local; it's entirely at the discretion of the sysadmin what to > > put there. *If* there is an appropriate file there, it should be used > > in preference/addition to the one in /usr, but your package must > > function perfectly without it. > > H. Package makes the assumption that it can load the server for any > datasets stored under /usr/local/games/// I'm not sure what you mean by this. What's a "server" in this context? It's fine to make use of things under /usr/local, of course. > According to how I read the packaging manual this is /encouraged/, AFA the > package can function without anything actually being under /usr/local. > I also intend to supply a script, to be run by the sysadmin, to assist in > setting up a dataset in the abovementioned directories. Sounds fine. > AFAICT both functions are reasonable. Both /supporting/ the use of a > directory under /usr/local if the local admin so wishes, and the supplying > of a script to assist the admin in correctly configuring anything sie > wishes to have under /usr/local. Sounds helpful. However, I don't know that much about your package: Why is it necessary to set up local datasets? Why can the package not have sensible default datasets? Might individual users want different datasets? What happens during an upgrade if the format of the datasets changes as you're not meant to touch stuff in /usr/local automatically in general? > > Configuration files *must* go in /etc and be marked as conffiles or > > otherwise handled carefully (see policy (version >= 3.1.0.0) section 4.7). > > Okay. You're not saying that any configuration-like files the server uses > internally must go under /etc, do you? :> If they're intended to be modifiable by the sysadmin, then yes. I guess that datasets do not come under this category. Why can't you have the default data in /usr/games and a file in /etc to select the particular data to be used? Again, though, I know nothing about your package. > > You need to also look at policy, in the debian-policy package, and at > > the Filesystem Hierarchy Standard, found in the debian-policy package. > > Easy, isn't it?! > > Will have another look. I admit some bits are confusing even after the > second read-through. Please file bug reports about the confusing things so that we can try to clarify them. > > If the dataset is architecture independent, as it probably is if it is > > modifiable, then you should be using /usr/share/ and > > /usr/local/share/ rather than the lib directories. > > > > What happens if the sysadmin installs the package and isn't interested > > in customising it for the users? Is there a default dataset? Is > > there a search path to look through? > > I'm intending to make the server a seperate package from the dataset(s), > and to have a -common package on the current assumption I'll have > two seperate servers for a while. > > The init scripts will have an option to load any datasets found under > certain users' home directories as well. As long as this is controllable by the user, I would guess. > So what it looks like at this point: > > Main configuration file in /etc/.conf > > ELF binaries installed in /usr/lib// > > Wrapper script installed in /usr/bin/ > > "default" dataset(s) installed in /usr/share// > > Init script checks in /usr/local/games/// and optionally > ~//.// for valid datasets to load. ~/... > As far as I can tell at this point it looks about right. I'm not missing > anything very major, am I? Sounds fine. Good luck! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: config files
On Thu, Dec 23, 1999 at 11:04:49AM +1100, Brian May wrote: > Hello, > > what is the best way to > > > 1. automatically prompt the user for configuration information > > 2. store this in a config file in such a way that any customizations > the user may have made are not lost > > 3. allow for changes by the upstream maintainer. > > > If have looked at debconf, but this only seems to solve 1. > > I am sure I have seen ideas on 2 and 3, but can't seem to find them > now. > > If nothing has been standardised, I will invent my own method (I have > some good ideas on how to do this), but thought this was a common > situation... I believe that debconf does, indeed, address all three issues. I haven't yet converted my packages to use debconf, though, so I can't help further. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: dh_shlibdeps warnings
On Tue, Nov 30, 1999 at 08:12:07PM -0800, Joey Hess wrote: > Julian Gilbey wrote: > > You can get rid of this warning by using > > dh_shlibdeps -l`pwd`/debian/libepplet0/usr/lib > > for then the directory name will be absolute (and dpkg-shlibdeps > > expects this). > > > > You will, however, replace the warnings with other warnings about > > being unable to locate the package containing > > /usr/local/.../debian/libepplet0/usr/lib/libepplet.so.0. > > Hmm. > > I'd make debhelper force that path to an absolute one if it didn't result in > this. If anyone has a better idea, let me know. Modify dpkg-shlibdeps to not issue a warning if the library lives under the current working directory and dpkg -S does not recognise it. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Proposing debugging aid in scripts
On Sat, Jan 08, 2000 at 08:19:56PM +0100, Christian Hammers wrote:
> Hello
>
> Since I begun using debconf I had very much problems because my scripts
> suddenly were completely silent as I removed all the nice "echo"
> commands that before told me what was going on.
>
> To solve this problem (verbose for me, no output for users), I started
> inserting the following line in all my postinst/preinst etc. scripts:
>
> $DEBIAN_SCRIPT_DEBUG || set -v -x
>
> This helped me very much. Does anybody has similar tricks, too ?
if [ -n "$DEBIAN_SCRIPT_DEBUG" ]
then
echo=echo
else
echo=:
fi
Then use $echo everywhere.
Alternatively, use something like:
if ...; then echo(){ command echo "$@"; } ; else echo(){ } ; fi
and then use echo normally from then on.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: directory not empty message
On Sun, Jan 09, 2000 at 04:04:39PM +0100, Christian Hammers wrote: > Hello list > > When purging my mysql-server package I always get the following message: > Purging configuration files for mysql-server ... > dpkg - warning: while removing mysql-server, directory `/var/lib/mysql' > not empty so not removed. > > How can I get rid of it ? I tried to do a > if [ "$1" = "purge" ]; then rm -rf /var/lib/mysql; fi > in the prerm script but it seems that it always gets called with > "remove" as argument and postrm is the only script that gets called > with "purge". > > Any ideas ? dpkg bug. Don't worry about it. One thought, though: has the directory actually disappeared at the end of the dpkg run? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Create .changes file
On Wed, Jan 12, 2000 at 01:31:38AM +0100, Gergely Madarasz wrote: > On Wed, 12 Jan 2000, Holger Eitzenberger wrote: > > > So, GLE now builds fine, the source and binary package files are > > build, lintian has just one warning (spelling error). One problem though: > > i have read the packaging-manual but i still don't know how to make a > > .changes file... > > generate the source package, binary packages and the .changes file with > one command: > dpkg-buildpackage [-rfakeroot] Or debuild in the devscripts package (which needs a bit of updating, but I haven't had the chance recently -- should change in a few weeks, I hope). Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Create .changes file
On Wed, Jan 12, 2000 at 05:30:03PM +0100, Holger Eitzenberger wrote: > On Wed, Jan 12, 2000 at 02:10:21PM +0000, Julian Gilbey wrote: > > > > generate the source package, binary packages and the .changes file with > > > one command: > > > dpkg-buildpackage [-rfakeroot] > > > > Or debuild in the devscripts package (which needs a bit of updating, > > but I haven't had the chance recently -- should change in a few weeks, > > I hope). > > The problem is actually that i am still using pgp5 and the fact that > dpkg-genchanges gives an '-s' to the signing prog which pgp5 doesn't > recognize. I guess the easiest way for me is to put my gpg-key in the > Debian keyring... Huh? Either use pgp2 and the -ppgp -spgp options to either of the two programs in question, or use gpg. You can even tell gpg to use your pgp key if you have the gpg-rsaref package, I believe. But I'm not certain about license and patent issues, so please be careful. Anyway, have a play! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Binary Changes Drill
On Fri, Jan 21, 2000 at 01:44:46AM -0600, Paul Serice wrote: > What's the drill whenever I have "binary changes" to the upstream > tarball? I ask because there are some chess images (gif format) > that make for a nice html-based cmoputer annotation of games > that aren't distributed with the main Crafty source. > > Right now, I've just copied the images into "debian" and would > like to just copy them to their final resting place in "rules". > > dpkg-buildpackage does not like this scheme. Please, what are > my options? uuencode (or tar.gz them and then uuencode the .tar.gz) the binary files before creating the package. Then uudecode them in the rules file. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Build-Depends?
On Sun, Jan 23, 2000 at 11:58:31AM -0800, Seth R Arnold wrote: > On Sun, Jan 23, 2000 at 02:47:53PM +0200, Antti-Juhani Kaijanaho wrote: > > On Fri, Jan 21, 2000 at 10:09:37AM -0800, Seth R Arnold wrote: > > > I am not a packaging expert, but I think you are missing a single lone `.' > > > in the control file in place of the blank line. > > > > If I understand you right, you are wrong. > > Which file is it that requires no blank lines? The Description: field in the control file. Not the whole file. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
