Debian
I new, and I need to install Debian in my PC. I have downloaded all files I need, so now I have to generate disks for installation. I would be very please if someone could explain me how to do it, and the first step when installing. Thanks,
Re: Debian
On Sat, Feb 24, 2001 at 02:58:36AM -0500, Nuria Lope Gil wrote: > > I new, and I need to install Debian in my PC. I have downloaded all files I > need, so now I have to generate disks for installation. > I would be very please if someone could explain me how to do it, and the > first step when installing. The installation process is quite well documented. http://www.debian.org/releases/stable/#new-inst If you have trouble you can also try asking on debian-user, it is more appropriate than debian-mentors - brian. -- Brian Russo <[EMAIL PROTECTED]> Debian/GNU Linux <[EMAIL PROTECTED]> http://www.debian.org LPSG "member"<[EMAIL PROTECTED]> http://www.lpsg.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Caught in the act
On Friday 16 February 2001 00:15, Martin Albert wrote: > Hello to all friendly people reading this ... > > I'm pkging new upstream of a quite basic lib (libgii). And that was looong ago. Sorry, that i didn't say thanks to Matt Zimmerman, Ingo Saitz, Brian Russo, Hamish Moffatt earlier for your kind response. I was busy with that stuff to the end - and learned a lot. Now my decision based on your answers (and the impossibility to flush dpkg's cache as a package being installed) was to - package according to policy the small binaries to -dev, - that means simply downgrading is not possible without removing first - have a README.Debian saying so nicely :) Anybody interested in a summary of this topic: mail me. Thank You, greetings, martin
Re: Package checking
> On Fri, Feb 23, 2001 at 08:30:49AM -0800, Sean 'Shaleh' Perry wrote: > > you also fail to install a menu file. I am coming up with a > > lintian check for packages linked to X and not installing one. So > > you reminded me of another bug (-: No, i'm sure you wouldn't do that. :) libggi-target-x links X but will never have a menu entry. tnx for your work. martin -- Cross Building nano HOW-TO V 0.2 http://eisdoc.debox.de
Re: Package checking
On Fri, Feb 23, 2001 at 11:16:16PM -0600, Sam TH wrote: > samth# lintian --version > Lintian v1.20.6 > samth# lintian -i uf-view_1.2-2_i386.changes > W: uf-view source: newer-standards-version 3.5.2.0 > > I presume this is a lintian bug. Right? No, this is because your standards version is 3.5.0, and the current version is 3.5.2 Another thing: you should use a newer debian/rules file. There is a new target 'configure' which you can use to call ./configure. When doing this, look out if you have to depend on debhelper >= 3.0. Yet another thing: your Build-depends seems wrong. Policy says: 'A source package may declare a dependency or a conflict on a binary package', but your are depending on a source package (libghttp), not the binary package (libghttp1). Ah, no, it should be libghttp-dev, the header package. Hmm, the configure file should also check for ghttp.h, it didnt complain when I run it without having ghttp.h, but compiling fails: [...] gladesig.c:6: ghttp.h: No such file or directory Bastian pgp8yVQOKJJTF.pgp Description: PGP signature
Re: /etc/ question
"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: >On 23-Feb-2001 Amaya wrote: >> Of course not! ;-) I'd just move them to the new location. >> But, I'm starting to think this is not a good idea, maybe. > >after talking with other devels here is a method: > >in your preinst, check for /etc/foo and if it exists, mkdir /etc/package and >copy /etc/foo there. Then remove /etc/foo. Import thing here is that the >preinst should not die because of any errors here. > >Your package contains /etc/package/foo. When dpkg gets to the point where the >conffile will be installed, it will do the usual checking if the conffile >should be changed and prompting the user. You have to be even more careful than that, since the installation might fail and dpkg might want to unwind the maintainer scripts - so 'postrm abort-upgrade' and 'postrm abort-install' need to move the file back if possible. -- Colin Watson [EMAIL PROTECTED]
Re: Policy and conffile editing
Aaron, On Fri, Feb 23, 2001 at 02:02:53PM -0800, Aaron Lehmann wrote: > It seems this is at odds with policy, which prohibutes the automated > editing of conffiles (such as squid.conf). This is a bit ironic, since > asking 'Would you like to enable this package by inserting a line FOO > into /etc/squid.conf? [Y/n]' is much cleaner than printing a note 'You > must run the script /usr/sbin/setupthispckage to enable this package'. > While both of those would acomplish essensially the same thing, only > one would be permissible by policy. > > What should I do in regards to editing this conffile? You should not change (semi-)automatic the squid.conf by asking debconf questions. Those changes are vital and the admin should make these changes by hand. Take a look in login.app. It displays a message to change your inittab accordingly (change default runlevel for example). If you really think you want to change this automatically, you can ask the squid maintainer to remove /etc/squid.conf from his conffiles. Then ask him to include a configuration script in his package which modifies squid.conf accordingly. Then use this script to make your changes (for example update-inetd is one such script for /etc/inetd.conf). Bastian pgp0fCQt13LaF.pgp Description: PGP signature
Re: Package checking
On Sat, Feb 24, 2001 at 12:25:01PM +0100, [EMAIL PROTECTED] wrote: > On Fri, Feb 23, 2001 at 11:16:16PM -0600, Sam TH wrote: > > samth# lintian --version > > Lintian v1.20.6 > > samth# lintian -i uf-view_1.2-2_i386.changes > > W: uf-view source: newer-standards-version 3.5.2.0 > > > > I presume this is a lintian bug. Right? > No, this is because your standards version is 3.5.0, and the current > version is 3.5.2 > Actually, my standards version is 3.5.2.0. And the lintian explanation for this is: N: The source package refers to a `Standards-Version' which is newer than N: the one lintian is programmed to check. If the source package is N: correct, then please upgrade lintian to the newest version. (If there N: is no newer lintian version, then please bug [EMAIL PROTECTED] N: to make one.) So I think it is a lintian bug. > Another thing: you should use a newer debian/rules file. There is a new > target 'configure' which you can use to call ./configure. > When doing this, look out if you have to depend on debhelper >= 3.0. > What's the advantage to using this? I couldn't find any references in the debhelper docs or in policy to it. Would this be different that having a private configure target for the internal use of the build system? > Yet another thing: your Build-depends seems wrong. > Policy says: 'A source package may declare a dependency or a conflict > on a binary package', but your are depending on a source package > (libghttp), not the binary package (libghttp1). Ah, no, it should be > libghttp-dev, the header package. Doh. Fixed. > Hmm, the configure file should also check for ghttp.h, it didnt complain > when I run it without having ghttp.h, but compiling fails: > [...] > gladesig.c:6: ghttp.h: No such file or directory Fixed. New package at the same location, deb[-src] http://samth.dyndns.org/debian ./ Thanks for your help sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgpyYYmcS9pqZ.pgp Description: PGP signature
Re: Policy and conffile editing
On Sat, 24 Feb 2001 [EMAIL PROTECTED] wrote: > If you really think you want to change this automatically, you can ask the > squid maintainer to remove /etc/squid.conf from his conffiles. If it's necessary to remove it from conffiles in order to edit it from a script in /usr/sbin, then both sgml-base (/etc/sgml/transitional.cat edited by install-sgmlcatalog) and mime-support (/etc/mailcap edited by update-mime) violates this policy.
Making a package arch independant
I've taken one of my packages (dnet-common) and turned its only binary into a shell script so that the package is now architecture independant. If I just upload the new dnet-common_2.09-1_all.deb, will it remove the existing dnet-common_2.08-1_i386.deb or do I have to do anything special? patrick
Re: debian revision numbers for gnome-utils
On Fri, 23 Feb 2001, Jochen Voss wrote: > last week I prepared a new package for the gnome-utils package > and asked for a sponsor. As nobody volunteered this one was > not uploaded to the server. > > Now I did some additional fixes (add a man page, ...) and > want to prepare a new package. Should I increase the > Debian revision number for this (to avoid possible confusion) > or should I just replace my files with new version (to keep > the revision numbers of official versions contiguous)? Since you didn't uploaded the old package to incoming, katie does not know it exists, so it will not complain if you upload it without increasing the Debian revision number. This is a matter of taste, really. Some people think of the changelog (and related Debian revision numbers) as the complete history of all the changes made to the package, either public or private. Some other people think it is ok that the changelog documents only *released* versions of the package. In short, it's up to you.
Re: /etc/ question
Colin Watson dijo: > You have to be even more careful than that, since the installation might fail > and dpkg might want to unwind the maintainer scripts - so 'postrm > abort-upgrade' and 'postrm abort-install' need to move the file back if > possible. Thanks a lot. I had not taken that into account 0:-) -- If you don't spend energy getting what you want, you'll have to spend it dealing with what you get. - Unknown Proudly running Debian GNU/Linux Sid (Kernel 2.2.17) on this Dell Laptop pgpGSnZlFVB38.pgp Description: PGP signature
Re: debian revision numbers for gnome-utils
On Sat, Feb 24, 2001 at 02:56:46PM +0100, Santiago Vila wrote: > In short, it's up to you. I was told that "Closes: #12345"-like entries in the changelog only close bugs which are mentioned in the most recent release. You must close bugs in older (but not uploaded) releases manually. So it may be easier to not increase the revision number too often. Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html pgpBkJ1e4c0dR.pgp Description: PGP signature
Re: debian revision numbers for gnome-utils
On Sat, Feb 24, 2001 at 05:28:52PM +0100, Jochen Voss wrote: > On Sat, Feb 24, 2001 at 02:56:46PM +0100, Santiago Vila wrote: > > In short, it's up to you. > > I was told that "Closes: #12345"-like entries in the changelog > only close bugs which are mentioned in the most recent release. > You must close bugs in older (but not uploaded) releases > manually. You can compensate for this with the little-known -v option to dpkg-buildpackage. If you're building version 1.3, and the latest version in the archive is 1.1, you can specify -v1.1 to get all the changelog entries after 1.1 in your changes file. Richard Braakman
Re: Package checking
On Saturday 24 February 2001 14:22, Sam TH wrote: > On Sat, Feb 24, 2001 at 12:25:01PM +0100, [EMAIL PROTECTED] wrote: > > Yet another thing: your Build-depends seems wrong. > > Policy says: 'A source package may declare a dependency or a > > conflict on a binary package', but your are depending on a source > > package (libghttp), not the binary package (libghttp1). Ah, no, it > > should be libghttp-dev, the header package. > > Doh. Fixed. > > > Hmm, the configure file should also check for ghttp.h, it didnt > > complain when I run it without having ghttp.h, but compiling fails: > > [...] > > gladesig.c:6: ghttp.h: No such file or directory > > Fixed. Ahm, sorry, i'm new to this and don't know much yet, but: I think Build-Depends: libghttp-dev should be sufficient. > > Hmm, the configure file should also check for ghttp.h, it didnt This produces unnecessary hassles when, for instance, cross compiling. greetings, martin -- Cross Building nano HOW-TO V 0.2 http://eisdoc.debox.de
Re: Package checking
On Sat, Feb 24, 2001 at 06:21:13PM +0100, Martin Albert wrote: > On Saturday 24 February 2001 14:22, Sam TH wrote: > > On Sat, Feb 24, 2001 at 12:25:01PM +0100, > [EMAIL PROTECTED] wrote: > > > Hmm, the configure file should also check for ghttp.h, it didnt > > This produces unnecessary hassles when, for instance, cross compiling. > I don't see why. The package isn't going to compile if $host doesn't have ghttp.h on the system. Sure, $target doesn't need it, but I don't see how that will matter to configure. Configure gets run on $host, which is where the file needs to be. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgp00C3K811BB.pgp Description: PGP signature
.debhelper files
When I run debhelper on pristine source tree, *.debhelper files are created. Are they examples, or should they be included in the final package ? Thanks. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
checking dependencies
Hi, I've read several times here that you can use chroot to check dependencies when building a package. How shoud I do it ? Thanks. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
dh_installdeb & postrm
Hi, >From what I understand of the doc, debian/tmp/DEBIAN/postrm is generated from debian/postrm.debhelper. Now if I add a line to debian/postrm.debhelper, everytime I re-build my package (dpkg-buildpackage -rfakeroot), this line is erased. Where do I have to declare my cutomized commands ? man dh_installdeb doesn't help and is a bit confused : > dh_installdeb automatically installs the following files > from debian/ into the DEBIAN directory: >package.postinst >package.preinst >package.postrm >package.prerm >package.shlibs >package.conffiles > > The postinst, preinst, postrm, and prerm are handled spe- > cially: If a corresponding file named debian/script.deb- > helper exists, the contents of that file are merged into ^^ debian/script.debhelper ? > the script as follows: If the script exists, then anywhere ^^ debian/script.debhelper again ?? File merged into itself ? > in it that "#DEBHELPER#" appears, the text of the .deb- > helper file is inserted. If the script does not exist, ^^^ debian/script.debhelper ? > then a script is generated presumably debian/script.debhelper > from the .debhelper file. ^ from debian/script.debhelper, right ? I don't get it. Can anyone help ? > The .debhelper files are created by other debhelper programs, > such as dh_installmenu(1) , and are shell script frag- > ments. Thanks -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Fwd: Message Undeliverable! (Sat, Feb 24, 2001 at 11:58:22AM -0700 eric)
Any idea why this is happening to all my e-mails to this list sincde this morning ? - Forwarded message from [EMAIL PROTECTED] - Envelope-to: [EMAIL PROTECTED] From: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Message Undeliverable! X-OriginalArrivalTime: 24 Feb 2001 18:58:22.0974 (UTC) FILETIME=[C2AAF9E0:01C09E93] Date: 24 Feb 2001 11:58:22 -0700 The email you sent was routed to our server, but there were no recipients at this domain. Please check the address and send the message again. Thanks. Here are the recipients: debian-mentors@lists.debian.org - End forwarded message - -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: checking dependencies
On Sat, Feb 24, 2001 at 03:31:32PM +0100, Eric VB wrote: > Hi, > > I've read several times here that you can use chroot to check dependencies > when > building a package. > > How shoud I do it ? Here's how I did it. 1. Install debootstrap 2. use debootstrap to create a chroot enviroment, and move your source into it. 3. chroot into your new enviroment 4. try to build your package. 5. When it fails, install the needed package, and add that package to the Build-Depends line. You're done. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgpLt2ARLccfM.pgp Description: PGP signature
Re: dh_installdeb & postrm
On Sat, Feb 24, 2001 at 05:48:24PM +0100, Eric VB wrote:
> Hi,
>
> >From what I understand of the doc, debian/tmp/DEBIAN/postrm is generated from
> debian/postrm.debhelper.
>
> Now if I add a line to debian/postrm.debhelper, everytime I re-build my
> package
> (dpkg-buildpackage -rfakeroot), this line is erased. Where do I have to
> declare
> my cutomized commands ?
>
> man dh_installdeb doesn't help and is a bit confused :
>
> > dh_installdeb automatically installs the following files
> > from debian/ into the DEBIAN directory:
> >package.postinst
> >package.preinst
> >package.postrm
> >package.prerm
> >package.shlibs
> >package.conffiles
> >
> > The postinst, preinst, postrm, and prerm are handled spe-
> > cially: If a corresponding file named debian/script.deb-
> > helper exists, the contents of that file are merged into
>^^
> debian/script.debhelper ?
>
> > the script as follows: If the script exists, then anywhere
> ^^
> debian/script.debhelper again ??
>
> File merged into itself ?
>
> > in it that "#DEBHELPER#" appears, the text of the .deb-
> > helper file is inserted. If the script does not exist,
> ^^^
> debian/script.debhelper ?
>
> > then a script is generated
>
> presumably debian/script.debhelper
>
> > from the .debhelper file.
> ^
>
> from debian/script.debhelper, right ?
>
> I don't get it. Can anyone help ?
>
> > The .debhelper files are created by other debhelper programs,
> > such as dh_installmenu(1) , and are shell script frag-
> > ments.
>
Little less confusing if I comment here, rather than inline, I think.
Create files named debian/post{rm,inst} and debian/pre{rm,inst} if you
need to add specific code for one package. For multiple debs from same
source create debian/$package.post{rm,inst} debian/$package.pre{rm,inst}
If you use debhelper commands (ie dh_installdocs, dh_isntallman,
dh_installmenu) inside your debian/rules, then at the bottom of your
hand crafted maintainer scripts (debian/[$package]{post,pre}.{rm,inst})
add on a line by itself #DEBHELPER#.
That will cause the dh_scripts to automatically merg code into your hand
crafted scripts before they are installed into
debian/{$package,tmp}/DEBIAN.
For instance, the #DEBHELPER# token causes dh_installdocs to add code to
automatically create a symlink from /usr/share/doc/$package to
/usr/doc/$package and remove it upon package removal.
HTH
Gordon Sadler
Re: Package checking
On Fri, Feb 23, 2001 at 10:32:02AM -0600, Gordon Sadler wrote: > Most likely cause, debian/docs or debian/$package.docs. If you used > dh_make, it seems to pick up INSTALL. Maybe a bug should be filed > against dh_make? Yeah, dh_make should be modified to only add those files in @DOCS if configure isn't used... -- Digital Electronic Being Intended for Assassination and Nullification
Re: What is happening with debian-devel list ?
On Fri, Feb 23, 2001 at 11:21:33PM +0100, Ryszard Lach wrote: > I did not receive any mails from debian-devel since 10'th Februar. Archive > (updated 23'th Feb) contains messages up to 8'th Feb. What is wrong with > this list? I don't see anything wrong, I'm getting mail from the list normally, the archive was updated at 13:13 GMT Sat Feb 24, and the last message was at Sat, 24 Feb 2001 14:00:19 +0100. -- Digital Electronic Being Intended for Assassination and Nullification
Re: Fwd: Message Undeliverable! (Sat, Feb 24, 2001 at 11:58:22AM -0700 eric)
On Sat, Feb 24, 2001 at 08:11:35PM +0100, Eric Van Buggenhaut wrote: > Any idea why this is happening to all my e-mails to this list sincde this > morning ? > > - Forwarded message from [EMAIL PROTECTED] - > > From: <[EMAIL PROTECTED]> > Subject: Message Undeliverable! Looks like a subscriber to -mentors has an insane MTA... happens often :( -- Digital Electronic Being Intended for Assassination and Nullification
Re: Making a package arch independant
On Sat, Feb 24, 2001 at 01:43:38PM +, Patrick Caulfield wrote: > I've taken one of my packages (dnet-common) and turned its only binary into a > shell script so that the package is now architecture independant. > > If I just upload the new dnet-common_2.09-1_all.deb, will it remove the > existing > dnet-common_2.08-1_i386.deb or do I have to do anything special? I think it will; if not, you can file a bug against ftp.debian.org to get it cleaned up. -- Digital Electronic Being Intended for Assassination and Nullification
Re: Debian
Y el sábado 24 de febrero, Nuria Lope Gil escribió: > > I new, and I need to install Debian in my PC. I have downloaded all files I > need, so now I have to generate disks for installation. > I would be very please if someone could explain me how to do it, and the > first step when installing. Por tu nombre veo que puedes ser hispano-hablante, así que quizás te convenga más hacer este tipo de preguntas en debian-user-spanish. Saludos -- Luis Arocha Hernandez "Data" <[EMAIL PROTECTED]>, Islas Canarias - Spain _ o__o__ o__ O_ OO o/,>/ ,>/ ,//,/\ ,/| _()_\()___()_()_\(()_\()__()_\()_()_<()__()_<() pgp9V0tYM6Zi4.pgp Description: PGP signature
Re: .debhelper files
On Sat, Feb 24, 2001 at 03:42:26PM +0100, Eric VB wrote: > When I run debhelper on pristine source tree, *.debhelper files are created. > Are they examples, or should they be included in the final package ? You mean when you build the package? They're created and are merged in with your existing maintainer scripts where #DEBHELPER# is e.g. postinst #!/bin/sh -e echo -n foo #DEBHELPER postinst.debhelper echo bar the postinst in the package will be #!/bin/sh -e echo -n foo echo bar > > Thanks. > > -- > Eric VAN BUGGENHAUT > > [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Brian Russo <[EMAIL PROTECTED]> Debian/GNU Linux <[EMAIL PROTECTED]> http://www.debian.org LPSG "member"<[EMAIL PROTECTED]> http://www.lpsg.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bug Squashing, here: sponsor wanted for libgii, libggi
Hello, ya all! I chose the above mentioned pkgs from the beginning, prepared a NMU of the old packages, but now have new upstream packages ready. My first try to contact the corresponding debian maintainer was mid Jan 2001. Feb 2nd i received: > Are you alive? Yes. Alive, but busy. I just started a new job a couple of weeks ago, and haven't had much Debian time recently... > I just wanna know, 'coz i had a sudden urge to do sth. and fixed all > but 1 bug against libgii0. > What am i gonna do with them patches now? > If you're smply not interested in that ligii/ggi stuff anymore, i > would ;-) If you're interested in maintaining libggi, libgii and friends, I'm happy to give them away. They do need more attention than I've been able to give them recently. Treat them well ;) That was the last, that i got. My last mail (partly): If you still want to pass the continuation of these packages to me, please drop me a note, like: All sane, .. free will, .. publicly & who concerns, .. these packages from Charles Briscoe Smith to the greedy hands of Ma ... I would surely love, if you would want to sponsor the upload! *g* My last mail, saying 'relax, time enough', seems to be outdated by the announcement of freeze plans for woody. I sure would like to become the official maintainer of the packages, i use them every day, am willing to devote on their quality (upstream and deb) and documentation and am willing to further promote their use. Ah, forgot - to have them in woody naturally! The last i did on them was to provide lintian/overrides, with the remaining lintian warnings (postrm-calls-ldconfig) intendedly not overwritten, as i think they behave according to policy as they should. I personally, would have waited another two or three days, to receive an answer, but i have to go travelling for three weeks from tomorow, sunday, on and would like to have a clean slate before. As the former maintainer expressed his current state and intention clearly, i don't think he would feel bad, if we give those pkgs a push. Btw.: My name is in the changelog, already. Is that enough to be the maintainer in the future? Now, if anybody would be willing, the signed source packages libgii and libggi can be had with deb-src http://home.t-online.de/home/eislink/debian unstable main or downloaded from the web page at http://eislink.debox.de. I'm _really_ sorry that my postings always tend to be somwhat longer. I try as much to reduce, but am used to work in the background and come up to the open with a solution then ... and then i have to explain ... When you've become used to that, i promise to stop explaining this in the future at least ;-) Thanks for reading, greetings and a nice weekend to all of you, martin I expect to be able to receive mail during the next three weeks anyhow. -- Cross Building nano HOW-TO V 0.2 http://eisdoc.debox.de
Re: dh_installdeb & postrm
On Saturday 24 February 2001 17:48, Eric VB wrote: > Now if I add a line to debian/postrm.debhelper, everytime I re-build > my package (dpkg-buildpackage -rfakeroot), this line is erased. Where > do I have to declare my cutomized commands ? > > man dh_installdeb doesn't help and is a bit confused : Hm, all in there. And you can read source code? _Big_ ;-) > > dh_installdeb automatically installs the following files > > from debian/ into the DEBIAN directory: .. > >package.postrm .. > > The postinst, preinst, postrm, and prerm are handled spe- > > cially: If a corresponding file named debian/script.deb- > > helper exists, the contents of that file are merged into dh_make gives you some files to start with. They come from /usr/share/debhelper/.. The main package (the first binary package in your control file) may simply have 'postrm' as your script. But you may also give an explicit package prefix for this. If you do this or build more binaries, you may name them package.postrm, that is eg. libggi.postrm and libggi2-dev.postrm. These may again contain lines with #DEBHELPER# in them. This keyword will be replaced by the scripts that are automatically generated by the various debhelper progs. These are called postrm.debhelper or package.postrm.debhelper and naturally overwrite your changes made there. greetings, martin
Re: Package checking
> > > On Sat, Feb 24, 2001 at 12:25:01PM +0100, > > [EMAIL PROTECTED] wrote: > > > > Hmm, the configure file should also check for ghttp.h, it didnt > On Sat, Feb 24, 2001 at 06:21:13PM +0100, Martin Albert wrote: > > This produces unnecessary hassles when, for instance, cross > > compiling. On Saturday 24 February 2001 18:45, Sam TH wrote: > I don't see why. The package isn't going to compile if $host doesn't > have ghttp.h on the system. Sure, $target doesn't need it, but I > don't see how that will matter to configure. Configure gets run on > $host, which is where the file needs to be. I understand what you mean with $host and $target. As lots of progs use autoconf and it's the one solution to provide complete coverage of all required cases, i propose to follow autoconfs nomenclature in section 'Definition of terms' in Cross building nano HOW-TO V0.2 ;-) We would then speak of BUILD and HOST, as silly this may be. The scenario you describe above would be the worst case. Autoconf not recognizing an attempted cross build, falsely using /usr/include. You would hardcode that bad/wrong/outdated behaviour into your configure script by testing for /usr/include/whatever Modern autoconf tries to do better (and fails when X is not available for HOST, but is for BUILD) and can be fed with HOST information, so that simple programs do not require to be configured externally on the host machine. A newly created Debian package should not be build with erronous behaviour built in, but instead make intelligent use of the advanced environment available with Debian/GNU Linux, so that it can stand for it in the future. Sorry, if this sounds a bit dry - i'm still in the process to get this all sorted out, to be able to provide better info and advice in the future. Let's just simply make it better ;-) It still stands anyway, that IMHO a Build-Dependency is sufficient (or it were simply useless) and that i personally would like the one person preparing that package to undertake the effort to get rid of this additional (useless) configure test in his new package. Reference-packages: autoconf, dpkg-cross greetings, martin -- Cross Building nano HOW-TO V 0.2 http://eisdoc.debox.de
Re: Policy and conffile editing
On Sat, Feb 24, 2001 at 01:42:01PM +0100, [EMAIL PROTECTED] wrote: > On Fri, Feb 23, 2001 at 02:02:53PM -0800, Aaron Lehmann wrote: > > It seems this is at odds with policy, which prohibutes the automated > > editing of conffiles (such as squid.conf). This is a bit ironic, since > > asking 'Would you like to enable this package by inserting a line FOO > > into /etc/squid.conf? [Y/n]' is much cleaner than printing a note 'You > > must run the script /usr/sbin/setupthispckage to enable this package'. > > While both of those would acomplish essensially the same thing, only > > one would be permissible by policy. > > > > What should I do in regards to editing this conffile? > You should not change (semi-)automatic the squid.conf by asking debconf > questions. Those changes are vital and the admin should make these changes by > hand. Take a look in login.app. It displays a message to change your inittab > accordingly (change default runlevel for example). You could, however, make the changes to a copy of the configuration file, so that if the admin decides to implement your changes, she need only copy that file over the existing config file. -- - mdz
Re: I would like to debianize mod_gzip
* Britton | Yes, you should check the wnpp page http://www.debian.org/devel/wnpp/index | to make sure no one else is already working on it, then announce you | intent to package by filing a wishlist bug against wnpp as per the | instructions in the developers reference (which you should read :). Actually - he should rename the RFP bug to an ITP. | > I would like to debianize mod_gzip requested 5 days ago. Since I'm not an | > official debian maintainer (yet) I'll probably need a sponsor for this package | > (any volunteers ?). Should/can I submit a bug announcing my intention ? I can sponsor you. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Package checking
On Fri, Feb 23, 2001 at 11:16:16PM -0600, Sam TH wrote: > > $ lintian --version > > Lintian v1.20.6 > > $ lintian uf-view_1.2-2_i386.changes > > E: uf-view source: package-uses-debhelper-but-lacks-build-depends > > Fixed, I think. I removed every possibly related package I could find > from my chroot, and then tried to build uf-view. I had to ask apt-get > to install only: libgnome-dev, libghttp-dev and debhelper, but those > brought in close to 50 other packages (all of X and GNOME, for > example). Are those three all that is needed for Build-Depends? >From current policy: When specifying the set of build-time dependencies, one should list only those packages explicitly required by the build. It is not necessary to list packages which are required merely because some other package in the list of build-time dependencies depends on them. The reason is that dependencies change, and you should list only those _you_ need. What others need is their business. Hopefully this will answer your question. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: /etc/ question
On Fri, Feb 23, 2001 at 03:57:33PM -0800, Sean 'Shaleh' Perry wrote: > in your preinst, check for /etc/foo and if it exists, mkdir /etc/package and > copy /etc/foo there. Then remove /etc/foo. Import thing here is that the > preinst should not die because of any errors here. Perhaps better: copy it in the postinst, remove the old version in the postinst. Then if any problems arise, the original version will still be present. If you are really careful, you should also move them back if the package is being downgraded to a pre-move version. Check policy to see how the maintainer scripts are run. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: I can't sign .dsc file
On Fri, Feb 23, 2001 at 12:47:32PM +0100, Javier Vi?uales Guti?rrez wrote: > Hello, I can't sign the file .dsc of a new package I'm makeing because > debsign says: > > gpg: [stdin]: clearsign failed: Secret key no available > /usr/bin/debsign: GPG error occurred! > > I can sign my e-mail messages with gpg, my ~/.gnupg has the files needed, > what I doing wrong please?. The username + email that you use in your debian/changelog must exactly match that in your secret keyring. If it doesn't, then have a look at the debsign docs! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Policy and conffile editing
On Sat, Feb 24, 2001 at 02:19:08PM +0100, Ove Kaaven wrote: > > On Sat, 24 Feb 2001 [EMAIL PROTECTED] wrote: > > > If you really think you want to change this automatically, you can ask the > > squid maintainer to remove /etc/squid.conf from his conffiles. > > If it's necessary to remove it from conffiles in order to edit it from a > script in /usr/sbin, then both sgml-base (/etc/sgml/transitional.cat > edited by install-sgmlcatalog) and mime-support (/etc/mailcap edited by > update-mime) violates this policy. You're right. They should have bugs filed against them. Because otherwise, every time the package is upgraded, the sysadmin will be asked to check the changes unnecessarily. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: /etc/ question
On Sun, 25 Feb 2001, Julian Gilbey wrote: > On Fri, Feb 23, 2001 at 03:57:33PM -0800, Sean 'Shaleh' Perry wrote: > > in your preinst, check for /etc/foo and if it exists, mkdir /etc/package and > > Perhaps better: copy it in the postinst, remove the old version in the > postinst. Then if any problems arise, the original version will still > be present. BAD idea. This will defeat the conffile change detection engine in dpkg, and will cause problems in some cases. Don't do that. In the *pre*inst, mv old -> new IFF old exists and new does NOT exist In the posinst, just use the new location. Remember to correctly unwind, moving the conffile back to its original place (as long as the original file does not exist) in the abort-install and abort-upgrade targets of preinst, postrm and postinst. [never tried this, but that seems to be what's needed from the not-so-clear policy chapter 6] > If you are really careful, you should also move them back if the > package is being downgraded to a pre-move version. Check policy to > see how the maintainer scripts are run. Yes, that might be a good idea. However, as a rule of thumb, downgrading is not supported (do note that failed/aborted upgrades ARE supported). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh pgpqPVwuSaVSu.pgp Description: PGP signature
Re: /etc/ question
On Sat, Feb 24, 2001 at 10:42:38PM -0300, Henrique M Holschuh wrote: > On Sun, 25 Feb 2001, Julian Gilbey wrote: > > On Fri, Feb 23, 2001 at 03:57:33PM -0800, Sean 'Shaleh' Perry wrote: > > > in your preinst, check for /etc/foo and if it exists, mkdir /etc/package > > > and > > > > Perhaps better: copy it in the postinst, remove the old version in the > > postinst. Then if any problems arise, the original version will still > > be present. > > BAD idea. This will defeat the conffile change detection engine in dpkg, and > will cause problems in some cases. Don't do that. Oops, typo! Thanks for spotting it. Read as follows: Perhaps better: copy it in the PREINST, remove the old version in the postinst. Then if any problems arise, the original version will still be present. > In the *pre*inst, mv old -> new IFF old exists and new does NOT exist Good. > In the posinst, just use the new location. > Remember to correctly unwind, moving the conffile back to its original place > (as long as the original file does not exist) in the abort-install and > abort-upgrade targets of preinst, postrm and postinst. [never tried this, > but that seems to be what's needed from the not-so-clear policy chapter 6] Agreed it's not so clear. I want to figure out what questions to ask Wichert about what it says. I'm confused about when error unwinding is done and would like to clarify it. > > If you are really careful, you should also move them back if the > > package is being downgraded to a pre-move version. Check policy to > > see how the maintainer scripts are run. > > Yes, that might be a good idea. However, as a rule of thumb, downgrading is > not supported (do note that failed/aborted upgrades ARE supported). It isn't? I thought we tried to as much as possible. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: debhelper and multiple README files
Manfred Wassmann wrote: > > Well, um, partly so that if dh_installdocs does not do what you want, > > you can work around it and still be assured of proper permissions once > > you run dh_fixperms? > > But if it was done in the first place dh_fixperms was not required. In > other words, it would be redundant but failsafe and you created debhelper > to make life easier, dind't you? ;) dh_fixperms ensures that _all_ files you have installed have appropriate permissions. Including documentation files you installed by hand, for example. I have slowly been making debhelper commands set appropriate file permissions w/o dh_fixperms, but it's a very low priority and I doubt I'll do them all. -- see shy jo
Bigloo and libgc5
I am creating a new package for bigloo, a Scheme compiler, version 2.2b. It depends on a version of libgc, previously (in version 2.0e) this was libgc4. I have recently adopted this package, and in looking over the previous maintainer's work, I noticed that bigloo includes the source code to libgc, and that the previous maintainer forced bigloo to use the libgc from the libgc4 package rather than the libgc that comes with bigloo. Now, libgc4 has been gone for quite some time now (and there were numerous bugs submitted on bigloo because of this fact), replaced by libgc5. The new version of bigloo, 2.2b, also includes a copy of libgc5 albeit an older one (5.1, where libgc5 package is 5.3). Apparently the libgc 5.1 source code has been somewhat integrated into the bigloo source tree. The problem arises when I try to do what the previous maintainer did, namely: copy the libgc 5.3 lib from the libgc5 package and bypass the building of libgc 5.1 in the source tree. Everything goes fine, until it tries to build the bigloo.heap: LD_LIBRARY_PATH=/home/mrd/debian/bigloo/old/bigloo-2.2b/lib/2.2b:$LD_LIBRARY_PATH; \ export LD_LIBRARY_PATH; \ /home/mrd/debian/bigloo/old/bigloo-2.2b/bin/bigloo -unsafe -q -mkheap -mklib -s Llib/make-lib.scm -heap bigloo.heap *** ERROR:bigloo:internal error: aborting -- #f /home/mrd/debian/bigloo/old/bigloo-2.2b/lib/2.2b contains the libgc 5.3 library. Now, when I allow bigloo to build its own version of libgc (5.1) and compile, everything runs smoothly, and I was able to create a debian package with little trouble. But as the libgc5 package already exists, the bigloo package would then have to install an older version of the same library. True, it installs the library into /usr/lib/bigloo/2.2b, which eliminates the name conflict, rather than /usr/lib, but it would seem more appropriate if it used the libgc5 (5.3) package's library instead (and perhaps used a symlink from /usr/lib/bigloo/2.2b/libgc.so to /usr/lib/libgc.so). From what I can see, I have two options: prepare the package that contains bigloo's old version of libgc.so, or contact the author and attempt to figure out why bigloo does not play well with the libgc5 package's libgc.so. Any input on this matter would be of great help to me, thanks. Matthew Danish -- GPG Public Key Fingerprint: A3C6 93AF 5805 F46B 67D5 96B2 CF15 3232 C24B 6010 Key available from: wwwkeys.pgp.net ID: C24B6010 pgpyepcr5cOaB.pgp Description: PGP signature
Re: /etc/ question
On Sun, 25 Feb 2001, Julian Gilbey wrote: > On Sat, Feb 24, 2001 at 10:42:38PM -0300, Henrique M Holschuh wrote: > > Yes, that might be a good idea. However, as a rule of thumb, downgrading is > > not supported (do note that failed/aborted upgrades ARE supported). > > It isn't? I thought we tried to as much as possible. Try is the operative word. Don't do that to anything you can't risk being left as a complete mess. Downgrading glibc has killed more than one with extreme prejudice, I'm told :P -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh pgptpEcfPicAv.pgp Description: PGP signature
Re: /etc/ question
On Sat, Feb 24, 2001 at 10:42:38PM -0300, Henrique M Holschuh wrote: [...] > > Remember to correctly unwind, moving the conffile back to its original place > (as long as the original file does not exist) in the abort-install and > abort-upgrade targets of preinst, postrm and postinst. [never tried this, > but that seems to be what's needed from the not-so-clear policy chapter 6] In the package I maintain, called crafty, I moved /etc/craftyrc to /etc/crafty.rc and /var/cache/crafty to /var/lib/crafty in the previous version (17.9). Version now is 17.13. The 'move' routine is still in preinst of the latest version because we don't know what version people are upgrading from. Now that's my problem : if upgrade fails or is aborted, I should move the files back to their original location. But if people are upgrading from a 'post-move' version, the original location is different than if they were upgrading from a 'pre-move' location. So, where do I move the files back ??? -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: Caught in the act
On Friday 16 February 2001 00:15, Martin Albert wrote: > Hello to all friendly people reading this ... > > I'm pkging new upstream of a quite basic lib (libgii). And that was looong ago. Sorry, that i didn't say thanks to Matt Zimmerman, Ingo Saitz, Brian Russo, Hamish Moffatt earlier for your kind response. I was busy with that stuff to the end - and learned a lot. Now my decision based on your answers (and the impossibility to flush dpkg's cache as a package being installed) was to - package according to policy the small binaries to -dev, - that means simply downgrading is not possible without removing first - have a README.Debian saying so nicely :) Anybody interested in a summary of this topic: mail me. Thank You, greetings, martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package checking
> On Fri, Feb 23, 2001 at 08:30:49AM -0800, Sean 'Shaleh' Perry wrote: > > you also fail to install a menu file. I am coming up with a > > lintian check for packages linked to X and not installing one. So > > you reminded me of another bug (-: No, i'm sure you wouldn't do that. :) libggi-target-x links X but will never have a menu entry. tnx for your work. martin -- Cross Building nano HOW-TO V 0.2 http://eisdoc.debox.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package checking
On Fri, Feb 23, 2001 at 11:16:16PM -0600, Sam TH wrote: > samth# lintian --version > Lintian v1.20.6 > samth# lintian -i uf-view_1.2-2_i386.changes > W: uf-view source: newer-standards-version 3.5.2.0 > > I presume this is a lintian bug. Right? No, this is because your standards version is 3.5.0, and the current version is 3.5.2 Another thing: you should use a newer debian/rules file. There is a new target 'configure' which you can use to call ./configure. When doing this, look out if you have to depend on debhelper >= 3.0. Yet another thing: your Build-depends seems wrong. Policy says: 'A source package may declare a dependency or a conflict on a binary package', but your are depending on a source package (libghttp), not the binary package (libghttp1). Ah, no, it should be libghttp-dev, the header package. Hmm, the configure file should also check for ghttp.h, it didnt complain when I run it without having ghttp.h, but compiling fails: [...] gladesig.c:6: ghttp.h: No such file or directory Bastian PGP signature
Re: /etc/ question
"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: >On 23-Feb-2001 Amaya wrote: >> Of course not! ;-) I'd just move them to the new location. >> But, I'm starting to think this is not a good idea, maybe. > >after talking with other devels here is a method: > >in your preinst, check for /etc/foo and if it exists, mkdir /etc/package and >copy /etc/foo there. Then remove /etc/foo. Import thing here is that the >preinst should not die because of any errors here. > >Your package contains /etc/package/foo. When dpkg gets to the point where the >conffile will be installed, it will do the usual checking if the conffile >should be changed and prompting the user. You have to be even more careful than that, since the installation might fail and dpkg might want to unwind the maintainer scripts - so 'postrm abort-upgrade' and 'postrm abort-install' need to move the file back if possible. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy and conffile editing
Aaron, On Fri, Feb 23, 2001 at 02:02:53PM -0800, Aaron Lehmann wrote: > It seems this is at odds with policy, which prohibutes the automated > editing of conffiles (such as squid.conf). This is a bit ironic, since > asking 'Would you like to enable this package by inserting a line FOO > into /etc/squid.conf? [Y/n]' is much cleaner than printing a note 'You > must run the script /usr/sbin/setupthispckage to enable this package'. > While both of those would acomplish essensially the same thing, only > one would be permissible by policy. > > What should I do in regards to editing this conffile? You should not change (semi-)automatic the squid.conf by asking debconf questions. Those changes are vital and the admin should make these changes by hand. Take a look in login.app. It displays a message to change your inittab accordingly (change default runlevel for example). If you really think you want to change this automatically, you can ask the squid maintainer to remove /etc/squid.conf from his conffiles. Then ask him to include a configuration script in his package which modifies squid.conf accordingly. Then use this script to make your changes (for example update-inetd is one such script for /etc/inetd.conf). Bastian PGP signature
Re: Package checking
On Sat, Feb 24, 2001 at 12:25:01PM +0100, [EMAIL PROTECTED] wrote: > On Fri, Feb 23, 2001 at 11:16:16PM -0600, Sam TH wrote: > > samth# lintian --version > > Lintian v1.20.6 > > samth# lintian -i uf-view_1.2-2_i386.changes > > W: uf-view source: newer-standards-version 3.5.2.0 > > > > I presume this is a lintian bug. Right? > No, this is because your standards version is 3.5.0, and the current > version is 3.5.2 > Actually, my standards version is 3.5.2.0. And the lintian explanation for this is: N: The source package refers to a `Standards-Version' which is newer than N: the one lintian is programmed to check. If the source package is N: correct, then please upgrade lintian to the newest version. (If there N: is no newer lintian version, then please bug [EMAIL PROTECTED] N: to make one.) So I think it is a lintian bug. > Another thing: you should use a newer debian/rules file. There is a new > target 'configure' which you can use to call ./configure. > When doing this, look out if you have to depend on debhelper >= 3.0. > What's the advantage to using this? I couldn't find any references in the debhelper docs or in policy to it. Would this be different that having a private configure target for the internal use of the build system? > Yet another thing: your Build-depends seems wrong. > Policy says: 'A source package may declare a dependency or a conflict > on a binary package', but your are depending on a source package > (libghttp), not the binary package (libghttp1). Ah, no, it should be > libghttp-dev, the header package. Doh. Fixed. > Hmm, the configure file should also check for ghttp.h, it didnt complain > when I run it without having ghttp.h, but compiling fails: > [...] > gladesig.c:6: ghttp.h: No such file or directory Fixed. New package at the same location, deb[-src] http://samth.dyndns.org/debian ./ Thanks for your help sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key PGP signature
Re: Policy and conffile editing
On Sat, 24 Feb 2001 [EMAIL PROTECTED] wrote: > If you really think you want to change this automatically, you can ask the > squid maintainer to remove /etc/squid.conf from his conffiles. If it's necessary to remove it from conffiles in order to edit it from a script in /usr/sbin, then both sgml-base (/etc/sgml/transitional.cat edited by install-sgmlcatalog) and mime-support (/etc/mailcap edited by update-mime) violates this policy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Making a package arch independant
I've taken one of my packages (dnet-common) and turned its only binary into a shell script so that the package is now architecture independant. If I just upload the new dnet-common_2.09-1_all.deb, will it remove the existing dnet-common_2.08-1_i386.deb or do I have to do anything special? patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian revision numbers for gnome-utils
On Fri, 23 Feb 2001, Jochen Voss wrote: > last week I prepared a new package for the gnome-utils package > and asked for a sponsor. As nobody volunteered this one was > not uploaded to the server. > > Now I did some additional fixes (add a man page, ...) and > want to prepare a new package. Should I increase the > Debian revision number for this (to avoid possible confusion) > or should I just replace my files with new version (to keep > the revision numbers of official versions contiguous)? Since you didn't uploaded the old package to incoming, katie does not know it exists, so it will not complain if you upload it without increasing the Debian revision number. This is a matter of taste, really. Some people think of the changelog (and related Debian revision numbers) as the complete history of all the changes made to the package, either public or private. Some other people think it is ok that the changelog documents only *released* versions of the package. In short, it's up to you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/ question
Colin Watson dijo: > You have to be even more careful than that, since the installation might fail > and dpkg might want to unwind the maintainer scripts - so 'postrm > abort-upgrade' and 'postrm abort-install' need to move the file back if > possible. Thanks a lot. I had not taken that into account 0:-) -- If you don't spend energy getting what you want, you'll have to spend it dealing with what you get. - Unknown Proudly running Debian GNU/Linux Sid (Kernel 2.2.17) on this Dell Laptop PGP signature
Re: debian revision numbers for gnome-utils
On Sat, Feb 24, 2001 at 02:56:46PM +0100, Santiago Vila wrote: > In short, it's up to you. I was told that "Closes: #12345"-like entries in the changelog only close bugs which are mentioned in the most recent release. You must close bugs in older (but not uploaded) releases manually. So it may be easier to not increase the revision number too often. Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html PGP signature
Re: debian revision numbers for gnome-utils
On Sat, Feb 24, 2001 at 05:28:52PM +0100, Jochen Voss wrote: > On Sat, Feb 24, 2001 at 02:56:46PM +0100, Santiago Vila wrote: > > In short, it's up to you. > > I was told that "Closes: #12345"-like entries in the changelog > only close bugs which are mentioned in the most recent release. > You must close bugs in older (but not uploaded) releases > manually. You can compensate for this with the little-known -v option to dpkg-buildpackage. If you're building version 1.3, and the latest version in the archive is 1.1, you can specify -v1.1 to get all the changelog entries after 1.1 in your changes file. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package checking
On Saturday 24 February 2001 14:22, Sam TH wrote: > On Sat, Feb 24, 2001 at 12:25:01PM +0100, [EMAIL PROTECTED] wrote: > > Yet another thing: your Build-depends seems wrong. > > Policy says: 'A source package may declare a dependency or a > > conflict on a binary package', but your are depending on a source > > package (libghttp), not the binary package (libghttp1). Ah, no, it > > should be libghttp-dev, the header package. > > Doh. Fixed. > > > Hmm, the configure file should also check for ghttp.h, it didnt > > complain when I run it without having ghttp.h, but compiling fails: > > [...] > > gladesig.c:6: ghttp.h: No such file or directory > > Fixed. Ahm, sorry, i'm new to this and don't know much yet, but: I think Build-Depends: libghttp-dev should be sufficient. > > Hmm, the configure file should also check for ghttp.h, it didnt This produces unnecessary hassles when, for instance, cross compiling. greetings, martin -- Cross Building nano HOW-TO V 0.2 http://eisdoc.debox.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package checking
On Sat, Feb 24, 2001 at 06:21:13PM +0100, Martin Albert wrote: > On Saturday 24 February 2001 14:22, Sam TH wrote: > > On Sat, Feb 24, 2001 at 12:25:01PM +0100, > [EMAIL PROTECTED] wrote: > > > Hmm, the configure file should also check for ghttp.h, it didnt > > This produces unnecessary hassles when, for instance, cross compiling. > I don't see why. The package isn't going to compile if $host doesn't have ghttp.h on the system. Sure, $target doesn't need it, but I don't see how that will matter to configure. Configure gets run on $host, which is where the file needs to be. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key PGP signature
.debhelper files
When I run debhelper on pristine source tree, *.debhelper files are created. Are they examples, or should they be included in the final package ? Thanks. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
checking dependencies
Hi, I've read several times here that you can use chroot to check dependencies when building a package. How shoud I do it ? Thanks. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dh_installdeb & postrm
Hi, >From what I understand of the doc, debian/tmp/DEBIAN/postrm is generated from debian/postrm.debhelper. Now if I add a line to debian/postrm.debhelper, everytime I re-build my package (dpkg-buildpackage -rfakeroot), this line is erased. Where do I have to declare my cutomized commands ? man dh_installdeb doesn't help and is a bit confused : > dh_installdeb automatically installs the following files > from debian/ into the DEBIAN directory: >package.postinst >package.preinst >package.postrm >package.prerm >package.shlibs >package.conffiles > > The postinst, preinst, postrm, and prerm are handled spe- > cially: If a corresponding file named debian/script.deb- > helper exists, the contents of that file are merged into ^^ debian/script.debhelper ? > the script as follows: If the script exists, then anywhere ^^ debian/script.debhelper again ?? File merged into itself ? > in it that "#DEBHELPER#" appears, the text of the .deb- > helper file is inserted. If the script does not exist, ^^^ debian/script.debhelper ? > then a script is generated presumably debian/script.debhelper > from the .debhelper file. ^ from debian/script.debhelper, right ? I don't get it. Can anyone help ? > The .debhelper files are created by other debhelper programs, > such as dh_installmenu(1) , and are shell script frag- > ments. Thanks -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: Message Undeliverable! (Sat, Feb 24, 2001 at 11:58:22AM -0700 eric)
Any idea why this is happening to all my e-mails to this list sincde this morning ? - Forwarded message from [EMAIL PROTECTED] - Envelope-to: eric@localhost From: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Message Undeliverable! X-OriginalArrivalTime: 24 Feb 2001 18:58:22.0974 (UTC) FILETIME=[C2AAF9E0:01C09E93] Date: 24 Feb 2001 11:58:22 -0700 The email you sent was routed to our server, but there were no recipients at this domain. Please check the address and send the message again. Thanks. Here are the recipients: [EMAIL PROTECTED] - End forwarded message - -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: checking dependencies
On Sat, Feb 24, 2001 at 03:31:32PM +0100, Eric VB wrote: > Hi, > > I've read several times here that you can use chroot to check dependencies when > building a package. > > How shoud I do it ? Here's how I did it. 1. Install debootstrap 2. use debootstrap to create a chroot enviroment, and move your source into it. 3. chroot into your new enviroment 4. try to build your package. 5. When it fails, install the needed package, and add that package to the Build-Depends line. You're done. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key PGP signature
Re: dh_installdeb & postrm
On Sat, Feb 24, 2001 at 05:48:24PM +0100, Eric VB wrote:
> Hi,
>
> >From what I understand of the doc, debian/tmp/DEBIAN/postrm is generated from
> debian/postrm.debhelper.
>
> Now if I add a line to debian/postrm.debhelper, everytime I re-build my package
> (dpkg-buildpackage -rfakeroot), this line is erased. Where do I have to declare
> my cutomized commands ?
>
> man dh_installdeb doesn't help and is a bit confused :
>
> > dh_installdeb automatically installs the following files
> > from debian/ into the DEBIAN directory:
> >package.postinst
> >package.preinst
> >package.postrm
> >package.prerm
> >package.shlibs
> >package.conffiles
> >
> > The postinst, preinst, postrm, and prerm are handled spe-
> > cially: If a corresponding file named debian/script.deb-
> > helper exists, the contents of that file are merged into
>^^
> debian/script.debhelper ?
>
> > the script as follows: If the script exists, then anywhere
> ^^
> debian/script.debhelper again ??
>
> File merged into itself ?
>
> > in it that "#DEBHELPER#" appears, the text of the .deb-
> > helper file is inserted. If the script does not exist,
> ^^^
> debian/script.debhelper ?
>
> > then a script is generated
>
> presumably debian/script.debhelper
>
> > from the .debhelper file.
> ^
>
> from debian/script.debhelper, right ?
>
> I don't get it. Can anyone help ?
>
> > The .debhelper files are created by other debhelper programs,
> > such as dh_installmenu(1) , and are shell script frag-
> > ments.
>
Little less confusing if I comment here, rather than inline, I think.
Create files named debian/post{rm,inst} and debian/pre{rm,inst} if you
need to add specific code for one package. For multiple debs from same
source create debian/$package.post{rm,inst} debian/$package.pre{rm,inst}
If you use debhelper commands (ie dh_installdocs, dh_isntallman,
dh_installmenu) inside your debian/rules, then at the bottom of your
hand crafted maintainer scripts (debian/[$package]{post,pre}.{rm,inst})
add on a line by itself #DEBHELPER#.
That will cause the dh_scripts to automatically merg code into your hand
crafted scripts before they are installed into
debian/{$package,tmp}/DEBIAN.
For instance, the #DEBHELPER# token causes dh_installdocs to add code to
automatically create a symlink from /usr/share/doc/$package to
/usr/doc/$package and remove it upon package removal.
HTH
Gordon Sadler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package checking
On Fri, Feb 23, 2001 at 10:32:02AM -0600, Gordon Sadler wrote: > Most likely cause, debian/docs or debian/$package.docs. If you used > dh_make, it seems to pick up INSTALL. Maybe a bug should be filed > against dh_make? Yeah, dh_make should be modified to only add those files in @DOCS if configure isn't used... -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is happening with debian-devel list ?
On Fri, Feb 23, 2001 at 11:21:33PM +0100, Ryszard Lach wrote: > I did not receive any mails from debian-devel since 10'th Februar. Archive > (updated 23'th Feb) contains messages up to 8'th Feb. What is wrong with > this list? I don't see anything wrong, I'm getting mail from the list normally, the archive was updated at 13:13 GMT Sat Feb 24, and the last message was at Sat, 24 Feb 2001 14:00:19 +0100. -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Message Undeliverable! (Sat, Feb 24, 2001 at 11:58:22AM -0700 eric)
On Sat, Feb 24, 2001 at 08:11:35PM +0100, Eric Van Buggenhaut wrote: > Any idea why this is happening to all my e-mails to this list sincde this > morning ? > > - Forwarded message from [EMAIL PROTECTED] - > > From: <[EMAIL PROTECTED]> > Subject: Message Undeliverable! Looks like a subscriber to -mentors has an insane MTA... happens often :( -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making a package arch independant
On Sat, Feb 24, 2001 at 01:43:38PM +, Patrick Caulfield wrote: > I've taken one of my packages (dnet-common) and turned its only binary into a > shell script so that the package is now architecture independant. > > If I just upload the new dnet-common_2.09-1_all.deb, will it remove the existing > dnet-common_2.08-1_i386.deb or do I have to do anything special? I think it will; if not, you can file a bug against ftp.debian.org to get it cleaned up. -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian
Y el sábado 24 de febrero, Nuria Lope Gil escribió: > > I new, and I need to install Debian in my PC. I have downloaded all files I need, >so now I have to generate disks for installation. > I would be very please if someone could explain me how to do it, and the first >step when installing. Por tu nombre veo que puedes ser hispano-hablante, así que quizás te convenga más hacer este tipo de preguntas en debian-user-spanish. Saludos -- Luis Arocha Hernandez "Data" <[EMAIL PROTECTED]>, Islas Canarias - Spain _ o__o__ o__ O_ OO o/,>/ ,>/ ,//,/\ ,/| _()_\()___()_()_\(()_\()__()_\()_()_<()__()_<() PGP signature
Re: .debhelper files
On Sat, Feb 24, 2001 at 03:42:26PM +0100, Eric VB wrote: > When I run debhelper on pristine source tree, *.debhelper files are created. > Are they examples, or should they be included in the final package ? You mean when you build the package? They're created and are merged in with your existing maintainer scripts where #DEBHELPER# is e.g. postinst #!/bin/sh -e echo -n foo #DEBHELPER postinst.debhelper echo bar the postinst in the package will be #!/bin/sh -e echo -n foo echo bar > > Thanks. > > -- > Eric VAN BUGGENHAUT > > [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Brian Russo <[EMAIL PROTECTED]> Debian/GNU Linux <[EMAIL PROTECTED]> http://www.debian.org LPSG "member"<[EMAIL PROTECTED]> http://www.lpsg.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug Squashing, here: sponsor wanted for libgii, libggi
Hello, ya all! I chose the above mentioned pkgs from the beginning, prepared a NMU of the old packages, but now have new upstream packages ready. My first try to contact the corresponding debian maintainer was mid Jan 2001. Feb 2nd i received: > Are you alive? Yes. Alive, but busy. I just started a new job a couple of weeks ago, and haven't had much Debian time recently... > I just wanna know, 'coz i had a sudden urge to do sth. and fixed all > but 1 bug against libgii0. > What am i gonna do with them patches now? > If you're smply not interested in that ligii/ggi stuff anymore, i > would ;-) If you're interested in maintaining libggi, libgii and friends, I'm happy to give them away. They do need more attention than I've been able to give them recently. Treat them well ;) That was the last, that i got. My last mail (partly): If you still want to pass the continuation of these packages to me, please drop me a note, like: All sane, .. free will, .. publicly & who concerns, .. these packages from Charles Briscoe Smith to the greedy hands of Ma ... I would surely love, if you would want to sponsor the upload! *g* My last mail, saying 'relax, time enough', seems to be outdated by the announcement of freeze plans for woody. I sure would like to become the official maintainer of the packages, i use them every day, am willing to devote on their quality (upstream and deb) and documentation and am willing to further promote their use. Ah, forgot - to have them in woody naturally! The last i did on them was to provide lintian/overrides, with the remaining lintian warnings (postrm-calls-ldconfig) intendedly not overwritten, as i think they behave according to policy as they should. I personally, would have waited another two or three days, to receive an answer, but i have to go travelling for three weeks from tomorow, sunday, on and would like to have a clean slate before. As the former maintainer expressed his current state and intention clearly, i don't think he would feel bad, if we give those pkgs a push. Btw.: My name is in the changelog, already. Is that enough to be the maintainer in the future? Now, if anybody would be willing, the signed source packages libgii and libggi can be had with deb-src http://home.t-online.de/home/eislink/debian unstable main or downloaded from the web page at http://eislink.debox.de. I'm _really_ sorry that my postings always tend to be somwhat longer. I try as much to reduce, but am used to work in the background and come up to the open with a solution then ... and then i have to explain ... When you've become used to that, i promise to stop explaining this in the future at least ;-) Thanks for reading, greetings and a nice weekend to all of you, martin I expect to be able to receive mail during the next three weeks anyhow. -- Cross Building nano HOW-TO V 0.2 http://eisdoc.debox.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_installdeb & postrm
On Saturday 24 February 2001 17:48, Eric VB wrote: > Now if I add a line to debian/postrm.debhelper, everytime I re-build > my package (dpkg-buildpackage -rfakeroot), this line is erased. Where > do I have to declare my cutomized commands ? > > man dh_installdeb doesn't help and is a bit confused : Hm, all in there. And you can read source code? _Big_ ;-) > > dh_installdeb automatically installs the following files > > from debian/ into the DEBIAN directory: .. > >package.postrm .. > > The postinst, preinst, postrm, and prerm are handled spe- > > cially: If a corresponding file named debian/script.deb- > > helper exists, the contents of that file are merged into dh_make gives you some files to start with. They come from /usr/share/debhelper/.. The main package (the first binary package in your control file) may simply have 'postrm' as your script. But you may also give an explicit package prefix for this. If you do this or build more binaries, you may name them package.postrm, that is eg. libggi.postrm and libggi2-dev.postrm. These may again contain lines with #DEBHELPER# in them. This keyword will be replaced by the scripts that are automatically generated by the various debhelper progs. These are called postrm.debhelper or package.postrm.debhelper and naturally overwrite your changes made there. greetings, martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package checking
> > > On Sat, Feb 24, 2001 at 12:25:01PM +0100, > > [EMAIL PROTECTED] wrote: > > > > Hmm, the configure file should also check for ghttp.h, it didnt > On Sat, Feb 24, 2001 at 06:21:13PM +0100, Martin Albert wrote: > > This produces unnecessary hassles when, for instance, cross > > compiling. On Saturday 24 February 2001 18:45, Sam TH wrote: > I don't see why. The package isn't going to compile if $host doesn't > have ghttp.h on the system. Sure, $target doesn't need it, but I > don't see how that will matter to configure. Configure gets run on > $host, which is where the file needs to be. I understand what you mean with $host and $target. As lots of progs use autoconf and it's the one solution to provide complete coverage of all required cases, i propose to follow autoconfs nomenclature in section 'Definition of terms' in Cross building nano HOW-TO V0.2 ;-) We would then speak of BUILD and HOST, as silly this may be. The scenario you describe above would be the worst case. Autoconf not recognizing an attempted cross build, falsely using /usr/include. You would hardcode that bad/wrong/outdated behaviour into your configure script by testing for /usr/include/whatever Modern autoconf tries to do better (and fails when X is not available for HOST, but is for BUILD) and can be fed with HOST information, so that simple programs do not require to be configured externally on the host machine. A newly created Debian package should not be build with erronous behaviour built in, but instead make intelligent use of the advanced environment available with Debian/GNU Linux, so that it can stand for it in the future. Sorry, if this sounds a bit dry - i'm still in the process to get this all sorted out, to be able to provide better info and advice in the future. Let's just simply make it better ;-) It still stands anyway, that IMHO a Build-Dependency is sufficient (or it were simply useless) and that i personally would like the one person preparing that package to undertake the effort to get rid of this additional (useless) configure test in his new package. Reference-packages: autoconf, dpkg-cross greetings, martin -- Cross Building nano HOW-TO V 0.2 http://eisdoc.debox.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy and conffile editing
On Sat, Feb 24, 2001 at 01:42:01PM +0100, [EMAIL PROTECTED] wrote: > On Fri, Feb 23, 2001 at 02:02:53PM -0800, Aaron Lehmann wrote: > > It seems this is at odds with policy, which prohibutes the automated > > editing of conffiles (such as squid.conf). This is a bit ironic, since > > asking 'Would you like to enable this package by inserting a line FOO > > into /etc/squid.conf? [Y/n]' is much cleaner than printing a note 'You > > must run the script /usr/sbin/setupthispckage to enable this package'. > > While both of those would acomplish essensially the same thing, only > > one would be permissible by policy. > > > > What should I do in regards to editing this conffile? > You should not change (semi-)automatic the squid.conf by asking debconf > questions. Those changes are vital and the admin should make these changes by > hand. Take a look in login.app. It displays a message to change your inittab > accordingly (change default runlevel for example). You could, however, make the changes to a copy of the configuration file, so that if the admin decides to implement your changes, she need only copy that file over the existing config file. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I would like to debianize mod_gzip
* Britton | Yes, you should check the wnpp page http://www.debian.org/devel/wnpp/index | to make sure no one else is already working on it, then announce you | intent to package by filing a wishlist bug against wnpp as per the | instructions in the developers reference (which you should read :). Actually - he should rename the RFP bug to an ITP. | > I would like to debianize mod_gzip requested 5 days ago. Since I'm not an | > official debian maintainer (yet) I'll probably need a sponsor for this package | > (any volunteers ?). Should/can I submit a bug announcing my intention ? I can sponsor you. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package checking
On Fri, Feb 23, 2001 at 11:16:16PM -0600, Sam TH wrote: > > $ lintian --version > > Lintian v1.20.6 > > $ lintian uf-view_1.2-2_i386.changes > > E: uf-view source: package-uses-debhelper-but-lacks-build-depends > > Fixed, I think. I removed every possibly related package I could find > from my chroot, and then tried to build uf-view. I had to ask apt-get > to install only: libgnome-dev, libghttp-dev and debhelper, but those > brought in close to 50 other packages (all of X and GNOME, for > example). Are those three all that is needed for Build-Depends? >From current policy: When specifying the set of build-time dependencies, one should list only those packages explicitly required by the build. It is not necessary to list packages which are required merely because some other package in the list of build-time dependencies depends on them. The reason is that dependencies change, and you should list only those _you_ need. What others need is their business. Hopefully this will answer your question. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/ question
On Fri, Feb 23, 2001 at 03:57:33PM -0800, Sean 'Shaleh' Perry wrote: > in your preinst, check for /etc/foo and if it exists, mkdir /etc/package and > copy /etc/foo there. Then remove /etc/foo. Import thing here is that the > preinst should not die because of any errors here. Perhaps better: copy it in the postinst, remove the old version in the postinst. Then if any problems arise, the original version will still be present. If you are really careful, you should also move them back if the package is being downgraded to a pre-move version. Check policy to see how the maintainer scripts are run. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I can't sign .dsc file
On Fri, Feb 23, 2001 at 12:47:32PM +0100, Javier Vi?uales Guti?rrez wrote: > Hello, I can't sign the file .dsc of a new package I'm makeing because > debsign says: > > gpg: [stdin]: clearsign failed: Secret key no available > /usr/bin/debsign: GPG error occurred! > > I can sign my e-mail messages with gpg, my ~/.gnupg has the files needed, > what I doing wrong please?. The username + email that you use in your debian/changelog must exactly match that in your secret keyring. If it doesn't, then have a look at the debsign docs! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy and conffile editing
On Sat, Feb 24, 2001 at 02:19:08PM +0100, Ove Kaaven wrote: > > On Sat, 24 Feb 2001 [EMAIL PROTECTED] wrote: > > > If you really think you want to change this automatically, you can ask the > > squid maintainer to remove /etc/squid.conf from his conffiles. > > If it's necessary to remove it from conffiles in order to edit it from a > script in /usr/sbin, then both sgml-base (/etc/sgml/transitional.cat > edited by install-sgmlcatalog) and mime-support (/etc/mailcap edited by > update-mime) violates this policy. You're right. They should have bugs filed against them. Because otherwise, every time the package is upgraded, the sysadmin will be asked to check the changes unnecessarily. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/ question
On Sun, 25 Feb 2001, Julian Gilbey wrote: > On Fri, Feb 23, 2001 at 03:57:33PM -0800, Sean 'Shaleh' Perry wrote: > > in your preinst, check for /etc/foo and if it exists, mkdir /etc/package and > > Perhaps better: copy it in the postinst, remove the old version in the > postinst. Then if any problems arise, the original version will still > be present. BAD idea. This will defeat the conffile change detection engine in dpkg, and will cause problems in some cases. Don't do that. In the *pre*inst, mv old -> new IFF old exists and new does NOT exist In the posinst, just use the new location. Remember to correctly unwind, moving the conffile back to its original place (as long as the original file does not exist) in the abort-install and abort-upgrade targets of preinst, postrm and postinst. [never tried this, but that seems to be what's needed from the not-so-clear policy chapter 6] > If you are really careful, you should also move them back if the > package is being downgraded to a pre-move version. Check policy to > see how the maintainer scripts are run. Yes, that might be a good idea. However, as a rule of thumb, downgrading is not supported (do note that failed/aborted upgrades ARE supported). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh PGP signature
Re: /etc/ question
On Sat, Feb 24, 2001 at 10:42:38PM -0300, Henrique M Holschuh wrote: > On Sun, 25 Feb 2001, Julian Gilbey wrote: > > On Fri, Feb 23, 2001 at 03:57:33PM -0800, Sean 'Shaleh' Perry wrote: > > > in your preinst, check for /etc/foo and if it exists, mkdir /etc/package and > > > > Perhaps better: copy it in the postinst, remove the old version in the > > postinst. Then if any problems arise, the original version will still > > be present. > > BAD idea. This will defeat the conffile change detection engine in dpkg, and > will cause problems in some cases. Don't do that. Oops, typo! Thanks for spotting it. Read as follows: Perhaps better: copy it in the PREINST, remove the old version in the postinst. Then if any problems arise, the original version will still be present. > In the *pre*inst, mv old -> new IFF old exists and new does NOT exist Good. > In the posinst, just use the new location. > Remember to correctly unwind, moving the conffile back to its original place > (as long as the original file does not exist) in the abort-install and > abort-upgrade targets of preinst, postrm and postinst. [never tried this, > but that seems to be what's needed from the not-so-clear policy chapter 6] Agreed it's not so clear. I want to figure out what questions to ask Wichert about what it says. I'm confused about when error unwinding is done and would like to clarify it. > > If you are really careful, you should also move them back if the > > package is being downgraded to a pre-move version. Check policy to > > see how the maintainer scripts are run. > > Yes, that might be a good idea. However, as a rule of thumb, downgrading is > not supported (do note that failed/aborted upgrades ARE supported). It isn't? I thought we tried to as much as possible. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debhelper and multiple README files
Manfred Wassmann wrote: > > Well, um, partly so that if dh_installdocs does not do what you want, > > you can work around it and still be assured of proper permissions once > > you run dh_fixperms? > > But if it was done in the first place dh_fixperms was not required. In > other words, it would be redundant but failsafe and you created debhelper > to make life easier, dind't you? ;) dh_fixperms ensures that _all_ files you have installed have appropriate permissions. Including documentation files you installed by hand, for example. I have slowly been making debhelper commands set appropriate file permissions w/o dh_fixperms, but it's a very low priority and I doubt I'll do them all. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bigloo and libgc5
I am creating a new package for bigloo, a Scheme compiler, version 2.2b. It depends on a version of libgc, previously (in version 2.0e) this was libgc4. I have recently adopted this package, and in looking over the previous maintainer's work, I noticed that bigloo includes the source code to libgc, and that the previous maintainer forced bigloo to use the libgc from the libgc4 package rather than the libgc that comes with bigloo. Now, libgc4 has been gone for quite some time now (and there were numerous bugs submitted on bigloo because of this fact), replaced by libgc5. The new version of bigloo, 2.2b, also includes a copy of libgc5 albeit an older one (5.1, where libgc5 package is 5.3). Apparently the libgc 5.1 source code has been somewhat integrated into the bigloo source tree. The problem arises when I try to do what the previous maintainer did, namely: copy the libgc 5.3 lib from the libgc5 package and bypass the building of libgc 5.1 in the source tree. Everything goes fine, until it tries to build the bigloo.heap: LD_LIBRARY_PATH=/home/mrd/debian/bigloo/old/bigloo-2.2b/lib/2.2b:$LD_LIBRARY_PATH; \ export LD_LIBRARY_PATH; \ /home/mrd/debian/bigloo/old/bigloo-2.2b/bin/bigloo -unsafe -q -mkheap -mklib -s Llib/make-lib.scm -heap bigloo.heap *** ERROR:bigloo:internal error: aborting -- #f /home/mrd/debian/bigloo/old/bigloo-2.2b/lib/2.2b contains the libgc 5.3 library. Now, when I allow bigloo to build its own version of libgc (5.1) and compile, everything runs smoothly, and I was able to create a debian package with little trouble. But as the libgc5 package already exists, the bigloo package would then have to install an older version of the same library. True, it installs the library into /usr/lib/bigloo/2.2b, which eliminates the name conflict, rather than /usr/lib, but it would seem more appropriate if it used the libgc5 (5.3) package's library instead (and perhaps used a symlink from /usr/lib/bigloo/2.2b/libgc.so to /usr/lib/libgc.so). From what I can see, I have two options: prepare the package that contains bigloo's old version of libgc.so, or contact the author and attempt to figure out why bigloo does not play well with the libgc5 package's libgc.so. Any input on this matter would be of great help to me, thanks. Matthew Danish -- GPG Public Key Fingerprint: A3C6 93AF 5805 F46B 67D5 96B2 CF15 3232 C24B 6010 Key available from: wwwkeys.pgp.net ID: C24B6010 PGP signature
Re: /etc/ question
On Sun, 25 Feb 2001, Julian Gilbey wrote: > On Sat, Feb 24, 2001 at 10:42:38PM -0300, Henrique M Holschuh wrote: > > Yes, that might be a good idea. However, as a rule of thumb, downgrading is > > not supported (do note that failed/aborted upgrades ARE supported). > > It isn't? I thought we tried to as much as possible. Try is the operative word. Don't do that to anything you can't risk being left as a complete mess. Downgrading glibc has killed more than one with extreme prejudice, I'm told :P -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh PGP signature
Re: /etc/ question
On Sat, Feb 24, 2001 at 10:42:38PM -0300, Henrique M Holschuh wrote: [...] > > Remember to correctly unwind, moving the conffile back to its original place > (as long as the original file does not exist) in the abort-install and > abort-upgrade targets of preinst, postrm and postinst. [never tried this, > but that seems to be what's needed from the not-so-clear policy chapter 6] In the package I maintain, called crafty, I moved /etc/craftyrc to /etc/crafty.rc and /var/cache/crafty to /var/lib/crafty in the previous version (17.9). Version now is 17.13. The 'move' routine is still in preinst of the latest version because we don't know what version people are upgrading from. Now that's my problem : if upgrade fails or is aborted, I should move the files back to their original location. But if people are upgrading from a 'post-move' version, the original location is different than if they were upgrading from a 'pre-move' location. So, where do I move the files back ??? -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
