Planet Ubuntu

Christer Edwards: Compiz-Check and EnvyNG Configuration Tips : Ubuntu 8.04

Christer Edwards — Sat, 10 May 2008 21:01:45 +0000

I was looking at some of the most popular posts on my blog, as reported by my awstats installation, and I noticed that one of the most popular is a post outlining common keyboard shortcuts for Compiz-Fusion on Ubuntu 7.10. Apparently everybody loves their eye-candy!

I thought, now that Ubuntu 8.04 “Hardy” is released, I’d update the basic configuration suggestions and hopefully help a few more of you get your bling-on.

The Compiz-Check Script

Recently I saw a post over at Forlong’s Blog releasing a script that will check your hardware in regards to Compiz support. From the article:

Compiz-Check is a script to test if Compiz is able to run on your system/setup and if not, it will tell you the reason why.

If you’ve had issues with Compiz support in the past I’d suggest running this script and pay attention to the output towards reasons why it appears to be unsupported. In some cases it is simply a matter of poor hardware. In other cases its only a matter of software changes, and may help you get things going.

To download and run the script:

wget http://blogage.de/files/3729/download -O compiz-check

chmod +x compiz-check

./compiz-check

If everything comes out as “OK” you should be able to activate Compiz as seen in the Compiz configuration instructions.

Driver Support With Envy

Another very useful tool I’ve found is the Envy tool, which will install required non-free driver support for nvidia or ATI cards for you. I’ll admit that I’ve only used this occasionally, considering I have intel graphics cards on my main laptops, but in the situations where I have needed it things have worked great.

If you are using Ubuntu 8.04 “Hardy” you can try the newer EnvyNG, which is available in the universe repository. How to install EnvyNG on Ubuntu 8.04.

If you are still using a previous version of Ubuntu you can try the legacy version of Envy, instructions here.

Are there any other common tips that I’ve missed? If you know of any other great resources for Compiz support tests, nvidia or ATI driver installation, or basic Compiz tweaks please comment and share with the rest of us.

Sebastian Kügler: GTK themes are fine again.

Sat, 10 May 2008 20:28:19 +0000

Two days ago, I've blogged about the environmental variable that sets the correct path to the GTK theme was broken. This made GTK apps use the default theme, which looks rather clunky. Yesterday, Kevin Kofler and Rex Dieter committed a fix for this bug. Rocking, dude! :-)

Matthew Helmke: Christians in America looking to moderate themselves

matthew — Sat, 10 May 2008 14:10:58 +0000

Today I was reading the news and ran across a link to something called The Evangelical Manifesto. This isn’t from all members of that community, but only those who wrote it. The authors have said the main goal is to get a conversation started among believers as a starting point for some needed reforms in their community (their words, not mine).

In any case, I see this a something that gives me hope.

I would love to see people of faith able to live their beliefs publicly and openly, yet without forcing them on others, just as I would love to see people who do not believe in spiritual things able to live their lives in freedom without forcing others to give up their beliefs. If this manifesto were actually accepted by most Christians, it could have a positive impact in each of these directions.

I have also noticed that it is beginning to give rise to a positive sounding conversation among Jews and Muslims as well.

In a large community, I would like to see room for everyone to feel welcome. Part of what this requires is a maturity within the individuals in a diverse setting. With that maturity comes a sense of security that is not easily shaken by the presence of others who believe differently, making it far less difficult to take offense when someone says or embraces something you do not like.

I wonder what sort of comments I’ll find on this post…I’ve posted similar thoughts before.

Jonathan Carter: Wine project announces first release candidate

jonathan — Sat, 10 May 2008 09:46:24 +0000

The Wine project has announced the first release candidate for Wine, the free Windows API for Unix/Unix-like systems (and even non-unix systems like MS Windows itself and ReactOS). The Wine project started in 1993, which makes this release candidate 15 years in the making.

With so many excellent software for Linux systems these days, and the combination of powerful desktop hardware with great free virtualisation suites such as Virtualbox, people often ask me what the actual benefit of having a complete and stable free Windows API is. The ones I could think of is:

Gaining the benefits of free software. This comes down to having the ability to fix bugs yourself, or getting someone else to fix them for you. A company might have to run some legacy software under Windows, and Microsoft itself might not find it financially beneficial to fix a certain bug in their system. You could then switch to a free API and if the bug is present there as well, have it fixed. Since Wine does not run Windows under an emulator (or run Microsoft Windows at all), you do not need a Windows license, which you would need if you would run Windows under KVM/Virtualbox/VMWare/etc.

Beneficial to ReactOS (and similar projects). ReactOS is an attempt to completely re-write the entire Windows operating system, including boot loader, registry. kernel and user interface. ReactOS uses Wine for its Windows API. ReactOS is currently in early alpha state, and plans to release an alpha that is roughly 70% of a Windows NT 5 (Windows XP) kernel by the end of 2008.

Allows software vendors to dip their toes into cross-platform support. Software vendors such as Google have ported software such as Picassa and GoogleEarth to Linux-based systems using Winelib. Using Winelib, a software vendor can package their software to run on non-Windows systems at a fraction of the cost of what a rewrite or proper port would cost. While this may be a short-term solution for some providers, it may give them a market lead boost by being able to provide to a large audience rather sooner than later.

Commercial Wine support providers such as Crossover or Transgaming (see Tom’s comment below). These companies patch Wine to provide additional support for certain software and also provide user interfaces to allow easy installation and configuration of Windows software. The software released by these type of companies are usually proprietary software.

Performance and integration. Even though desktop hardware has become cheaper, and virtualisation software offers more and more nice features such as ’seamless’ window mode, running a complete additional operating system does come at a performance hit. At the very least, it will typically consume a dedicated amount of memory. Unless you do fancy tricks with shared directories between the host and guest systems, you also don’t get tight desktop integration with the software running in the guest. Running your legacy software under Wine allows you to get past some of these problems.

That’s the immediate benefits I could think of from having a free, stable Windows API available. There are probably more, and while I think that we probably won’t care about this anymore 10-15 years from now, considering all the next-generation cross-platform programming tools that are available now, I do think that the coming of age of the Wine project will be welcomed by many, and will provide many companies and individuals plenty of short-term benefits while the computing landscape transforms.

Alberto Milone: Call for testers for EnvyNG

albertomilone — Sat, 10 May 2008 09:16:04 +0000

It’s been a month since my last blog post. EnvyNG was included in Hardy but it had a few problems and I have worked to fix them. I can’t upload such fixes since Hardy is a stable release. This means that all the updates will have to be tested before they are moved to the stable repositories. This is why I need your help. The more users test the fixes the sooner we can get them into stable.

Special Thanks:
All this wouldn’t have been possible without the amazing support of Martin Pitt, who guided me and helped me with the SRU (Stable Release Update). He has spent a lot of time on EnvyNG, gave me a lot of extremely useful suggestions, therefore I can say that you should really thank Martin for this release.

