Today the apache-2.4.1 ebuild has appeared in gentoos portage tree. Emerging php-5.4.1_rc1 fails with installed apache-2.4.1 web server  on gentoo with the following error message:

Configuring SAPI modules
checking for AOLserver support… no
checking for Apache 1.x module support via DSO through APXS… no
checking for Apache 1.x module support… no
checking whether to enable Apache charset compatibility option… no
checking for Apache 2.0 filter-module support via DSO through APXS… no
checking for Apache 2.0 handler-module support via DSO through APXS…

Sorry, I cannot run apxs.  Possible reasons follow:

1. Perl is not installed
2. apxs was not found. Try to pass the path using –with-apxs2=/path/to/apxs
3. Apache was not built using –enable-so (the apxs usage page is displayed)

The output of /usr/sbin/apxs follows:
./configure: line 8325: /usr/sbin/apxs: No such file or directory
configure: error: Aborting

The reason for this is, that the apxs executable does not get installed with the apache-2.4.1 ebuild. According to gmane.org this issue got fixed with the apache-2.4.1-r1 ebuild.  However, after upgrading apache to 2.4.1-r1 emerging php still fails with the same error message. A quick look onto the filesystem shows that /usr/sbin/apxs got installed as well as the /usr/sbin/apxs2 symlink got created.

mittelerde sbin # ls -alsh apxs*
24K -rw-r–r– 1 root root  23K  1. Apr 16:14 apxs
0 lrwxrwxrwx 1 root root   14  1. Apr 16:14 apxs2 -> /usr/sbin/apxs

This also reveals the reason for emerging php failing with apache-2.4.1-r1. The /usr/sbin/apxs perl-script coming with the apache-2.4.1-r1 ebuild lacks the executable flag.

Thus a simple

chmod +x /usr/sbin/apxs

solves the issue and emerging php afterwards works like a charm. Most probably this will get fixed with the next apache ebuild. To get the apache configuration working after the 2.4 upgrade, you might want to read: Upgrading to 2.4 from 2.2.

Jürgen

(No Ratings Yet)

Loading...

Posted in gentoo, linux, web | 4 Comments »

Recently, when updating the gentoo linux on my amd64 box I got errors when building packages with the doc USE flag. All failing packages were using the gtkdoc tool for generating the documentation. Nowhere in the web was a topic concerning this problem. All these packages failed similar to example for libbonobo below. But many other ebuilds, i.e. glib, gedit etc. were also affected.

