Gnome OCR and Other Stuff

I was looking for an OCR app to use with Gnome/Gentoo and decided to give OCRFeeder a try.  It is available in the an overlay which makes it easier to keep up with for updates.  It is found in the anyc overlay.

layman -a anyc  then  emerge ocrfeeder (have to unmask)

WTF!!! A lot of rebuilds and new packages … that means probable trouble.  Yep, mplayer2 will not compile.  One of the updates was for ffmpeg and that had me worried that I had run into my first libav–ffmpeg blowup because I use ffmpeg rather than the mandated libav.

So, I unmask mplayer2-2.0_p20131009-r1 and still get the error:

libmpdemux/aviheader.c: In function ‘read_avi_header’:
libmpdemux/aviheader.c:600:8: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
fread(&magic, 6, 1, fp);
libmpdemux/aviheader.c:605:8: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
fread(&priv->idx_size, sizeof(priv->idx_size), 1, fp);
libmpdemux/aviheader.c:616:10: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
fread(idx, sizeof(AVIINDEXENTRY), 1, fp);
libmpdemux/demuxer.c:48:2: error: #error MP_INPUT_BUFFER_PADDING_SIZE is too small!
#error MP_INPUT_BUFFER_PADDING_SIZE is too small!
Makefile:536: recipe for target ‘libmpdemux/demuxer.o’ failed

Well, I try emerge @preserve-rebuild without mplayer2 and now I get this for /vlc-2.1.2:

checking for AVCODEC… yes
configure: error: libavcodec versions 56 and later are not supported yet.

Yep, vlc is giving me issues.  Now I am on the slippery slide of getting off the Gentoo path, so I up the stakes, I unmask media-video/vlc-2.1.5-r1 and try again.  You might ask why jump up to 2.15-r1 and I would reply that if I am going to blow things up badly then I might as well go big.

Great, now k3b errors on compile!  Unmask k3b-2.0.3-r1 and emerge without problems.  Okay, so where am I now?  Yep, back to this mplayer2 issue:

libmpdemux/demuxer.c:48:2: error: #error MP_INPUT_BUFFER_PADDING_SIZE is too small!
#error MP_INPUT_BUFFER_PADDING_SIZE is too small!

I don’t feel like going to battle for mplayer because I only use vlc or others, so a quick:

equery d mplayer2

results in:

  * These packages depend on mplayer2:
media-video/smplayer-14.9.0-r1 (media-video/mplayer2[libass,png,X])


emerge –unmerge mplayer2 smplayer 

Now what was I doing?  Yep, OCRFeeder install.  Well, that went okay finally, but OCR engines have to be installed.  I installed gocr, ocrad, cuneiform, and tesseract.  OCRFeeder lets the user select the engine.

Another day in Gentoo world ….


Tracker Thrashing at Gnome Boot

Use Gnome?  What is Tracker?  Well, here is the official description:

Tracker is a search engine, search tool and metadata storage system.

It allows you to find the proverbial needle in your computer’s haystack as well as providing a one stop solution to the organisation, storage and categorisation of your data.

Source:  Tracker Wiki

I would add that Tracker kills my system at boot.  Maybe not kill, but brings it to a crawl.  I have thought about disabling it, but sometimes I like the Gnome desktop search.  My fix for the boot issue:

littleturd autostart # ls -l tracker*
-rw-r--r-- 1 root root 524 Dec 30 21:33 tracker-extract.desktop
-rw-r--r-- 1 root root 532 Dec 30 21:43 tracker-miner-fs.desktop
-rw-r--r-- 1 root root 597 Dec 30 21:44 tracker-store.desktop

Now change the following in each of the above files:


Of course, resetting things helped too.

tracker-control -r   :Kill all Tracker processes and remove all databases
tracker-control -s   :Starts miners (which indirectly starts tracker-store too)

Last, don’t be dumb like me who mounts his NAS in his home directory, know what directories tracker is set to scan!

Another day, another kernel and that VMware problem

Yep, another day, a new kernel:

