Building Yocto/Poky on openSUSE Factory

Since a few weeks, openSUSE Factory no longer is labeled as "openSUSE Project 13.2", but as:

seife@susi:~> lsb_release -ir
Distributor ID: openSUSE project
Release: 20140918

When trying to build the current Yocto poky release, you get the following Warning:

WARNING: Host distribution "openSUSE-project-20140918" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.

Now I know these warnings and have ignored those before. The list of tested distributions is hard coded in the build system configuration and in general it would be a bad idea to add not yet released versions (as 13.2) or rolling releases. And since the Factory release number changes every few days, it is clearly impossible to keep this up to date: once you have tested everything, the version has increased already. But apart from this, purely cosmetic warning, there is a really annoying consequence of the version change: the configuration cache of bitbake (the build tool used by Yocto poky/OpenEmbedded) is rebuilt on every change of the host distribution release. Updating the cache takes about 2 minutes on my machine, so doing a simple configuration check on your already built Yocto distribution once a week can get quite annoying. I looked for a solution and went for the "quick hack" route:

• bitbake parses "lsb_release -ir"
• I  replace "lsb_release" with a script that emits filtered output and is before the original lsb_release in $PATH

This is what I have put into ~/bin/lsb_release (the variable check is a bit of paranoia to let this only have an effect in a bitbake environment):

#!/bin/bash

if [ -z "$BB_ENV_EXTRAWHITE" -o "x$1" != "x-ir" ]; then

        exec lsb-release $@

fi

printf "Distributor ID:\topenSUSE project\nRelease:\t2014\n"

Then "chmod 755 ~/bin/lsb_release" and now the warning is

WARNING: Host distribution "openSUSE-project-2014" has not been validated...

And more important: it stays the same after updating Factory to the next release. Mission accomplished.

UPDATE: Koen Kooi noted that "Yocto" is only the umbrella project and what I'm fixing here is actually the "poky" build system that's part of the project, so I edited this post for clarity. Thanks for the hint!

Fix openSUSE's grub2 for Virtualization and Servers

After installing current openSUSE Factory in a VM, I found that the old GRUB option was removed from YaST2. I knew this from the mailing list, but now I actually realized that this happened. I still prefer GRUB over GRUB2, because for me it is easier to manage. But being lazy, I just went with the default.
Everything went well, until I added a customized kernel (I had installed the VM to do some kernel experiments after all). The boot menu suddenly was not very useful anymore. After selecting "advanced options", I got the following:

Well, which one of the four is now my hand-built, brand new kernel?
There is no such thing as in old GRUB where "Esc" got you out of gfxboot mode and into text mode. The command keys, like "e" for editing the current selection and "c" for a GRUB2 shell (something even more hellish than the old GRUB shell apparently) work, but you really need to know this, as there is no indication of that.

So I wanted to get rid of the gfxboot stuff. I don't need fancy, I need it usable.
Booted the VM, logged in. "zypper rm grub2-branding-openSUSE" followed by "grub2-mkconfig > /boot/grub2/grub.cfg". Much better:

But still it is in graphics mode, which I do not care about now, but once I have to deploy this stuff on something like an HP server where you can get a text console via SSH, but only if it is in plain VGA mode, I will not be amused. So boot that VM again, and look further. Finally, the solution is in /etc/default/grub: "GRUB_TERMINAL=console". The comment above says just uncommenting the original "gfxterm" setting would be enough, but it is not. After recreating the config file and rebooting, it looks quite useful:

And it is not even missing information, compared to the gfxterm version... no idea why this stuff is default.

Now that "Distribution" string in there looks completetly redundant, so getting rid of that will help, too.
Again, it is in /etc/default/grub, variable GRUB_DISTRIBUTOR. I see that in the grub2 rpm package, there is only "openSUSE" instead of  "openSUSE Factory Distribution", so it might be put into the config by the installer or something. I'll change it to just "Factory" (to distinguish between other openSUSE installations). After grub2-mkconfig, it looks almost good:

Now the important information (Kernel version) is completely visible. Much better than the original "bling bling" screen, which had no useful information at all...
Just fixing the Factory string would probably have helped also, but it still would fail the server test, so plain console will stay my favorite for now.

