Ιστολόγιο

About six months ago I ranted about Gentoo and that I wanted to start migrating my boxes to another distro. However, I failed miserably. I only managed to migrate just one box to Arch Linux but the rest of my boxes are far far away so it is not possible to do this process remotely. Or maybe it is,  but it would require a massive amount of time and energy which I currently don’t have. Moreover, I was not able to get my motivation back so I am still around doing some routine tasks (retirements, trivial version bumps, treecleaning etc) as well as some recruitment work. This is actually quite good, cos I get to recruit new people to fill in my void :)

I would also like to apologize for the long standing bugs, but given the fact that most of the herds, who co-maintain my packages, are nearly empty, and I have no fast, reliable and, most importantly, available hardware to do my tests, I can’t do much :). However, I still have a few VirtualBox machines, running on the remote boxes, which help me stay in touch for the time being.

We’re happy to announce a KDE 4.8 Release Party in Prague,CZ!

The party will take place on Friday, 24th of February, 17:00, at the SUSE Linux building (Map, KDE Community Wiki). There will be KDE and openSUSE swag available, KDE SC 4.8 live CDs, plus some short KDE related talks. We’re also gonna have some drinks, a KDE Cake, and lots of fun!

PS In case you are a KDE contributor and would like to give a short talk about it, feel free to send a mail to me or Michal (for czech mails, michal [at] hrusecky [dot] net)

PS 2 Czech announcement and poster in Michal’s blog post

As discussed in the last Gentoo Qt meeting, we moved our overlay from gitorious to git.overlays.gentoo.org. This is going to be the final move, I promise

Along with that, we decided to change the overlay from qting-edge to just qt. Layman list is alreay updated, so if you still have the old one, you should remove it and add the new one:

# layman -f # layman -d qting-edge # layman -a qt

Keep in mind that this overlay contains mostly live ebuilds of Qt (branches 4.7 and master), so make sure that you really need it before blindly adding it (the same applies for the kde overlay). Enjoy!

1. Roll call

johu, hwoarang, pesa, tampakrap, wired

2. Qt 4.8

* cairo fails to build, patched ebuild available in qting-edge, #380013

Cairo build issue is fixed in qting-edge overlay, will be moved together with Qt 4.8.0 to tree.

* qt now defaults to the raster graphicssystem, we should remove raster USE flag, #398283

Wired created a eselect module to choose the Qt graphicsystem. Raster is default, other selectable are opengl, openvg and native. Raster use flag is not needed anymore, qt-gui depends on the new eselect module.

* do we really want to keep qpa USE flag?

qpa and c++0x will be masked in tree.

* are we going to fix #363939 for 4.8?

Wired fixed this bug in qt 4.8.0. Qt 4.8 will be moved to tree on next weekend. Dilfridge prepares kde-base/kstyles-4.7.4 to be rebuild together with Qt 4.8.0 to prevent crashes in KDE apps with Oxygen style.

3. Minor arches and Qt >= 4.7

Upstream supports official amd64, arm and x86, but other arches also considered in configure script. Keep stable keywords for minor arches in Qt 4.6. Wait for minor arches arm, ppc, ppc64 in current stabilization in Qt 4.7.4. Drop sparc keywords in Qt 4.8.0.

4. Overlay migration to git.overlays.gentoo.org

Tampakrap will set up overlay on git.overlays.gentoo.org on next weekend. The new overlay will be renamed to qt instead of qting-edge.

5. Open bugs

* #398885 qdoc3 broken on arm

We will ask the reporter if it works when he builds manually by providing him a configure command to make sure he tries the proper build.

* #394533 Libreoffice crashes in qt on exit

Can’t be reproduced with Libreoffice 3.5.0.1, seems to be resolved by upstream.

* #392433 desktop file name issues

Will be fixed in Qt 4.8.0, so that qt-gui and qt-assistant no longer pass absolute paths to make_desktop_entry().