Timo Aaltonen brought bugs #212648, #186382, #118605 to my attention and suggested the solution. In case you don’t know it already, he’s one of the guys who take care of Ubuntu’s restricted modules. Keep up the good work, Timo!

A stripped down list of Changes:
envyng-core (1.1.1ubuntu15) hardy-proposed; urgency=low * Fix (LP: #224004) Update NVIDIA compatibility list. * Fix (LP: #221304) Use the new l-r-m-envy packages now. * Install -envy packages instead of the ones in main * Hide FutureWarning caused by python-apt * xorgconfig2 now ignores sections which are not relevant in xorg.conf
linux-restricted-modules-envy-2.6.24 (2.6.24.500-500.28) hardy-proposed; urgency=low * Fix (LP: #228649) xorg-driver-fglrx-dev conflicted with xorg-driver-fglrx * Sync with the fixes in linux-restricted-modules-2.6.24 (2.6.24.12-17.36) * nvidia: Do not divert libwfb.so, because if the xserver provides one it should be used. This caused at least problems with some websites crashing on certain pages (see #212648), and pink shadows with compiz. (see: #186382) * fglrx: Patch authatieventsd.sh to search for xauth files in /var/run/xauth/. Otherwise the session would freeze on logout for KDM users. Thanks Ilja Pavkovic! (see: #118605) * Remove previous diversions of libwfb.so in the postinst. Thanks Timo Aaltonen. * Make sure that any previous module of fglrx and nvidia built by DKMS are removed before the new module is built and installed. * Use -envy so as not to conflict with Ubuntu's lrm * Add fglrx driver 8.4

Envyng-core will also fix the problem which prevented the QT interface from working properly.

EnvyNG now relies on its own packages (available in multiverse) therefore you will have to install the driver from EnvyNG again so that the correct packages are installed. If you don’t do it you will keep using Ubuntu’s default restricted modules. Of course DKMS, CUDA, etc. are back in my packages.

The latest release of ATI’s proprietary driver (8.4) is also available and contains a patch which should fix bug #118605 (which doesn’t solve the problem on my computer though).

How to test it:
You will have to enable the hardy-proposed repositories (Go to System/Administration/Software Sources/Updates and select “Proposed Updates (hardy-proposed)”) and upgrade to envyng-core (1.1.1ubuntu15), then launch EnvyNG and install the drivers.

Where to report:
If you have problems with EnvyNG (e.g. if EnvyNG crashes during the installation of the driver) you can report them here.

If you have problems with the drivers which EnvyNG installed you can report them here.

You can simply add a comment to one of the bugreports which you will find at these links if your problems are related to those reports or if you just want to confirm that either EnvyNG or the drivers work well for you (this will really help us).

If you want you can use this model to report:

Used EnvyNG (yes/no):
Worked with Ubuntu’s default restricted modules (yes/no):
Graphic card model:
Problem (solved/otherwise describe the problem):

Example:
If it works for you:

Used EnvyNG: yes
Worked with Ubuntu’s default restricted modules (yes/no): yes
Graphic card model: Geforce 7300GT
Problem: solved

OR if it doesn’t solve the problem

Used EnvyNG: yes
Worked with Ubuntu’s default restricted modules (yes/no): yes
Graphic card model: Geforce 7300GT
Problem: NVIDIA driver 169.12 still freezes my computer when I visit this website…

NOTE:
I’m working on this Bug too.

Sebastian Kügler: Are we breathing in the same rhythm?

Fri, 09 May 2008 23:05:19 +0000

Tom and Aaron discuss timing and release schedules, and development cycles. Aaron talks about trunk/ and freezes therein should follow a natural lifecycle. This assumes that the whole KDE community lives and breathes as one individual, synchronised and all. So a development-and-release-cycle forces all developers into one rhythm. Everyone has to follow this one release rhythm. It's a good idea, but I think we should also make the lives of those easier that choose another breathing ryhthm. There are a couple of things to consider here. The most obvious being that we need this flexibility anyway. We rely on certain release mechanisms and interface stability policies in other projects as well. (We partly solve this problem by providing abstraction layers, think phonon and solid). Now the interesting case is that Phonon, which is new in Qt's 4.4 release is also provided by Qt. Phonon now breathes in a 9 month release cycle in Qt, and a 6 months one in KDE. So one could argue that it's a smart idea to breathe in the same rhythm as Qt does. We could follow up every release of Qt with a KDE release.
This does not solve the initial problem I think, which I think is "different parts of KDE have different heartbeats". Neither Tom nor Aaron have really questioned the way we currently deal with SVN before releases, so I'll put on my shiny pink asbestos suit and do it.

What if we never froze trunk? Others (such as, incidentally Qt) have no freezes in trunk/ and it seems to be a popular and well-working development style for some. When a release enters a freeze, a branch is created that will be stabilised towards the release. trunk/ at the same time stays open for feature additions. The Golden Rule is "You don't break trunk/ (this is what branches are for)".

(For those not too intimate with development schedules of KDE: trunk/ is frozen roughly 2 months in advance of a release (supposedly every 6 months). After the actual release, trunk/ is opened again for new features. Features that take longer than the allotted time be developed in a branch and moved into trunk/ "when they're ready, but not during freeze".)

The obvious downside of this "It's always summer in trunk" is that you need to spend extra efforts to get people to stabilise, i.e. working in a stabilise-branch rather than in trunk/. It needs more discipline, and probably puts some extra weight on the shoulders of those who simply care about good KDE releases. But as we all agree, SVN sucks for branching and merging. So right now we make it hard for people to work with different branches (stable/ and trunk/). It would allow those that need more time to do their thing to stay in sync with latest features. Basically, it would allow for different rhythms in the community. As this community grows and becomes more diverse this might pay off in the end.
New tools are on the horizon as well. Distributed version control systems allow for a more flexible way of sharing code between peers.

The thing is that we cannot really choose, people are using git anyway. And after having used it for a bit, and git-svn to interact with svn, I have to say that it makes a lot of things much easier. For one, it doesn't force the commit policy of the project ("don't break trunk" maybe ;-)) on yourself or your team, and it makes it easy to share code with others. That might want to work one a feature (or some surgery) together, but others (those that don't want to be affected by this surgery just want their desktop to work. Now imagine these peeps, just start developing features by sharing a number of git trees and committing features to trunk/ when they stabilise, i.e. presumably don't cause regressions. It also nicely solves another issue we had recently. Rafael needs some time to finish Goya (have it API reviewed by Kevin ;-)), but Jeremy already wants to use this feature in GetHotNewStuff2. Those three share a "review" branch, which is merged when everyone's happy (after having been announced on kde-core-devel. (Imagine integration of some sort of peer review system, like review board with this branch!). This development style can partly be tested by a subproject, of course. This subproject can then track trunk/ from SVN and develops features in a distributed way, probably with another branch as master that sits on top of it and tracks. It's not really a technical problem, after all, the tools should support the natural way of breathing for the community. For git in particular, I see the steep learning curve as one of the major show-stoppers right now. It would, at this point simply make the barrier of entering a project much higher, which is not a good thing. With distributed source code management, the question "Which one is the authoritative copy?" becomes a purely social thing. In the SVN case, it's always the SVN server, in the DVCS (OMG!) case, it's "who you trust", that would be the version we publish via SVN.

Interestingly, the KDE's Internationalisation people already work in a distributed fashion. In the Netherlands for example, Rinse collects translations; that are sent to him by the people in the translation team he reviews them and commits them to SVN.

Does this whole mess of an idea also contain a solution for "synching downstream"? One of the reasons why the Release Team initially decided to adopt 6 months releases is to make it easier for downstream (distributions, for example) to ship a recent version of KDE. The thing is that those distributions also have different heartbeats, OpenSuse comes 8-9 monthly, Fedora comes 6 monthly, others as well. Now we're trying to sync with upstream, in different heartbeats and downstream in different heartbeats. Right now, we have the unfortunate situation that we're just too late for OpenSuse 11 (which is really one of the symptoms of "heartbeats out of sync"). At last year's Akademy, Mark Shuttleworth brought up the idea of synching release over the whole Free software stack. While this is a nice vision, I do not see this happen 'globally enough' so that it really works. The trend in the Free Software world seems to be to move to a more distributed way of development.

This "we all breathe synchronously" might be one of the things that ties us together. We've seen this a lot in the time up to 4.0. That was where we as a community acted as one and lifted KDE from 'utterly broken' into a releasable desktop. In KDE 4.x, things are fundamentally different. With all the new frameworks and libraries solidly in place now we we want this to be a stable platform for a long time. That means we develop features on top of it and fix bugs in the infrastructure and extend it - not break it. Basically that's the "Binary Compatible until KDE 5.0" promise.

Moving from one, proven style of development to another is something we should not take lightly. On the one hand it would help us solving some scalability challenges in the community (such as too many different people, expectations, needs for their product and whatnot) and adopting new styles of collaboration in a community where you're free to share.

Things such as new ways of working together and the ever more diverse community's needs, expectations and lifestyles are not something we can ignore. We need to constantly look at ourselves and our environement and think about how we can improve it. Probably not one big step ("starting tomorrow we never freeze trunk again, promised") but hundreds of little baby steps.

Jordan Mantha: bzr, git, and hg performance on the Linux tree

laserjock — Fri, 09 May 2008 20:24:57 +0000

OK, so I just did a historical comparison of git and bzr performance using the Linux source tree. One of the comments I got was “what about Mercurial?” Fair enough. I’ve really never done much with Mercurial because Ubuntu primarily uses bzr and git is what most of the other people I know using a DVCS use. However, there are a lot of projects using Mercurial, Mozilla being probably the most notable one. So, here’s a comparison of bzr and hg. You may want to read my previous post for details on the steps I’m doing.

Repo Initialization:
git                bzr          hg
0m0.086s     0m0.334s     0m0.137s
1        :         3.88      :    1.59

Add 2.6.0 Linux tree:
git              bzr          hg
0m14.269s   0m4.852s     0m2.526s
5.65      :      1.92      : 1

Commit 2.6.0 Linux tree:
git          bzr            hg
0m10.263s   0m43.968s    0m30.890s
1     :     4.28    :    3.01

Diff after copying in 2.6.25.2 Linux tree:
git            bzr            hg
0m24.425s   0m51.158s    0m37.846s
1        :       2.09      :    1.55

Committing large changes:
git            bzr             hg
0m28.468s   1m8.627s     0m47.948s
1    :         2.41    :    1.68

Diff after no changes:
git            bzr            hg
0m0.343s    0m47.448s    0m1.340s
1         :    138       :    3.91

Getting repo status after no changes:
git            bzr            hg
0m1.230s     0m4.027s     0m1.077s
1.14     :     3.74      : 1

Committing a trivial change:
git            bzr            hg
0m0.397s    0m9.010s      0m1.913s
1     :      22.7       : 4.82

Repository size (just VCS control directory):
git (gc) bzr (pack) hg
92 MB 112 MB 179 MB

So, Mercurial performs quite well. It generally sits somewhere between git and bzr. Hg runs somewhere around 2.75 times slower than git in the tested operations. Bzr runs around 5 times slower with the notable exception that bzr diff when there are no changes is 138 times slower than git and 35 times slower than Hg.

Ubuntu QA blog: Ubuntu Brainstorm keeps growing

nand — Fri, 09 May 2008 20:20:44 +0000

Hello everybody, In less than two weeks, the Ubuntu Developer Summit will take place, and the best ideas out there will be reviewed (See the previous post)! Meanwhile, we just upgraded Ubuntu Brainstorm:

Developer comments For a better visibility, developer comments now appear on the idea list pages. You can now quickly check the developers feedback on ideas. Expect some updates during the Ubuntu Developer Summit!
Bookmarks As requested by frandavid100 and many others, it is now possible to bookmark ideas. Just click on the star, and it's bookmarked. You can now easily follow the development of ideas that matters to you!
User infos and stats The user page has been reworked to provide you much more infos and stats. You can now see the ideas a user posted, which ideas he voted down or up, the latest reactions to ideas he commented, his bookmarks, and some nice stats. And the best idea contributor so far is ... Ubuwu!!
New categories lists Categories ideas can now be browsed in two more differents ways: latest ideas and most popular this month.
Get rid of bug submissions Finally, idea can now be marked as "Not an idea" by moderators.This will hopefully prevent further non-ideas, generally bugs, to be submitted on Ubuntu Brainstorm. Please remember that Brainstorm is a place to post ideas only! Any bugreports posted here won't be looked at. To report a bug, please use the Ubuntu bug tracker.

So nothing revolutionnary yet, but tiny bit by tiny bit, Ubuntu Brainstorm is improving. Expect some nice new plans for Ubuntu Brainstrom from the UDS!

Tiago Faria: Choose how to read our Planets (Update: Screenshot)

Gouki — Fri, 09 May 2008 17:51:14 +0000

Can you tell I’m bored and unemployed?!

Yesterday I blogged about the Jabber bot, which, by the way, has more available feeds, including Planet Gnome and Planet Debian (rss-list to get a complete list). Today I decided to keep playing with the Planets and decided to implement an idea Joey had for Planet Debian.

I installed and configured rss2email and set up two different mailing lists; one for Planet Ubuntu and another one for Planet Ubuntu Users.

Screenshot

You can subscribe using the web-based form at: rss2email.ubuntuweblogs.org

Even though messages can be in HTML format, I decided to go with plain text. I would really like to hear someone else’s opinion on which format to use.

If you have any recommendations, please, let me know. Comments are open again, but only if people start behaving. If you’re going to say something stupid please don’t write anything at all.

P.S.: Stephan Hermann, thanks buddy! ;)

Christer Edwards: A Root Shell On Ubuntu : The Right Way

Christer Edwards — Fri, 09 May 2008 13:58:27 +0000

Just the other day we were having a discussion on using the root shell in Ubuntu. Now, remember, the root user account is disabled with no assigned password on a default Ubuntu system so administrative tasks need to be done using the sudo command. For nearly all of the administration you would need sudo will be adequate. There are occasionally those fringe cases where you might require a root shell. Below I have a few alternatives and then, if you must, the correct way of opening a root shell.

For more information please see the RootSudo page on the Ubuntu Community Wiki.

Alternatives To A Root Shell

One of the most common reasons that a user might need a root shell is due to output redirection not working as expecting while using sudo. This can be bypassed fairly easily. Let me outline an example:

sudo echo “foo” > /root/somefile

The above example will not work because the normal user does not have access to write to the root user home directory, and combining the redirection in the command we’ve lost sudo access.

An alternative that will work would look something like this:

echo "foo" | sudo tee /root/somefile

This will echo the output on the console but the tee command ('man tee‘ for more information) will also take that output and write it to the file as expected. Also note that 'tee -a' will work in the same fashion as >>, appending the data to the current file vs overwriting.

The Proper Way To A Root Shell

If you still need a root shell (perhaps you’ve come across a different scenario? perhaps you’re just lazy? perhaps you’re coming from another distribution?) let me outline the proper way to gain a root shell.

DISCLAIMER: This should be avoided if at all possible. It is not suggested to run a root shell on an Ubuntu system. Use at your own risk. See examples above, etc.

sudo -i

The command sudo -i is the equivalent to the 'su -' command. This will properly change to the root user, switch to the root user’s home directory, use his (her?) environment values, etc.

sudo -s

The command sudo -s is the equivalent to the 'su' command. This will change to the root user but will not properly use his (her?) environment values, etc.

The WRONG Way To A Root Shell

Please DO NOT use the following methods to gain root access:

sudo bash, sudo sh, sudo su -, sudo su, sudo -i -u root

If you currently do use these methods this post was written for you!

UPDATE: Based on the feedback in the comments for this post I’ll try to expand the reasoning on *why* the right way is the preferred way.

First of all we need to understand some background information. When a user creates a session there are a number of environment values that are set. To have a look at some of these try this command:

env

This will output a number of details about the current working environment. These environment values may be different for different users. Some of the values are generated by way of the .bashrc file (assuming a bash shell, of course), the .bash_profile, etc. Take a look at the .bashrc in your users home directory and compare it with the .bashrc in root’s home directory.

diff -u ~/.bashrc /root/.bashrc

You should see some differences, and this is just from one of the multiple files that are read during a proper login.

When creating a root shell by using ‘sudo bash‘ you are not incorporating the root environment properly. You are creating a shell with root privileges but the env output is still that of your user. Each user, whether unprivileged or root, should have unique environment settings to truly be that user. This will be the case for ‘sudo bash‘, ‘sudo su‘ and ‘sudo sh‘.

Random Posts

Henrik Omma: QA team key positions

Henrik — Fri, 09 May 2008 10:27:00 +0000

The QA team has vibrant communities around both bug triage and testing. Community contributors and Canonical employees share a range of key positions between them such as bugmaster, QA website developer and Windows-related test lead. This model where one or two team members take primary responsibility for a certain topic has evolved organically as people have simply taken on responsibility for certain tasks. It works really well though and we would like to build further on that approach. At a recent QA team meeting we agreed on three new QA team positions:

Kernel bug first-response

Description: Provide initial response to new kernel bugs and perform initial triage
Rationale: The kernel is a complex package to triage — many bugs are hardware-specific and difficult to reproduce independently. It is therefore important to have efficient communication with the initial reporter so the relevant debugging information can be collected while the bug is still relevant. Faster bug response will also help improve the perception of our bug work.

Responsibilities:

Be subscribed to New kernel bugs and provide a response to the reporter
Perform basic triage following Kernel Team bug policies, asking for additional information as appropriate
Work closely with the kernel bug lead and the kernel team to identify potentially high-impact issues

Test image maintainer

Description: Configure and maintain ready-to-use virtual images for testing Ubuntu and upstream code.
Rationale: Bugs filed in Ubuntu are often best fixed by the upstream developers who know the code base best. But first we should confirm that the bug is also present in the raw upstream version rather than one introduced by Ubuntu-specific changes.

Responsibilities:

Configure ready-made VM images (KVM or VirtualBox) with the Ubuntu development release of Ubuntu and Debian testing
Update the images weekly and make them available for download
Maintain documentation on using and updating the images

Forums feedback coordinator

Description: Liaison between the QA and forum communities
Rationale: The Ubuntu forums represent a huge resource with people of all skill levels, able to provide useful testing and debugging of Ubuntu. Some guidance in how to use our development resources properly would improve the flow of information between the forum and the QA team.
Responsibilities:

Point forum users to the right QA resources in discussions about bugs or testing
Help forum users file bugs in Launchpad
Keep the forum community informed of the activities of the QA team, including bug days and testing and invite participation

If you are interested in taking on one of these challenging positions, please send your application to the ubuntu-qa mailing list and turn up at the next QA team meeting so we can ask further questions and vote. Current members of the team and people new to QA are all invited to apply. See the key QA positions wiki page for more information.

Note for clarification: These ‘positions’ do not represent job postings (even though they have a similar format) but key roles in the open QA team that we encourage people to take responsibility for.

Martin Pitt: Apport retracers are back

martinpitt — Fri, 09 May 2008 09:19:49 +0000

As a lot of you were rightfully complaining, the automatic Apport crash bug retracers had been offline for about two weeks. The main reason was that the hardy chroot became totally broken, due to bugs in fakechroot.

Yesterday I finally took some hours to track them down and fix them (see LP #228534). Now, after also dealing with the usual breakage of python-launchpad-bugs and Launchpad getting out of sync, the retracers have been restarted and are working happily again.

Now they are grinding through a huge backlog, I guess it will take them a few days to process all the crash reports that piled up.

John Vivirito: Testing again

gnomefreak — Fri, 09 May 2008 09:14:07 +0000

sorry for the useless posts but i’m setting everything up for use with wordpress instead of Livejournal I hope this works.

Matthew East: Ubuntu hits mainstream Italian television

matt — Fri, 09 May 2008 07:19:56 +0000

Seriously long time no blog… life has been incredibly busy recently.

Ubuntu appeared on Italian terrestrial television yesterday, by way of a short piece on the program “Neapolis”, broadcast by RAI 3. RAI 3 is a state run television channel in Italy, and is popular for having plenty of interesting programs on culture and current events.

Congratulations to the members of the Italian local community team who made this possible: Fabio Marzocca (who appears in the clip), Milo Casagrande and Flavia Weisghizzi.

Watch the clip here (Italian language).

John Vivirito: Testing

gnomefreak — Thu, 08 May 2008 23:06:39 +0000

this is a test i had edited my planet blog link to wordpress instead of livejournel and need to see if it works

Edward A Robinson: Google Docs As An Expense Tracker

earobinson — Thu, 08 May 2008 20:34:49 +0000

I am a huge fan of the google docs, In fact I am pretty much a fan of all of googles services. I love having all my information with me wherever I go and I am willing to “sacrifice” my privacy in exchange for that service. Anything really important and I will keep it on my own server but I am yet to have anything that I really worry about. That said some people might not want to use google to host there expenses, I do.

The great thing about using google docs to host my expenses is that I can add an expense from anywhere using the google docs form feature In the example I provided (Fake Expenses), I use the forum feature to add expenses on the road as well as getting real time updates about the amount of money I spend per day, week, etc.

If you would like to use my expense tracker you can view it here (Be sure to check all the sheets (Form, Overview, Worker, and Totals)), or download it here. Then simply upload it to your google docs and set up a form. Also feel free to play around and add fake expenses to the doc.

How do you track your expenses?

©2008 Edward Andrew Robinson.
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Canada License.

Jordan Mantha: git/bzr historical performance comparison

laserjock — Thu, 08 May 2008 19:03:35 +0000

OK, I know git vs. bzr has been beat to death and that bzr speed seems to be often cited as its “Achilles’ heel“, but I was in #bzr the other day and somebody (a git fan I take it) said something to the effect of “well, bzr couldn’t be used to work with the linux kernel tree, that’s what git was made for”. Now, I have no experience of working on the linux tree, but it got me to thinking about if anybody had done any benchmarking of that kind of operation.

After some googling I found an old blog post from 2006 by Jo Vermeulen where he did some basic timing of common tasks such as adding files, doing diffs, commits, and finding repo status on the Linux 2.6 kernel tree using both git and bzr. Since both git and bzr have come a long ways since 2006 I thought I’d replicate Jo’s comparison (with git 0.99.9c and bzr 0.7pre) using current (by Ubuntu 8.04 standards anyway) versions of git (1.5.4.3) and bzr (1.3.1). So, here’s the results:

First we unpack a Linux 2.6.0 tarball into linux-bzr and linux.git directories, then initialize the repos:

Initialization:
git (old) bzr (old) git (new) bzr (new)
0m0.161s 0m1.593s 0m0.086s 0m0.334s

Nothing exciting so far. Now we tell the VCSs to track the files via bzr/git add :

Adding files:
git (old) bzr (old) git (new) bzr (new)
0m42.121s 0m31.870s 0m14.269s 0m4.852s

In this case bzr not only wins in terms of absolute speed, but also in proportional gains with time. The git:bzr ratio in 2006 was 1.32:1 and now it’s 2.93:1 . Jo didn’t mention in his comparison how long it took him to then commit the initial 2.6.0 tree we added but for me it was 0m10.263s for git and 0m43.968s for bzr, a pretty clear win for git.

Next we’ll untar the latest 2.6.x kernel into our repos. Jo used linux-2.6.15.4 and I used linux-2.6.25.2. Perhaps I should have used the same version he did but considering we’re using entirely different hardware I don’t think our results are directly comparable anyway. OK, so now we want to see how long it takes to diff the changes:

Diffing changes:
git (old) bzr (old) git (new) bzr (new)
2m26.982s 1m13.869s 0m24.425s 0m51.158s

This is one of the more fascinating results in my little experiment. The 2006 results gave a git:bzr ratio of 1.99 whereas my new results give a ratio of 0.48 . Apparently git has done a lot of work on speeding up diffing.

Next we commit our new 2.6.x changes:

Committing large changes:
git (old) bzr (old) git (new) bzr (new)
0m54.964s 2m4.757s 0m28.468s 1m8.627s

so an old ratio of 0.44 and a new ratio of 0.41: not a lot going on there.

A really interesting test that Jo did was to do a bzr/git diff right after committing. Ideally this would take no time at all as we haven’t done anything since the commit, however:

Diffing no changes:
git (old) bzr (old) git (new) bzr (new)
0m0.057s 3m51.918s 0m0.343s 0m47.448s

Back when Jo did his experiment the git:bzr ratio was 0.00025! Ouch. My results gave a ratio of 0.0072. In this case bzr has been gaining a lot of ground but it’s still rather remarkable how long it takes to diff when there are no changes.

The other things we would often do is a bzr/git status to see what’s going on:

Getting repo status:
git (old) bzr (old) git (new) bzr (new)
0m0.442s 0m19.711s 0m1.230s 0m4.027s

The original git:bzr ratio was 0.022 and for the new one 0.305 so bzr has gained by an order of magnitude but still lags a bit.

Lastly, we look at what happens if you make a minor change (let’s just add our name to MAINTAINERS for fun) and then commit:

Small commit:
git (old) bzr (old) git (new) bzr (new)
0m7.364s 2m6.685s 0m0.397s 0m9.010s

The times I got for both git and bzr are significantly faster than what Jo got in 2006. His git:bzr ratio was 0.058 and mine is 0.044, so some marginal gain by bzr here.

A last interesting note of comparison is the storage size that the VCS takes up. After all the operations above my .bzr directory is 112MB (or 23% of the total size of the repo+working tree) and the .git directory is 162MB (or 30% of the total size) so it seems that bzr has a bit better storage compression.

OK, so now the question is, what does it all mean? Well, I’m not entirely sure to be honest. When it comes to my original question of “Would bzr be usable working on the Linux tree” I would think, at least when it comes to common local operations, that the answer would definitely be yes. It’s not the fastest thing around but it’ll get the job done.

I use both git and bzr on a regular basis and both are exciting and have their own strengths and weaknesses. Git is no doubt very fast, though I think other DVCSs are starting to catch up. Bzr is very user friendly and has great plugins. It’s really a cool time for code sharing, in my opinion. Rock on!

Stephan Hermann: Interpol Update

shermann — Thu, 08 May 2008 17:38:03 +0000

Just to give you an update on that case..

The meatbag was arrested two days after making his pictures public.

Interpol reports:

>> “Two days ago, this man’s nationality, identity and location were totally unknown. All we had to go by were a series of graphic photographs in which the suspect was seen sexually abusing young children and our confidence that the public and police worldwide would once again respond to INTERPOL’s call for assistance. That two days later, the primary suspect is now in custody is an outstanding achievement and a credit to the citizens, media and law enforcement worldwide who responded to INTERPOL’s call,” said INTERPOL Secretary General Ronald K. Noble.<<

At the end of the news they write:

>> This is the second time that INTERPOL has launched a public appeal to identify a suspected child offender. Operation VICO last October led to the arrest in Thailand of Christopher Paul NEIL. Following the success of that operation, INTERPOL’s General Assembly in 2007 approved a resolution empowering the organization to publish information to request the public’s assistance in child sex abuse investigations. <<

So, despite some of the commenters on my blog the last days, I think it made a difference to publish those pictures to a world wide media.

---

Btw, thanks to all people who were writing eMails, makeing positive comments to not listen to some other people who were swearing, calling me names etc.

Most of the writers were coming from the Ubuntu Community, so I think it's true to say: The Ubuntu Community Makes A Difference.

And another remark:

ONe community member was asking me on IRC, how the hell I can live with all the hate comments and mails I'm receiving, because of my somewhat not related Ubuntu articles on the Ubuntu Planet. I told them, I grew a think skin...and it's true. He knows who he is, and I hope that he will grew a thick skin, too...Dude, you did really awesome work, don't let it be destroyed by morons.

When I started to work towards the Ubuntu Distro, I never thought, that the Ubuntu Community actually evolves to a community which not only cares about technical news and issues.

Today, the Ubuntu Community grew to something new...Yes, you people are great, and yes, there will be always people who will be somewhat strange and too focused on technical issues, actually I'm one of them most of the time.

IMHO, Ubuntu is more then just a technical issue. It's lifestyle, it's community, it's (reading some articles on blogs from other colleagues) becoming in some parts even a family.

Strange, it never happened before, at least I never saw that in any other community.

Launchpad News: Your questions for the Launchpad podcast

Matthew Revell — Thu, 08 May 2008 17:03:56 +0000

Over the next couple of weeks we’re going to record a brand new Launchpad podcast.

In it we’ll talk to projects about how they’re using Launchpad and also to members of the Launchpad team.

Perhaps the most important part will be questions from you. Whatever you want to know about Launchpad, ask us on the podcast help wiki page.

Also, if you’ve got a suggestion for a name for the podcast or a Creative Commons licensed theme tune, send it over to feedback@launchpad.net! Best suggestion gets a hearty handshake.

Matthew Helmke: This world is not my home

matthew — Thu, 08 May 2008 16:29:51 +0000

Is it possible to spam your own blog? I’m not sure, but I’ll try anyway. I have a new project.

People who move away from their country or culture of origin to live in another culture for any amount of time will understand what I say when I comment that this is a wonderful, life changing, and sometimes difficult experience. Cross cultual living requires adaptation, a sense of humor, and will cause a person to grow, often in unanticipated ways.

If you have experienced this sort of thing and tried to share your new insights with others who have not, you may have found them to be a bit less excited about your ideas than you had expected. They didn’t mean to frustrate or hurt you, or anything else, they just didn’t understand what you were saying or where you were coming from.

I have started a small niche forum for people who, like me, either live in a culture other than the one that they were born in or that issued their passport, or that have done so previously. If that sounds interesting to you, check it out at http://thisworldisnotmyhome.com/ and see what you think.

If you are not interested, that’s okay. I now return you to your regularly scheduled blog reading and promise not to interrupt further with news on this project (unless, of course, the positive response is truly overwhelming).

John Meinel: This Week In Bazaar First Edition

jam (noreply@blogger.com) — Thu, 08 May 2008 15:19:12 +0000

This is the first in a mostly-every-week series of posts about whats been happening in the development world of the Bazaar distributed version control system. The series is co-authored by John Arbash-Meinel, one of the primary developers on Bazaar, and Elliot Murphy, Launchpad developer and wanted criminal.

We get to talk about anything we want. This week:

What's been happening for a better GUI on Windows
What's new in the 1.4 release
Importing from other VCS's with bzr fast-import

... details ...

GUI on Windows

We found this guy named Mark Hammond who claims to know how to make python stuff work well on windows. There is an existing GUI tool for Bazaar on Windows called TortoiseBZR now, modeled after TortoiseSVN. If you haven't used a Tortoise before, they are
extensions that integrate into Windows Explorer; allowing you to see and control
the versioning of your files without needing to change to a separate tool.

Mark has taken a look and proposed a series of enhancements to make the tool work even
better. Bazaar already works very well from the Windows command prompt, but we want to provide excellent GUI tools as well. Take a look at the TortoiseBZR web page for screenshots of it in action.

What's new in the 1.4 release

The Bazaar team releases a new version of Bazaar just about every month, with
both bugfixes and new features. The bzr-1.4 release came out last Thursday, May 1st.

The major changes for 1.4 include improvements in performance of 'log' and 'status', and a new
Branch hook called post-change-branch-tip, which will trigger any time a Branch is modified (push, commit, etc). This should enable server generated emails whenever somebody publishes their changes. Write something cool with it and tell us what you did!

The full list of changes for 1.4 can be found at: https://launchpad.net/bzr/1.4/1.4
The list of all changes is at http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html

bzr fast-import

Bazaar fast-import is a plugin for bazaar that allows you to import from many different version control systems. The fast-import stuff is intended to support any system that can use the fast-export format. This format was originated by git developers, and quickly adopted elsewhere. So if a source format can generate a "fast-import" stream, you should be able
to import it into Bazaar.

CVS
To convert from cvs, you currently use the cvs2svn converter. Which has a flag to generate a "fast-import" stream.
Mercurial
There is a script called hg-fast-export.py bundled with the plugin (in the exporters/ directory).
SVN
The svn-fast-export script is also bundled with the bzr-fastimport plugin.
git
Bundled with the standard git distribution is the git-fast-export command.
Your own exotic system here.

Give fast-import a try. It's mostly designed for 1-time conversions, rather than
mirroring, but there are already some rudimentary mirroring capabilities.

That's all for the first installment of "This Week in Bazaar".

Launchpad News: Offline 21.00 - 23.00 UTC 10th May 2008

Matthew Revell — Thu, 08 May 2008 14:25:57 +0000

We’re taking Launchpad offline for a couple of hours this Saturday (UTC) to upgrade our main database server to Ubuntu 8.04 LTS (also known as Hardy Heron).

Going offline: 21.00 UTC
Expected back: 23.00 UTC

If you want to see Launchpad service notifications, such as this, in your feed reader please subscribe to our notifications feed.

We’re sorry for the down time this database upgrade will cause.

Nick Ali: Links for May 8th, 2008

boredandblogging — Thu, 08 May 2008 14:10:30 +0000

The heron has landed: a review of Ubuntu 8.04: Page 1 - “This release is disappointing because it falls short of what was promised, but it still delivers a lot of value for experienced users who will be able to work around the weaknesses…”
Moving to Ubuntu | A Wor[l]d of Mentations - “My overall experience in these past days using Ubuntu has been really incredible and I would suggest each and every Windows user to atleast try Ubuntu using Wubi..”
LinuxDevCenter.com — Meet The Hardy Heron: What’s New in Ubuntu 8.04 - Background on Ubuntu and its development and the Ubuntu Massachusetts LoCo gets a plug.
Why many MCSEs won’t learn Linux | Paul Murphy | ZDNet.com - “Basically, to learn Unix you learn to understand and apply a small set of key ideas and achieve expertise by expanding both the set of ideas and your ability to apply them - but you learn Windows by working with the functionality available in a specific release.”

Sebastian Kügler: Hideous GTK themes in KDE4 sessions.

Thu, 08 May 2008 10:58:09 +0000

For some time, GTK apps running inside my KDE4 session would not pick up their theme properly, making them look hideous in their default theme. I'm using a small wrapper script (/usr/local/bin/startkde4) to get my KDE4 desktop up and running. Since I've put the "unset GTK2*" line into the script, GTK apps pick their theme again:

#!/bin/sh

export LD_LIBRARY_PATH=/home/kdedev/kde/lib
export KDEDIR=/home/kdedev/kde
export PATH=$KDEDIR/bin/:$PATH
export KDEHOME=~/.kde4

unset GTK2_RC_FILES

. /home/kdedev/kde/bin/startkde

If you're still living under the "I use a GTK1 app" stone, put another line for GTK(1) apps in there.

Hope this tip keeps someone from tearing out hair. :)

Jorge Bernal: Function of the day: rgrep

Jorge Bernal — Thu, 08 May 2008 10:08:03 +0000

Add this to your ~/.bashrc

rgrep ()
{
grep -rin "$*" .
}

And you get a handy grep replacement

$ rgrep function wp_head
./general-template.php:785:function wp_head() {

Stephan Hermann: Move of www.sourcecode.de to new server successfull

shermann — Thu, 08 May 2008 08:55:38 +0000

I just moved the www.sourcecode.de webserver to my new machine.

The move was just straight forward, thanks to drupal.

The steps:

set Drupal into maintainance mode
mysqldump the drupal database with --opt
tar the whole drupal installation directory
scp everything to the new server
install apache2 , libapache2-mod-php5, php5-mysql and some other required php5 modules
configure php.ini, apache2 modules, apache2 sites
install postfix and configure it
restart postfix, restart apache2, adjust your dns, set IN A record to new IP for your host (you should do that with setting the TTL time downto 60 seconds, before you do such a move)
enjoy

straight forward...with a pre-requisites, it took now <= 30 mins.

Elizabeth Bevilacqua: I tweet

pleia2 — Thu, 08 May 2008 04:17:59 +0000

https://twitter.com/pleia2

Nicolas Valcárcel: Bugs!?

nxvl — Thu, 08 May 2008 02:43:10 +0000

Since i start in development i have had a question in mind, why the f*ck program errors are called Bugs? It seems that it’s for a whimsical reason as it’s said on How to Think Like a Computer Scientist: Learning with Python:

For whimsical reasons, programming errors are called bugs…

But the question finally has been answered!!! The firsts computer errors, given the size of the firsts computers, where caused by real Bugs interfering on the circuits and make the computers do unexpected operations.

Martin Pool: Bazaar gedit integration

Thu, 08 May 2008 00:47:20 +0000

Javier Derderian is working on ">">"integrating Bazaar into gedit, the GNOME standard text editor, so that you can very easily record changes, push them to a server, and so on. Bazaar's model that a branch is just a directory with extra metadata fits pretty well here. He just made another exciting release (or should that be "excited"? :-)

Martin Pool: Avoiding "not permitted to upload" errors from PPAs

Thu, 08 May 2008 00:47:20 +0000

Morten asked today on irc about an error I have hit before myself: you go to upload your new package to a PPA, and get an odd message of Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.

What this means is that your upload was trying to go into the Ubuntu distribution, rather than into a PPA, and you're not authorized to put it there. The underlying reason is that the command line for dput, the tool for uploading source packages, is

dput [options] [host] package.changes ...

It's easy to forget the optional host parameter and if it's omitted it uploads into the Ubuntu archive.

There is a pretty easy (if crude) way to disable this behaviour, by adding these lines to your ~/.dput.cf:

[DEFAULT] default_host_main = notspecified

[notspecified]
fqdn = SPECIFY.A.PPA.NAME

Pete Savage: Kdenlive building from svn…..still no luck :(

debug — Wed, 07 May 2008 21:57:41 +0000

Ok, I got it built. I had to make two small hacks.

1) I hacked up the script, line 287 becomes

export CFLAGS="$CFLAGS -I$DEST_DIR/include/libavcodec/ -I$DEST_DIR/include/libavformat/ -I$DEST_DIR/include/libswscale/ -I$DEST_DIR/include/libavdevice/ -I$DEST_DIR/include/"

else it complains that it can’t find the avcodec.h

2) Hack up a file in mlt source dir mlt/src/modules/avformat/Makefile
Change line 18, to read

LDFLAGS+=-L/home/pete/build/lib

However, even after doing this, it builds, but as soon as it starts, it segfaults, with this.

Continuing.
Qt: gdb: -nograb added to command-line options.
	 Use the -dograb option to enforce grabbing.
kbuildsycoca running...
kio (KMimeType): WARNING: KServiceType::offers : servicetype ThumbCreator not found
kio (KMimeType): WARNING: KServiceType::offers : servicetype ThumbCreator not found
kdenlive: //  INIT EFFECT SEARCH
kdenlive: ---------  close 1b
kdenlive: ---------  close 2b

Program received signal SIGSEGV, Segmentation fault.
mlt_properties_set (this=0x0, name=0x829fb1c "resource", 
    value=0x852a7b8 "/usr/share/apps/kdenlive/profiles/metadata.properties")
    at mlt_properties.c:277
277		property_list *list = this->local;
Current language:  auto; currently c
(gdb) bt
#0  mlt_properties_set (this=0x0, name=0x829fb1c "resource", 
    value=0x852a7b8 "/usr/share/apps/kdenlive/profiles/metadata.properties")
    at mlt_properties.c:277
#1  0xb6ce2bd8 in Mlt::Properties::set ()
   from /home/pete/build/lib/libmlt++.so.0
#2  0x081af929 in KRender::KRender ()
#3  0x081b0948 in KRenderManager::createRenderer ()
#4  0x081b0cd0 in KRenderManager::findRenderer ()
#5  0x08192dc6 in KdenliveDoc::KdenliveDoc ()
#6  0x0817c715 in Gui::KdenliveApp::initDocument ()
#7  0x0818a987 in Gui::KdenliveApp::KdenliveApp ()
#8  0x081d0781 in main ()
(gdb)

Any ideas??

Alan Pope: Ubuntu UK Podcast Episode 5 is Out

Alan Pope — Wed, 07 May 2008 21:22:48 +0000

Once again proving his editing prowess, Tony has managed to squeeze around 4 hours of wibble into a 40 minute podcast. Nice one.

In this episode:-

Discussion:
- An interview with Pete Savage.
  - progbox.vid
- A chat with Phil Newborough.
  - Random Ubuntu Advocacy
  - Crunchbang Linux
- We rate our Hardy upgrade experiences.
- Following up with our CLI vs GUI discussion with Laura Cowen.
In the news:
- gNewSense release version 2.
- Adobe opening up the FLV specs.
- The UK's Unix User Group has convinced the High Court to carry out a judicial review of the British Standard Institute's decision to vote in favour of Microsoft's controversial Office Open XML (OOXML) specification.
- 30th birthday of spam
- Sun in process of certifying Ubuntu.
Competition results!
- The winner of the trivia competition is announced. We'll send them a coupon for the Canonical Store to spend on whatever they want! We'll have another competition in Episode 6.

Comments and suggestions are welcomed to: podcast@ubuntu-uk.org
Up to 30 seconds of voicemail can be left at +44 (0) 845 508 1986
Follow our twitter feed http://twitter.com/uupc

Steven Harms: Valve to port Source games to Linux

admin — Wed, 07 May 2008 20:07:12 +0000

From Phoronix (http://www.phoronix.com/scan.php?page=article&item=source_linux&num=1):

“There have been rumors since last year that Valve may be serious about porting Source games to Linux after Valve Software began seeking a senior software engineer with the responsibility of porting Windows-based games to the Linux platform. Valve Software has yet to officially announce Linux clients for any of its software, but at Phoronix we have received information confirming that Valve is indeed porting its very popular Source engine to the Linux platform.”

Celeste Lyn Paul: KDE User Research Profiles (May 7 2008)

seele — Wed, 07 May 2008 19:54:49 +0000

Updates on current KDE User Research Profiles:

Plasma User Research Profile: A lot of good stuff came out of the Plasma Interviews and the work from Tokamak. I’d like to see more of this written up and discussed in public.

Both the Okular User Research Profile and Gwenview User Research Profile have some good stuff in their profiles. Remember that these profiles grow with the project, and as you expand your scope or add/change functionality, the profiles must be updated to remain useful.

This week, I would like to call on Kopete to begin working on their User Research Profile.

Instant messaging is an activity that nearly every type of user participates in and Kopete is one of the best instant messenger applications out there. But because Kopete has such a broad audience, it makes it that much more important to get all of the user types and use cases/scenarios documented. As always, ping me if you need help getting started.

Henrik Omma: UME testing

Henrik — Wed, 07 May 2008 15:39:06 +0000

As you may know, the Ubuntu team is working on a mobile version of the OS for mobile internet devices. But because there isn’t much of this hardware around, the UME builds don’t get the natural community testing that the desktop and server editions do. But if you are interested there is a way you can help!

The mobile environment can run in a Xephyr window. Setting up this environment is fairly easy and is described in detail here.

If you want to help with structured testing please follow the UME test cases starting with the desktop test. And if you find any bugs please file them under the ubuntu-mobile project in Launchpad.

If you have questions you can usually find cgregan, davmor2 or myself (heno) in the #ubuntu-testing channel. Have fun

Steven Harms: Fun with Amazon S3 in Ubuntu Hardy

admin — Wed, 07 May 2008 15:33:21 +0000

Project website: https://fedorahosted.org/s3fs

There are a few different projects calling themselves “s3fs”, but I have used this one with a lot of success. It is written in python and uses fuse, making it very easy to use on the desktop.

Prerequisites

Amazon Web Services Account - http://aws.amazon.com
sudo aptitude install python-fuse python-boto git-core
git clone git://git.fedorahosted.org/s3fs s3fs

Handy things
One thing that isn’t required, but is very handy, is s3cmd:
sudo aptitude install s3cmd

If you opted to install s3cmd, run s3cmd --configure and enter your amazon account details. From there you can run commands like s3cmd ls and s3cmd la to see items stored on your account and verify s3fs is working as expected.

Using s3fs
The first thing we need to do is put our access key and our secret key into the environment variables. This could be dangerous if your box is compromised as people could take your keys, but there isn’t much that isn’t dangerous if it’s compromised anyway. Ideally you can make a small bash script with your keys in it for when you launch s3fs and just chmod that 600 for your user, or make it prompt you using the bash ‘read’ command.

For playing around, just throw it in your environment (it will show up in your history, but if you enter a space before these commands it wont):
export AWS_ACCESS_KEY_ID="YOUR_KEY_ID_HERE" export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY_HERE"

Run s3fs
To run s3fs just change to the directory, and chmod +x if it isn’t already executable:
cd s3fs/src chmod +x s3fs ./s3fs --help

Create a bucket for your files
We need to create a “bucket” which is like a folder to store our files in:
s3fs -C -c ubuntushareddrive

I made up ubuntushareddrive, your bucket name needs to be a globally unique name for all of amazon web services, so you might want to add some numbers at the end of it etc.

After that, we need to “format” our s3fs bucket:
s3fs -C -f ubuntushareddrive

From there, we can mount it and are good to go:
mkdir ~/amazon_drive
s3fs -o bucket=ubuntushareddrive ~/amazon_drive/

For questions on this process, please leave comments on the blog first. If you find a bug, there is a trac page at https://fedorahosted.org/s3fs

Martin Pitt: HAL is dead, long live DeviceKit

martinpitt — Wed, 07 May 2008 12:52:05 +0000

Thanks to David for summarizing the future of hardware management. Interesting read, and the thread promises an interesting discussion.

Patrice Vetsel: Nouveau T-shirt Hardy

Kagou — Wed, 07 May 2008 12:48:00 +0000

Mise à jour de mon billet sur le T-shirt spécial Hardy, un nouveau T-shirt est disponible et celui-ci n'est pas en quantité limitée, même s'il n'est qu'en pré-commande.

Update of my ticket about the new limited edition Hardy Heron T-shirt, a new version is available and it is not limited in quantity, although it's in pre-orders.

Martin Pitt: My computer discovered playing games

martinpitt — Wed, 07 May 2008 09:54:35 +0000

The other day I read about the current c’t programming contest and got addicted immediately. The task is to create a program which plays the Atari Asteroids game from 1979:

Unfortunately they do not send that gem to everyone :-), but they do send the original 8 KB of ROM, so you can play it on the MAME emulator.

So far I got the emulator and the game running, and have a Python script which tracks the objects and their velocity vectors. I spent half of the weekend doing the vector analysis bits with good old pencil and paper. Reviving all the maths bits from school (about 11 years ago) was a lot of fun! Now I have useful formulas for determining the shooting angle to hit a moving comet from a moving and decelerating ship, determining if and when two moving objects with given radius collide, etc. In my head I have a first cut of a strategy, too.

Now I just need to find some time to actually implement all of this…

Once the contest is over, I’ll publish my sources, in case anyone else is interested.