app-text/tesseract 4.0 alpha ebuild available for testing

Tesseract is one of the best open-source OCR software available, and I recently took over ebuilds maintainership for it. Current development is still quite active, and since last stable release they added a new OCR engine based on LSTM neural networks. This engine is available in an alpha release, and initial numbers show a much faster OCR pass, with fewer errors.

Sounds interesting? If you want to try it, this alpha release is now in tree (along with a live ebuild). I insist on the alpha tag, this is for testing, not for production; so the ebuild masked by default, and you will have to add to your package.unmask file:
The ebuild also includes some additional changes, like current documentation generated with USE=doc (available in stable release too), and updated linguas.

Testing with paperwork

The initial reason I took over tesseract is that I also maintain paperwork ebuilds, a personal document manager, to handle scanned documents and PDFs (which is heavy tesseract user). It recently got a new 1.1 release, if you want to give it a try!

Nextcloud available in portage, migration thoughts

I think there has been more than enough news on nextcloud origins, the fork from owncloud, … so I will keep this post to the technical bits.

Installing nextcloud on Gentoo

For now, the differences between owncloud 9 and nextcloud 9 are mostly cosmetic, so a few quick edits to owncloud ebuild ended in a working nextcloud one. And thanks to the different package names, you can install both in parallel (as long as they do not use the same database, of course).

So if you want to test nextcloud, it’s just a command away:

# emerge -a nextcloud

With the default webapp parameters, it will install alongside owncloud.

Migrating owncloud data

Nothing official again here, but as I run a small instance (not that much data) with simple sqlite backend, I could copy the data and configuration to nextcloud and test it while keeping owncloud.
Adapt the paths and web user to your setup: I have these webapps in the default /var/www/localhost/htdocs/ path, with www-server as the web server user.

First, clean the test data and configuration (if you logged in nextcloud):

# rm /var/www/localhost/htdocs/nextcloud/config/config.php
# rm -r /var/www/localhost/htdocs/nextcloud/data/*

Then clone owncloud’s data and config. If you feel adventurous (or short on available disk space), you can move these files instead of copying them:

# cp -a /var/www/localhost/htdocs/owncloud/data/* /var/www/localhost/htdocs/nextcloud/data/
# cp -a /var/www/localhost/htdocs/owncloud/config/config.php /var/www/localhost/htdocs/nextcloud/config/