* #388551 qt-gui[gtkstyle] should depend on gnome-base/libgnomeui-2

We will add a elog message in qt-gui[gtkstyle] saying that for things to work you either need libgnomeui or that variable set properly in your env.

* #382559 qt_mkspecs_dir() returns bad spec directory

The bug will be marked as RESOLVED WORKSFORME, because we can’t reproduce it. Additionally we change the eclass not to use LIBDIR in favor of get_libdir() after Qt 4.8 hits the portage tree.

* #359391 qt4-build.eclass should check for —buildpkgonly before downgrade sanity check

Resolution will be RESOLVED WONTFIX. Sanity check is there for a reason. It’s not a matter of source or binary downgrade.

Since one hour ago, Qt-4.8.0 is in Gentoo portage tree. New major release so lots of new (or broken) stuff. The most important feature in this release is the integration of a new eselect module. This module will allow you to set your default graphics engine without the need to recompile Qt (x11-libs/qt-gui to be precise) from scratch. So, provided you have qt-gui-4.8.0 installed, you should be able to use the eselect module as follows:

hwoarang@mystical ~$ eselect qtgraphicssystem list Available Qt Graphics Systems: [1] native [2] opengl [3] raster *

(note: if you have x11-libs/qt-openvg installed, one more option should be available)

Simply select your graphics system of preference, and then logout and login again.

hwoarang@mystical ~$ eselect qtgraphicssystem set 2 Setting opengl as your active Qt Graphics System... done Please logout for changes to take effect.

Thanks to Alex(wired) for the eselect module implementation.
Enjoy ;-)

 

 

1) Roll call

alexxy, jmbsvicetto, dilfridge, johu, mschiff, tampakrap, Thev00d00

2) Electing a new team leader

Since one year is not over yet, it will be skipped for the next meeting.

3) What shall we do with kdepim-4.4

KDEPIM 4.4 is not supported any more by upstream, but on the other hand KDEPIM2 is still too buggy. We had a discussion if we should remove it completely or if we should continue maintain it, despite the compatibility bugs that started to emerge with newer KDE versions. Final decision is that we will continue support it as long it works with newer KDE SC releases. We’ll keep the kdepim-l10n split package to provide the translations for it.

4) kdeenablefinal revisited

Since upstream doesn’t seem to care about it much, plus it doesn’t make much sense now that there are many split tarballs, we decided to remove it the next day after the meeting.

5) phonon-xine removal

KDE upstream acknowledged that this is not maintained anymore. It’s already masked since 2011/12/01. Will be last rited and removed 15 days afterwards.

6) Qt 4.8

We expect no big issues with it. Kdenlive is the only known application that does not build at the moment and will be patched. kde-base/kstyles-4.7.* needs to be rebuilt after the upgrade, which we’ll solve with a combination of revbump/dependencies (otherwise KDE apps using oxygen style crash).

7) Dropping RPATH from installed binaries

Postponed for next meeting, need more info from reavertm and/or hardened herd.

To eselect Boost or not to eselect boost

No final decision was taken, discussion will be moved to -dev mailing list.

9) Bugs

* dev-util/cmake picks always the latest boost. Fix in overlay since 13. Dec. Move to tree? https://bugs.gentoo.org/show_bug.cgi?id=335108

see 8.

* cmake-utils.eclass PREFIX is not defined, any progress? https://bugs.gentoo.org/show_bug.cgi?id=358059

Postponed for next meeting

* Remove hard dep on media-libs/phonon from kde-base/kdelibs https://bugs.gentoo.org/show_bug.cgi?id=356681 https://bugs.gentoo.org/show_bug.cgi?id=388041

Although it is possible to build kdelibs against qt-phonon, it is not recommended by upstream. Decision postponed for next meeting.

* Eclass problem with handbook without LINGUAS. https://bugs.gentoo.org/show_bug.cgi?id=372457

