BeagleBone Black on Linux: running from an uSD card

BeagleBoard Black can boot either from internal eMMC (that’s default), or from the external uSD card. The GettingStarted page is useful http://beagleboard.org/Getting%20Started , but it does not give direct instructions for Linux users. And the preparation and booting from an uSD image is very simple.

First, download an image you want to use, for instance from http://beagleboard.org/latest-images

Then you have to decompress it. Ark and tar in the recent version support the .xz format.

Now connect the uSD card you want to use and find out which device it is. I use dmesg for this. Note that normally the card already has partitions, so you’ll have /dev/sdb1 for instance. What we need is the device itself, so /dev/sdb for instance.
The flashing can be done with dd:

dd if=Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.08.21.img of=/dev/sdb bs=64k

Wait a couple of minutes. It takes time.

When it’s done, disconnect your BBB from any power sources and insert the card.

Then press the USER button. It’s the one without clear name, on top of the uSD card, next to HDMI.

Now,  keep the button pressed and connect power. Keep it pressed until two LEDs are on
(there will be some blinking during the process).

Then it’s done, you can connect to your BB to verify that you have booted from the bigger image. I’m using minicom or screen:

minicom -D /dev/ttyACM0

or

screen /dev/ttyACM0


Commit Digest Cheat Sheet Part 2: the Merge Commits

With git, many developers tend to work on branches, even for longer time. Then they merge them into the ‘master’ branch when the functionality is finished, the freeze is over and so on.

In the Commit Digest we usually do not include commits outside of the master branch. Because of this, we can miss some of the interesting functionalities. Some developers have started putting DIGEST tag to their merge commits with information on the branch content. I really like the idea. If you develop a new function or some important refactoring during a longer period of time, make sure you include the DIGEST tag if you want to be sure the Commit Digest includes it.

Commit Digest Cheat Sheet Part 1: the DIGEST tag

This post is inspired by an Akademy discussion with a developer who likes the Commit Digest but didn’t know about the DIGEST tag 🙂

The KDE Commit Digest http://commit-digest.org/ provides weekly review of KDE developers activity. The reviewers of the Digest choose the commits to include based on the developer’s commit message and the commit content itself.

However, the change that is clear to the developer, may not be at all clear to someone with less knowledge of the project internals. There are two basic ways you can tell the Digest reviewers that your commit is important:

• Use the DIGEST tag in your commit message to mark the commit, normally at the end of your commit message. Use it as additional description of the general effect of your change. This can look like this: “DIGEST: This implements The New Great Function”.
• Write easy to read message that describes the function of the commit. Example: “With this change The Function Everyone Uses works 50% faster”).

Hint: Do not be afraid to use the DIGEST tag. The reviewers will make the decision and they generally prefer to have too many of those tags (this is a strictly theoretical situation at this moment) than not enough.

New article: Understanding How Messages Appear to Translators

When translators and developers look at the same program, the see different things. For the developers, the code is clear. There is context around. For the translators, however, it is different. They just see the message text. It’s good to have a document that describes the two views.

Lasse Liehu has just finished a Techbase page about the subject. You can access is here: http://techbase.kde.org/Development/Tutorials/Localization/Message_Appearance .What I really like about this that it is full of illustrations. You can see the same situation from two viewpoints yourself. I recommend the example with “d/M/yyy”. That is a situation when
a context comment is really welcome.

I think this document is a must-read for both developers and translators. And if your program is not yet ready for translations, search Techbase for more documentation.

Akademy 2013: l10n BoF Impressions

We had a BOF on translation issues on this year’s Akademy. Many people came up and we really didn’t have time to discuss everything. However, it was a very interesting meeting and a needed one. Sebastien made a summary on the translators’s list: http://lists.kde.org/?l=kde-i18n-doc&m=137413658517601&w=2

The common reservation system
The Google Summer of Code work is on the way. Up to this point different teams developed different solutions to handle the management of their teams, like the translation reservation. The GSoC work is going to provide a common tool. We were discussing mostly the details like authentication for translators and new people. The general agreement was that we’re going to try the new methods. The functionality will be optional and each team will decide if they’re going to use it or not.

Wiki translation workflow
Currently the wiki translations are somewhat apart from the main translation work. There is no information to the translation team if somebody joins the wiki translation, there is no automatic notification of the changes either. Most of the teams expressed concerns on the wiki translation quality and prefer the wiki translations to be linked more to the general ones.

Reporting a typo
It was a surprise to me to learn that most of the teams have problems getting user feedback, like typo reports. The Bugzilla system is not working well for such cases.

In the Polish translation we have a note to the user about this in the “About translations” window. It says to send a typo/clarification request to a mailing list. It was there since long ago and seems to work quite well.

We came with an idea to add a new window next/in the “Report a bug” one that allows to contact the translation team. I find it a good idea and it looks that it is also OK for kdelibs.

What we did not have time to discuss…
After my Akademy presentation, many translators told me that they also have a need for more promotion efforts. We did not have time to discuss it at the BoF, but we’ll use the mailing list for that.

KDE Commit Digest: How to make your commit seen?

I had a presentation at Akademy this year, talking about the way developers can use their commit messages to promote their projects further. The short version of the talk is: make the commit messages easy to understand and if you have an important new feature, add the DIGEST tag.

Slides the presentation are online. You can download them from:
my blog, Akademy site or my site.

Commit Digest is recruiting!

KDE Commit-Digest provides an overview of the developers activity in KDE. However, bringing it to the readers every week requires significant number of people to review and classify the commits (thanks to developers!) on regular basis. That’s why we’re continously waiting for contributors!

Participation in the Commit-Digest offers an unique perspective on what is happening in the repos in real-time. Visit us and join as an editor, commit classifier or commit reviever, or any combination of those functions.

GCI Follow-up

I’m in progress of making all the work done by the students during GCI to the main repository. We (the Polish team) had 10+ tasks, all were taken and finished. Impressive.

Currently all the screenshots are updated and I’m going through the correction suggestions. There are many of them and I think they will add quality to Polish KDE documentation (mostly, as most tasks were in the documentation area) and the desktop itself.

Thanks again to all the students who participated!

4.6

Pliki z tłumaczeniem KDE 4.6 już od pewnego czasu znajdują się w gałęzi stabilnej, pliki i statystyki można pobrać z: http://i18n.kde.org/stats/gui/stable-kde4/team/pl/

Gałąź trunk to (przyszłe) 4.7. Nie są planowane kolejne wydania z serii 4.5.

Częste problemy: Your names/Your emails

Jest kilka błędów popełnianych typowo przez początkujących tłumaczy KDE.

Jeden z najczęściej spotykanych to dosłowne tłumaczenie komunikatów Your names/Your emails. Czemu nie? Pierwsza wątpliwość powinna pojawić się w spojrzeniu w kontekst (w Lokalize: na dole po lewej stronie): NAME OF TRANSLATORS.

Jakie więc jest prawidłowe tłumaczenie? W Your names należy wpisać swoje imię i nazwisko. W Your emails adres poczty elektronicznej. Te pola zostaną automatycznie wstawione w okno Pomoc->O programie … ->Tłumaczenie.