Monthly Archives: January 2015

Re-install pkg for the win

This morning another pkg update && pkg upgrade failed on my FreeBSD 11 CURRENT amd64. It was some 80-ish packages, and it wouldn’t go past py33-atspi-2.12.0_1. It took a make deinstall && make reinstall of the /usr/ports/ports-mngmt/pkg to complete the upgrade.

I couldn’t figure out in details what caused this awkward situation.

Fortunately, with the exception of the necessity to keep enchant locked if I want gedit to have language dictionaries available in the spell-checker plugin, this is the first clumsiness of the pkgng tool I’ve run into in several months of usage, even under the CURRENT branch.

There, just a brief note! 🙂

The conjugate function for clang 3.4.1 on FreeBSD fails?

Dealing with the conjugate of complex numbers brought me some linker failures for clang 3.4.1 on FreeBSD 11 CURRENT amd64:

vanja@current:/tmp % cat konjugat.c
#include <complex.h>
#include <stdio.h>

int main(void)
{
double complex kpx = 1.0 + 3.0*I;
double complex konjugat = conj(kpx);
printf(“Kompleksni broj je %.2f%+.2fi\n”, creal(kpx), cimag(kpx));
printf(“Konjugat od kpx je %.2f%+.2fi\n”, creal(konjugat) ,cimag(konjugat));
return 0;
}

Continue reading

enchant stole the languages in gedit-plugins

A note on strange gedit behaviour: after the last update of ports  – yes, there is always something wrong with ports after an update, no matter what it looks like – my gedit wasn’t able to do spell checking, though I was sure I had hunspell and aspell for at least English and German installed system-wide.

Gedit simply displayed no languages in the appropriate menu.

It would re-compile and re-install even from ports, just fine, but no re-compilation of plugins, python bindings or dictionaries helped until I re-installed enchant from ports! There, it might help someone figure out where have all the languages gone:

pkg info gedit\* \*enchant \*aspell
gedit-3.14.2
gedit-plugins-3.14.1
enchant-1.6.0_4
py27-enchant-1.6.5_6
aspell-0.60.6.1_5
de-aspell-20030222.1_1
en-aspell-7.1.0_1
it-aspell-2.2.20050523.0_1,2

OpenSuSE zombies from btrfs

I installed an openSuSE 13.2 x64. I opted out btrfs and went with ext4. I logged in and found zombies on a freshly installed and updated OS:

lizzy:~ # ps ajx | grep -w Z | grep -v grep ; uname -a
9955 10011 1149 1149 ? -1 Z 0 0:05 [btrfs-defrag-pl]
9955 10012 1149 1149 ? -1 Z 0 0:05 [snapper.py]
Linux lizzy 3.16.7-7-desktop #1 SMP PREEMPT Wed Dec 17 18:00:44 UTC 2014 (762f27a) x86_64 x86_64 x86_64 GNU/Linux

Zombies are coming from the btrfs-something-backend, but why? Those are a perl and a python scripts, ran from who-knows-where-and-why, and I will find them, and tame them, but this is not looking good – first I got some Adobe’s garbage (IC profiles and that idiotic flash player) pre-installed, and it took me a few minutes to figure out where to declare those as persona non-grata in yast, making sure they won’t try to update or install again on every single operation with packages! Now the zombies…

“This does not bond well, commander…”; yet XCOM is working flawlessly, out of the box, with the FLOSS radeon driver, and the dreadful NetworkManager is not calling home – openSUSE introduces wicked here, a home-brew connections manager that actually co-operates with the user well (unlike the NM, that hijacks everything it can, systemd-style). I’ll keep this lizard in my digital garden a bit more…