Feb 25

Since random people poke us in IRC about the same questions, I decided to redistribute the last meeting’s summary in my blog.

0) Elect new lead

Wheee I am the new Leader! I am the head, the boss, the godfather, the lord of the rings, the bourne identity (joke stolen from The IT Crowd). I can’t see how that affects anything though, in my opinion team leaders are useless positions, the council is enough.

1) Status regarding hal

Since KDE SC 4.6 is out, we don’t need it anymore. As soon as 4.6 gets stable, hal can die

2) Should we try to form a “stable KDE devs” team? Meaning just call for volunteers on the gentoo-dev mailing list?

dilfridge stated that since most of the kde team members use ~arch, stable seems to lag behind. The problem is very obvious now, mainly because we haven’t stabilized 4.4. The problem will go away as soon as 4.6 gets stable though. Apart from main kde, the misc apps are also slow in stabilization. We expect users to request for stabilizations in bugzilla.

3) kde-git/eclasses migration and status, move kdepim 4.6 beta in tree masked

reavertm, Sput, and scarabeus did a major cleanup in our eclasses and added git support to eclasses and ebuilds. In order to migrate the eclasses to tree we will need to get git-2.eclass in tree first (it is now in kde overlay as well). ETA: not less than a month. As a side note, we decided to remove koffice-specific codeout of the eclasses.

4) Shall we drop useflags kdeenablefinal and/or kdeprefix to simplify code?

First of all, both useflags are masked. We agreed to keep kdeenablefinal, since it is an upstream feature. About kdeprefix, the problem is that bindings are not prefixed, and a possible fix (proposed by reavertm) would be to slot sip. tampakrap said he’ll work on this, and bring the topic back in next meeting.

5) Dropping of semantic-desktop useflag with guide update (mostly even kdebase needs it on now)

This entry is invalid, semantic-desktop is not needed by kdebase. The problem is in our ebuilds (plasma-workspace is semi broken, kdeplasma-addons is completely broken). We have open bugs for those, the problem is clearly in our side.

6) Making +consolekit and +policikit or removing the useflags as whole (non working stuff run-as is annoying)

scarabeus and dilfridge are in favour of dropping them, since it caused a lot of trouble debugging various user reports. reavertm prefers adding it to IUSE defaults. No consensus was succeeded, the topic will be continued in the gentoo-desktop mailing list (Here is the topic).

7) HT/overlay/bugzie access policy

Since we don’t have a clear list of who is an HT and who isn’t, we decided to compile a list, and state what priviledges the HT has. (HT = Herd Tester). Some people don’t have time/motivation to complete their ebuild quiz, thus we’ll have two groups of people: * full HTs (overlay access, editbugs, access to ktown, IRC cloak) * overlay commiters We decided to drop the KDE HT Lead title, seems rather useless. (As a side note, we always welcome new members, either for HT or for full developer status, feel free to contact me).

8 ) LiveDVD issues

LiveDVD comes with KDE SC 4.6 as default DE, and we called likewhoa (the guy behind it) to report any issues. He said that everything seems to be fine, but random users wanted the cool gentoo graphics to be applied to in-tree ebuilds as well. The KDE Team is willing to do that, likewhoa said he’ll provide us some artwork and we’ll discuss again the USE=”branding” issue.

9) documentation status

There has been a major improvement in the guide, added some 4.6 specific tips and troubleshooting parts, we need to add a hal->udev migration guide (there is a draft in my devspace, based on this forum post), and migrate some texts that are in kde overlay to guidexml.

10 & 11) 4.6 (and misc apps with 4.6) status / Early discussion about 4.6 stabilization

KDE SC 4.6 is going fine, we all agreed that 4.6.1 could be a good candidate, we’ll discuss it again after its release. About a 4.6 KDEPIM version, no idea yet, we’ll have to wait on upstream moves first. Most misc apps seem to be fine with 4.6 as well.

*) Open floor