Needs more analysis. Postponed.

* MacOSX request for cmake-utils.eclass: Remove force of  CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE https://bugs.gentoo.org/show_bug.cgi?id=398437

That was a request by the Gentoo Prefix team, and got accepted

* Revise the change “semantic-desktop? -> semantic-desktop=”. Why was the change needed. https://bugs.gentoo.org/show_bug.cgi?id=396491

We had split opinions on this. Skipped for next meeting, as we need reavertm’s input on this.

10) Open floor

• Tampakrap will make a KDE SC 4.8 release party in Prague, more info coming soon.
• Qt meeting on Thursday 26th Jan.
• See you at fosdem

Meeting Log can be found here

I’m writing a program to gather data from twitter. It’s meant to work via command line or used with a cron daemon. My program uses SQLite3 to store data. I was not able to install the sqlite3 gem, on a remote server running RVM, because requires root level access. In my case the remote server is way more reliable than the local one. The biggest problem on installing a ruby-1.9.3 script to be executed with cron on the local system was… Gentoo.

The first problem was the default cron: vixie-cron. For some reason, the permissions are set erroneously at the time of vixie’s installation, making impossible for the user to use crontab. To solve this, you need to change permissions to some directories, maybe even create user, probably adjust crontab’s group id and other hassles. The easy way is to remote vixie-cron which is old anyway and install fcron which is a modern, worthy replacement.

The second problem was the current sad state of ruby-1.9 on the Gentoo portage tree. There are forum topics about it and many online discussions about the subject. Unmasking ruby-19 is a bit a huge hassle and doesn’t always work the way it should. Didn’t work for me. Too many errors on every step. So I opted for RVM once again. Yes, it’s a life savior.

After installing RVM – it’s a one-liner – everything works fine as long as you’re the user but when you need to execute a script using RVM environment variables along with fcron, you must be really pedantic. So here is an example of RVM + user’s fcrontab configuration, take a look and save your time:

# atmat's crontab configuration SHELL=/bin/bash PATH=/home/atma/.rvm/gems/ruby-1.9.3-p0/bin:/home/atma/.rvm/gems/ruby-1.9.3-p0@global/bin:/home/atma/.rvm/rubies/ruby-1.9.3-p0/bin:/home/atma/.rvm/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.5.3 RUBYLIB=/home/atma/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1 GEM_HOME='/home/atma/.rvm/gems/ruby-1.9.3-p0'GEM_PATH='/home/atma/.rvm/gems/ruby-1.9.3-p0:/home/atma/.rvm/gems/ruby-1.9.3-p0@global' RUBYOPT=rubygems %nightly,mail(no) * 8-9 /home/atma/.rvm/rubies/ruby-1.9.3-p0/bin/ruby /usr/local/bin/morula -s username update

Note that I’ve tried all the options described on RVM’s website, like sourcing the specific RVM variables file, adding a bash wrapper but nothing worked until I setup all the environment variables manually as you see in the above example.

Cheers

ps. I’m not sure what is the current status of ruby on Ubuntu or BSD’s. Reading about same kind of issues under FreeBSD I get the feeling that most source-code packaging system distributions have a difficulty parting from ruby18.

Related posts:

1. Follow-up post: Ruby RVM, Python και Git στους server της CreatForce.
2. Εγκατάσταση Ruby gems σε server της CretaForce
3. Going back to the roots: Gentoo

I needed to create a Time Machine sparse bundle on an external HD formated ext3fs. I start digging up Google and here is what I came up with! First we need to download the Tuxera MacFuse unofficial bundle for MacOSX Lion and install it. Then we need to get the MacFuse ext3 extention and install it.

Then attach the external USB hd on your mac and issue “sudo dmesg” to check out what is happening. You’ll probably see this:

/dev/disk1s1 on /Volumes/Untitled (osxfusefs_ext2, local, read-only, synchronous) /dev/disk1s2 on /Volumes/Untitled 1 (osxfusefs_ext2, local, read-only, synchronous)

 

