On November 26, the Qt/KDE Debian team (qkd from now on) released an
experimental packaging of KDE SC 4.7.
This means a substantial and very much awaited upgrade from the
actual version available in sid, 4.6.5 . From what I've been told, it has taken
so long because there have been a lot of changes in source code structure (KDE has
recently restructured its source modularization) and in packaging itself, and
even with recent aditions to the group, the resources in terms of developers is
still low. In any case, thanks to them for getting this version out, I really
appreciate your hard work.
But because of this lack of resources, they only got out packages for the amd64
architecture, and I'm running i386 at home, so I decided to try and compile it
by myself. This is the log of the attempt.
First, I added deb-src http://qt-kde.debian.net/debian experimental-snapshots main
to my sources.list and got the code for kde4libs, the package I think is the
root of the whole repo[1][2]:
mdione@mustang:~/src/system/debian$ apt-get source kde4libs
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'kde4libs' packaging is maintained in the 'Git' version control system at:
git://git.debian.org/pkg-kde/kde-sc/kde4libs.git
Need to get 12.4 MB of source archives.
Get:1 http://qt-kde.debian.net/debian/ experimental-snapshots/main kde4libs 4:4.7.2-0r3 (dsc) [4,883 B]
Get:2 http://qt-kde.debian.net/debian/ experimental-snapshots/main kde4libs 4:4.7.2-0r3 (tar) [12.1 MB]
Get:3 http://qt-kde.debian.net/debian/ experimental-snapshots/main kde4libs 4:4.7.2-0r3 (diff) [334 kB]
Fetched 12.4 MB in 1min 54s (109 kB/s)
gpgv: Signature made Sat 22 Oct 2011 02:29:45 AM CEST using RSA key ID 73A85F31
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./kde4libs_4.7.2-0r3.dsc
dpkg-source: info: extracting kde4libs in kde4libs-4.7.2
dpkg-source: info: unpacking kde4libs_4.7.2.orig.tar.bz2
dpkg-source: info: unpacking kde4libs_4.7.2-0r3.debian.tar.gz
dpkg-source: info: applying kconf_update_migrate_from_kde3_icon_theme.diff
dpkg-source: info: applying add_debian_build_type.diff
dpkg-source: info: applying disable_usr_lib_install_rpath.diff
dpkg-source: info: applying make_libkdeinit4_private.diff
dpkg-source: info: applying default_kde4_xdg_menu_prefix.diff
dpkg-source: info: applying qt4_designer_plugins_path.diff
dpkg-source: info: applying hardcode_ptm_device.diff
dpkg-source: info: applying kfreebsd_support.diff
dpkg-source: info: applying debian_menu.diff
dpkg-source: info: applying findservicebydesktoppath_try_realfilepath.diff
dpkg-source: info: applying findqt4_optional_x11_pthread.diff
dpkg-source: info: applying use_dejavu_as_default_font.diff
dpkg-source: info: applying hack_in_etc_kde4_in_kstandarddirs.diff
dpkg-source: info: applying ld_exclude_libs_qtuitools.diff
dpkg-source: info: applying konsole_kfreebsd_fix.diff
dpkg-source: info: applying hurd_support.diff
dpkg-source: info: applying kfileshare_kdesu_fileshareset.diff
dpkg-source: info: applying relax_plugin_kde_version_check.diff
dpkg-source: info: applying add_dlrestrictions_support.diff
dpkg-source: info: applying findpythonlibrary_layout_deb_on_debian.diff
dpkg-source: info: applying ktar_header_checksum_fix.diff
dpkg-source: info: applying ktar_longlink_length_in_bytes.diff
dpkg-source: info: applying nepomuk_unicode.diff
Nice, now get the build-deps:
mdione@mustang:~/src/system/debian$ sudo apt-get build-dep kde4libs
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Build-Depends dependency for kde4libs cannot be satisfied because candidate version of package shared-desktop-ontologies can't satisfy version requirements
Dang, I have an old shared-desktop-ontologies (v. 0.6.x in sid), and peeking
in qkd's repo I find no new version of it. The answer must be in experimental,
so I add deb http://ftp.nl.debian.org/debian/ experimental main to my sources.list
and run apt-get update. Now it must be just a matter of:
mdione@mustang:~/src/system/debian$ sudo apt-get install -t experimental shared-desktop-ontologies
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
shared-desktop-ontologies
1 upgraded, 0 newly installed, 0 to remove and 103 not upgraded.
Need to get 129 kB of archives.
After this operation, 4,096 B of additional disk space will be used.
Get:1 http://ftp.nl.debian.org/debian/ experimental/main shared-desktop-ontologies all 0.8.0-1 [129 kB]
Fetched 129 kB in 1s (92.7 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
apt-listchanges: Mailing root: apt-listchanges: changelogs for mustang
(Reading database ... 218251 files and directories currently installed.)
Preparing to replace shared-desktop-ontologies 0.6.0-1 (using .../shared-desktop-ontologies_0.8.0-1_all.deb) ...
Unpacking replacement shared-desktop-ontologies ...
Setting up shared-desktop-ontologies (0.8.0-1) ...
And I try again:
mdione@mustang:~/src/system/debian$ sudo apt-get build-dep kde4libs
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
hspell libacl1-dev libattica-dev libattr1-dev libdbusmenu-qt-dev libdlrestrictions-dev libpolkit-qt-1-dev libqca2-dev libstreamanalyzer-dev libstreams-dev
libutempter-dev pkg-kde-tools
0 upgraded, 12 newly installed, 0 to remove and 8 not upgraded.
Need to get 1,170 kB of archives.
After this operation, 3,551 kB of additional disk space will be used.
Do you want to continue [Y/n]?
[...]
We're set! now to fire the compilation itself. The method I use must not be the best one, but I remember it by heart and works for me :)
mdione@mustang:~/src/system/debian$ cd kde4libs-4.7.2/
mdione@mustang:~/src/system/debian/kde4libs-4.7.2$ nice -n 19 fakeroot debian/rules binary
Notice I use nice to not hog too much my computer and fakeroot. I don't
remember why I must use it :| , but I remember I must. Later, asking in #debian-devel
I was pointed to dpkg-buildpackage, to which you can give the -j# option,
which makes the package to be compiled with # processes in parallel (actually
it only works if the compilation is make based, as is in this case), so from
now on I'll use that.
The resulting packages are these:
kdelibs5-data_4.7.2-0r3_all.deb
kdelibs5-dbg_4.7.2-0r3_i386.deb
kdelibs5-dev_4.7.2-0r3_i386.deb
kdelibs5-plugins_4.7.2-0r3_i386.deb
kdelibs-bin_4.7.2-0r3_i386.deb
kdoctools_4.7.2-0r3_i386.deb
libkcmutils4_4.7.2-0r3_i386.deb
libkde3support4_4.7.2-0r3_i386.deb
libkdeclarative5_4.7.2-0r3_i386.deb
libkdecore5_4.7.2-0r3_i386.deb
libkdesu5_4.7.2-0r3_i386.deb
libkdeui5_4.7.2-0r3_i386.deb
libkdewebkit5_4.7.2-0r3_i386.deb
libkdnssd4_4.7.2-0r3_i386.deb
libkemoticons4_4.7.2-0r3_i386.deb
libkfile4_4.7.2-0r3_i386.deb
libkhtml5_4.7.2-0r3_i386.deb
libkidletime4_4.7.2-0r3_i386.deb
libkimproxy4_4.7.2-0r3_i386.deb
libkio5_4.7.2-0r3_i386.deb
libkjsapi4_4.7.2-0r3_i386.deb
libkjsembed4_4.7.2-0r3_i386.deb
libkmediaplayer4_4.7.2-0r3_i386.deb
libknewstuff2-4_4.7.2-0r3_i386.deb
libknewstuff3-4_4.7.2-0r3_i386.deb
libknotifyconfig4_4.7.2-0r3_i386.deb
libkntlm4_4.7.2-0r3_i386.deb
libkparts4_4.7.2-0r3_i386.deb
libkprintutils4_4.7.2-0r3_i386.deb
libkpty4_4.7.2-0r3_i386.deb
libkrosscore4_4.7.2-0r3_i386.deb
libkrossui4_4.7.2-0r3_i386.deb
libktexteditor4_4.7.2-0r3_i386.deb
libkunitconversion4_4.7.2-0r3_i386.deb
libkutils4_4.7.2-0r3_i386.deb
libnepomuk4_4.7.2-0r3_i386.deb
libnepomukquery4a_4.7.2-0r3_i386.deb
libnepomukutils4_4.7.2-0r3_i386.deb
libplasma3_4.7.2-0r3_i386.deb
libsolid4_4.7.2-0r3_i386.deb
libthreadweaver4_4.7.2-0r3_i386.deb
Next package is kadebase. Again, we find the missing deps with:
mdione@mustang:~/src/system/debian$ sudo apt-get build-dep kdebase
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Build-Depends dependency for kdebase cannot be satisfied because candidate version of package kde-sc-dev-latest can't satisfy version requirements
The message is simlar to the one about shared-desktop-ontologies, but I have
not even the slightest idea which one of the packages above is the one
responsible for it, so I'll just install everything, as most probably they're
build-deps for most of the remaining packages (it's kde5libs, after all):
mdione@mustang:~/src/system/debian$ sudo dpkg -i *.deb
(Reading database ... 218481 files and directories currently installed.)
[...]
After that I try again, but still the same thing. Poking around I find that a package with that name exists (it's the first time I met him, enchanté), so I get the source in the usual way:
mdione@mustang:~/src/system/debian$ apt-get source meta-kde
Reading package lists... Done
Building dependency tree
Reading state information... Done
Need to get 14.0 kB of source archives.
Get:1 http://qt-kde.debian.net/debian/ experimental-snapshots/main meta-kde 5:71~pre15 (dsc) [2,098 B]
Get:2 http://qt-kde.debian.net/debian/ experimental-snapshots/main meta-kde 5:71~pre15 (tar) [11.9 kB]
Fetched 14.0 kB in 0s (49.3 kB/s)
gpgv: Signature made Mon 21 Nov 2011 09:38:12 PM CET using RSA key ID 73A85F31
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./meta-kde_71~pre15.dsc
dpkg-source: info: extracting meta-kde in meta-kde-71~pre15
dpkg-source: info: unpacking meta-kde_71~pre15.tar.gz
And to compile:
mdione@mustang:~/src/system/debian$ ( cd meta-kde-71~pre15 && nice -n 19 dpkg-buildpackage -j3 -b -us -uc )
dpkg-buildpackage: source package meta-kde
dpkg-buildpackage: source version 5:71~pre15
dpkg-buildpackage: source changed by Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
dpkg-buildpackage: host architecture i386
[...]
That generates several packages, but I just install the one I want:
mdione@mustang:~/src/system/debian$ sudo dpkg -i kde-sc-dev-latest_4.7.2+5.71~pre15_all.deb
Selecting previously unselected package kde-sc-dev-latest.
(Reading database ... 218469 files and directories currently installed.)
Unpacking kde-sc-dev-latest (from kde-sc-dev-latest_4.7.2+5.71~pre15_all.deb) ...
Setting up kde-sc-dev-latest (4:4.7.2+5.71~pre15) ...
Now the build-deps again:
mdione@mustang:~/src/system/debian$ sudo apt-get build-dep kdebase
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
libkatepartinterfaces4
The following NEW packages will be installed:
libqimageblitz-dev libtidy-dev
0 upgraded, 2 newly installed, 1 to remove and 8 not upgraded.
Need to get 205 kB of archives.
After this operation, 1,932 kB disk space will be freed.
Do you want to continue [Y/n]?
[...]
You'll probably won't notice (as I didn't) that it has removed a package,
libkatepartinterfaces. This is because in my system I have the old version of
it and there seems to be some kind of conflict somewhere. I just cross my
fingers it won't break much[3].
Now get the sources and compile:
mdione@mustang:~/src/system/debian$ apt-get source kdebase
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'kdebase' packaging is maintained in the 'Git' version control system at:
git://git.debian.org/pkg-kde/kde-sc/kdebase.git
Need to get 2,721 kB of source archives.
Get:1 http://qt-kde.debian.net/debian/ experimental-snapshots/main kdebase 4:4.7.1-0r2 (dsc) [3,217 B]
Get:2 http://qt-kde.debian.net/debian/ experimental-snapshots/main kdebase 4:4.7.1-0r2 (tar) [2,685 kB]
Get:3 http://qt-kde.debian.net/debian/ experimental-snapshots/main kdebase 4:4.7.1-0r2 (diff) [33.1 kB]
Fetched 2,721 kB in 26s (105 kB/s)
gpgv: Signature made Tue 27 Sep 2011 09:43:53 PM CEST using RSA key ID 73A85F31
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./kdebase_4.7.1-0r2.dsc
dpkg-source: info: extracting kdebase in kdebase-4.7.1
dpkg-source: info: unpacking kdebase_4.7.1.orig.tar.bz2
dpkg-source: info: unpacking kdebase_4.7.1-0r2.debian.tar.gz
dpkg-source: info: applying enable_debianabimanager.diff
dpkg-source: info: applying enable_dlrestrictions.diff
mdione@mustang:~/src/system/debian$ ( cd kdebase-4.7.1 && nice -n 19 dpkg-buildpackage -j3 -b -us -uc )
[...]
Installing the resulting packages is another history, as some of them depend on
kde-runtime, so it's better if you compile kde-runtime before[4]. Trying to
install its build-deps, you realize taht you actually need to compile soprano
first.
You get the idea. Now I'll just show the generated packages I installed by hand after each compilation, but only those that suited my needs:
soprano:
mdione@mustang:~/src/system/debian$ sudo dpkg -i \
soprano-daemon_2.7.3+dfsg.1-0r0_i386.deb \
libsoprano4_2.7.3+dfsg.1-0r0_i386.deb \
libsoprano-dev_2.7.3+dfsg.1-0r0_i386.deb
kde-runtime:
mdione@mustang:~/src/system/debian$ sudo dpkg -i \
kdebase-runtime_4.7.2-0r3_all.deb \
khelpcenter4_4.7.2-0r3_i386.deb \
kde-config-phonon-xine_4.7.2-0r3_i386.deb \
kde-runtime-data_4.7.2-0r3_all.deb \
kde-runtime_4.7.2-0r3_i386.deb \
plasma-scriptengine-javascript_4.7.2-0r3_i386.deb
While installing kde-runtime-data I had to remove kdebase-runtime-data:
[...]
Selecting previously unselected package kde-runtime-data.
dpkg: regarding kde-runtime-data_4.7.2-0r3_all.deb containing kde-runtime-data:
kde-runtime-data breaks kdebase-runtime-data (<< 4:4.7.2)
kdebase-runtime-data (version 4:4.6.5-1) is present and installed.
[...]
mdione@mustang:~/src/system/debian$ sudo dpkg --remove kdebase-runtime-data
(Reading database ... 218612 files and directories currently installed.)
Removing kdebase-runtime-data ...
[...]
kdebase:
mdione@mustang:~/src/system/debian$ sudo dpkg -i \
dolphin_4.7.1-0r2_i386.deb \
kdebase-bin_4.7.1-0r2_i386.deb \
kdebase-data_4.7.1-0r2_all.deb \
kdepasswd_4.7.1-0r2_i386.deb \
konq-plugins_4.7.1-0r2_i386.deb \
konqueror_4.7.1-0r2_i386.deb \
konqueror-nsplugins_4.7.1-0r2_i386.deb \
libkonq5abi1_4.7.1-0r2_i386.deb \
libkonq-common_4.7.1-0r2_i386.deb \
plasma-widget-folderview_4.7.1-0r2_i386.deb
While trying to get akonadi I got this error message:
Failed to fetch http://qt-kde.debian.net/debian/pool/main/a/akonadi/akonadi_1.6.2-0r1.dsc Hash Sum mismatch
Checking the MD5, SHA1 and SHA256 checksums and comparing to the ones in the
.dsc file revealed no difference. lisandro told me to use dget instead:
mdione@mustang:~/src/system/debian$ dget http://qt-kde.debian.net/debian/pool/main/a/akonadi/akonadi_1.6.2-0r1.dsc
dget: retrieving http://qt-kde.debian.net/debian/pool/main/a/akonadi/akonadi_1.6.2-0r1.dsc
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2620 100 2620 0 0 6842 0 --:--:-- --:--:-- --:--:-- 8161
dget: using existing akonadi_1.6.2.orig.tar.bz2
dget: using existing akonadi_1.6.2-0r1.debian.tar.gz
akonadi_1.6.2-0r1.dsc:
dscverify: akonadi_1.6.2-0r1.dsc failed signature check:
gpg: Signature made Thu 03 Nov 2011 08:55:52 AM CET using RSA key ID 73A85F31
gpg: Can't check signature: public key not found
Validation FAILED!!
Unpacking by hand:
mdione@mustang:~/src/system/debian$ dpkg-source -x akonadi_1.6.2-0r1.dsc
gpgv: Signature made Thu 03 Nov 2011 08:55:52 AM CET using RSA key ID 73A85F31
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./akonadi_1.6.2-0r1.dsc
dpkg-source: info: extracting akonadi in akonadi-1.6.2
dpkg-source: info: unpacking akonadi_1.6.2.orig.tar.bz2
dpkg-source: info: unpacking akonadi_1.6.2-0r1.debian.tar.gz
dpkg-source: info: applying x11_not_required.diff
akonadi:
mdione@mustang:~/src/system/debian$ sudo dpkg -i \
akonadi-server_1.6.2-0r1_i386.deb \
akonadi-backend-sqlite_1.6.2-0r1_i386.deb \
libakonadi-dev_1.6.2-0r1_i386.deb \
libakonadiprotocolinternals1_1.6.2-0r1_i386.deb
Here I cheated: I really didn't want to spend 10 minutes of iterative attempts to find the minimal set of lib packages to install:
libkdepim:
mdione@mustang:~/src/system/debian$ sudo dpkg -i \
kdepimlibs5-dev_4.7.2-0r1_i386.deb \
kdepimlibs-kio-plugins_4.7.2-0r1_i386.deb \
lib*.deb
kde-wallpapers:
mdione@mustang:~/src/system/debian$ sudo dpkg -i \
kde-wallpapers-default_4.7.2-0r0_all.deb
kde-workspace:
sudo dpkg -i --auto-deconfigure \
systemsettings_4.7.2-0r7_i386.deb \
plasma-desktop_4.7.2-0r7_i386.deb \
plasma-scriptengine-python_4.7.2-0r7_all.deb \
plasma-widgets-workspace_4.7.2-0r7_i386.deb \
plasma-dataengines-workspace_4.7.2-0r7_i386.deb \
klipper_4.7.2-0r7_i386.deb \
kdm_4.7.2-0r7_i386.deb \
kde-workspace-bin_4.7.2-0r7_i386.deb \
kde-workspace-data_4.7.2-0r7_all.deb \
kde-window-manager_4.7.2-0r7_i386.deb \
kdebase-workspace_4.7.2-0r7_all.deb \
kdebase-workspace-bin_4.7.2-0r7_all.deb \
libkworkspace4_4.7.2-0r7_i386.deb \
kde-workspace-kgreet-plugins_4.7.2-0r7_i386.deb \
kde-style-oxygen_4.7.2-0r7_i386.deb \
libkdecorations4_4.7.2-0r7_i386.deb \
libkephal4abi1_4.7.2-0r7_i386.deb \
libkwineffects1abi2_4.7.2-0r7_i386.deb \
libkworkspace4_4.7.2-0r7_i386.deb \
libplasmagenericshell4_4.7.2-0r7_i386.deb \
libtaskmanager4abi2_4.7.2-0r7_i386.deb \
libplasmaclock4abi2_4.7.2-0r7_i386.deb \
libksgrd4_4.7.2-0r7_i386.deb \
libplasma-geolocation-interface4_4.7.2-0r7_i386.deb \
libsolidcontrol4abi2_4.7.2-0r7_i386.deb \
libprocesscore4abi1_4.7.2-0r7_i386.deb \
libweather-ion6_4.7.2-0r7_i386.deb \
libkscreensaver5_4.7.2-0r7_i386.deb \
libprocessui4a_4.7.2-0r7_i386.deb \
libsolidcontrolifaces4abi2_4.7.2-0r7_i386.deb \
kde-workspace_4.7.2-0r7_all.deb \
ksysguard_4.7.2-0r7_i386.deb \
freespacenotifier_4.7.2-0r7_i386.deb \
libksignalplotter4_4.7.2-0r7_i386.deb \
ksysguardd_4.7.2-0r7_i386.deb
I'll just finish this post here. The rest is just more of the same. The final list of packages a compile in right order is:
kde4libs
meta-kde
soprano
kde-runtime
kdebase
akonadi
prison
kdepimlibs
kde-wallpapers
kde-workspace
All in all, this took some 10 hours of finding deps, compiling and installing,
and 6.4 GiB between original .tar.gz files, compilation dirs and generated
packages.
[1] It's nice that I don't need to compile libqt4*, those take ages[5].
[2] Later lisandro from qkd pointed me to the dependency graph
that confirms my guess.
[3] I did all this while running a KDE SC 4.6.5 session, and even writing this
post in kate. Thanks to Linux and Debian not much actually broke, I only lost
the ability to browse with konqueror after I installed the first batch of
packages because KIO could not instantiate an HTTP/HTTPS ioslave anymore.
[4] Note that the dependency graph two notes above is actually a build dependency graph.
[5] Not that this compilation was fast. kdelibs without parallelism took some
3h and kdepimlibs and kde-workspace are two huge beasts.
debian kde
Yes, a little bit late, but my blog was brokenito. Unluckly I missed the release party at FOSDEM and it seems there were none in France. I hope the guys back in my country will have fun tonight. Anybody else, just enjoy this incredible relase!
Edit/Update: so brokenito that it took me a while to gather the intentions to fix it :| At the end it was a small thing about wich I'll write about later.
kde
I've been compiling KDE SC trunk on and off for several years now. I used
to compile everything with my own scripts[1], but for a solid couple of
years now I've been using kdesvn-build: it
works without problems, is maintained better and maintaining my own scripts
was not fun anoymore.
Without problems until a couple of weeks ago. KDE's Qt (a copy of Qt's code
that has patches by KDE developers) has been moved to
gitorious (it only makes
sense, given that Qt's code is not in gitorious as well) and somehow git
and kdesvn don't like each other and you end up with a error like this:
fatal: The remote end hung up unexpectedly
Yeah, that kind of fatal. Luckily I got so frustrated that I tried to rest reading a bit of KDE planet, and there it was, the solution, in a post by Hans Chen, in the section 'Can’t checkout qt-copy'. I will just add that after you check out (or update) by hand, you simply run:
$ kdesvn-build --no-svn qt-copy
and that's it.
kde
[1] I still kinda do: some support things like PyQt and more I have to
compile with my own scripts.
No somos muchos en Córdoba. Tal vez uno 10, tal vez menos. Pero tenemos un objetivo común: hacer KDE, y hacerlo una mejor plataforma para nosotros, y para todo el mundo. Este objetivo tan amplio incluye desde desarrollar aplicaciones o simples features, arreglar bugs, hasta reportarlos, difundir un poco su potencia y lindura (no me pidan redacción a esta hora de la noche).
Por eso nos juntamos esta noche a tomar unas cervezas y ver en qué parte de este objetivo quiere estar cada uno, y hasta dónde cree llegar hoy día y slogan-de-una-empresa-gigantesca-de-software. Estuvimos Emanuel emanuel Sartori, Franco frapell Pellegrini, Manuel elpreto Ramírez y yo. Tomamos unos cafecitos, comimos unos tostaditos y charlamos.
Cosas concretas aún no tenemos; somos pocos, y si bien eso parece simplificar la organización, hace que sea difícil que pensemos en exactamente lo mismo. Lo que sí sabemos que ésta no es la última reunión, y que en las siguientes vamos a estar viendo de hacer lo que cada uno quiere aprovechando lo que el otro sabe. Esto puede parecer poco, pero la idea es fortalecernos con el tiempo.
Aún no hay fecha fija; queremos que sea la semana que viene, pero empiezan las clases y eso significa cambios de horarios para muchos. Ya avisaremos con anticipación en la lista kde-ar.
kde kde-ar
When I arrived to pyCamp (I'm at pyCamp!) I was fighting with a battery applet bug. When the battery is almost full the applet got 'confused' and thought the battery just finished charging, and if it where showing the remaining time, it switched to charge percentage, which actually showed that it wasn't fully charged, but somewhere near 96% or so (this is wrong assuming the battery can fully charge up to 100%, as my 6 month old Dell battery). The problem was really that my code was checking if the remaining time were 0 or not. So I started from there down.
Down was it indeed. Seems like from time to time, when the bettry is
filling up, one can't ask hal about the remaining time. Using qdbus to
ask hal directly we get this answer:
Error: org.freedesktop.Hal.NoSuchProperty
No property battery.remaining_time on device
This situation is not stable; sometimes I get the value I want. Not only that, when the battery is full, the values get horrobly wrong. Here's some samples (values are seconds since epoch and remaining time in seconds):
1237677446 1134
1237677746 261
1237677806 235
1237677866 313
1237677927 190
# at some moment in this gap the battery is fully charged
1237678167 188836
1237678227 152509
1237678287 112581
So I changed the algorithm to a more correct one; that is, ask if the battery is charging or discharging or none of those (in that case the battery is full) and show the time or the percentage accordingly. This works, except that it doesn't.
The problem has shifted to another place. Now I don't get the signal
when is_chaging goes false. With lshal -m I can see the event:
11:48:46.823: computer_power_supply_battery_BAT0 property battery.rechargeable.is_charging = false
but I keep getting "Charging" from this code:
battery_data.value()["State"].toString()
where battery is a powermanagement data engine. Interesting enough, if
I close the applet and load it again (as anyone debugging plasmoids,
I'm using plasmoidviewer), that line returns the correct value of
"NoCharge", which is what's spected.
I will try to file a bug against the data engine, or maybe Solid, and wait for the fix before comitting the fix to this bug.
Update: it ended being a bug in Solid, after all. I posted a fix.
kde
Back in the days when the company I worked for announced that it would completely shut down in less than 2 months, I felt somewhat free. You see, around that time I was already thinking about what I wanted to be my professional future and that didn't match what I was doing. As I said in a previous post, I really liked that company, so deciding what to do was really hard. So when the shutdown was announced there was no other option: I had to pursue my dreams.
What drems were those? To work in free software. Not only with free software, as I already did in that job (I was the sysadmin), but coding, creating, fixing, twisting free software. Which prject? KDE, of course. It's one of the most influencing free software for me, one of the ones I most admire, and one of the ones I most closely followed since I knew it (I think the only other one is Debian).
I followed the KDE1.x series upgrading from on version to another of Mandriva, and when KDE2.x started appearing in CVS I already was riding Debian. Compiling KDE once a week was a trademark of mine in my local free software group, everybody knew me for being a KDE fan and all. Later came KDE3.x and I kept compiling, until it was so mature that it didn't gave me the kicks anymore. Also I was already getting some serious works, so I couldn't afford to loose my desktop because I had a compile error or everything just crashed (not that it happened very often, I just couldn't risk it), like the problem I had just before giving a presentation about KDE more than 5 years ago.
And almost never in all those years (8, maybe? no, a little over 9 years! I made my firt post to [kde-devel] in Nov 1999!) I added a single line of code. I remember hacking a couple of features in KDE2.something, and even mentioned them in [kde-devel], but never pushed them enough, I guess. Until last month.
I joined #kde-devel, just to hang around, on November 2008. On the
8th, DanielW mentioned he had problem with a EINTR error. He though it
was Soprano, but after 40 minutes of digging I found the culprit, and 3
more hours until I was really sure and developed a solution, which was
not very clean, and 2 more hours of hacking until I was pleased with the
patch and DanielW said it was fixed. Later, in the next day, DanielW and
me decided to file the patch. On Nov 10th he added the patch to the
patches dir in qt-copy and my first ever contibution to KDE, and no
less that fixing QT! I just couldn't stop doing backflips in my office
(well, not actually doing them, I'm not in that good shape, just felt
like it)!
Unluckly that patch lacked a return somewhere, so the next day half of
the KDE developers were left with no DNS resolution (or any network, for
that matter). aseigo found that my patch was the culprit and disabled
it, so all the happyness I still had about that patch turned into
embarrasment. Later that day I wrote a much better patch that not only
fixed that, but also refactored some code.
Fortunately that didn't make me dissapear. I kept helping here and there, specially in Plasma, more specifically in those plasmoids I already used and that already were nagging me to fix this or code that feature. Sebastian Kügler help me twice with my patches, once for the digital clock, making it properly draw the date and/or timezone bellow in horizontal panels, and once for the battery plasmoid, making it show the remaining time until either the battery runs out or the battery gets fully recharged, depending on the AC was plugged or not; the latter was a feature I though of.
So, what happened is that he told me to apply for a svn account, which I almost promptly did (there was a hiatus forced by my vacations; not that I missed hacking :) and today I completed hopping all the hops and got my new shiny svn account. I spent the rest of the evening compiling KDE4 again and writing this post.
Why did I wrtite it? Not only because I'm really proud of it, but because I wanted to stress two things: that the KDE community is really welcoming when you express your intentions to help, and that getting involved into it is really simple: you just need to want it to happen and to actually start doing it. The latter was something I never realized until I made it happen.
But this is just the begining. As I said before I would really like to get paid to help in KDE. The job offer I was eyeing has just been covered, but there will be plenty of opportunities, and I'm still a newbie. Now I'll just keep helping in whatever I like to, and let's see what the future brings. And sebas, I really appreciate your help.
kde
Acaba de terminar la edición 2009 de pyCamp. Esta vez vinieron cerca de 40 personas, lo cual hizo que hubiera más proyectos dando vueltas y mas gente en los proyectos. Fueron 4 días fantásticos llenos de ideas, código, reuniones, juegos, algo de alcohol y mucho mas. A diferencia del año pasado, esta vez vienieron algunos audaces con familia, no sé cómo les habrá ido.
Este año estuve mucho mas enganchado. El primer día hicimos un schedule
cuasi definitivo y en el momento se me ocurrió hacer cosas con Fuse y
Python. Cuando tocó el slot, di una charla de cómo funciona Fuse y
algunas puntas de cómo implementar file systems con él. Al final del
evento yo había terminado el wrapper que venía haciendo hace unas
semanas (ok, ok, falta statvfs) y perrito
se hizo un filesystem para acceder los iPod. Lucio me hizo prometer ver
cómo combinar Fuse async con Twisted. También le estuve explicando
ctypes al Polako, con lo que creo que terminé de entender el módulo y
me ayudó a entender algunas cosas que había hecho para el wrapper.
También estuve en el diseño y (re)implementación del bot de irc. En
apenas 2 días y medio ya tenemos el core y unos cuantos plugins, y hay
varios desarrolladores haciendo mas. Sólo faltan implementar pedezos de
infraestructura, sobre todo la parte de bases de datos, pero me veo
metiendo un par de plugins mas y ponerla en producción muy muy pronto
(en relaidad perrito le va a dar hosting). También fue una oportunidad
para (re)aprender Twisted, y enterarse de cosas como que no podés hacer
asincrónico un proceso
sincrónico,
y de aprender de boca de Guillo cómo usar bzr para laburar entre los 6
u 8 que metíamos código.
También estuve renegando los dos primeros días con el applet de batería de KDE4. Terminé encontrando (un bug en Solid)[https://bugs.kde.org/show_bug.cgi?id=187600] y aprendiendo detalles sobre Hal, D-Bus, algunos bastante oscuros y bizarros. Al mismo tiempo estuve viendo cómo se comportan los algoritmos de recarga de batería y de estimación de los tiempos de descarga y de descarga. Resulta que cuando está terminando de cargar se empieza a estirar el tiempo y los últimos 5 minutos pueden termiar siendo 20.
Estuvo genial poder conocer más gente y de volver a ver algunas caras conocidas (hace rato que no estaba en un evento de alguna comunidad). Entre los nuevos encontré a gente de Kde-ar como Leo u otros jugando con PyQt. Me encantó volver a sentir que programaba, ver unos proyectos arrancar y otros continuar a velocidades de la hostia, con features apareciendo como hongos y bugs desapareciendo como... bueno, no es una buena fecha para hablar de desapariciones :|
El último sprint estuvo genial; monitoreen la lista y/o el canal para enterarse de los resultados ;-)
Estoy organizado un code jam en Córdoba y Lisandro está organizando una en Bahía Blanca. La idea es que nos juntemos a laburar un poco en KDE, aprendiendo y haciendo o features o cerrando bugs o lo que sea. En función de eso estaría piola que cada uno ya lleve un kde trunk compiladito, al menos la parte que les interese. Este post apunta a explicar cómo hacerlo. Casi toda la info la saqué en su momento de techbase y/o preguntando en IRC, listas de correo y hasta en DebConf.
Veamos cómo se organiza el código de KDE. Éste reside en un repositorio subversion que tiene dos formas de acceso: uno autenticado por ssh para los desarrolladores que tienen cuenta y uno anónimo que es de sólo lectura. Los que ya tienen cuenta ya deberían saber usarlo y hasta cómo compilar, así que para ellos este post no sirve. Cuando mencioné a trunk en el párrafo anterior me refería a la rama principal de este repo.
A su vez el código está diseminado en distintos módulos: kdesupport, kdelibs, kdepimlibs, kdebase, etc. Estos módulos y otras porciones de código que andan dando vueltas están en un árbol:
anonsvn.kde.org/home/kde/
+ branches
| + ...
+ tags
| + ...
+ trunk
+ extragear
| + ...
+ kdereview
| + ...
+ playground
| + ...
+ kdesupport
| + ...
+ qt-copy
+ KDE
+ kdebase
+ kdegraphics
+ kdelibs
+ kdemultimedia
+ kdenetwork
+ kdepim
+ kdepimlibs
+ ...
Pueden ver este mismo árbol por web. La rama
KDE es la que tiene el código de los distintos módulos de KDE.
kdesupport contiene un montón de software que no es de KDE, pero que
es necesario para correrlo. Allí van a encontrar las versiones adecuadas
de los mismos, y por lo general es muy aconsejable compilarlo. qt-copy
es una copia del código de Qt a su última versión, con el agregado de
varios parches. kdereview son proyectos que están siendo considerados
para la inclusión en KDE. playground está llenos de proyectos a medias
o casi completos, pero que no tienen pinta de estar listos para
revisión. Los nuevos proyectos normalmente nacen y/o crecen allí. Sin
embargo, mucho de lo que hay ahí funciona. Por último, extragear
contiene aplicaciones KDE que no se ajustan al ciclo de desarrollo de
KDE (actualemnte, un release menor cada 6 meses). En este directorio
podemos encontrar aplicaciones grosas como el amarok, el k3b o el
digikam.
Una instalación mínima de KDE consta de los módulos qt-copy,
kdesupport, kdelibs, kdepimlibs y kdebase. Compilarlos uno por
uno es un garrón, por lo que vamos a usar
kdesvn-build, un script que lo
automatiza todo. Pero antes, las dependencias.
Por un lado necesitamos las herramientas de configuración y de
compiloación. Éstas son cmake y g++ (en realidad es cualquier
compilador de C++, pero para hacerla fácil me voy a limitar a g++.
También me voy a limitar a distros basadas en Debian, como *buntu, sólo
porque es lo que más conozco.). El cmake de Debian Sid es el 2.6.0 y
desde hace un rato KDE necesita el 2.6.2 [ Update: 2.6.2 acaba de
entrar en Sid ], así que capaz haya que bajar y compilar ése también.
Si lo hacen, les aconsejo que corran el configure con la opción
--prefix=/usr/local o mejor, apuntando a algún lado de su propio home.
En mi caso, instalé todo en ~/local/soft/kde4.
Luego están las dependencias de cada módulo per se. La siguiente es una tabla que he ido creando con el tiempo y que trata de ser tan completa como pude, pero seguro se me ha escapado más de un paquete. Los nombres corresponden a los de los paquetes en Debian Sid, y que deben ser muy similares a los de los *buntu. En cada módulo encontramos dos grupos de dependencias: las estrictamente necesarias, sin las cuales el módulo no compila, seguido de una línea en blanco, seguida por otra lista con las dependencias opcionales. Estas dependencias hacen que el módulo ofrezca más funcionalidad. Yo puse las que me interesan; después veremos cómo ver qué otras son posibles.
cmake:
~~~~~~
libncurses5-dev
qt-copy:
~~~~~~~~
libssl-dev
libpng12-dev
zlib1g-dev
libsqlite3-dev
libxinerama-dev
libdbus-1-dev
libjpeg62-dev
libsm-dev
kdesupport:
~~~~~~~~~~~
cmake
mysql
libclucene-dev
doxygen
dotty
librdf0-dev
libbz2-dev
libxml2-dev
libexiv2-dev
libgstreamer0.10-dev
libgstreamer-plugins-base0.10-dev
libgl1-mesa-dev
libgamin-dev
sun-java6-jdk
kdelibs:
~~~~~~~~
libsm-dev
libpcre3-dev
libgif-dev
libxrender-dev
libglu1-mesa-dev
libopenexr-dev
libenchant-dev
libgamin-dev
kdepimlibs
~~~~~~~~~~
libical-dev
libgpg-error-dev
libgpgme11-dev
libboost-dev
libsasl2-dev
kdebase
~~~~~~~
libfontconfig1-dev
libxt-dev
libsensors4-dev
libxklavier12-dev
libusb-1.0-0-dev
libxcomposite-dev
libxdamage-dev
libxtst-dev
libusb++-dev
libasound2-dev
libxss-dev
libxft-dev
libxkbfile-dev
kdemultimedia
~~~~~~~~~~~~~
libvorbis-dev
libcdparanoia0-dev
libxine-dev
kdegraphics
~~~~~~~~~~~
liblcms1-dev
libgphoto2-2-dev
libxxf86vm-dev
libimlib2-dev
kdepim
~~~~~~
libopensync0-dev
libpisock-dev
extragear
~~~~~~~~~
libjasper-dev
kdenetwork
~~~~~~~~~~
libavahi-compat-libdnssd-dev
Muchas, eh? Y éstos son sólo algunos de los módulos.
Ah! Antes de que nos mandemos a compilar, tenemos que preparar tres
cosas: un directorio donde van a ir las fuentes, otro donde vamos a
compilar y otro donde lo vamos a instalar. Yo personalmente prefiero
mantener todo a nivel de usuario, por lo que las fuentes las pongo en
~/src/system/kde4, compilo en build dentro de ese directorio y lo
instalo en ~/local/soft/kde4. El primero en realidad puede ser
cualquier directorio, realmente no es relevante, salvo por el espacio
que ocupa. Las fuentes de cada módulo (en MiB):
316 extragear[*]
549 kdebase
42 kdegraphics
185 kdelibs
18 kdemultimedia
106 kdenetwork
156 kdepim
41 kdepimlibs
10 kdereview
160 kdesupport
81 playground[*]
570 qt-copy
Los marcados con [*] no están completos, sino que elegí algunas cosas que me interesaban. Los directorios donde compilamos, también en MiB:
2146 build/extragear
1152 build/kdebase
253 build/kdegraphics
971 build/kdelibs
99 build/kdemultimedia
570 build/kdenetwork
1045 build/kdepim
194 build/kdepimlibs
33 build/kdereview
623 build/kdesupport
264 build/playground
1441 build/qt-copy
El último directorio sí me parece relevante; si no les gusta instalarlo
en su home, les aconsejo que lo hagan en /opt o al menos en
/usr/local, de forma de no destruir lo que haya instalado sus
sistemas.
Ok, suficiente introducción, vamos a los bifes. Bajamos kdesvn-build
en el directorio de compilación, lo descomprimimos y lo configuramos. La
configuración pasa por darle algunos detalles de qué, cómo y dónde
compilar e instalar. Pueden tomar del kdesvn-buildrc-sample que viene
incluido o tomar del que estoy usando
yo.
Revísenlo bien; la mayoría del trabajo es configurar la sección
global, que es la que está al principio del archivo; está bastante
comentada. Vean en particular source-dir, build-dir, kdedir
(donde va a ser instalado), qtdir (donde vamos a instalar
qt-copy; yo lo puse en el mismo directorio que todo kde4),
svn-server (ojo que mi copia apunta al servicio autenticado, pero
tiene el anónimo comentado), cmake-options, y lo que mas o menos les
pinte. Ponemos este archivo en ~/.kdesvn-buildrc y ya casi estamos.
Otra cosa que hay que hacer es poner todo un conjunto de variables de
entorno a tono. Yo robé mucho de un script en
techbase.
A diferencia de todos los tutoriales en techbase, en vez de crear todo
un usuario para hacer toda la bola, yo simplemente puse todas esas
variables en un
script que
podía cargar a piaccere. Allí tambié puse que el directorio donde KDE4
va a guardar la configuración es .kde4-dev, así no me pisa la
configuración de KDE3. también péguenle una revisada así pega con lo que
tienen puesto en otros lados.
Bueno, ya estamos listos. Levantamos las variables de entorno y lanzamos el script de compilación:
$ source environ.sh
$ ./kdesvn-build-1.7.1/kdesvn-build --reconfigure --verbose --color
¡Eso es todo! El script saca los módulos unos a uno de svn; a medida que los tiene bajado los va compilando e instalando en paralelo. La primera vez tarda muchisimo, sobre todo si configuraron muchos módulos. Recomiendo compilar primero lo mínimo indispensable, dejarlo compilado de noche, y luego ir compilando de a pedacitos.
El script va dejando en log/latest logs de la compilación de cada
módulo. Allí podemos encontrar la salida del proceso de configuración,
donde veremos qué dependencias encontró y cuáles faltan. Si hay errores
deja un error.log con la falla.
Para ejecutar la bestia, la cosa no se complica mucho mas. Yo no sé bien cómo hacer para que me lo tome el DM de turno (KDM, GDM, el que sea), por lo que lo lanzo a mano desde una terminal de texto:
$ source ~/src/system/kde4/environ.sh
$ xinit /home/mdione/local/soft/kde4/bin/startkde
También podemos lanzarlo en un Xephir, que es como un X dentro de X. Eso
sí, no le pidan OpenGL (necdesario para los efectos de escritorio).
Abrimos un konsole o la terminal que prefieran y:
$ Xephyr :1 -screen 1280x800 -ac -extension GLX
$ export DISPLAY=:1
$ ~/local/soft/kde4/bin/startkde
Una forma truchísima mal es entrar en una sesión failsafe (*buntu le
llama 'Terminal a prueba de fallos' últimamente). Esto nos da un X
pelado con una xterm y ni siquiera un Window Manager. En la terminal
entramos levantamos el entorno y lanzamos KDE4:
$ source ~/src/system/kde4/environ.sh
$ ~/local/soft/kde4/bin/startkde
Voilá. Sólo asegúrensé no cerrar nunca esa xterm, sino se les cierra todo sin preguntar nada.
Un detalle es que el sistema queda solamente en inglés. Ya me voy a sentar a ver cómo meter los módulos de traducción al español.
Ok, ya estoy cansadísimo y esto es larguísimo. Cualquier duda la seguimos en el thread en kde-ar y lo vamos puliendo.
kde