One major issue is digikam, it comes with lots of bundled libraries, which violates the Gentoo QA Policy. We heard that Debian has same thoughts on the matter, we’ll have to bring them to table. Relevant bug report: https://bugs.kde.org/show_bug.cgi?id=265328

Desktop Summit! We were invited last year to Akademy to give a talk about Gentoo-KDE, noone made it. Some of us expressed interest for this year’s event, which combines GUADEC and Akademy. Also, some of our gnomies may be there, which is a perfect opportunity for some in-person trolling.

Gentoo KDE team meeting Summary and Log

Feb 01

I’m pleased to announce the availability of KDE SC 4.6.0 to another distro. You will find it in main portage tree, though currently hardmasked until bug 353129. Every major update of KDE gets inserted as hardmasked in Gentoo, as it lacks some keywords for new packages (all but amd64/x86). So, currently at least users of amd64/x86 can safely unmask and use it. I have updated the KDE guide, it now explains in detail how to install KDE SC 4.6.0 and the KDEPIM options. There is no ETA for the unmasking, since it doesn’t depend on us. As for a stabilization, KDE SC 4.6.1 is a good candidate, but we’ll have an official decision after its release and a regular meeting.

In case you find a bug regarding the installation, please take a look first at the Hints and Troubleshooting section and the Gentoo KDE buglist. Feel free to open new bugs or talk to us in #gentoo-kde (Freenode).

As a side note, KDE SC 4.6 doesn’t need hal any more. Samuli wrote a nice guide to replace it with udev and friends.

Enjoy :)

PS: A small graph that shows our recent activity

=-=-=-=-=
Powered by Blogilo

Mar 05