At this point all we need to do is unmount and remount the partitions using read-write support:

$ sudo umount /dev/disk1s2  $ sudo umount /dev/disk1s1 $ sudo fuse-ext2 /dev/disk1s2 /Volumes/BACK -o force fuse-ext2: version:'0.0.7', fuse_version:'27' [main (../../fuse-ext2/fuse-ext2.c:324)] fuse-ext2: enter [do_probe (../../fuse-ext2/do_probe.c:30)]fuse-ext2: leave [do_probe (../../fuse-ext2/do_probe.c:55)] fuse-ext2: opts.device: /dev/disk1s2 [main (../../fuse-ext2/fuse-ext2.c:351)] fuse-ext2: opts.mnt_point: /Volumes/BACK [main (../../fuse-ext2/fuse-ext2.c:352)] fuse-ext2: opts.volname:  [main (../../fuse-ext2/fuse-ext2.c:353)] fuse-ext2: opts.options: force [main (../../fuse-ext2/fuse-ext2.c:354)] fuse-ext2: parsed_options: force,allow_other,local,noappledouble,fsname=/dev/disk1s2,fstypename=ext2,volname=disk1s2 [main (../../fuse-ext2/fuse-ext2.c:355)] fuse-ext2: mounting read-write [main (../../fuse-ext2/fuse-ext2.c:369)]

The write supports is not “good”. You’d better fsck the volume when you plug the disk on the linux system.

Good luck!

 

 

Related posts:

1. As you probably already know MacOSX Lion was released earlier this month. Although apple machines th
2. TrueCrypt 6.3 supports snow leopard!
3. Manage to launch OpenVPN at boot under MacOSX

Ένας λόγος να κάνω την δουλειά μου πιο εύκολα ήταν πάντα ένας τοπικός mirror τουλάχιστον για rsync αν όχι για files, που με γλύτωνε από extra bandwidth και μου επέτρεπε ίσως να προσθέσω και δικά μου script/ebuild μαζί με τα official του Gentoo Foundation. Ας δούμε για αρχή πως στήνουμε έναν rsync mirror.

Τι θα χρειαστούμε:

• Ένα μηχάνημα με οποιαδήποτε διανομή linux, με τουλάχιστον 1 GB δίσκο και 10/10 Mbps σύνδεση.
• Το πακέτο rsync μαζί με το daemon του.
• Έναν vixie cron daemon.
• Έναν ftp/http server (προαιρετικό, χρησιμεύει στην προβολή τον αρχείων στο internet ).

Απο κεί και πέρα σύμφωνα με το:  http://www.gentoo.org/doc/en/rsync.xml

Δημιουργία rsync script.

[bash]
#!/bin/bash

RSYNC=”/usr/bin/rsync”
OPTS=”–quiet –recursive –links –perms –times -D –delete –timeout=300″
SRC=”rsync://rsync.server.com/gentoo-portage” # Master rsync server
DST=”/gentoo/portage/path/” # Path αποθήκευσης
LOG=”/var/log” # Path για τo log

echo “Started update at” `date` >> ${LOG}/$0.log 2>&1
logger -t rsync “re-rsyncing the gentoo-portage tree”
${RSYNC} ${OPTS} ${SRC} ${DST} >> ${LOG}/$0.log 2>&1

echo “End: “`date` >> ${LOG}/$0.log 2>&1
[/bash]

Το variable SRC καθορίζει τον rsync server απο τον οποίο θα τραβήξουμε τα αρχεία, ενώ το DST, το path μέσα στο οποίο θα αποθηκεύσουμε τα αρχεία που θα κατεβάσει το rsync script.
Για το variable SRC οι round robin hosts που προτείνω είναι οι παρακάτω:

