It is nearly two months since I switched from Debian/Ubuntu to Fedora/RHEL. And I start to miss Debian tools…
Under Debian (which also means derivatives like Ubuntu) I used simple set of tools and I have found their Fedora replacements:
The problem with Fedora tools is that they feel like few years behind Debian ones ;(
While Debian world moved to use “quilt” to manage patches in source packages few years ago, Fedora’s RPM just got it recently so it is hard to find package which makes use of it. Updating patches is far from being pleasure.
Yum (and it’s younger brother ‘dnf’) work in other way than APT. But are usable and do what they have to. The fun starts when you run “yum upgrade -y” on slow machine (like AArch64 model) and someone will regenerate repository data in meantime — you end with 404 errors cause repodata/ directory uses random file names…
rpmbuild works. It even has some limited support for running separate steps. But without dependencies between them so “rpmbuild -bi specfile” needs “rpmbuild -bc specfile” first while in Debian world “debian/rules install” is enough. There is also “--short-circuit” option to not clean build directory when you want to go through single steps. But resulting binary packages are tainted and can not be installed without using “–nodeps” switch to RPM. I see a sense behind it but it hit me hard on AArch64 when I was building Qt (do not ask how long it took cause I did it several times during last 2 months).
Then we have mock. Argh… I put it in one line with pbuilder but it is not worthy. No user setup possible, just one build at time (my machine is now 10% busy) make mock wasting lot of developer time. I opened bugs with feature requests for user config and multiple builds — hope that one day it will appear.
And last entry is what I like. Both fedpkg and rhpkg allow me to clone git repository of package so I can create patches for packaging in quick way. In Debian world I never used such tool. Under Ubuntu packages were kept in Bazaar repositories but you know already what I think of this SCM.
Yesterday I switched my home desktop from Ubuntu 13.10 to Fedora 19 to have work environment ready for my Red Hat tasks.
Installation was easy as Fedora installer does not ask too many questions. But also does not give any software choice so I took KDE one. Made a backup of Ubuntu rootfs and /home partition and 10 minutes later I was running same X11 session but with Fedora logo in a corner.
Installing extra packages is argh… There is yum and basically nothing else. I tried Apper and Yumex — none of them was useful. Apper was unable to remove Konversation and message I got was useless (“some package depend on it” like). Yum did not have any objections. Yumex was even worse as it gave me a list of all packages without any grouping applied. Even “dselect” was better in 1999 when I started with Debian.
So I installed APT. This one works but only kind of… “apt-cache search something” takes eons, installing packages is impossible due to a way how RPM works…
Because RPM allows to have more than 1 version of package installed at same time. WHY? How it is supposed to work at all??? And no, I did not have any filesystem corruptions or something like that…
Anyway those problems can be bypassed or ignored. But then there are other ones. I always thought that Debian legal team has very strict rules about what can go into distribution. Fedora proved that I was wrong. External repositories are a must have here. MP3 or AAC playback? Forget. Probably also video playback etc. Want Google Chrome? Forget. I understand why Adobe Flash is not in repo (but there is one with it as well) but all that? Probably there are more entries here but I did not yet finished installing stuff I use/need.
Will have to add few tweaks here and there (like bumping “nr_uarts” kernel option to have all 7 serial ports) but it works. And I like “journalctl -b” way of checking what was going on since system boot ;D
After 3 years at Linaro I have decided to not continue my trip with Canonical. So now I am back to be on my own again.
I will not write why I made such decision but also want to mention that time at Canonical/Linaro was good. I learnt some new tools and added some of them to “avoid if possible” list. From products created and developed at Canonical there are Bazaar and Unity. Both have replacements which I like more.
What next? Will see — I had some meetings and discussions. But I am open for job offers of course ;) It can be Debian or OpenEmbedded or Ubuntu or other ARM Linux related as long I do not have to move.
During ELCE in Barcelona I spoke with guys from Qualcomm about their new board, what it is etc. Some time later guys from Intrinsyc (manufacturer of board) contacted me with free coupon for it. I ordered board and received few days later. Played a bit then but my Linaro work occupied me so it went back to the box.
During Linaro Connect in Hong Kong I bought small mini-ITX case to have a way of storing Dragonboard in safe way under desk as I thought that it may be interesting machine for doing some ARM development. There is SATA, Ethernet, USB 2.0 on board so why not…
It came with Android 4.0.4 installed on on-board eMMC. I hope to replace it with Ubuntu or Debian one day. But first have to get kernel newer than 3.0 working on it.
Which may lead into usual problem — there is only vendor kernel for it as mainline lacks support for it. Probably kernel/msm repository from CodeAurora will be fine. Will see.
A bit to big to be useful as FM radio but had to check it ;D
That day had to come. It was just a matter of time. Debian bootstrapped new architecture port using just own tools and packages…
It was long trip. During last few years we saw bigger amount of work spent in Debian/Ubuntu on cross building packages. Then were Google Summer of Code projects on bootstrapping Debian and one for multiarch cross toolchains. And we had Wookey with his ideas, knowledge and abilities to get one thing to work on for months in a way that managers were agreeding that it needs another month and another ;)
And today I found an email from Wookey about AArch64 port. I suggest you to read it as it has a lot of information. You can find ready to use rootfs there which (connected with kernel from OpenEmbedded) boots to fresh Ubuntu 13.04:
Ubuntu Raring Ringtail (development branch) localhost ttyAMA0
localhost login: root
Last login: Thu Jan 1 00:07:37 UTC 1970 on ttyAMA0
Welcome to Ubuntu Raring Ringtail (development branch) (GNU/Linux 3.8.0 aarch64)
* Documentation: https://help.ubuntu.com/
root@localhost:~# uname -a
Linux localhost 3.8.0 #1 SMP Wed Feb 20 14:31:07 CET 2013 aarch64 aarch64 aarch64 GNU/Linux
You need to have patience as Upstart needs to run lot of stuff before it gives login prompt.
Still lot of work required as there are many patches to packaging waiting for being merged but I think that it is a big day for Debian and all distributions derived from it.
This year no one blocked me from going to FOSDEM ;D
What are plans? There will be some AArch64 related talks which I want to attend:
- Bootstrapping Fedora for AArch64
- Bootstrapping Debian/Ubuntu for AArch64
- Porting software for AArch64
- Porting OpenJDK for AArch64
- What the hell is AArch64
Few ARM ones:
- Freedreno update
- Open ARM GPU drivers
- ARM status in Linux kernel
Few for entertainment:
- Buildroot contra Debian
- Baserock introduction
Some for curiosity:
- Why there is no such thing as FOSS phone?
Original titles may differ. There are over 450 events during FOSDEM, several keynotes etc. There will be also few thousand people so I would rather not find a time to attend even half of sessions listed above… But for me this is how this conference work :D
Normally I do not take hardware with my (other than phone). This time I packed two boards, two tablets and hope to get rid of most of them ;)
Most of my work at Linaro is around AArch64 architecture. Ubuntu cross compilers were kind of adopted by Matthias Klose (Debian/Ubuntu toolchain maintainer) so I was able to spend more time on ARMv8.
We have two projects at Launchpad:
In short: first one is about porting software to ARMv8, second about OpenEmbedded support for it. The fact that both projects are on Launchpad does not mean that they are for Ubuntu (which is common mistake). It is open for everyone. We have people working on fixing packages in Debian, Fedora, Ubuntu (when it comes to distributions) and in OpenEmbedded. All of that with usual mantra: upstream first.
So how it goes today? I would say that quite good. Since September (when we started OpenEmbedded work) we got to point when we fixed several projects and find less and less new ones to work on.
For me it is nice experience. As I am not a programmer (my last application was for AmigaOS in last millennium) I was often surprised how small changes are sometimes needed to get software running. I got X11 running with ~8 lines of code. Libav required editing of one line in configure script. NumPy was adding 4 lines. OProfile required copying few lines from kernel source. And all those got merged upstream or is on a way to it.
If you want to track our work then check “Merge ARMv8 support into OpenEmbedded” blueprint where I track every project I touch. And ignore ‘milestone’ field — it is always work in progress because every project we fix gives us new projects to build. Which often means another set of software to patch.
I prefer not to think how much it would take us without OpenEmbedded. Being able to just easily cross compile huge amount of software in automated way is great. Sure, from time to time I had to boot software model and do some native compilation or run some tests. But mostly to generate some files which are not properly built/guessed during cross compilation.
Also I would like to thank all maintainers (from OE and upstream projects) for reviewing all our patches and all help we got. But we did not finished yet — there is a long queue of things to clean up and send for merging :)