In the last KDE and Qt meetings, there have been many and important changes, so I decided to blog about them to keep users up-to-date. The summaries and logs are available in each project’s site (http://kde.gentoo.org and http://qt.gentoo.org). Both projects have regular meetings, every third Thursday of the month (unless announced otherwise), and very often they have a common one. The channel that hosts us is #gentoo-meetings in Freenode, and everyone is welcome to join us. I will mention only the most remarkable issues that were discussed/decided, which seem to be a lot:

Qt meeting, 19 February 2010

This was delayed one day, so I missed it. I really hate it when I miss Gentoo meetings, as every time they are very fun and challenging, and I like very much interacting with so many Gentoo developers and contributors at the same time. Before proceeding, I’d like to point out that the Qt Project was very recently founded as a separate project, because the Qt Team (sub-herd of the KDE Project) has grown too much and had too many non-KDE issues. The Qt members are doing an awesome work. And here are some of the important issues:

  1. We now have an "unofficial" channel in IRC, and a new shiny Qt Subdomain! So from now on you can find us in #gentoo-qt on Freenode, and our documentation resides in http://qt.gentoo.org (thanks to Robin (robbat2) for setting that up). Of course we will still be available in #gentoo-kde or #gentoo-desktop.
  2. Raster USE flag is going to be on by default. Μάρκος (hwoarang) already blogged about this asking for testing.
  3. Qt 3 has been masked for removal from the tree, along with all Qt 3 packages and the qt3 USE flag. The only blocker for this task was MythTV, which now has a stable Qt 4 replacement in Gentoo. Also, Ben (yngwin) informed the kde-sunset maintainers about this, but so far I didn’t see anyone committing those apps there, so if you want to do it (or do general qt3 and kde3 work), consult this document. (Reminder: kde-sunset is user-maintained overlay, anyone interested can ask for access there, so if you are still interested in Qt 3 and/or KDE 3 packages, please ask for commit access instead of complaining to the Gentoo developers).

KDE meeting, 25 February 2010

This was delayed one week, which was a request by me, so it won’t be during my exams. There hasn’t been a KDE meeting in January, so there were plenty of topics to discuss. I was also the moderator of this one, which made it double fun. In most of the issues there has been some progress, so let’s begin:

  1. We now have a new leader, Tomáš Chvátal aka scarabeus. After a year of Jorge Manuel B.S. Vicetto’s (jmbsvicetto) absolutely perfect leadership, we had the annual elections, were scarabeus was voted by pretty much everyone. He is admittedly very skilled and very active in Gentoo community in general, as a member of QA, X11 and KDE Teams and also a recent council member. I’d also like to give props to my former "boss" Jorge, especially for taking over that old nasty mysql/amarok issue and creating the libmysqld.so patch.
  2. KDE SC 4.3.5 is stable in tree now, and the newly released KDE SC 4.4.1 is available in tree as testing. There have been many problems with 4.4.0 (mostly crashes), so it won’t be a stable candidate for sure. We’ll see how 4.4.1 goes and accordingly decide if this is going to be a stable candidate, or wait for 4.4.2.
  3. Amarok and MySQL 5.1 suffer from the same old libmysqld.so issue. Thus, we strongly recommend to remove the embedded USE flag from both Amarok and MySQL. In fact, it is not anymore enabled by default in the ebuilds. As a side note about MySQL, Akonadi seems to break in some machines with >MySQL-5.1.42. The problem is known to upstream developers, and there have been some workarounds in KDE forum, but I didn’t have time to test any of them yet.
  4. KDEPIM in trunk KDE is currently broken (really just kmail). This is because kmail’s mail storage is being ported to akonadi, so IMAP (I don’t know about the other protocols for sure) doesn’t work at all at the moment. Sput (Quassel developer) proposed to use the enterprise KDEPIM branch, which is supposed to work, as it is being paid by companies. I sent an email asking for help in gentoo-desktop mailing list, with no answers so far. Please see the thread archive (available here) for more info. I would also like to inform you that the KDE Team decided not to provide the usual trunk snapshots until version 4.4.70 (which is going to be the first alphas), because of this KDEPIM issue.
  5. KOffice 2.1.1 is released a month ago, but it is not available to users yet. Actually, it is in tree hardmasked, as it needs a close depedency checking in ebuilds. I was held responsible for this, and I hope till the weekend it will be done, if I get enough help from scarabeus which was the former KOffice ebuilds maintainer, or by anyone else from the KDE Team (there are plenty of people in the Team, I’m sure I’ll find someone to help me). By the way, this is my only KDE todo thing left.
  6. KNetworkManager is now in tree, but also hardmasked. This was in upstream’s kdereview branch, which contains packages that stay there for review by the developers for wider testing, before they move to their final KDE module or extragear branch (take a look at KDE’s SVN repo to get the picture). It was supposed to be released along with KDE 4.4, but it didn’t make it. So, I created a snapshot of the current SVN repository, which seems to have many problems, like crashes, missing features etc. So I guess it will remain hardmasked for a while, and I will continue to update the snapshot once every two weeks.
  7. The KDE Documentation is also one of my playgrounds. I recently updated the guide, and with a quick look I did the following: closed all three bugs regarding the KDE Installation Guide, added more items in Hints and Troubleshooting section, completely removed the kdeprefix reference, replaced the snapshots installation guide with a note that we won’t provide them for now, and done a bunch of small fixes (mostly version corrections and typos).
  8. I raised the issue of kde-meta (and accordingly @kde-* sets) not including all KDE modules. It currently excludes the developer-specific modules like KDESDK and KDEbindings (although it does contain KDEWebDev), and proposed either to include them all in kde-meta or to introduce a developer or sdk USE flag in kde-meta. Some developers were opposed on this, proposing to have a new meta package, like kdefull-meta, an idea which I actually hated. Our final word on this was to open a new discussion thread in gentoo-desktop mailing list, which I did, and review the issue in the next meeting.
  9. Finally, I’d like the attention of everybody here, as the following issue is very very important. In a previous meeting we discussed the split of the desktop profile in gnome/ and kde/ subprofiles. We raised the idea in gentoo-dev mailing list for review, and we had a positive feedback in general. Other DE’s refused to have a special subprofile, so they will stick to the basic desktop profile. What this means is that the desktop profile from now on will not contain GNOME or KDE-specific USE flags, which are transfered to the according subprofile. For users that want both DE’s (or just both DE-specific USE flags) can enable them manually in their make.conf (they are not many after all). The major advantage from the user-side of view is that many unwanted dependencies get stripped off automatically, and from the developer-side of view is that from now on we’ll have a more separate approach when packaging. The patches are ready and sent for review in gentoo-dev mailing list. Currently the result can be seen in the kde-crazy overlay, and here you can see the relevant thread. A news item will also be made before committing, and I hope that the final move will happen next week. I’d like to thank Maciej (reavertm), Ben (yngwin) and Samuli (ssuominen) for their precious help on this. (P.S. This is one of the very few moments that I felt I did some Gentoo development instead of KDE packaging, if you know what I mean :) )