• Για Ευρώπη (σύμφωνα με το gentoo.org): rsync.de.gentoo.org
• Για Ελλάδα: rsync.gr.gentoo.org

Τα παραπάνω hosts αντοιστοιχούν σε κάποιον random rsync mirror της κάθε χώρας (de = Γερμανία, gr = Ελλάδα).

Ρύθμιση του vixie cron daemon.

Αφού τελειώσουμε με το rsync script πρέπει να αναλάβει ο vixie cron daemon ώστε να το εκτελεί κάθε μισή ώρα, ενημερώνοντας έτσι τα αρχεία του δικού μας mirror. Δημιουργούμε ένα αρχείο στο /etc/cron.d (π.χ. touch gentoo-mirror) και μέσα σε αυτό προσθέτουμε τα παρακάτω:

[bash]
*/30 * * * * user /script/path/gentoo-mirror.sh &> /dev/null
[/bash]

Με αυτή την γραμμή λέμε στον vixie cron deamon, να εκτελεί το script gentoo-mirror.sh στο path που βρίσκεται ως ένας χρήστης του συστήματος κάθε 30 λεπτά. Το script θα τρέχει δηλαδή: xx:00 και xx:30 λεπτά, ανάλογα με το ρολόι του συστήματος. Φυσικά αλλάζουμε το path και τον user με αυτά που θέλουμε.

Ρύθμιση του rsync daemon.

Οι ρυθμίσεις που θα χρειαστεί ο rsync daemon βρίσκονται στο αρχείο /etc/rsyncd.conf, σε περίπτωση που δεν υπάρχει το δημιουργούμε εμείς και του εισάγουμε τα παρακάτω:

[bash]
uid = nobody
gid = nobody
use chroot = yes
max connections = 15
pid file = /var/run/rsyncd.pid
motd file = /etc/rsync/rsyncd.motd
log file = /var/log/rsync.log
transfer logging = yes
log format = %t %a %m %f %b
syslog facility = local3
timeout = 300

[gentoo-portage] # Ξεχωριστό section για το portage (mirror) μας
path = /gentoo/portage/path # Path των αρχείων που κατέβασε το rsync script
comment = Gentoo Linux Portage tree mirror
exclude = distfiles # Εξαιρέσεις απο τον mirror
[/bash]

Τα προβλήματα που ίσως εμφανιστούν έιναι η ύπαρξη του nobody user, οπότε και τον αλλάζουμε σε root ή τον δημιουργούμε. Επίσης σχετικά με τι διανομή debian, που χρησιμοποιώ σαν server, θα πρέπει να αλλάξουμε στο αρχείο /etc/default/rsync το πεδίο RSYNC_ENABLE=false σε RSYNC_ENABLE=true και μετά να κάνουμε έναρξη του rsync daemon από τα init scripts.

[bash]
/etc/init.d/rsync start
[/bash]

Και πλέον έχουμε έτοιμο τον δικό μας rsync mirror.
Μέχρι στιγμής είμαι maintainer σε έναν ανεπίσημο rsync mirror server poy βρίσκεται εδώ: http://mirrors.pebkac.gr/ && http://mirrors.pebkac.gr/gentoo-portage. Κάποια στιγμή όταν θα έχω χρόνο θα προσθέσω άλλον ένα επίσημο ελληνικό rsync & files mirror με την βοήθεια του Εργαστηρίου Υπολογιστικών Συστημάτων Υψηλής Επίδοσης του ΑΤΕΙ Μεσολογγίου.