Restoring stock recovery on Moto G

Yesterday, my Moto G got an Official update to Android 4.4.4. Yeah!
Unfortunately, it did not work: After downloading the update, the phone went into a boot loop, because CWM 6.0.4.6 (which I had installed in order to root the device) cannot flash the update. The phone then boots up, just to shut reboot almost immediately into recovery to try again.
To get out of this boot loop, I manually entered recovery and wiped the "cache" partition.
I retried with the latest CWM 6.0.4.7, this also did not work.
So I had to get the original stock recovery image for the Moto G and flash that. I did not easily find it with a web search, so in the end I downloaded the matching stock SBF image for my installed firmware (in my case "Blur_Version.176.44.1.falcon_umts.Retail.en.DE") from the Moto G firmware page on droid-developers.org, looked into the zip file and found that there is a "recovery.img" in the archive.

Now everything was easy: boot the phone into fastboot mode (power on + volume down), then

fastboot erase recovery

fastboot flash recovery recovery.img

reboot, once the phone is booted select "install system update" from the notification, stock recovery boots and installs the update, done.
I did not even lose root access, so I kept the stock recovery for now.
Later on I checked the md5sum of the recovery.img I flashed and of the recovery partition on the phone and they are identical, so the 4.4.4 update did not flash a new recovery for me. I'll keep the old one around in case I need it again.

Recovering my OwnCloud admin user password

Because of its endless awesomeness, I'm running an ownCloud instance on my server at home.
What I'm actually using of it is the WebDAV frontend to up/download stuff from Android (the native ownCloud App seems to have problems with really big files, such as several hundred MB) and the "instant upload" feature for the android camera, to automatically upload photos for easy reusing on the PC.

Today I wanted to configure some stuff and found out that I had totally forgotten the admin password, simply because I never needed it after the initial setup.

Modern applications no longer just store the passwords in the database, so it's not as simple as it could be. Additional problems arise from the fact that I have basically zero database knowledge.
Fortunately, I still knew that I'm using a mariadb on the server...

So that's what I did to restore admin access:

• cat config/config.php, note values of "dbuser" and "dbpassword"
• mysql -u <dbuser> -p;
• paste <dbpassword>
• show databases;
• note that there is a database called "owncloud", which is probably the one I need...
• use owncloud;
• select * from oc_users;
• Oh! My admin user is called "root", not "admin" as I would have guessed... Important information. So I try to use the password reset from the web form for user "root", however, it does not work...
• select * from oc_preferences;
• Oh! "root" has no email address configured, no wonder the password reset does not work.
• After some searching, I found the way to the solution in the ownCloud forum:
• INSERT INTO `oc_preferences` ( `userid` , `appid` , `configkey` , `configvalue` ) VALUES ( 'root','settings','email','root@localhost' );

And voilà: the password reset link is working, root get's an email which contains the link to set a new password. Life is good again :-)

"Drive-by-bugfixing" and why I might not bother anymore

I like to call this "drive-by-bugfixing" and this is how it usually happens:

• I have a problem with e.g. xfce4-power-manager, which I'm unable to fix right now


• I check out some random other package (let's call it "yerba-power-manager") to check if it can replace xfpm for me


• I find it has a bug. Or two. Actually caused by broken openSUSE patches trying to implement new APIs


• Because it is "an interesting problem", I fix it them just for fun


• Later I find that I have no use for this package as (for unreated reasons), it does not fix any of my original problems

So far so good. Now I have a fixed package lying around in my home:seife buildservice repository. Trying to be a good cititzen, I submit it back to the original YERBA desktop project.
Can you imagine what happens next?
Correct! It gets rejected. Why? Because I did not mention all my patches in the changelog.

Come on guys. Policies etc. are all fine, but if you want people helping maintain your broken packages, then don't bullshit them with policy crap, period.
I had done the heavy lifting last sunday and fixed the bugs, now all that the desktop maintainer would have needed to do would have been to amend the changelog.

Well, I am not that interested in that particular desktop and its problems, so I just revoked the submitrequest and am done with it. I fixed XFPM instead :-)