Qt Team meeting Log and Summary
KDE Team meeting Log and Summary

=-=-=-=-=
Powered by Blogilo

Jan 05

Hello, first actual post in linux planets :)

Introduction

Recently I wanted to have an svn+ssh installation, without giving ssh access to the users. The procedure is very simple, and it doesn’t diverge much from the typical subversion configuration. This is going to be the first topic I’m going to expand. The second one is a Gorg installation, that takes advantage of it, and helps translation teams. Let me clear this out, by telling you the whole story of it:

Some Greek geeks recently gathered and wanted to create a greek gentoo community. So, the very first thing I wanted to do is to have better communication between translators, but also give a motivation to some people to contribute to the translations, even with just reviewing. The current model does not allow it that much. There is only one or two people that have CVS access to translations (for greek there is none at the moment). So, if there are other people also translating the documentation, they have to send patches, which has many drawbacks: What if two or more people where working at the same thing? What if someone finds a simple typo? Why should he create a patch? If a bunch of people could just correct those kind of small mistakes in documentations, without getting in the procedure of creating patches or whatever, the translation progress would be very rapid, and it could be easy for more people to contribute. Let’s begin with the subversion configuration.

Subversion

In fact, all I have done here is to collect information. No special tweaking. This is going to be rather a quick installation, configuration and usage howto.

First of all, we install subversion :P (in Gentoo it is dev-util/subversion). Then we create a svn user and group, setting its home folder to /var/svn. This is the place where our subversion repositories will be stored.

useradd -m -d /var/svn -s /bin/bash svn

(For some extra security I set rbash as this user’s shell, it seems to work but you’ll have to make sure it doesn’t break your hooks first). The following changes should be done with the svn user, in order to avoid permissions problems. So, we go to that directory and create a test repository:

svnadmin create test

Next step is to set up the users accounts. We need ssh keys from the users for this. In /var/svn/.ssh/authorized_keys we write the following:

command="svnserve -t -r /var/svn --tunnel-user=commiter1",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-dss AAAAB3Nza.... user@host

Now, a little explanation about the above snippet. When the user performs an svn+ssh command, he actually logs in to the system with the svn user. So, ssh immediately calls the command svnserve, with some extra parameters, like the path of the folder where the repos reside and the actual username of the commiter (here it is commiter1). After that follow some extra ssh options which provide more security (like preventing execution of X11 forwarding). At the end is the user’s public key. The last step is to configure the repository, and specify who has read/write, who has read-only and who hasn’t any access. We have to edit two files, test/conf/authz and test/conf/svnserve.conf. In svnserve.conf we uncomment the following lines:

anon-access = read # optional: only if we want an anonymous svnserve running
auth-access = write
authz-db = authz

Then we edit authz file, where we specify the users’ privileges. There are many ways to do it, by specifying aliases, groups of people, and extra permissions to subdirectories. There are examples inside the file, so I am not going to expand on it at all. I’m just going to show a very simple configuration:

[test:/]
commiter1 = rw
commiter2 = rw
commiter3 = r
* = r
# Note: Of course the wildcard * = r covers the commiter3 = r entry