Writing libbonobo-bonobo-persist-file.html for refentry(libbonobo-bonobo-persist-file)
Writing libbonobo-bonobo-persist-stream.html for refentry(libbonobo-bonobo-persist-stream)
Writing libbonobo-bonobo-persist-client.html for refentry(libbonobo-bonobo-persist-client)
Writing persist.html for chapter(persist)
Writing debugging.html for refentry(debugging)
Writing libbonobo-faq.html for refentry(libbonobo-faq)
Writing libbonobo-bonobo-config-database.html for refentry(libbonobo-bonobo-config-database)
Writing misc.html for chapter(misc)
Writing ix01.html for index
Writing index.html for book(index)
Writing index.sgml for book(index)
Writing libbonobo.devhelp for book(index)
Writing libbonobo.devhelp2 for book(index)
gtk-doc: Fixing cross-references
try vitry vish: /usr/bin/vim: Datei oder Verzeichnis nicht gefunden
readline() on closed filehandle NEWFILE at /usr/bin/gtkdoc-fixxref line 467.
Use of uninitialized value in substitution (s///) at /usr/bin/gtkdoc-fixxref line 470.
Use of uninitialized value in substitution (s///) at /usr/bin/gtkdoc-fixxref line 471.
Use of uninitialized value in substitution (s///) at /usr/bin/gtkdoc-fixxref line 475.
Use of uninitialized value in substitution (s///) at /usr/bin/gtkdoc-fixxref line 476.
Use of uninitialized value in substitution (s///) at /usr/bin/gtkdoc-fixxref line 477.
Use of uninitialized value in substitution (s///) at /usr/bin/gtkdoc-fixxref line 478.
Use of uninitialized value in substitution (s///) at /usr/bin/gtkdoc-fixxref line 479.
Use of uninitialized value in substitution (s///) at /usr/bin/gtkdoc-fixxref line 480.
Use of uninitialized value in substitution (s///) at /usr/bin/gtkdoc-fixxref line 481.
Can’t delete html/_temp_src.15046.h.html: Datei oder Verzeichnis nicht gefunden at /usr/bin/gtkdoc-fixxref line 486.
make[1]: *** [html-build.stamp] Fehler 2
make[1]: Leaving directory `/var/tmp/portage/gnome-base/libbonobo-2.24.3/work/libbonobo-2.24.3/doc/api’
make: *** [all-recursive] Fehler 1

After some days of searching I was able to track the issue down to the part of gtk-docfixref that uses vim for highlighting. Perhaps my gtk-doc version (gtk-doc-1.13-r2) is not compatible to my vi version (vim-7.2.303). Even uninstalling vi for testing purposes was not successful since at least this version of gtk-docfixref tries to use vi even if it is not installed.

Line 290 of gtkdoc fixref:

if (“/usr/bin/vim” ne “”) {

Changing this line to

if (“/usr/bin/vim” ne “/usr/bin/vim”) {

for forcing gtk-docfixref to always ignore vi was the (temporary) solution for me. Afterwards I was again able to build all the packages using gtk-doc for documentation.

Since I did not find any information about the problem in the web I am quite unsure if I should open a bug report for it or if it is only a local problem.  So, if you experience the same problem please leave a comment.

Jürgen

(No Ratings Yet)

Loading...

Posted in gentoo, linux | 2 Comments »

Today, when I ran the regular update of my gentoo systems there was an update for compiz-fusion in portage. The compiz update did not work out of the box on my x8_64 systems, missing keywords, blocking packages, etc.

Here is the way I got it to work. The procedure is similar to the one I described in upgrade-to-compiz-fusion-0.82.

emerge -uND world

!!! All ebuilds that could satisfy “>=x11-plugins/compiz-plugins-main-0.8.6” have been masked.
!!! One of the following masked packages is required to complete your request:
– x11-plugins/compiz-plugins-main-0.8.6 (masked by: ~amd64 keyword)

Add to /etc/portage/package.keywords:

=x11-plugins/compiz-plugins-main-0.8.6 **
=x11-plugins/compiz-plugins-unsupported-0.8.6 **
=x11-plugins/compiz-plugins-extra-0.8.6 **
=x11-plugins/compiz-plugins-unsupported-0.8.4-r1 **

the last line is there just because I don´t know if there will be a newer version of compiz-plugins-unsuported or not.

emerge compiz-fusion

[blocks B ] x11-plugins/compiz-fusion-plugins-extra (“x11-plugins/compiz-fusion-plugins-extra” is blocking x11-plugins/compiz-plugins-extra-0.8.4-r1)
[blocks B ] x11-plugins/compiz-fusion-plugins-main (“x11-plugins/compiz-fusion-plugins-main” is blocking x11-plugins/compiz-plugins-main-0.8.4-r1)

emerge -C compiz-fusion-plugins-extra compiz-fusion-plugins-main compiz-fusion-plugins-unsupported

emerge compiz-fusion

Afterwards I had a working compiz-fusion-0.8.6.

regards

Jürgen

(No Ratings Yet)

Loading...

Posted in Uncategorized | No Comments »

On a gentoo system you may get the error

QA Notice: Package has poor programming practices which may compile but will almost certainly crash on 64bit architectures

during emerge. This is usually a wanted behaviour since one does not want to have broken packages installed, but sometimes you may want to decide yourself or you need the program and can live with crashes that may occur under certain circumstances. As far as I know portage does not give us an easy method to override this.

You may change this behaviour by changing line 477 in /usr/lib/portage/bin/misc-functions.sh to i.e.

if [[ ${abort} == “disabled” ]] ; then

After emerging the brocken package you usually want to change the line back to

if [[ ${abort} == “yes” ]] ; then

to prevent having broken packages on your system without knowing about it.

Hoping this information is of some help.

Jürgen

(1 votes, average: 5.00 out of 5)

Loading...

Posted in gentoo, linux | No Comments »

Today, when I ran the regular update of my gentoo systems there was an update for compiz-fusion in portage. The compiz update did not work out of the box on my x8_64 systems, missing keywords, blocking packages, wrong manifests, etc.

Here is the way I got it to work:

emerge -uND world

!!! All ebuilds that could satisfy “~x11-plugins/compiz-plugins-main-0.8.2” have been masked.
!!! One of the following masked packages is required to complete your request:
– x11-plugins/compiz-plugins-main-0.8.2 (masked by: ~amd64 keyword)

Add to /etc/portage/package.keywords:

=x11-plugins/compiz-plugins-main-0.8.2 **
=x11-plugins/compiz-plugins-unsupported-0.8.2 **
=x11-plugins/compiz-plugins-extra-0.8.2 **

emerge compiz-fusion

[blocks B ] x11-plugins/compiz-fusion-plugins-extra (“x11-plugins/compiz-fusion-plugins-extra” is blocking x11-plugins/compiz-plugins-extra-0.8.2)
[blocks B ] x11-plugins/compiz-fusion-plugins-main (“x11-plugins/compiz-fusion-plugins-main” is blocking x11-plugins/compiz-plugins-main-0.8.2)
[blocks B ] x11-plugins/compiz-fusion-plugins-unsupported (“x11-plugins/compiz-fusion-plugins-unsupported” is blocking x11-plugins/compiz-plugins-unsupported-0.8.2)

emerge -C compiz-fusion-plugins-extra compiz-fusion-plugins-main compiz-fusion-plugins-unsupported

emerge compiz-fusion

!!! A file listed in the Manifest could not be found: /usr/portage/x11-plugins/compiz-plugins-extra/files/compiz-plugins-extra-no-gconf.patch

ebuild /usr/portage/x11-plugins/compiz-plugins-extra/compiz-plugins-extra-0.8.2.ebuild digest

Note: The generation of the digest is only a temporary solution. There should be the correct manifest in the portage tree.

emerge compiz-fusion

* Messages for package x11-wm/emerald-0.8.2:

* Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is:
*
* /usr/portage/x11-wm/emerald/files/emerald-ru.po.patch
* ( emerald-ru.po.patch )
*
* ERROR: x11-wm/emerald-0.8.2 failed.

cd /usr/portage/x11-wm/emerald/files/

ln -s emerald-0.7.8-ru.po.patch emerald-ru.po.patch

Note: The symlink is only a temporary solution. The file should be added to the portage tree.

ebuild /usr/portage/x11-wm/emerald/emerald-0.8.2.ebuild digest

emerge compiz-fusion

Afterwards I had a working compiz-fusion-0.8.2 .

regards

Jürgen

(No Ratings Yet)

Loading...

Posted in 3d, gentoo, graphics, linux | 2 Comments »