Hi! Please consider to upgrade FreeWRL 1.06 package (doesn't work propely) with this two ebuilds you can downloads from: http://denics.free.fr/various/ebuilds/FreeWRL-dev-1.11_pre4.ebuild.tar.bz2 http://denics.free.fr/various/ebuilds/FreeWRL-1.10-r2.ebuild.tar.bz2 FreeWRL is an open-source(R) VRML and X3D browser written by a group of developers, who wish to produce a high quality, up to date, browser that is in the public domain.
denics, please attach the ebuilds (as PLAINTEXT, NOT as tarballs) to this bug report instead.
Created attachment 55453 [details] freewrl-1.10-r2
Created attachment 55454 [details] freewrl-dev-1.11_pre4
FreeWRL-1.11 is out (http://freewrl.sourceforge.net/index.html).
Created attachment 56457 [details] freewrl-1.11.ebuild I tried to create a freewrl 1.11 ebuild by modifying attachment 55454 [details], but it failed to compile with the error below. No idea what this is about. ProdCon.c:15:24: installdir.h: No such file or directory ProdCon.c: In function `_perlThread': ProdCon.c:682: error: `INSTALLDIR' undeclared (first use in this function) ProdCon.c:682: error: (Each undeclared identifier is reported only once ProdCon.c:682: error: for each function it appears in.) make[1]: *** [ProdCon.o] Error 1
I did a new ebuild, some changes are in the compile system and a small problem have to be fixed. I hope to do a release for monday. Now I've no my sources with me. Cheers, Denis
Created attachment 56476 [details] freewrl-1.11.ebuild another try at an ebuild for freewrl 1.11 made lots of changes (moved things around so that they work like a normal ebuild) this ebuild requires two patch files that I'm about to attach. Got this to compile and install, but have yet to test if it runs.
Created attachment 56477 [details, diff] FreeWRL-1.11-nostrip.patch patch to comment out all the strip commands so that FEATURES=nostrip can have some effect
Created attachment 56478 [details, diff] FreeWRL-1.11-Makefile.PL.patch patch to get 'make install' to install to the right path and a workaround to get libFreeWRLFunc.so not to be installed during compile phase. A modified version of this patch should probably be sent upstream.
Created attachment 56496 [details] freewrl-1.11.ebuild new ebuild fixes 2 issues: didn't get browser plugin install correctly shouldn't call prepall
ok, I've tested in firefox. It runs.
Created attachment 56583 [details] FreeWRL-1.11
voila' the new ebuild. without patch :) cheers, Denis
The current build in portage (freewrl-1.06) is kinda old and doesn't work very well. How about including this latest ebuild sometime?
Created attachment 57206 [details] freewrl-1.12.ebuild new release, Makefile.PL patch no longer needed.
Created attachment 57286 [details] FreeWRL 1.12 - New release. Fixed mozilla plugins problem With this version everything works, I hope gentoo guys have a look. If somebody with a joystick can also give a report, it'd be welcome. Cheers, Dnix
Created attachment 59780 [details] freewrl 1.12 r1 changed between dev-perl/Digest-MD5 and perl-core/Digest-MD5. everything works so why is not this new version in the portage? tks
Created attachment 59871 [details] freewrl-1.12-r2 why they didn't move all the packages in the same day? I'm sure, tomorrow I'll release a 1.12 r3 version... Denix
The 1.12 build currently stable in portage is broken due to the dev-perl->perl-core problem: # emerge -pv freewrl These are the packages that I would merge, in order: Calculating dependencies emerge: there are no ebuilds to satisfy ">=dev-perl/Digest-MD5-2.09".
I retract my comment. It's just the ebuild in my overlay. Sorry.
*** Bug 92689 has been marked as a duplicate of this bug. ***
I'd like to commit an updated freewrl-ebuild to portage, but the one provided here is absolutely unusable. I failed to understand it myself. If you want this to be added to portage, please clean it up and change at least these issues: * What's the thing about the libsball and the FreeWRLduneInputDevice-packages? Is there any need that they have to be built inside the freewrl-ebuild? If not, please remove them and provide extra ebuilds for them. * Please clean up the depend-var. freewrl-dev was never in portage, so the blocker is unneeded. glut depends on opengl, wget is a system-package (and I doubt freewrl needs wget), so is zlib, perl etc. * PLEASE PLEASE remove those thousands of echo-lines! If you need a config-file, provide one in the filesdir. There is already a config-file inside the freewrl-package, what's wrong with that? * You have a bunch of sed-lines I don't understand. Are these fixes? If yes, did you send them to the upstream-devs? Please also note that sed has an -i Option which allows to sed inside one file without copying it around. This makes ebuilds much more readable. Beside that, please upload ebuilds as text/plain and don't call them -r1, -r2 as long as no version of them is in portage.
Created attachment 60715 [details] freewrl-1.12
Comment on attachment 60715 [details] freewrl-1.12 ops, the one before had a wrong MIME...
Unfortunately FreeWRL has a very strange system to compile information based on a perl script so: * What's the thing about the libsball and the FreeWRLduneInputDevice-packages? Is there any need that they have to be built inside the freewrl-ebuild? If not, please remove them and provide extra ebuilds for them. the devices *MUST* be compiled with FreeWRL, for this I use the USE="joystick" to install them; * Please clean up the depend-var. freewrl-dev was never in portage, so the blocker is unneeded. glut depends on opengl, wget is a system-package (and I doubt freewrl needs wget), so is zlib, perl etc. the packages Freewrl needs are listed in the Makefile.PL file. to avoid any problem, I just cut & paste all dependances I found. Reguarding freewrl-dev, sorry was only for test use * PLEASE PLEASE remove those thousands of echo-lines! If you need a config-file, provide one in the filesdir. There is already a config-file inside the freewrl-package, what's wrong with that? * You have a bunch of sed-lines I don't understand. Are these fixes? If yes, did you send them to the upstream-devs? Please also note that sed has an -i Option which allows to sed inside one file without copying it around. This makes ebuilds much more readable. Unfortunately we need this thousands of line as the install system of Freewrl is quite complicate! try yourself to install it compiling it. you have to do changes to VRML.conf and about sed is necessary because the makefile.PL needs root permission to write directly on the filesystem (I asked they change it) but for now, delete these lines is the only solution. I can put the sed in an external file as you suggest. > Beside that, please upload ebuilds as text/plain and don't call them -r1, -r2 > as long as no version of them is in portage. Ok was a mistake :( and about the version is only because in the place where I work we have 30 pc using freewrl... It's the simplest way :) cheers and thanks for your suggestions, Denix
>Unfortunately we need this thousands of line as the install system of Freewrl >is >quite complicate! try yourself to install it compiling it. you have to do >changes to VRML.conf and about sed is necessary because the makefile.PL needs >root permission to write directly on the filesystem (I asked they change it) >but >for now, delete these lines is the only solution. I can put the sed in an >external file as you suggest. Maybe you misunderstood me here. I don't want you to put the sed-lines into an external file, but put the vrml.conf into the filesdir and not creating it by echoing it (which is a very bad way). About the sed-commands, you can reduce their complexity by using the -i parameter. And in general, I know that the build-system of freewrl is weird, that's the reason why I didn't update freewrl for a long time myself, but if you know how to handle it, you should work together with the freewrl-author to make it less weird, that's always the better solution instead of writing ebuilds nobody can read.
Three additional comments: 1) /usr/local/portage/media-gfx/freewrl/freewrl-1.12.ebuild: line 167: inst_mozilla_plugin: command not found /usr/local/portage/media-gfx/freewrl/freewrl-1.12.ebuild: line 170: inst_mozilla_plugin: command not found Is inst_mozilla_plugin a function that was (is?) supplied by an eclass, or an external binary? 2) The linker complains quite loudly about runtime text relocations in opt/netscape/plugins/npfreewrl.so and usr/lib/libjs.so ... 3) There's a dependancy on "=dev-java/saxon-bin-7.8" - this is not only no longer the latest version marked stable (8.0b is) but there's also saxon-8.4b. Has this dependancy not been updated, or does freewrl-1.12 really break with more recent saxon builds?
Hello Gentoo Developers; Thanks for supporting FreeWRL. I'm the main maintainer of FreeWRL. Although I don't use Gentoo, I do appreciate the support from Denis and you guys for the package. Feel free to email comments, etc, and add suggestions. Sometimes my inbox overfloweth, so I may be delayed replying; if this is the case, keep bugging :-) Yes the make of freewrl is complex and wierd. It *is* getting better, believe it or not! comments/suggestions/help always welcome. John A. Stewart CRC Canada.
Created attachment 63150 [details] freewrl-1.13-pre3 Still weird, but working, enjoy 3D world :) cheers, Denis
freewrl-1.13 is finally released. ;-)
I am on an amd64 system. So I tried this package to see if I could get it to work. The standalone works but it fails to build the plugin which is what I need. When I examine the compiler output I see a number of line complaining about incompatible pointer type and cast from integer to pointer and so on. The typical stuff you see when things have been poorly written with the assumption that ints and pointers are the same size. I will open a bug upstream. Hopefully it will get fixed sooner rather than later.
tried 1.13-pre3 ebuild here on amd64. renamed the file 1.13, removed the -pre3 inside. downloaded by hand cause the ebuild couldn't do it i indeed have a lot of jsVRMLClasses.c:1214: warning: cast from pointer to integer of different size and it fails on linking: /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: warning: i386 architecture of input file `./CFuncs/GenPolyRep.o' is incompatible with i386:x86-64 output ./CFuncs/GenPolyRep.o: In function `make_text': /usr/local/src/freewrl/FreeWRL-1.13-pre4/CFuncs/GenPolyRep.c:39: undefined reference to `__bounds_push_function' and indeed : berlioz FreeWRL-1.13 # file ./CFuncs/GenPolyRep.o ./CFuncs/GenPolyRep.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped could that be that this file is in the .tgz ??? removing it and doing ebuild freewrl-1.13.ebuild merge fixed it...
Created attachment 69277 [details] freewrl-1.13.ebuild This is a much simpler ebuild for installing freewrl. It lacks joystick-support and maybe other things. It works for me for a few examples, others don't, but I don't know if this is due to errors in the ebuild or lack of features in freewrl. About joystick-support: If you want this, please provide a separate ebuild for libsball. And please, if you submit ebuilds in the future, make them more sane, the freewrl-ebuilds you submitted were nearly impossible to understand.
Hi Hanno, did you tryied to remove complitely all the FreeWRL libraries from your system or to install in a new system (where you never had installed freewrl)? It doesn't works with your ebuild. Another thing is: Ok, we can remove all the echo lines and clean everything putting a diff file, but why remove the support for joystick? Gentoo is nice because is flexible... and flexible is not always cleaner... Cheers, Dnix
About the echo-lines: They should be moved to patches that are a) documented!! (I have no idea what they do) and b) upstream-author should be informed so that we hopefully don't need them in future versions. I don't want to remove joystick-support, but your ebuild builds libsball inside freewrl, while it's a separate lib. As I said, provide a separate ebuild for libsball.
>did you tryied to remove complitely all the FreeWRL libraries from your system >or to install in a new system (where you never had installed freewrl)? It >doesn't works with your ebuild. I cannot reproduce this... Can you send me the output?
Created attachment 72371 [details] freewrl-1.13.1 It works for 1.13.1 for me. I've corected MY_P variable for a general use. Ive try http://bugs.gentoo.org/attachment.cgi?id=69277, because it seems shorter but it generate "cannot find system font path" loop.
>It works for 1.13.1 for me. I've corected MY_P variable for a general use. >Ive try http://bugs.gentoo.org/attachment.cgi?id=69277, because it seems shorter but it generate "cannot find system font path" loop.(In reply to comment #37) > Created an attachment (id=72371) [edit] > freewrl-1.13.1 This is the bug I've mentioned in my last post... Obviously there is some work to do for the ebuild, but the freewrl team doesn't want to change the install method. Thus, I suggest that the gentoo team accept this ebuild (it is not elegant but it *works*). Otherwise we are only left with version 1.06 in portage that is very buggy (it works only under certain conditions and a lot of people continue to post bugs about it that have already been solved in this ebuild...). So... Hanno can you propose a working solution or publish the ebuild, please? cheers, Denix
Dnix please use plain text for ebuild attachments, I'm going to try get this ebuild acceptable. It's not about elegance, it's about maintainability and casual users ability to understand what each change does.
Created attachment 74476 [details] freewrl-1.15.ebuild here the ebuild I promised. I left out joystick support as it cluttered the ebuild, will do it in another package/ebuild. This ebuild depends on a number of patches which I'll post next.
Created attachment 74477 [details, diff] disable plugin support
Created attachment 74478 [details, diff] enable plugin support
Created attachment 74480 [details, diff] make plugin installing work correctly (submitted upstream)
Created attachment 74481 [details, diff] use JAVA_HOME envar to find java (submitted upstream)
Created attachment 74482 [details, diff] disable rpm creation (only needed for version 1.16 and above)
Comment on attachment 74476 [details] freewrl-1.15.ebuild note that this ebuild should also work with version 1.16/1.16.1 (I've tested with 1.16.1)
This looks MUCH better. A few notes though: - The MY_P-stuff seems to be not neccessary. - Please remove the saxon-bin-dep (as noted in bug 109622) - The use-flag for browser-plugins is nsplugin, minimal-useflag is not the right one here. - I think the dodir is not neccessary, AFAIK insinto/doins takes care of creating the dir (didn't test right now). Beside that, as soon as I've time for it, I'll look at it and commit.
Created attachment 74500 [details] freewrl-1.15.ebuild second try, should fix issues mentioned in comment 47. Remove some deps, move some into rdep. I've removed saxon dep completely (not sure if this is the right thing, but freewrl seems to be working for me without saxon, maybe I'm not looking at complex enough wrl files :P ).
forgot to mention that I've uploaded ebuilds for FreeWRLDuneInputDevice (bug 115192) and libsball (bug 115185)
Had a closer look, some more notes: - Just cosmetic, but the commented parts should be removed. The DEPEND/RDEPEND-Vars shouldn't contain useless newlines, it should look like: DEPEND="cat/dep1 cat/dep2" - The disable-plugin is imho useless, it souldn't care if the vars are in the conf even if the plugin isn't built. Also the enable-conf can be applied always. - Is the emake realclean needed? What does it do?
(In reply to comment #50) > Had a closer look, some more notes: > > - Just cosmetic, but the commented parts should be removed. ok I wasn't sure about the saxon changes (I am now, will post an ebuild without saxon), and the PDEPEND/joystick changes depend on bug 115192, I'll remove it (maybe file a bug about adding it back when/if bug 115192 gets fixed). > The > DEPEND/RDEPEND-Vars shouldn't contain useless newlines, it should look like: > DEPEND="cat/dep1 > cat/dep2" ok, will fix > > - The disable-plugin is imho useless, it souldn't care if the vars are in the > conf even if the plugin isn't built. Also the enable-conf can be applied > always. umm not sure what you mean here. Do you mean the plugin should always be built? > > - Is the emake realclean needed? What does it do? no idea, I got it from the old ebuild, I'll try without it and see if it works.
(In reply to comment #51) > (In reply to comment #50) > > - The disable-plugin is imho useless, it souldn't care if the vars are in the > > conf even if the plugin isn't built. Also the enable-conf can be applied > > always. > umm not sure what you mean here. Do you mean the plugin should always be built? ok on a second look at the code, I get what you mean, will test and post a new ebuild.
Hi all, with the version of freewrl up to 1.13 emerge realclean was necessary because the freewrl team give a binary version with the sources you can use directly from command line. a normal emake clean doesn't delete these files, but emake realclean yes. Hope this help and thanks for all your work!
(In reply to comment #52) > (In reply to comment #51) > > (In reply to comment #50) > > > - The disable-plugin is imho useless, it souldn't care if the vars are in the > > > conf even if the plugin isn't built. Also the enable-conf can be applied > > > always. > > umm not sure what you mean here. Do you mean the plugin should always be built? > ok on a second look at the code, I get what you mean, will test and post a new > ebuild. Ok, after testing, I found that disable-plugin is needed so that the 'emake install' doesn't compile and install the plugin. Also just realized that the install phase is wrong, I forgot to 'if use nsplugin' the plugin parts. > (In reply to comment #53) > Hi all, > with the version of freewrl up to 1.13 emerge realclean was necessary because > the freewrl team give a binary version with the sources you can use directly > from command line. a normal emake clean doesn't delete these files, but emake > realclean yes. > Hope this help and thanks for all your work! Thanks! I've removed it, and it works.
(In reply to comment #54) Hei Basic, if you have any other doubt ask me without any problem, I know a little bit freewrl and I can explain my previous ebuilds ;) cheers, Denix
Created attachment 74706 [details] freewrl-1.15.ebuild
I've now added the ebuild with a few other changes (mostly cosmetic, changed the enable/disable-plugin-patches to sed-lines, this also fixes the platform-specific libdir). Many thanks to basic for your great help so this finally get's resolved. Please test, test, test!
