Re: RFC: irrlicht
* -fPIC is only used when building the .so file but not when compiling the source files (is it ok this way?) No, it is not ok that way. Follow this link. It also answers your question regarding -fPIC and static linking (short answer, also not ok): http://www.debian.org/doc/debian-policy/ch-files.html * whether to use the .pc file or not (personally I see no advantage, what do you think Brandon?) I think the .pc file is pretty important for development libraries. It is especially important for irrlicht for two reasons. 1) The linking procedure for compiling against irrlicht is different in Debian than what people who download from upstream are used to. You dynamically linked against libpng, libjpeg62, etc, whereas upstream included those with the package. 2) You are going to have to rewrite the Makefiles for the examples, becasue the current ones don't work in an installed irrlicht. This will be easier to maintain if, rather than writing the compiler lines by hand, you just had the .pc file, and in the Makefiles wrote lines like `pkg-config --libs irrlicht`. * Should the .chm file be shipped in the -doc package or only the HTML documentation? That's more of a personal choice than anything. If you do provide both, make sure you document somewhere, such as the readme, that both files contain the same information. * what to do with the media/ files in the -examples package (some files are not free like dx's logo, opengl logo; there's also the lucida font in a .png file so I'm not sure it is ok) You probably already know this, but your choices are: * Put irrlicht-examples in non-free (kind of a cop-out, but acceptable) * Replace the non-free items with free items * Rewrite the examples to not use anything non-free * Not include irrlicht-examples I'm not an expert in debian policy, but I think you can't include the non-free components in the source package if you want to put the source package in main. You want to keep the source package in main, otherwise the whole thing will have to go to non-free. If you put irrlicht-examples in non-free, you'll need two separate source packages. You might actually find it easier to replace the non-free content. Openarena has quake meshes. They are GPL. You'll have to make a note of that in the copyright file. I'm not sure how to actually handle replacing the files. Is it ok to put them into the orig.tar.gz? I'm sure the answer is in the policy manual somewhere. Perhaps it would be best to skip the examples for the initial version. * lintian complaining about missing soname I noticed that too. Not from lintian, but using executables compiled against your library require the symlink that is only included in the development library. I bet the fix is easy, but I don't really know what it is. I bet it is a gcc option. Good luck! -Brandon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: irrlicht
On Thu, Sep 06, 2007 at 10:15:28AM -0700, Brandon wrote: I'm not sure how to actually handle replacing the files. Is it ok to put them into the orig.tar.gz? I'm sure the answer is in the policy manual somewhere. The orig.tar.gz can't have any files introduced relative to upstream. * lintian complaining about missing soname I noticed that too. Not from lintian, but using executables compiled against your library require the symlink that is only included in the development library. I bet the fix is easy, but I don't really know what it is. I bet it is a gcc option. -Wl,-soname,libfoo.so.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: irrlicht
Sorry for the late response. On 17/08/07, Andres Mejia [EMAIL PROTECTED] wrote: On 8/17/07, Raphael Geissert [EMAIL PROTECTED] wrote: Yesterday night I uploaded to mentors a new version of the package. Changes: * debhelper files are now generated from templates so the package version information (except debian/control) is updated automatically by debian/rules. * Added -dbg package * Added -D_REENTRANT * $(version) and $(major) are manually set now (but there's a check that makes sure that include/IrrCompileConfig.h says the same as those two vars) * Fixed build-depends * merged the two binary-arch- build targets * moved headers to include/Irrlicht1.3.1 (with symlink at include/Irrlicht) TO CHECK (comments on this please): * irrlicht seems not to be compiled with zlib/libpng/libjpeg support * -fPIC is only used when building the .so file but not when compiling the source files (is it ok this way?) * whether to use the .pc file or not (personally I see no advantage, what do you think Brandon?) * Should the .chm file be shipped in the -doc package or only the HTML documentation? * what to do with the media/ files in the -examples package (some files are not free like dx's logo, opengl logo; there's also the lucida font in a .png file so I'm not sure it is ok) * lintian complaining about missing soname I still see only version 1.3.1-1 of irrlicht, or did you mean to leave it as that? It would make more sense to change it to 1.3.1-2. I did leave it as -1 -- Regards, Andres Mejia -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: irrlicht
Yesterday night I uploaded to mentors a new version of the package. Changes: * debhelper files are now generated from templates so the package version information (except debian/control) is updated automatically by debian/rules. * Added -dbg package * Added -D_REENTRANT * $(version) and $(major) are manually set now (but there's a check that makes sure that include/IrrCompileConfig.h says the same as those two vars) * Fixed build-depends * merged the two binary-arch- build targets * moved headers to include/Irrlicht1.3.1 (with symlink at include/Irrlicht) TO CHECK (comments on this please): * irrlicht seems not to be compiled with zlib/libpng/libjpeg support * -fPIC is only used when building the .so file but not when compiling the source files (is it ok this way?) * whether to use the .pc file or not (personally I see no advantage, what do you think Brandon?) * Should the .chm file be shipped in the -doc package or only the HTML documentation? * what to do with the media/ files in the -examples package (some files are not free like dx's logo, opengl logo; there's also the lucida font in a .png file so I'm not sure it is ok) * lintian complaining about missing soname On 13/08/07, Raphael [EMAIL PROTECTED] wrote: On 10/08/07, Brandon [EMAIL PROTECTED] wrote: 1) It appears that the irrlicht engine is incompatable with the libjpeg engine that comes with debian. I have attached a log with errors. This is from compiling, and then running, 02.Quake3Map. However, after checking the versions, it seems irrlicht comes with the exact same version as debian, 62 (or 6b). I don't know what to make of it. I'll see what I can do. 2) Your examples do not compile with make. It looks like you copied the Makefiles straight across. You'll have to edit them. From the examples directory, there is no ../../bin/Linux, ../../include, or ../../lib. Hmm, ok. 3) It's always nice when libraries have dbg versions. I think all you would have to do is create the dbg package, then strip the libraries of their debug symbols, and use that for the end-user package. Just added the necessary modifications. 4) You are missing some build flags, such as -fPIC and -DREENTRANT. See the policies for more info, and possibly more requirements. http://www.debian.org/doc/debian-policy/ch-files.html -fPIC is already being used by upstream's Makefile. I'll add -D_REENTRANT. About -fPIC I would like to know what to do when building the static lib, because as I said, upstream's Makefile uses it for both, shared and static. -Brandon -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: irrlicht
On 8/17/07, Raphael Geissert [EMAIL PROTECTED] wrote: Yesterday night I uploaded to mentors a new version of the package. Changes: * debhelper files are now generated from templates so the package version information (except debian/control) is updated automatically by debian/rules. * Added -dbg package * Added -D_REENTRANT * $(version) and $(major) are manually set now (but there's a check that makes sure that include/IrrCompileConfig.h says the same as those two vars) * Fixed build-depends * merged the two binary-arch- build targets * moved headers to include/Irrlicht1.3.1 (with symlink at include/Irrlicht) TO CHECK (comments on this please): * irrlicht seems not to be compiled with zlib/libpng/libjpeg support * -fPIC is only used when building the .so file but not when compiling the source files (is it ok this way?) * whether to use the .pc file or not (personally I see no advantage, what do you think Brandon?) * Should the .chm file be shipped in the -doc package or only the HTML documentation? * what to do with the media/ files in the -examples package (some files are not free like dx's logo, opengl logo; there's also the lucida font in a .png file so I'm not sure it is ok) * lintian complaining about missing soname I still see only version 1.3.1-1 of irrlicht, or did you mean to leave it as that? It would make more sense to change it to 1.3.1-2. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: irrlicht
On 10/08/07, Giovanni Mascellani [EMAIL PROTECTED] wrote: All'incirca Thu, 9 Aug 2007 19:47:01 -0500, Raphael Geissert [EMAIL PROTECTED] sembrerebbe aver scritto: Hello everybody, I've finally prepared the irrlicht package. As I wrote many hacks to get dpkg-buildpackage successfully build all the different packages I want it to be reviewed and commented. Package name: irrlicht Version : 1.3.1-1 Upstream Author : Nikolaus Gebhardt [EMAIL PROTECTED] * URL : http://irrlicht.sourceforge.net * License : zlib/libpng Programming Lang: C++ Well, I'm not a DD, so I cannot give you right advices and, most of all, cannot upload your package. I just tried to build this package under pbuilder, but obtained lots of errors, because the compiler couldn't find GL/gl.h co. and then all identifiers declared in these headers. I checked better, and I discovered that the package doesn't depend on any package connected with OpenGL. Isn't this an error? It is, thanks for reminding me about build-deps. Thank you for your answers, and good luck to Francois! Giovanni. -- Giovanni Mascellani [EMAIL PROTECTED] Pisa, Italy Web: http://giomasce.altervista.org SIP: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] / [EMAIL PROTECTED] GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70) -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: irrlicht
On 10/08/07, Brandon [EMAIL PROTECTED] wrote: 1) It appears that the irrlicht engine is incompatable with the libjpeg engine that comes with debian. I have attached a log with errors. This is from compiling, and then running, 02.Quake3Map. However, after checking the versions, it seems irrlicht comes with the exact same version as debian, 62 (or 6b). I don't know what to make of it. I'll see what I can do. 2) Your examples do not compile with make. It looks like you copied the Makefiles straight across. You'll have to edit them. From the examples directory, there is no ../../bin/Linux, ../../include, or ../../lib. Hmm, ok. 3) It's always nice when libraries have dbg versions. I think all you would have to do is create the dbg package, then strip the libraries of their debug symbols, and use that for the end-user package. Just added the necessary modifications. 4) You are missing some build flags, such as -fPIC and -DREENTRANT. See the policies for more info, and possibly more requirements. http://www.debian.org/doc/debian-policy/ch-files.html -fPIC is already being used by upstream's Makefile. I'll add -D_REENTRANT. About -fPIC I would like to know what to do when building the static lib, because as I said, upstream's Makefile uses it for both, shared and static. -Brandon -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: irrlicht
Keep in mind that irrlicht breaks ABI compatability every release. 1.3.1, for example, is not compatable with 1.3. I just tested this by using your package with a Hello World program that I compiled with 1.3 a while ago. I got a warning that the version of the Irrlicht Engine (1.3.1) did not match the version that the application was compiled with (1.3). It segfaulted before displaying anything. You should label this package libirrlicht1.3.1, and remove the /usr/lib/libirrlicht1.3.0 symlink. Your diff file adds an excess file, irrlicht-1.3.1/source/Irrlicht/Makefile~. Probably, your editor backed up the original Makefile there. You don't want that. It would be nice if there was a pkg-config file. I have attached the one I've been using for irrlicht 1.3. It won't work as it is for your library. Specifically, you will need to add jpeg, png, and zlib, since you didn't compile them into your library. I'm not sure whether there is anything else you'd have to add. I haven't checked out the actual library, or the docs or examples yet. Good job so far. -Brandon On Thu, 9 Aug 2007 19:47:01 -0500 Raphael Geissert [EMAIL PROTECTED] wrote: Hello everybody, I've finally prepared the irrlicht package. As I wrote many hacks to get dpkg-buildpackage successfully build all the different packages I want it to be reviewed and commented. Package name: irrlicht Version : 1.3.1-1 Upstream Author : Nikolaus Gebhardt [EMAIL PROTECTED] * URL : http://irrlicht.sourceforge.net * License : zlib/libpng Programming Lang: C++ It builds these binary packages: libirrlicht1.3 - High performance realtime 3D engine libirrlicht1.3-dev - High performance realtime 3D engine development library libirrlicht1.3-doc - High performance realtime 3D engine (API documentation) libirrlicht1.3-examples - High performance realtime 3D engine (examples) The package appears to be linda and lintian clean (linda -i *.changes; lintian -i -I *.changes). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/irrlicht - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/irrlicht/irrlicht_1.3.1-1.dsc Notes: * this is my first lib package * .orig.tar.gz is not exactly upstream's .zip; some win32 stuff was removed (forgot to add dsfg to the version number) * upstream's Makefile is bogus and compiles everything even when calling make clean; that's the reason of one of the hacks * the examples package contain some media/ files which I don't think are all LGPL (specially dx and opengl logos) so I want to know what to do in those cases because they are used by some of the examples. * should archmage be used or should I better use doxygen to generate the html documentation and drop the .chm? * haven't had time to really test the generated libs -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition irrlicht.pc Description: Binary data
Re: RFC: irrlicht
All'incirca Thu, 9 Aug 2007 19:47:01 -0500, Raphael Geissert [EMAIL PROTECTED] sembrerebbe aver scritto: Hello everybody, I've finally prepared the irrlicht package. As I wrote many hacks to get dpkg-buildpackage successfully build all the different packages I want it to be reviewed and commented. Package name: irrlicht Version : 1.3.1-1 Upstream Author : Nikolaus Gebhardt [EMAIL PROTECTED] * URL : http://irrlicht.sourceforge.net * License : zlib/libpng Programming Lang: C++ Well, I'm not a DD, so I cannot give you right advices and, most of all, cannot upload your package. I just tried to build this package under pbuilder, but obtained lots of errors, because the compiler couldn't find GL/gl.h co. and then all identifiers declared in these headers. I checked better, and I discovered that the package doesn't depend on any package connected with OpenGL. Isn't this an error? Thank you for your answers, and good luck to Francois! Giovanni. -- Giovanni Mascellani [EMAIL PROTECTED] Pisa, Italy Web: http://giomasce.altervista.org SIP: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] / [EMAIL PROTECTED] GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70) signature.asc Description: PGP signature
Re: RFC: irrlicht
1) It appears that the irrlicht engine is incompatable with the libjpeg engine that comes with debian. I have attached a log with errors. This is from compiling, and then running, 02.Quake3Map. However, after checking the versions, it seems irrlicht comes with the exact same version as debian, 62 (or 6b). I don't know what to make of it. 2) Your examples do not compile with make. It looks like you copied the Makefiles straight across. You'll have to edit them. From the examples directory, there is no ../../bin/Linux, ../../include, or ../../lib. 3) It's always nice when libraries have dbg versions. I think all you would have to do is create the dbg package, then strip the libraries of their debug symbols, and use that for the end-user package. 4) You are missing some build flags, such as -fPIC and -DREENTRANT. See the policies for more info, and possibly more requirements. http://www.debian.org/doc/debian-policy/ch-files.html -BrandonPlease select the driver you want for this example: (a) Direct3D 9.0c (b) Direct3D 8.1 (c) OpenGL 1.5 (d) Software Renderer (e) Burning's Software Renderer (f) NullDevice (otherKey) exit Irrlicht Engine version 1.3.1 Linux 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 Using renderer: OpenGL 2.0.2 GeForce FX 5500/AGP/SSE2: NVIDIA Corporation OpenGL driver version is 1.2 or better. Loaded shader: scripts/common.shader for scripts/common.shader Loaded shader: scripts/models.shader for scripts/models.shader Loaded shader: scripts/e7.shader for textures/e7/e7walldesign01b JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7walldesign01b.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7steptop2.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7dimfloor.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7brickfloor01.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7bmtrim.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7sbrickfloor.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7brnmetal.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7beam02_red.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7swindow.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7bigwall.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7panelwood.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/e7/e7beam01.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture: textures/gothic_floor/xstepborder5.jpg JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 JPEG FATAL ERROR: JPEG parameter struct mismatch: library thinks size is 464, caller expects 428 Could not load texture:
Re: RFC: irrlicht
All'incirca Fri, 10 Aug 2007 13:55:22 +0200, Giovanni Mascellani [EMAIL PROTECTED] sembrerebbe aver scritto: Thank you for your answers, and good luck to Francois! Ok, I wanted to say Raphael, but I read the wrong name the email summary! Giovanni. -- Giovanni Mascellani [EMAIL PROTECTED] Pisa, Italy Web: http://giomasce.altervista.org SIP: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] / [EMAIL PROTECTED] GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70) signature.asc Description: PGP signature
RFC: irrlicht
Hello everybody, I've finally prepared the irrlicht package. As I wrote many hacks to get dpkg-buildpackage successfully build all the different packages I want it to be reviewed and commented. Package name: irrlicht Version : 1.3.1-1 Upstream Author : Nikolaus Gebhardt [EMAIL PROTECTED] * URL : http://irrlicht.sourceforge.net * License : zlib/libpng Programming Lang: C++ It builds these binary packages: libirrlicht1.3 - High performance realtime 3D engine libirrlicht1.3-dev - High performance realtime 3D engine development library libirrlicht1.3-doc - High performance realtime 3D engine (API documentation) libirrlicht1.3-examples - High performance realtime 3D engine (examples) The package appears to be linda and lintian clean (linda -i *.changes; lintian -i -I *.changes). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/irrlicht - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/irrlicht/irrlicht_1.3.1-1.dsc Notes: * this is my first lib package * .orig.tar.gz is not exactly upstream's .zip; some win32 stuff was removed (forgot to add dsfg to the version number) * upstream's Makefile is bogus and compiles everything even when calling make clean; that's the reason of one of the hacks * the examples package contain some media/ files which I don't think are all LGPL (specially dx and opengl logos) so I want to know what to do in those cases because they are used by some of the examples. * should archmage be used or should I better use doxygen to generate the html documentation and drop the .chm? * haven't had time to really test the generated libs -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