Έχει περάσει περισσότερο από 1 μήνας από τότε που πήρα στα χέρια μου το eBox 3350MX. Μπορείτε να διαβάσετε το review που είχα γράψει τότε εδώ. Η εμπειρία μου με την συσκευή όμως, έως σήμερα είναι αρνητική. Δεν έχω καταλάβει τι ακριβώς φταίει. Το πρώτο καιρό αντιμετώπιζα κάποια καθυστερήσεις όταν εκτελούσα εντολές από secure shell. Εντολές όπως το ‘emerge –search <packge-name>‘ π.χ. άλλες φορές αργούν υπερβολικά κι άλλες φορές δεν εμφανίζουν καν αποτέλεσμα. Πέφτει ένα disconnect από τον ‘remote server’ και τέλος. Άλλες φορές πάλι, μοιάζει να εκτελεί την εντολή κανονικά χωρίς πρόβλημα ταχύτητας.

Το load στο eBox είναι σχεδόν πάντοτε χαμηλό, η εντολή uptime δεν εμφανίζει ποτέ μεγάλα νούμερα. Παρόλα αυτά πολλές φορές δείχνει ιδιαίτερο ζόρι στο εκτελεί εντολές. Ίσως φταίει η SD card που χρησιμοποιώ ως σκληρό δίσκο. Καθότι το eBox δεν έχει εσωτερικό σκληρό, χρησιμοποιώ μια ADATA SDHC 16 GB class 10 κάρτα για σκληρό δίσκο.

Ένα ακόμη πρόβλημα είναι η κάρτα δικτύου. Υπάρχουν φορές που λειτουργεί κι άλλες φορές που σταματάει να λειτουργεί. Δεν μπορώ να τα καταλάβω τι ακριβώς φταίει γι αυτό, όμως έχει γίνει πολύ κουραστική ακόμη και η εκτέλεση απλών διεργασιών. Στα logs δεν βλέπω τίποτε το περίεργο, κι όμως εκεί που λειτουργεί 2 ημέρες κανονικά ο server σταματάει, σαν να κολλάνε τα πάντα. Κάνω 4 reboot και δεν λειτουργεί – δεν μπορώ να τον δω να σηκώνει sshd – έπειτα βάζω την SD Card στο macbook, κάνω boot από VirtualBox να δω τι συμβαίνει, δεν αλλάζω τίποτε, ούτε καν κάνω fsck.ext3 στο / partition, βάζω την κάρτα στο eBox και παίζει «κανονικά».

Σκέφτομαι την περίπτωση να αλλάξω λειτουργικό σύστημα, μήπως το Linux έχει κάποια προβλήματα με το RDC chipset αλλά χωρίς οθόνη η προσπάθεια να βάλω Free ή OpenBSD σε ένα τέτοιο μηχάνημα θα ήταν πραγματικά χρονοβόρα και δεν υπάρχει χρόνος για trial / error και log digging.

Δυστυχώς, ενώ θεωρητικά το μηχάνημα έχει τα προσόντα να γίνει ένας πολύ καλός σπιτικός server για torrents, backup (Time Machine via Netatalk), local DHCP server, WiFi Free Guest network κλπ. Δεν δείχνει να μπορεί να σταθεί στο «ύψος». Άλλωστε το συγκεκριμένο μηχάνημα χρησιμοποιείται κυρίως με WindowsCE σε robotics. Δυστυχώς η επόμενη λύση που βρήκα για σπιτικό fanless server ακούει στο όνομα fit-pc με πολλαπλάσια τιμή.

Θα δοκιμάσω λίγο ακόμη την τύχη μου με Gentoo και ίσως τα Χριστούγεννα εν Ελλάδι, περάσω BSD στο eBox.

Related posts:

1. Gentoo στο eBox 3350!

Πριν καιρό έγραψα ένα πολύ απλό προγραμματάκι που με χρήση του προγράμματος ping στέλνει παράλληλα πολλά πακέτα σε κάποιον «στόχο», με σκοπό να προκαλέσει DoS και να ρίξει κάποιον «στόχο». Η δημιουργία του έγινε για καθαρά εκπαιδευτικό σκοπό. Παραθέτω τον κώδικά του: /* Program: Ping Of Death Author: Nikolaos Chatzidakis (aka nikhatzi) Disclaimer: To programma