Linux littleturd 3.19.0-gentoo-mgreene #1 SMP PREEMPT Tue Feb 10 19:08:38 EST 2015 x86_64 Intel(R) Core(TM) i5-2320 CPU @ 3.00GHz GenuineIntel GNU/Linux

What does going from 3.18.x to 3.19.0 mean for me?  The damn Vmware modules don’t compile, so it is off to remember how to fix it.  Of course the old trusty Arch page has the answer: 3.19 kernels

Every time I have to do this I have to ask myself, “Why the hell do I have VMware installed?”  The truth is that I installed it to run my NAS firmware to try something, but that was a long time ago.  So once again I should just remove it … but what if I need it?



Bluefish 2.2.7 on Gentoo

Gentoo finally updated to Bluefish 2.2.6, so I know the latest version must be out which is 2.2.7.  In case you do not know:

Bluefish is a powerful editor targeted towards programmers and webdevelopers, with many options to write websites, scripts and programming code. Bluefish supports many programming and markup languages.

Unfortunately, I already use 2.2.6 and want 2.2.7. Just to make things easy, I download and unarchive then use the Gentoo configure to setup everything:

./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --libdir=/usr/lib64 --docdir=/usr/share/doc/bluefish-2.2.6 --disable-dependency-tracking --disable-update-databases --disable-xml-catalog-update --enable-nls --enable-spell-check --enable-python

Follow that by make and, if everything works, make install.  Now the latest version of Bluefish is installed.


Gentoo Java emerge issue

Once again portage tells me there is an Oracle Java update and I already know it will have to be downloaded manually and moved into /usr/portage/distfiles. I do this, expecting everything to install without a hitch, but it does not. I get the dreaded “tar: This does not look like a tar archive” (see below) and I have forgot why this happens as usual. The solution is simple, the archive needs to belong to portage:

chown -R portage:portage /usr/portage/distfiles/jdk-7u71-linux-x64.tar.gz

>>> Emerging (1 of 2) dev-java/oracle-jdk-bin-
* jdk-7u76-linux-x64.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking jdk-7u76-linux-x64.tar.gz to /var/tmp/portage/dev-java/oracle-jdk-bin-
gzip: /var/tmp/portage/dev-java/oracle-jdk-bin- Permission denied
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
* ERROR: dev-java/oracle-jdk-bin- failed (unpack phase):
* failure unpacking jdk-7u76-linux-x64.tar.gz
* Call stack:
*, line 93: Called src_unpack
* environment, line 2563: Called default
*, line 770: Called default_src_unpack
*, line 797: Called __eapi0_src_unpack
*, line 648: Called unpack 'jdk-7u76-linux-x64.tar.gz'
*, line 357: Called __unpack_tar 'gzip -d'
*, line 299: Called __assert_sigpipe_ok 'failure unpacking jdk-7u76-linux-x64.tar.gz'
*, line 39: Called die
* The specific snippet of code:
* [[ $x -ne 0 && $x -ne ${PORTAGE_SIGPIPE_STATUS:-141} ]] && die "$@"
* If you need support, post the output of `emerge --info '=dev-java/oracle-jdk-bin-'`,
* the complete build log and the output of `emerge -pqv '=dev-java/oracle-jdk-bin-'`.
* The complete build log is located at '/var/tmp/portage/dev-java/oracle-jdk-bin-'.
* The ebuild environment file is located at '/var/tmp/portage/dev-java/oracle-jdk-bin-'.
* Working directory: '/var/tmp/portage/dev-java/oracle-jdk-bin-'
* S: '/var/tmp/portage/dev-java/oracle-jdk-bin-'
>>> Failed to emerge dev-java/oracle-jdk-bin-, Log file:
>>> '/var/tmp/portage/dev-java/oracle-jdk-bin-'
* Messages for package dev-java/oracle-jdk-bin-
* ERROR: dev-java/oracle-jdk-bin- failed (unpack phase):
* failure unpacking jdk-7u76-linux-x64.tar.gz