Re: [Emc-users] New BDI-4 packages.
Paul, Each time you change your kernel version, you have to change the files debian/control, debian/rules and debian/emc2.files to reflect the kernel version. You did this once to change it from the original to 2.6.12.6-rtai, so I don't understand why you didn't simply change it again for 2.6.16. If you wanted to create a good experience for your users, you should publish a package based on the files tagged TESTING, not the HEAD version of a particular day. This is what Chris does when he builds the debian packages for Ubuntu. Until Paul has straightened this out, I recommend following the instructions on the emc wiki to build emc2 TESTING on bdi4 machines. http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BDI-4_38_Compile_EMC2 http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Testing If you run into problems because of Paul's kernel upgrade, please let me know; if you can update the instructions on the wiki, even better. Jeff PS If you have patches or advice about how the emc2 debian/ directory can be enhanced so it does not hard-code kernel version numbers, please let the emc2 developers know. I'd be pleased to incorporate any patches that improve the packaging of emc2 into .debs.
Jeff On Wednesday 29 March 2006 16:47, Jeff Epler wrote:
Each time you change your kernel version, you have to change the files debian/control, debian/rules and debian/emc2.files to reflect the kernel version.
If the rules were smart enough to interpret KSRC and KVERS (both exported when building with m-a), editing of any file would be unnecessary. With a little forethought and use of dh_install, there should be no need to have version dependant paths listed.
You did this once to change it from the original to 2.6.12.6-rtai, so I don't understand why you didn't simply change it again for 2.6.16.
The majority of users are running either a 2.6.10 or 2.6.12 kernel. The 2.6.16 is a candidate for the next BDI-4 build (up until a few days ago, it was going to be 2.6.15). In it's present state, the emc2 package will not be included in a BDI-4 build, only the sources, it is only in the repository for the few that want to try it.
PS If you have patches or advice about how the emc2 debian/ directory can be enhanced so it does not hard-code kernel version numbers.
See above comment about KSRC and KVERS - Failing that, you have all the kernel specific information in src/Makefile.inc, although it is poor policy to rely on that autogenerated file. Basic grep & sed will do the rest if you insist on using <package name>.files (suggestion: generate them on the fly). Once you have removed all hard coded version numbers, one rule set will serve for ALL debian derived packages, be it Ubuntu or what ever. Regards, Paul.
On Fri, Mar 31, 2006 at 12:51:04PM +0100, Paul wrote:
See above comment about KSRC and KVERS - Failing that, you have all the kernel specific information in src/Makefile.inc, although it is poor policy to rely on that autogenerated file. Basic grep & sed will do the rest if you insist on using <package name>.files (suggestion: generate them on the fly). Once you have removed all hard coded version numbers, one rule set will serve for ALL debian derived packages, be it Ubuntu or what ever.
So that I can get an idea how 'm-a' works, what's the commandline on a bdi 4.3x machine to rebuild the emc modules into a new .deb package? I tried these variations: m-a -t a-i emc m-a -t a-i emc-modules m-a -t a-i emc-modules-`uname -r` but they all failed for various reasons. I'll be happy to provide the error messages if you wish. Jeff
participants (2)
-
Jeff Epler -
Paul