Port dependencies on libxul / libxul19

N

Niatross

I receive the following error when installing the icedtea-web-1.3.1 port:

Code: 
 icedtea-web is using libxul for gecko support, but you can
 change that by defining WITH_GECKO to the following values:

   libxul 
   libxul19 

===>  License GPLv2 accepted by the user
===>  Found saved configuration for icedtea-web-1.3.1
===>  Extracting for icedtea-web-1.3.1
=> SHA256 Checksum OK for icedtea-web-1.3.1.tar.gz.
===>   icedtea-web-1.3.1 depends on file: /usr/local/bin/perl5.14.2 - found

IMPORTANT: To build IcedTea-Web 1.3.1, you have to turn on 'ICEDTEA' option
for java/openjdk6 (default).  Otherwise, it will neither build nor work.

===>  Patching for icedtea-web-1.3.1
===>   icedtea-web-1.3.1 depends on file: /usr/local/bin/perl5.14.2 - found
===>  Applying FreeBSD patches for icedtea-web-1.3.1
/usr/bin/sed -i.bak -e 's|/usr/bin/perl|/usr/local/bin/perl|' /usr/ports/java/icedtea-web/work/icedtea-web-1.3.1/javac.in
/usr/bin/sed -i.bak -e 's|%%LOCALBASE%%|/usr/local|'  /usr/ports/java/icedtea-web/work/icedtea-web-1.3.1/launcher/javaws.in
===>   icedtea-web-1.3.1 depends on file: /usr/local/bin/zip - found
===>   icedtea-web-1.3.1 depends on file: /usr/local/bin/bash - found
===>   icedtea-web-1.3.1 depends on file: /usr/local/openjdk6/bin/java - found
===>   icedtea-web-1.3.1 depends on package: libxul>=10 - not found
===>   Found libxul-1.9.2.28_1, but you need to upgrade to libxul>=10.
*** Error code 1

Stop in /usr/ports/java/icedtea-web.
*** Error code 1

Stop in /usr/ports/java/icedtea-web.

The problem is this:

There are ports out there that "still" rely on "www/libxul19". If I upgrade to "www/libxul" (to make "icedtea-web-1.3.1" happy) then other ports that "still" rely on "www/libxul19" will not install. How do I get around this issue? It's a pain in the ass.
 
cpu82 said:
Try instead x11-toolkits/swt-devel. Take a look to this message.

Someone have advertised about this upgrade problem.
Click to expand...

Why are these ports (that rely on "www/libxul19") being ignored by the FreeBSD ports team?

Why are they ramming "www/libxul" down our throats before all the ports that rely on "www/libxul19" are upgraded to "www/libxul"?

Seems ass backwards to me.

Do they need help? Do they need more people to test the ports on the FreeBSD ports team?

The only way to fix this problem is to use "www/libxul19" (...since there are too many ports out there that "still" rely on it) and forget about "www/libxul" altogether.

Maybe one day we'll be able to use "www/libxul"...
 
Next version should update all dependent ports to use www/libxul. Maintainers usually proceed in accordance with most important claimed messages.
 
cpu82 said:
Next version should update all dependent ports to use www/libxul. Maintainers usually proceed in accordance with most important claimed messages.
Click to expand...

I understand what your saying, but why not just hold off on the release of www/libxul and save the FreeBSD userbase the headaches. This is the "exact" reason (AKA: compiling errors) of why people run from FreeBSD and head for the hills. They don't want these headaches.

I love torture. That's why I'm still here.
 
I think your posture is positive about it. In my humble opinion, all provisional solutions are really necessary in this case before big revisions. Good developers can fight this, but they need time to do a good work. Coordination of all code changes to be implemented, is a daunting task, but it should be the aim.
 
Niatross said:
How can I tell portmaster to use the "www/libxul19" when compiling the java/icedtea-web port?

I could change the java/icedtea-web "Makefile" before using postmaster, but is their a way to override the "USE GECKO= libxul libxul19" setting (within the java/icedtea-web Makefile) ....using the portmaster command?
Click to expand...

Using portmaster(8) with --force-config option. Quoting from make(1):
-f makefile

Specify a makefile to read instead of the default one. If
makefile is not an absolute pathname, make will search for it as
described above. In case makefile is `-', standard input is
read. Multiple -f options can be supplied, and the makefiles
will be read in that order. Unlike the other command-line
options, -f is neither stored in .MAKEFLAGS nor pushed down to
sub-makes via MAKEFLAGS. See below for more details on these
variables.
Click to expand...

You have to define into the Makefile:
Code: 
.if ${PORT_OPTIONS:MPLUGIN}
USE_GECKO=	libxul libxul19
USE_GNOME=	glib20 gtk20
USE_WEBPLUGINS=	native
WEBPLUGINS_DIR=	${PREFIX}/lib
WEBPLUGINS_FILES=IcedTeaPlugin.so

Or setting make variables in /etc/make.conf:
Code: 
WITH_GECKO=libxul[B]19[/B]
 
You can't set "WITH_GECKO=libxul". I'm trying to use libxul19, not libxul.

libxul is for the birds. It doesn't work with a lot of ports. I explained this earlier. Read my posts above. Anyway, I'll just edit the makefile for "icedtea-web" and be done with it. I just though there might be an easier portmaster command that could overrride what's set in "Makefile".
 
Niatross said:
You can't set "WITH_GECKO=libxul". I'm trying to use libxul19, not libxul.

libxul is for the birds. It doesn't work with a lot of ports. I explained this earlier. Read my posts above. Anyway, I'll just edit the makefile for "icedtea-web" and be done with it. I just though there might be an easier portmaster command that could overrride what's set in "Makefile".
Click to expand...

Sorry for my carelessness, but is better set variables in /etc/make.conf, check above, I corrected what you should add. For future problems with conflicts ports is preferable modify make.conf(5).
 
Thank you very much for your help on this.

I added the following to the /etc/make.conf file:

Code: 
WITH_GECKO=libxul19

Do you know why the syntaxes between Makefile and make.conf are different:

Code: 
[file]Makefile[/file] uses: USE_GECKO
[file]make.conf[/file] uses: WITH_GECKO
 
Which ports would that be? I don't think there are a lot of ports that still depend on the old libxul19.
 
SirDice said:
Which ports would that be? I don't think there are a lot of ports that still depend on the old libxul19.
Click to expand...

See post #3. There are also many other ports out there that depend on libxul19.
 
I think somebody just needs to update that port. The version that's in the ports tree is 2, almost 3, years old. There's a 3.7.2 version that came out last February (looking at the releases it's quite possible there will be another new version next February). It's possible the dependency on the old libxul has already been fixed upstream.
 
You must log in or register to reply here.
Back
Top