Change all owncloud occurences in config.php to nextcloud (there should be only one, for ‘datadirectory’. And then run the (nextcloud) updater. You can do it via the web interface, or (safer) with the CLI occ tool:

# sudo -u www-server php /var/www/localhost/htdocs/nextcloud/occ upgrade

As with “standard” owncloud upgrades, you will have to reactivate additional plugins after logging in. Also check the nextcloud log for potential warnings and errors.

In my test, the only non-official plugin that I use, files_reader (for ebooks)  installed fine in nextcloud, and the rest worked as fine as owncloud with a lighter default theme 🙂
For now, owncloud-client works if you point it to the new /nextcloud URL on your server, but this can (and probably will) change in the future.

More migration tips and news can be found in this nextcloud forum post, including some nice detailed backup steps for mysql-backed systems migration.

Setting USE_EXPAND flags in package.use

This has apparently been supported in Portage for some time, but I only learned it recently from a gentoo-dev mail: you do not have to write down the expanded USE-flags in package.use anymore (or set them in make.conf)!

For example, if I wanted to set some APACHE2_MODULES and a custom APACHE2_MPM, the standard package.use entry would be something like:

www-servers/apache apache2_modules_proxy apache2_modules_proxy apache2_modules_proxy_http apache2_mpms_event ssl

Not as pretty/convenient as a ‘APACHE2_MODULES=”proxy proxy_http”‘ line in make.conf. Here is the best-of-both-worlds syntax (also supported in Paludis apparently):

www-servers/apache ssl APACHE2_MODULES: proxy proxy_http APACHE2_MPMS: event

Or if you use python 2.7 as your main python interpreter, set 3.4 for libreoffice-5.1 😉

app-office/libreoffice PYTHON_SINGLE_TARGET: python3_4

Have fun cleaning your package.use file

Testing clang 3.7.0 OpenMP support

Soon after llvm 3.7.0 reached the Gentoo tree, Jeremi Piotrowski opened two bugs to fix OpenMP support in our ebuilds. sys-devel/llvm-3.7.0-r1 (a revision bump that also now installs LLVM utilities) now has a post-install message with a short recap, but here is the blog version.

As detailed in upstream release notes, OpenMP in clang is disabled by default (and I kept this default in the Gentoo package), and the runtime is a separate package. So:

  • emerge sys-libs/libomp
  • add “-fopenmp=libomp” in your CFLAGS
  • check with a sample program like:
#include <stdio.h>
#include <omp.h>

int main() {
#pragma omp parallel
    printf("Hello from thread %d, nthreads %d\n", omp_get_thread_num(), omp_get_num_threads());
  • You should get multiple lines on STDOUT (default threads count is one per CPU):
% clang -fopenmp=libomp test_omp.c -o test_omp
% OMP_NUM_THREADS=6 ./test_omp
Hello from thread 4, nthreads 6
Hello from thread 5, nthreads 6
Hello from thread 1, nthreads 6
Hello from thread 3, nthreads 6
Hello from thread 0, nthreads 6
Hello from thread 2, nthreads 6

Some additional reading:

LLVM 3.7.0 released, Gentoo package changes

As announced here, the new LLVM release is now available. If you are interested after reading the release notes (or the clang ones), I just added the corresponding packages in Gentoo, although still masked for some additional testing. mesa-11.0 release candidates compile fine with it though.
2015/09/04 edit: llvm 3.7.0 is now unmasked!

On the Gentoo side, this version bump has some nice changes:

  • We now use the cmake/ninja build system: huge thanks to fellow developer mgorny for his hard work on this rewrite. This is the recommended build system upstream now, and some features will only be available with it
  • LLDB, the debugger  is now available via USE=lldb. This is not a separate package as the build system for llvm and subprojects is quite monolithic. clang is in the same situation: sys-devel/clang package currently does almost nothing, the magic is done in llvm[clang])
  • These new ebuilds include the usual series of fixes, including some recent ones by gienah

On the TODO list, some tests are still failing on 32bit multilib (bug #558604), ocaml doc compilation/installation has a strange bug (see the additional call on docs/ocaml_doc target in the ebuild). And let’s not forget adding other tools, like polly. Another recent suggestion: add llvm’s OpenMP library needed for OpenMP with clang.

Also, if people were still using the dragonegg GCC plugin, note that it is not released anymore upstream. As 3.6.x versions had compilation problems, this package received its last rites.

Removing old NX packages from tree

I already sent the last rites announce a few days ago, but here is a more detailed post on the coming up removal of “old” NX packages. Long story short: migrate to X2Go if possible, or use the NX overlay (“best-effort” support provided).
2015/04/26 note: treecleaning done!

Affected packages

Basically, all NX clients and servers except x2go and nxplayer! Here is the complete list with some specific last rites reasons:

  • net-misc/nxclient,net-misc/nxnode,net-misc/nxserver-freeedition: binary-only original NX client and server. Upstream has moved on to a closed-source technology, and this version  bundles potientally vulnerable binary code. It does not work as well as before with current libraries (like Cairo).
  • net-misc/nxserver-freenx, net-misc/nxsadmin: the first open-source alternative server. It could be tricky to get working, and is not updated anymore (last upstream activity around 2009)
  • net-misc/nxcl, net-misc/qtnx: an open-source alternative client (last upstream activity around 2008)
  • net-misc/neatx: Google’s take on a NX server, sadly it never took off (last upstream activity around 2010)
  • app-admin/eselect-nxserver (an eselect module to switch active NX server, useless without these servers in tree)

Continue using these packages on Gentoo

These packages will be dropped from the main tree by the end of this month (2015/04), and then only available in the NX overlay. They will still be supported there in a “best effort” way (no guarantee how long some of these packages will work with current systems).

So, if one of these packages still works better for you, or you need to keep them around before migrating, just run:

# layman -a nx


While it is not a direct drop-in replacement, x2go is the most complete solution currently in Gentoo tree (and my recommendation), with a lot of possible advanced features, active upstream development, … You can connect to net-misc/x2goserver with net-misc/x2goclient, net-misc/pyhoca-gui, or net-misc/pyhoca-cli.

If you want to try NoMachine’s (the company that created NX) new system, well the client is available in Portage as net-misc/nxplayer. The server itself is not packaged yet, if you are interested in it, this is bug #488334

chromium (the web browser) on Gentoo FAQ

As you’ve probably already heard from one of your favourite sites (slashdot, phoronix, …), Google has just released the first beta-quality version of Google Chrome for Linux. I figured this was as good a time as another to collect and answers a few questions frequently asked on it, or rather on chromium which is the open-source version available in portage

  • What’s the difference between Google Chrome and Chromium? Well, chromium web site has a nice page summing it up here. So emerging chromium will get you a browser very close to Google Chrome, except the log and a few Google specific report links (the sandbox is enabled in gentoo chromium)
  • Why does it depend on ffmpeg (and a recent version of it)? For HTML5 audio/video tags support. There is now a USE-flag to disable this dependency if you are on a stable system and do not need this
  • Where do the source tarballs come from? Are they official ones? I create them manually, based on the SVN dependencies listed for each revision here. And it does take some time (checking out their huge tree, trying to get rid of as much bundled sourcecode as possible, …) For now, I track the developer releases, but may switch to beta releases some time. Especially now that upstream is finally considering making source tarballs available 🙂 Bug report is here. There is also another bugreport interested people can track, number 28287, which lists all bugs that would make our life easier, “our” as in distrib packagers, read this recent rant by the Fedora packager for chromium. Also interesting to read is Evan’s answer, digging into what is exactly there in the 3rd party folder.
  • I want to debug/run gdb on it: again the chromium wiki has a nice page on it. The usual recommendations apply of course
  • Will google-chrome-bin get in the tree? This is bug #272805. Right now we have chromium-bin, installed from snapshots generated by chromium test farms, with SVN revisions close to the from-source packages. Right now I don’t see a lot of benefits between chromium-bin and official google-chrome (except a shiny logo?), but if that changes I’ll probably add it to tree (in addition to/replacing chromium-bin). Or if another dev decides to add it 😉

So that’s it for the first round of questions, add yours in comments if it’s still unanswered 😉

neatx and chromium in portage status updates

Yesterday, I finally found the bug which prevented neatx from working on my system (thanks upstream for the debugging), so in your next portage sync, you’ll find net-misc/neatx-0.3.1_p43 ready for your testing! If you don’t need vnc/sound/printer tunneling or load-balancing, neatx is easier to set up than freenx and works great out-of-the-box. Thanks again to Mike Auty (ikelos) for his work on the ebuild.

Another work-in-progress for me these days is a source ebuild for chromium (open-source version of Google Chrome). A binary version (chromium-bin) has been available in portage for some time now (with amd64 support added recently), but source version ebuild had some problems. Now my current version (available in my overlay for the curious) has fixed most of them, including use of system libraries, makefiles use instead of scons, –as-needed support, … So why is it not yet in portage? Well, for now the tarballs from upstream are not yet available, so you won’t go past the fetch phase 😉 These should be available soon, once available you can expect chromium to quickly land in a portage tree near you.

By the way, if chromium crashes at startup for you (either binary or source version), they finally found the cause: you are probably using nvidia-drivers and nvidia opengl (via eselect opengl). However the from nvidia overrides dlsym/dlopen (dynamic linker functions) with broken replacements, breaking applications relying on these functions! Chromium devs implemented a workaround, available for -bin in versions >=, but expect some breakage in time-related functions. All the gory details are here:

And now to change a bit from technical talks, I wanted to say a big “thank you” to all of you Gentoo users who spend time filing bugreports, fixing, writing or rewriting ebuilds, debugging and finding the cause for all sorts of bugs (finding that some dynamic linkers break with specific video cards for example…), in short to all of you who work to make your distro a better one! And recently, a special thanks to Bernd Lommerzheim, who helps me a lot in proftpd maintenance, up to providing an entirely new ebuild for latest version, with lots of fixes and new features.

Yet another open-source NX server!

In my last post about FreeNX future, I had mentioned the efforts on a freenx-redesign branch, which seemed to have stalled.

Well, trust the guys at Google that worked on this redesign, they did not give up, and in fact publicly announced the first public release of neatx, the result of the redesign work. While still missing some of the features available in FreeNX, it does already have some original ones, like the drop-down menu for session control in rootless sessions (which is something I use a LOT when running pidgin remotely from home 🙂 ). I’ll make sure to prepare an ebuild (in your favourite NX overlay first as usual) when they tag a new version (first released one has some bugs that were quickly found).

Now, you may be lost between the multiple servers (including the dead ones), considering I never blogged about tacix, a remote server using NX, but with a different approach from the ‘official’ NoMachine way (with the specifix ‘nx’ user, …), making heavy use of dbus, and with its own client. For now, it’s still in the early versions, but it has potential!

So which server will you install on your (Gentoo, but other work of course) system? Here are the ‘active’ ones:

  • Official NX server (net-misc/nxserver-freeedition in portage), closed-source, limited to 2 concurrent sessions, but has all the features. If you want to quickly try NX!
  • FreeNX (net-misc/nxserver-freenx in portage), oldest and most complete open-source version, but its development stalled. The last ebuilds in tree use the branch from the Ubuntu folks, which fixes a few bugs compared to the last upstream source. If you want a stable open-source version
  • X2GO (net-misc/x2goserver and x2goclient in portage, some extended parts are still in the NX overlay). Maturing fast, and worth a try. This one is brought to you thanks to Joachim Langenbach, who does most of the work on the x2go* ebuilds 🙂

And in the future:

  • tacix, for its simpler architecture (think x2go without postgresql,ldap and friends).
  • neatx, which I hope will provide a suitable replacement for freenx soon

Incoming gnustep-make parallel support

When I add gnustep-make-2.2.0 to portage, repoman (our QA and commit tool) will at last be happy, as from this version, it won’t be necessary to force -j1 make flag! This will also allow parallel make for all gnustep packages in our tree(as the gnustep eclass forces -j1). No need to sync again and again your portage tree, this version is not yet released 😉 Original announcement is here

Some other entries on my gentoo/gnustep TODO list: the Etoile packages in the gnustep overlay need some cleanup (some keywords should be dropped for example Melodie player, maybe bump llvm to 2.5, but I hope some other dev will look into it before me), and updates when 0.4.2 will be released, gnustep packages, fix AC_CANONICAL_TARGET usage found in most of gnustep-base packages (thanks Flameeyes for finding more work for us 😉 ), and filter -Werror in some of our packages (helps when switching to newer GCC for example),