And yes, I understand very well that such policies are a good thing to have, and necessary, and if I'm contributing to some subproject on a regular basis, then I of course make sure that I'm following these rules. On the other hand, it's really easy to discourage the occasional one-time contributor from helping out.

(Names changed to protect the guilty)

FreeDNS update mit FRITZ!Box

(This post is in german, since the router is commonly used in german-speaking countries)

Ich benutze seit längerem FreeDNS anstelle von Dyn.com oder ähnlichen Diensten, hauptsächlich weil das Update so einfach ist: einfach einen personalisierte URL per "wget" oder "curl" aufrufen und schon ist die eigene IP geändert, es wird keine spezielle Software benötigt. Dieser URL enthält eine Zeichenkette die den eigenen Account identifiziert, sie enthält aber nicht den Usernamen oder das Passwort. Somit ist es relativ ungefährlich, diesen URL in z.B. einem cronjob einzutragen: sollte jemand diesen String mitlesen, so kann er im schlimmsten Fall die IP falsch updaten, was zwar lästig aber relativ harmlos ist.

Nachdem Dyn.com küzlich die kostenlosen Accounts gekündigt hat, war das Thema FreeDNS für einige Bekannte auch aktuell, die größten Bedenken kamen allerdings daher, daß der in die FRITZ!Box eingebaute Dynamic DNS Unsterstützung FreeDNS nicht unterstützen würde. Das ist so nicht richtig:

Im Webfrontend, unter "Dynamic DNS" einfach "Benutzerdefiniert" auswählen, als "Update-URL" dann den URL einsetzen, die man in der Accountverwaltung auf http://freedns.afraid.org/dynamic/ als "Direct URL" bekommt.
Als "Domainname" wird der angemeldete Domainname eingetragen. Die FRITZ!Box prüft nach ob sich dieser auflösen lässt und meldet einen Fehler, wenn das nicht funktioniert.
Leere "Username" und "Passwort" akzeptiert die FRITZ!Box nicht, also habe ich in die Felder einfach "x" eingetragen. Fertig.

Getestet hier auf einer FRITZ!Box 7390 mit FRITZ!OS 06.03.

(Update 13.4.2014: "Domainname" ergänzt)

VDR updated to 2.0.x

I finally got around to update VDR to version 2.0.x
I'm using this version since some time and it is working fine for me. However, I'm quite sure that there are some kinks to be ironed out.
I'm not sure if updating from an old openSUSE VDR installation is a good idea or if it would be better to start from scratch. Personally, I'd do the latter and only keep my channels.conf.

The recommended way for starting VDR from systemd is now the runvdr-extreme-systemd package, the old runvdr init script is still available from the vdr-runvdr package, but is completely untested.

Configuration now happens in /etc/runvdr.conf, the old /etc/sysconfig/vdr is no longer read at all.

Normally, only the used plugins need to be added to runvdr.conf like

AddPlugin streamdev-server
AddPlugin epgsearch --logfile=/var/log/epgsearch/log --verbose=3
AddPlugin xineliboutput --local=none --remote=37890

This should be the equivalent of old sysconfig values

VDR_PLUGINS="streamdev-server epgsearch xineliboutput"
VDR_PLUGIN_ARGS_streamdev_server=""
VDR_PLUGIN_ARGS_epgsearch="--logfile=/var/log/epgsearch/log --verbose=3"
VDR_PLUGIN_ARGS_xineliboutput="--local=none --remote=37890"

The settings in runvdr.conf are commented, so the config file should be easy to understand.

If you are using vdradmin-am and are importing the old vdradmin.conf (I'd actually advise to start from scratch there, too) then you need to change the SVDR port setting to the new default of 6419 (or change the SVDRPORT variable for VDR to the old value).

The "supported" plugins are maintained in the "vdr" repository of the openSUSE Buildservice. I'm collection "unsupported" additional plugins in "vdr:plugins". The definition of "supported" right now is "the stuff that I use", simply because I cannot really test stuff that I don't use on a daily basis. Of course if someone wants to help maintain these things, I'm more than willing to move things into the main "vdr" repository.
Stuff that is in the supported repository will most likely end up in Factory and thus in openSUSE 13.2.

Bugreports via bugzilla or the opensuse-factory mailinlist, please ;-)