Re: build-essential / native-package-with-dash-version ?
On Tue, 28 Nov 2006 22:03:22 -0500, Joe Smith [EMAIL PROTECTED] said: Hubert Chan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, 28 Nov 2006 13:30:03 -0300, andremachado [EMAIL PROTECTED] said: The executable-not-elf-or-script I guess will continue. Jar, war, policy and stamp are generated by the compilation and are the results. I don't know about whether jar files should be executable, but if they shouldn't you should chmod -x them in your build process, after they get installed. Jar files are simply zip files with a manifest. The last I checked the exec syscall had no special handling for zip files, and as they lack a bang path, they relly are not executable as far as the system is concerned. So unless a JVM expects jars to have the executable bit set, it probably should not be. It is possible to support execution of jar files using the binfmt_misc mechanism. The only question is whether or not that's something that we do in Debian, which should probably be in the Debian Java policy somewhere. As I don't maintain any Java-related packages, though, I don't know what the Java policy says, so I don't know if jar files are allowed to be executable (although I suspect that they shouldn't be). -- Hubert Chan [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: build-essential / native-package-with-dash-version ?
On Tue, 28 Nov 2006 13:30:03 -0300 andremachado [EMAIL PROTECTED] wrote: The native-package-with-dash-version warning is still without solution. I read again the Debian Policy (my english skill is bare minimum) and still not find how to rename package and use debuild -rfakeroot -uc -us to correctly build package. Should I include version field in debian/control, while renaming source directory only php-java-bridge, diverging from the original real source file? The real source from site is a bz2 file. I expanded it to a temp dir for compiling. You have to somehow put the original tree in a .orig.tar.gz. You have a choice here, it's up to you. Basically you have to ponder how easy it is for you to do it, and for other people to check that you are really uploading the original source tree and have not made unclear modifications (knowingly or not). The three basic options are: - repack completely (tar -xj, then tar -cz). Time consuming, error prone, comparision has to be done on the unpacked source tree; I'd say you should not do that just for converting from bz2 to gz; - just bunzip and gzip. Simple, sensible. Comparision with upstream has to/can be done on the uncompressed tar, that's not so bad; - put the upstream tar.bz2 *into* a tar.gz, build-depend on bunzip and have your rules file unpack the source tree. You are really shipping the original upstream file, comparison can be done on it. You can't patch the source directly though, you need to use a build-time patch system to fiddle with upstream (which some see as the way to go anyway, depending on what your patches are for). Your orig file has to have the right name: pkg_upstream.verstion.orig.tar.gz. Your source directory must be called pkg-upstream.version. They must both be in the same directory, dpkg-buildpackage won't look around for them. The configure-generated-file-in-source warning is there because source contains it. Well you won't get rid of this warning then, it's OK. I believe you should make sure any target that modifies this file saves the original, and the clean target restores it. The package-contains-upstream-install-documentation is weird. I created a debian/docs file listing these files. Well, probably you should not! The warning means you should not install build instructions on the users systems. E.g., if there is an INSTALL file in the source, you should NOT put it in debian/doc. This file is useful for you, not for your users. Regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: build-essential / native-package-with-dash-version ?
On Tue, 28 Nov 2006 13:30:03 -0300, andremachado [EMAIL PROTECTED] said: Hello, Many thanks for all suggestions. the http://php-java-bridge.sf.net states some specific minimal versions of gcc, make, automake, java, etc. So, I included these versions on debian/control file. If the minimum versions are very old (e.g. if woody already meets the minimum versions), you probably don't need to include those. It's probably more trouble than it's worth. The remaining warnings can be seen at http://paste.debian.net/17466 until nov 30th. 404: Not Found The native-package-with-dash-version warning is still without solution. I read again the Debian Policy (my english skill is bare minimum) and still not find how to rename package and use debuild -rfakeroot -uc -us to correctly build package. Your package should not be a native package. It should consist of the orig tarball, plus a diff.gz file. You are probably getting this warning because when you built the package, it did not have access to the original tarball. When you build your package, the original tarball should be in the parent directory, with the name [package-name]_[upstream-version].orig.tar.gz. So, in your case, php-java-bridge_3.1.8.orig.tar.gz. Should I include version field in debian/control, while renaming The version comes from debian/changelog. source directory only php-java-bridge, diverging from the original real source file? The real source from site is a bz2 file. I expanded it to a temp dir for compiling. No, you should keep the source as pristine as possible. Probably the best thing to do, IMHO, is to just bunzip it, and then gzip it. The configure-generated-file-in-source warning is there because source contains it. Let upstream know about it. It may have been a mistake, and should be corrected for their next version. Just make sure that it doesn't case problems for your build, and you should be able to ignore that warning for now. The package-contains-upstream-install-documentation is weird. I created a debian/docs file listing these files. You don't need to include upstream's installation documentation, because the procedure will be different for those installing from your package. The executable-not-elf-or-script I guess will continue. Jar, war, policy and stamp are generated by the compilation and are the results. I don't know about whether jar files should be executable, but if they shouldn't you should chmod -x them in your build process, after they get installed. -- Hubert Chan [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: build-essential / native-package-with-dash-version ?
Hubert Chan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, 28 Nov 2006 13:30:03 -0300, andremachado [EMAIL PROTECTED] said: The executable-not-elf-or-script I guess will continue. Jar, war, policy and stamp are generated by the compilation and are the results. I don't know about whether jar files should be executable, but if they shouldn't you should chmod -x them in your build process, after they get installed. Jar files are simply zip files with a manifest. The last I checked the exec syscall had no special handling for zip files, and as they lack a bang path, they relly are not executable as far as the system is concerned. So unless a JVM expects jars to have the executable bit set, it probably should not be. HTH. (IANADD) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