With this configuration we don’t need a running svnserve daemon. This prevents anonymous checkouts, and allows us to close the svn port (default 3690).

However if you do want this, in Gentoo the file /etc/conf.d/svnserve is used to specify the user that will run the daemon, which should be the user svn. Also, the SVNSERVE_OPTS variable could contain the repos path ( –root=/var/svn ). Debian does not provide a script, but it is very easy to create a custom one, and a simple google search will provide millions. Contact me if you need more info on this.

The last part is to create an svnserve wrapper. gentoo-wiki provides one that I have extended a bit (based on a script that robbat2 gave me that he uses in a Gentoo server):

#!/bin/bash
export SSH_SESSION=1
echo "$(date),$(date +%s) $USER (${SSH_ORIGINAL_COMMAND}) ($@)" >> /var/log/svnserve.log 
if [ "$SSH_ORIGINAL_COMMAND" == "svnserve -t" ] ; then
    export SSH_LOGIN=
    umask 002
    exec /usr/bin/svnserve "$@"
else
    exit 1;
fi

The extra thing I added is to log the user and reject the connection if the ssh argument is not svnserve -t. Place the script in /usr/local/bin/svnserve, make it executable and make sure that "which svnserve" returns /usr/loca/bin/svnserve instead of /usr/bin/svnserve. According to the gentoo-wiki article:

If the latter is the case, SSH does not search /usr/local/bin for the svnserve command. To change that, you can use the PAM module pam_env.so which is usually included in /etc/pam.d/ssh via system-auth. pam_env's config file is /etc/security/pam_env.conf and by adding PATH OVERRIDE=/usr/local/bin:/usr/bin:/bin you instruct it to set this particular path for all system-auth services. It appears this PAM module affects local login commands also, so check you have all the directories normally included in root's PATH included in this /etc/security/pam_env.conf entry.

That covers pretty much everything needed for the installation. The following command show how we can checkout the repository:

svn co svn+ssh://svn@server/repo

Since we specified -r /var/svn in authorized_keys, we don't need to type the whole path (the same applies to anonymous checkouts). Note that we use the svn user to do the svn+ssh authentication. The commits though will be logged with the actual user, the one who was specified in --tunnel-user. An optional step is to install a web gui for our svn repositories, like websvn or viewVC. Their configuration is very easy and well documented, so I won't expand on this. We are done with the subversion configuration, now let's move to something more Gentoo-specific.

Gorg with SVN

The main problem in Gentoo translations (and documentation translations in general I suppose) is that they can't be handled with a transifex or pooptle installation. So, what I am proposing here is to have a Gorg installation that serves a copy of the gentoo.org website, apart from the /doc/XX folder which will be a separate svn repository, which will be updated after every commit with a simple post-commit hook. The whole thing seems to work very well for the greek language (/doc/el), and you can see a sample of my work in the following links: http://gorg.gentoo-el.org/doc/el/handbook and http://websvn.gentoo-el.org/listing.php?repname=gentoo-doc-el. (Note to other translation teams: if you are interested in this but you don't have a server to host it, I'll be glad to host it). The installation of gorg is fully explained in Xavier's website, and I don't think I have to say anything more on this. After it is up and running, we can go on doing some further tweaking on this.

First of all we create an svn repository (for example called gentoo-doc-xx). Then delete the folder doc-xx from the CVS checkout we did earlier. Replace this folder with the svn repository you just made, which has to have the same name:

svn co svn://localhost/gentoo-doc-xx /path/to/your/document/root/doc/xx

Then we set up the hook. Some templates are stored inside the repositories, in the subfolder hooks. Just create a file post-commit, make it executable and add to it the following two lines:

#!/bin/bash
/usr/bin/svn export file:///var/svn/gentoo-doc-el/ /path/to/your/document/root/doc/xx  --force >> /var/log/svnserve.log

And that's pretty much it. Feel free to contact me for any suggestions or questions. The docs I used for this are the following: