Re: Support for DEB_BUILD_OPTIONS in rules files
On Sun, Apr 22, 2001 at 07:35:01PM -0400, Bob Hilliard wrote: > It appears to me that the method recommended in policy section > 11.1 to support DEB_BUILD_OPTIONS in the rules file requires the > DEB_BUILD_OPTIONS variable to contain both `debug' and `nostrip' in > order to generate a package with debugging information included. > > Is this correct and is this what is intended? Yes. It's for debugging purposed only. However, if you build a library package, and you generate a libfoo1, libfoo1-dev and libfoo1-dbg, then this doesn't apply to you specifically. IOW, it's not the same thing. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Support for DEB_BUILD_OPTIONS in rules files
It appears to me that the method recommended in policy section 11.1 to support DEB_BUILD_OPTIONS in the rules file requires the DEB_BUILD_OPTIONS variable to contain both `debug' and `nostrip' in order to generate a package with debugging information included. Is this correct and is this what is intended? Bob -- _ |_) _ |_ Robert D. Hilliard <[EMAIL PROTECTED]> |_) (_) |_) 1294 S.W. Seagull Way <[EMAIL PROTECTED]> Palm City, FL USA GPG Key ID: 390D6559 PGP Key ID: A8E40EB9
Re: Support for DEB_BUILD_OPTIONS in rules files
On Sun, Apr 22, 2001 at 07:35:01PM -0400, Bob Hilliard wrote: > It appears to me that the method recommended in policy section > 11.1 to support DEB_BUILD_OPTIONS in the rules file requires the > DEB_BUILD_OPTIONS variable to contain both `debug' and `nostrip' in > order to generate a package with debugging information included. > > Is this correct and is this what is intended? Yes. It's for debugging purposed only. However, if you build a library package, and you generate a libfoo1, libfoo1-dev and libfoo1-dbg, then this doesn't apply to you specifically. IOW, it's not the same thing. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Support for DEB_BUILD_OPTIONS in rules files
It appears to me that the method recommended in policy section 11.1 to support DEB_BUILD_OPTIONS in the rules file requires the DEB_BUILD_OPTIONS variable to contain both `debug' and `nostrip' in order to generate a package with debugging information included. Is this correct and is this what is intended? Bob -- _ |_) _ |_ Robert D. Hilliard <[EMAIL PROTECTED]> |_) (_) |_) 1294 S.W. Seagull Way <[EMAIL PROTECTED]> Palm City, FL USA GPG Key ID: 390D6559 PGP Key ID: A8E40EB9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: modversion.h ?
> I'm using debian testing with kernel 2.2.18pre21 and am > trying to compile modules for my NVIDIA TNT2 card, This is off topic for this list. Please post user issues to debian-user. This list is for mentoring new debian maintainers or other issues involving in creating debian packaging. > In file included from os-registry.c:67: > /usr/src/kernel-source-2.2.18pre21/include/linux/module.h:19: > linux/modversions.h: No such file or directory This means that you have the kernel source, but it hasn't been configured. You must run make config, make menuconfig, make oldconfig, or make xconfig and set and save your kernel configuration options, and that will create this file. You should set the same configuration options as were used to compile your currently running kernel. If you're using one of the stock debian kernels, then you can install the kernel-headers package which have the corresponding headers for that particular kernel, and that will contain this file. I also don't recommend sticking anything in your kernel you don't have source for. If you're trying to use binary-only non-free modules released by nvidia, you're voluntarily giving up your freedom. You're better off switching to hardware that has open specs and open drivers. Buy Matrox or ATI or just about anything else. Eric
Re: modversion.h ?
> I'm using debian testing with kernel 2.2.18pre21 and am > trying to compile modules for my NVIDIA TNT2 card, This is off topic for this list. Please post user issues to debian-user. This list is for mentoring new debian maintainers or other issues involving in creating debian packaging. > In file included from os-registry.c:67: > /usr/src/kernel-source-2.2.18pre21/include/linux/module.h:19: linux/modversions.h: >No such file or directory This means that you have the kernel source, but it hasn't been configured. You must run make config, make menuconfig, make oldconfig, or make xconfig and set and save your kernel configuration options, and that will create this file. You should set the same configuration options as were used to compile your currently running kernel. If you're using one of the stock debian kernels, then you can install the kernel-headers package which have the corresponding headers for that particular kernel, and that will contain this file. I also don't recommend sticking anything in your kernel you don't have source for. If you're trying to use binary-only non-free modules released by nvidia, you're voluntarily giving up your freedom. You're better off switching to hardware that has open specs and open drivers. Buy Matrox or ATI or just about anything else. Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Building dynamic libraries.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21-Apr-2001 Eric Van Buggenhaut wrote: > Is there a ref doc about building packages of dynamic libraries ? I, too, would like some suggestions on more-or-less complex packages that have libs or are lib-only packages, so I can take a look, since I haven't packaged a program with libs yet. - -- carlos laviola - icq #55799523 $ chown us:us /your_base -R chown: what you say!! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE64kKCZAYCJzUW03IRAk2dAJ4163AGruFDvEg0iPpnbmZwAFjyDACePJIf hcl3Gi7KX0PycvXFqKtOE2Q= =Mb7X -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Package Ready, Need Sponsor
Hi, I have retitled bug #91842, which was an RFP for Althea (an IMAP email client for GTK+), as an IFP, and the package is now ready. If you want to download it compiled for Intel, it's at: ftp://ftp.kaplowitz.org/pub/althea/althea_0.4.1-1_i386.deb The source package is also there (.dsc, .diff.gz, .orig.tar.gz), as is my .changes file from the build. Could someone from debian-mentors please take a look at my package and sponsor it for inclusion in the distribution? If it gets in, I will seek to become an official Debian developer so I can handle this myself. I have fixed all the errors and warnings given by lintian, so that now lintian gives no messages. The dsc and changes files are properly signed, with a GPG key that is on keyserver.net - I have many there, most of which are obsolete :) but this is key ID DDE735DA. I am not currently subscribed to debian-mentors, so please CC me in all replies. If you think it's important for me to subscribe to debian-mentors for any reason, please just tell me so and I'll do it. Thank you, and I wish the Althea developers good luck with their program. I'm glad I can help. - Jimmy Kaplowitz [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Building dynamic libraries.
Is there a ref doc about building packages of dynamic libraries ? -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Update release management
Hello, I apologise if this is considered off-topic - might be barking up the wrong tree in the wrong forest here - but bringing up an old issue here of release frequency, once the transition to using package pools and the new debian-installer is done, would it be reasonable to expect Debian releases more often - say, once every quarter like FreeBSD already does? The comparison with FreeBSD is rather apt as both are community projects working on whole OSes, although FreeBSD has a principal sponsor (BSDi, then WindRiver) and positions itself more commercially than does Debian (selling official CDs) and thus perhaps having more to benefit from frequent releases? That asides, with the avalanches of release in the last few days (RH 7.1, Mdk 8.0, FreeBSD 4.3) leading me to think about the future of Debian - note that last week also sees the update of the Unofficial Debian CD sets (by Attila Nagy - many thanks!), one sets to ponder certain points of matter: - it should be easier maintaining the new modular installer in-between releases (considering the present one looks very much similar to FreeBSD's spartan interface, and *that* installer has not changed in ages it seems, it would be nice if our next installer can be that dependable) - Package pools allowing easy roll-out of custom-made mini-distributions Take the two together and certain possibilities arise: 1. Frequent releases made possible for the benefit of people without blazing-fast connection 2. This frequent release should allow Debian to generate more revenue 3. A sort of package rating system, allowing a core nucleus of important libraries and programs to coalesce. Since these packages are those most likely to change and thus most noticeable when they become out of date, having frequent releases would help, and doing so would be easier with less packages to concentrate bug-fixing on 4. Inter-release update CDs could be issued ala Microsoft's Service Packs with updated packages only - so it might depend on previous release CDs. Should be simple enough to automate, does not even need an installer. I am sure all these points have been raised before, or even seem obvious and if anyone think this posting is a waste of time and space, my apologies. Just thought to appease my curiousity about Debian's future plans since I am in the process of joining it. Warm regards, -- Michèl Alexandre Salim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Package Ready, Need Sponsor
Hi Jimmy! You wrote: > Could someone from debian-mentors please take a look at my package and sponsor > it for inclusion in the distribution? If it gets in, I will seek to become an > official Debian developer so I can handle this myself. I have fixed all the > errors and warnings given by lintian, so that now lintian gives no messages. I'll sponsor you. I'll take a look at the package tonight. -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| |[EMAIL PROTECTED] | Pablo Picasso | +---+ PGP signature
Update release management
Hello, I apologise if this is considered off-topic - might be barking up the wrong tree in the wrong forest here - but bringing up an old issue here of release frequency, once the transition to using package pools and the new debian-installer is done, would it be reasonable to expect Debian releases more often - say, once every quarter like FreeBSD already does? The comparison with FreeBSD is rather apt as both are community projects working on whole OSes, although FreeBSD has a principal sponsor (BSDi, then WindRiver) and positions itself more commercially than does Debian (selling official CDs) and thus perhaps having more to benefit from frequent releases? That asides, with the avalanches of release in the last few days (RH 7.1, Mdk 8.0, FreeBSD 4.3) leading me to think about the future of Debian - note that last week also sees the update of the Unofficial Debian CD sets (by Attila Nagy - many thanks!), one sets to ponder certain points of matter: - it should be easier maintaining the new modular installer in-between releases (considering the present one looks very much similar to FreeBSD's spartan interface, and *that* installer has not changed in ages it seems, it would be nice if our next installer can be that dependable) - Package pools allowing easy roll-out of custom-made mini-distributions Take the two together and certain possibilities arise: 1. Frequent releases made possible for the benefit of people without blazing-fast connection 2. This frequent release should allow Debian to generate more revenue 3. A sort of package rating system, allowing a core nucleus of important libraries and programs to coalesce. Since these packages are those most likely to change and thus most noticeable when they become out of date, having frequent releases would help, and doing so would be easier with less packages to concentrate bug-fixing on 4. Inter-release update CDs could be issued ala Microsoft's Service Packs with updated packages only - so it might depend on previous release CDs. Should be simple enough to automate, does not even need an installer. I am sure all these points have been raised before, or even seem obvious and if anyone think this posting is a waste of time and space, my apologies. Just thought to appease my curiousity about Debian's future plans since I am in the process of joining it. Warm regards, -- Michèl Alexandre Salim
Re: Debian Package Ready, Need Sponsor
Hi Jimmy! You wrote: > Could someone from debian-mentors please take a look at my package and sponsor > it for inclusion in the distribution? If it gets in, I will seek to become an > official Debian developer so I can handle this myself. I have fixed all the > errors and warnings given by lintian, so that now lintian gives no messages. I'll sponsor you. I'll take a look at the package tonight. -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| |[EMAIL PROTECTED] | Pablo Picasso | +---+ pgplcQDuSdefH.pgp Description: PGP signature
