How to handle ´/etc/ld.so.preload library packages?
I have a package with a library that needs to be entered to /etc/ld.so.preload. It is clear that this library needs to go in /lib rather than /usr/lib because there are systems that have /usr on a dedicated partition. But how do I handle the entry to /etc/ld.so.preload? There are packages that leave the ld.so.preload entry to the user, but they probably make the system fail when they are uninstalled and the user forgets to manually remove the ld.so.preload entry. So, how am I to deal with this in the packaging? (1) Don't add the lib to /etc/ld.so.preload, display a hint for the user to do so, but remove the entry in the prerm if the package is to be removed? (2) Ask the user if I should add the lib to /etc/ld.so.preload in the postinst and automatically remove the entry in prerm? Does order in /etc/ld.so.preload matter? (3) Do everything fully automatic? Any comments will be appreciated. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OK to use /etc/default for non-init script default data?
On Mon, 4 Jun 2001 10:12:19 +0100, Julian Gilbey <[EMAIL PROTECTED]> wrote: >Why not just /etc/foorc or /etc/foo.conf or something like that? Because the conffile is not a "real" conffile, but rather a shell script being sourced in, and /etc/foo.conf will probably suggest that this conffile is an upstream feature. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Integration of debian/ scripts in packages
--- Sam Hartman <[EMAIL PROTECTED]> wrote: > > "Michèl" == Michèl Alexandre Salim > <[EMAIL PROTECTED]> writes: > And if you come up with a clean solution for the > changelog issue, I > agree this is worth doing. If you do that, please > let me know what > your solution is. > As Richard Atterer said there should probably be another set of debian scripts provided by the upstream author (if possible) and maintained independently from the Debian-maintained scripts. Rather a neat idea. And certainly I have seen it implemented - for Enlightenment 0.17 CVS for instance. It is still the duty of the Debian maintainer to make sure the Debian version of the scripts conform to Debian specifications, but if something major changes in the package the author(s) would know best what has changes. So it is a two-way process: if Debian policy changes the maintainer informs the author, if the packaging changes the author-maintained debian scripts will still allow building of the package seamlessly while the Debian maintainer work on integrating the changes. There could probably be a naming scheme enforced, with say package version x.y.z having an upstream deb at version x.y.z.hack.n while the Debian version at x.y.z.official.n - the names are just example, I presume official will be seen by dpkg as being a higher version than hack? Just my penny's worth.. Regards, Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Integration of debian/ scripts in packages
> "Michèl" == Michèl Alexandre Salim <[EMAIL PROTECTED]> writes: >> Michèl> The reason I raise this issue in the first place is Michèl> actually a notion that it would be nice for users wanting Michèl> bleeding-edge software to update from CVS and just run Michèl> debian/rules binary or dpkg-buildpackage, the same way Michèl> they can rpm -tb package.tar.gz currently (granted, most Michèl> of the time one thing or another is broken. Especially the Michèl> changelog - rather incredible). And if you come up with a clean solution for the changelog issue, I agree this is worth doing. If you do that, please let me know what your solution is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Integration of debian/ scripts in packages
On Mon, Jun 04, 2001 at 06:31:54PM +0100, Michèl Alexandre Salim wrote: [debian/ in upstream makes maintaining package difficult] > The reason I raise this issue in the first place is actually a > notion that it would be nice for users wanting bleeding-edge > software to update from CVS and just run debian/rules binary or > dpkg-buildpackage, the same way they can rpm -tb package.tar.gz > currently (granted, most of the time one thing or another is broken. > Especially the changelog - rather incredible). I've been thinking about this as well - it /would/ be nice for a user to just run dpkg-buildpackage after unpacking the tarball... Maybe a simple and straightforward solution would be to provide a "debian.upstream" directory in the upstream sources, and a rule in the upstream Makefile which soft-links this to "debian" before running dpkg-buildpackage. Then the user would only have to "make deb". Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OK to use /etc/default for non-init script default data?
On Mon, Jun 04, 2001 at 10:31:18AM +0200, Marc Haber wrote: > Hi, > > let's say I have a package foo with a binary foo. The author suggests > the one should have a shell script wrapper to be able to call the foo > binary with the appropriate options. I want to do so in my package. > > - Have the foo-Binary in /usr/lib/foo/foo > - Have a foo shell script wrapper in /usr/bin/foo > - /usr/bin/foo sources /etc/default/foo so that the admin can change > the default values without interfering with the wrapper itself. > > This is the way to do it for an init script. Is it OK to have a file > in /etc/default that does not provider defaults for an init script > but for an executeable called by users? Why not just /etc/foorc or /etc/foo.conf or something like that? I don't know if it's such a great idea to pollute the /etc/default namespace, and it's not intuitive. 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: Integration of debian/ scripts in packages
> "Michèl" == Michèl Alexandre Salim <[EMAIL PROTECTED]> writes: Michèl> Hello, A general observation of Unix programs in general - Michèl> a lot more of them come with RPM spec files, even Michèl> generates them automatically from a spec.in file, than Michèl> with debian scripts. A lot of this has to do with the relative value of doing so. An RPM outside of the Redhat archive is more common than a deb outside of the Debian archive. Debian is willing to accept most DFSG free packages into its archive, so users can get a good approximation of all the Debian software available by looking at what is in unstable. RPM-based distributions tend to be more selective about what they accept. Thus, a user is going to be just as likely to go to the original author as to their distribution to find software. As a Debian user, I will tend to go to Debian before the original author. If there is a debian directory, I am likely to find it already in Debian and never get to the original author's site. Note that Debian directories outside of Debian have dubious utility. Really only the maintainer should be editing debian/changelog, but yet if debian/changelog doesn't match the version of software, then siginifacnt problems may result.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Integration of debian/ scripts in packages
--- Josip Rodin <[EMAIL PROTECTED]> wrote: > On Sun, Jun 03, 2001 at 11:40:26PM -0300, Henrique > de Moraes Holschuh wrote: > files there. Even if > > upstream keeps its debian/ up-to-date, it will > still cause you trouble if > > you have to remove a file, as you'll need to > either use dirty tricks, or > > Adding 'rm -f debian/foo' in debian/rules clean rule > is not a dirty trick. > The reason I raise this issue in the first place is actually a notion that it would be nice for users wanting bleeding-edge software to update from CVS and just run debian/rules binary or dpkg-buildpackage, the same way they can rpm -tb package.tar.gz currently (granted, most of the time one thing or another is broken. Especially the changelog - rather incredible). Then again, most of the time the diff.gz from packages.debian.org can be applied cleanly so it is not much of a problem - just when the software has radically changed (like Glib 1.2 -> Glib 1.3). Regards, Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Status update: GLib/GTK+ 1.3 CVS
Hello, A brief follow-up to my post last weekend. The current status of my test packages are as follows: GLib - packages created. RFC - I am not a seasoned developer (yet!), any advice more than welcome. Gtk-doc - needed if you want to recompile GNOME CVS modules (including GLib). I have packaged the CVS version, should be stable as I just applied the debian scripts from gtk-doc-package in sid Pango - stuck, problem with shlibs:Depends not being accepted by dpkg-gencontrol as a result of which package has no dependencies. See post to debian-mentors, any help very appreciated Atk GTK+ both waiting for Pango Packages downloadable from sourceforge.net/projects/alterdeb Any new (and would-be) maintainers wanting to put up Debian packages for review more than welcome to put it there as well, just shout :) TIA, Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: glib2, gtk2, inti
--- Robert Bihlmeyer <[EMAIL PROTECTED]> wrote: >
Michèl Alexandre Salim <[EMAIL PROTECTED]>
> writes:
>
> > Have not managed to package Pango - can anyone
> assist me in finding
> > out what is going wrong? Basically the package
> failed the install
> > stage of the rules script if installed using an
> alternate path
> > (specified using prefix or DESTDIR).
>
> Exactly how does it break? Copy the exact error
> message if feasable.
>
> --
> Robbe
Funny, could not replicate the error now, guess I was
sloppy and did not clean up and rebuild the source
before attempting it again. Have another problem
though, when building libpango0 dpkg-gencontrol
complained thus:
dpkg-gencontrol: warning: unknown substitution
variable ${shlibs:Depends}
Attached are the debian/control and debian/rules
files.
If this is fixed I can finish packaing libatk0 and
then libgtk+1.3, currently a bit wary having a package
that does not depend on anything.
TIA,
Michel
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
control
rules
Re: OK to use /etc/default for non-init script default data?
Marc Haber wrote: > This is the way to do it for an init script. Is it OK to have a file > in /etc/default that does not provider defaults for an init script > but for an executeable called by users? I don't know. I don't see a lot of advantage over just putting the conffile in /etc. There is something to be said for leaving /etc/default/ only for init scripts. Of course, "default" is perhaps not the best name for it if it only holds init script configs. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Integration of debian/ scripts in packages
On Sun, Jun 03, 2001 at 11:40:26PM -0300, Henrique de Moraes Holschuh wrote: > Most of the time, no. Upstream debian/ cruft gets in the way of the updated > debian/ files, especially if you need to delete files there. Even if > upstream keeps its debian/ up-to-date, it will still cause you trouble if > you have to remove a file, as you'll need to either use dirty tricks, or Adding 'rm -f debian/foo' in debian/rules clean rule is not a dirty trick. -- Digital Electronic Being Intended for Assassination and Nullification
Re: first questions
Andreas Bombe <[EMAIL PROTECTED]> writes: > It's just that making the package non-native makes it easier to > handle unless it's really a native package (i.e. written > specifically for Debian). YMMV, obviously. I find it easier to maintain quintuple-agent without Debian subversions; "native" if you will. > For a native package, a small bug in packaging requires a whole new > release. If it's not a Debian-specific package, you inflict a new > version number on all the users outside of Debian who feel compelled to > download the new release to stay on the edge. You're not forced to put the new version up for download outside of Debian. Or you can point out in the release notes that the changes are only relevant if you use the Debian package. quintuple-agent in Debian is at 1.0.3 while the "upstream" distribution point still has 1.0.0. Now, who said that Debian has only outdated versions, huh? -- Robbe signature.ng
Re: Adding device file to /dev.
Russell Coker <[EMAIL PROTECTED]> writes: > On Monday 04 June 2001 00:59, Julian Gilbey wrote: > > On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote: > > > Another thing any package that depends on the creation of nodes under > > > /dev MUST depend on "makedev | devfsd". People who run devfsd do not > > > need to have makedev installed. > > > > Should this stuff go into policy? > > I think so. In this case, please also add consideration for the Hurd. "hurd" package provides "makedev" so the above would work. "makedev (>> 1.2.3) | devfsd" is a problem, though. -- Robbe signature.ng
Re: Integration of debian/ scripts in packages
On Sun, Jun 03, 2001 at 11:40:26PM -0300, Henrique de Moraes Holschuh wrote: > Most of the time, no. Upstream debian/ cruft gets in the way of the updated > debian/ files, especially if you need to delete files there. Even if > upstream keeps its debian/ up-to-date, it will still cause you trouble if > you have to remove a file, as you'll need to either use dirty tricks, or Adding 'rm -f debian/foo' in debian/rules clean rule is not a dirty trick. -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Adding device file to /dev.
On Monday 04 June 2001 10:34, Hamish Moffatt wrote: > On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote: > > Another thing any package that depends on the creation of nodes under > > /dev MUST depend on "makedev | devfsd". People who run devfsd do not > > need to have makedev installed. > > Well, makedev is priority: required and section: base. Is it > necessary for packages to declare an explicit dependency in that > case? Currently many (most? all?) packages that need to create device nodes depend on makedev. I have been filing bug reports against them because I believe that they should depend on "makedev|devfs". I would be happy to have them depend on neither but the maintainers of some of the packages are quite adamant that they want to depend on such a package. As for it being required and base, I want to remove makedev from my systems. I have no need for it. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Adding device file to /dev.
On Monday 04 June 2001 00:59, Julian Gilbey wrote: > On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote: > > Also make the package check for the presence of the character device > > /dev/.devfsd first, if that device exists then your script must not > > attempt to create the device node and it should be left for the kernel to > > do it! If you create a node under /dev when devfs is running it may > > result in an attempt to load the module, also the node will disappear on > > reboot! > > > > Another thing any package that depends on the creation of nodes under > > /dev MUST depend on "makedev | devfsd". People who run devfsd do not > > need to have makedev installed. > > Should this stuff go into policy? I think so. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: /usr/share policy
On Sun, Jun 03, 2001 at 07:23:08PM -0400, Joey Hess wrote: > Julian Gilbey wrote: > > Agreed. (And I don't think /usr/share/ is mandated.) > > Every package MUST be accompanied by a verbatim copy of its copyright > and distribution license in the file > `/usr/share/doc/__/copyright' > > Packages that are not Debian-native MUST contain a copy of > `debian/changelog' file from the Debian source tree in > `/usr/share/doc/' as `changelog.Debian.gz'. > > (Caps mine.) That's not the issue under discussion; we're talking about putting data in /usr/share/ or elsewhere in /usr/share, not about the copyright file, etc. 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: Adding device file to /dev.
On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote: > Another thing any package that depends on the creation of nodes under /dev > MUST depend on "makedev | devfsd". People who run devfsd do not need to have > makedev installed. Well, makedev is priority: required and section: base. Is it necessary for packages to declare an explicit dependency in that case? Admittedly, it's not essential: yes. Nor is libc6. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
OK to use /etc/default for non-init script default data?
Hi, let's say I have a package foo with a binary foo. The author suggests the one should have a shell script wrapper to be able to call the foo binary with the appropriate options. I want to do so in my package. - Have the foo-Binary in /usr/lib/foo/foo - Have a foo shell script wrapper in /usr/bin/foo - /usr/bin/foo sources /etc/default/foo so that the admin can change the default values without interfering with the wrapper itself. This is the way to do it for an init script. Is it OK to have a file in /etc/default that does not provider defaults for an init script but for an executeable called by users? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Adding device file to /dev.
On Monday 04 June 2001 10:34, Hamish Moffatt wrote: > On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote: > > Another thing any package that depends on the creation of nodes under > > /dev MUST depend on "makedev | devfsd". People who run devfsd do not > > need to have makedev installed. > > Well, makedev is priority: required and section: base. Is it > necessary for packages to declare an explicit dependency in that > case? Currently many (most? all?) packages that need to create device nodes depend on makedev. I have been filing bug reports against them because I believe that they should depend on "makedev|devfs". I would be happy to have them depend on neither but the maintainers of some of the packages are quite adamant that they want to depend on such a package. As for it being required and base, I want to remove makedev from my systems. I have no need for it. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Adding device file to /dev.
On Monday 04 June 2001 00:59, Julian Gilbey wrote: > On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote: > > Also make the package check for the presence of the character device > > /dev/.devfsd first, if that device exists then your script must not > > attempt to create the device node and it should be left for the kernel to > > do it! If you create a node under /dev when devfs is running it may > > result in an attempt to load the module, also the node will disappear on > > reboot! > > > > Another thing any package that depends on the creation of nodes under > > /dev MUST depend on "makedev | devfsd". People who run devfsd do not > > need to have makedev installed. > > Should this stuff go into policy? I think so. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/share policy
On Sun, Jun 03, 2001 at 07:23:08PM -0400, Joey Hess wrote: > Julian Gilbey wrote: > > Agreed. (And I don't think /usr/share/ is mandated.) > > Every package MUST be accompanied by a verbatim copy of its copyright > and distribution license in the file > `/usr/share/doc/__/copyright' > > Packages that are not Debian-native MUST contain a copy of > `debian/changelog' file from the Debian source tree in > `/usr/share/doc/' as `changelog.Debian.gz'. > > (Caps mine.) That's not the issue under discussion; we're talking about putting data in /usr/share/ or elsewhere in /usr/share, not about the copyright file, etc. 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: Adding device file to /dev.
On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote: > Another thing any package that depends on the creation of nodes under /dev > MUST depend on "makedev | devfsd". People who run devfsd do not need to have > makedev installed. Well, makedev is priority: required and section: base. Is it necessary for packages to declare an explicit dependency in that case? Admittedly, it's not essential: yes. Nor is libc6. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
OK to use /etc/default for non-init script default data?
Hi, let's say I have a package foo with a binary foo. The author suggests the one should have a shell script wrapper to be able to call the foo binary with the appropriate options. I want to do so in my package. - Have the foo-Binary in /usr/lib/foo/foo - Have a foo shell script wrapper in /usr/bin/foo - /usr/bin/foo sources /etc/default/foo so that the admin can change the default values without interfering with the wrapper itself. This is the way to do it for an init script. Is it OK to have a file in /etc/default that does not provider defaults for an init script but for an executeable called by users? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: glib2, gtk2, inti
--- Robert Bihlmeyer <[EMAIL PROTECTED]> wrote: > Michèl Alexandre Salim <[EMAIL PROTECTED]> > writes: > > [your mail formatting was totally messed up, BTW] > Yes, sorry about that :) Using the university's network connection to do most of my e-mailing and somehow or another it is fraught with problems, not sure how they set up the firewalls. HTTP access was particularly slow so I did not bother doing a preview - sorry for that, and for sending it twice too. Timed out loading the 'message sent' page. > > Have not managed to package Pango - can anyone > assist me in finding > > out what is going wrong? Basically the package > failed the install > > stage of the rules script if installed using an > alternate path > > (specified using prefix or DESTDIR). > > Exactly how does it break? Copy the exact error > message if feasable. > Thanks for the offer :) Will post it tomorrow. Probably going to set up Red Hat on my other machine to see if building the RPM works. Regards, Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
