If you are involved as a package maintainer in Fedora you have probably already heard "do the fix in primary and koji-shadow will pick it up". The procedure is that all builds in primary Fedora (x86) are replicated in the secondary Fedoras (ARM, PPC, s390) using as close buildroots as possible. Generally only when a build doesn't exist in secondary, because it fails to build, it is replaced by a newer build. The 2 levels of architectures exist because the secondary architectures are not so widespread among Fedora users and a failing build on secondary architecture doesn't affect the package flow in primary. I was told that the original koji-shadow wasn't meant for building secondary architectures and this functionality (the ability to include newer builds in buildroots) was only later added there by Dennis Gilmore. Another useful feature is importing of noarch builds instead of their rebuilding, it saves important portion of the buildsystem resources.
The koji-shadow tool can run in 2 modes - doing a single build (all missing dependencies will be also built) or scanning a tag and queue all missing builds. I will now describe the improvement koji-shadow received in the previous months and also some existing features.
koji-shadow supports 2 lists for packages that won't be built, these lists are merged together and the packages listed there are skipped, but it allows to use one list generated automagically from the ExcludeArch/ExclusiveArch tags in source RPMs and the second list can be manually maintained and contain packages where queueing a build is waste of resources, but it still wasn't decided whether it will be fixed or properly excluded,
you can use globs in the ignore list, so I can have "nodejs-*" on s390 and nothing from the nodejs stack will be included on s390 because it depends on v8 and v8 is exclusive for x86 and
ARM architectures
originaly koji-shadow required all builds to be rebuilt to finish, which is not always the situation in the prefer-new mode, some of them can be skipped, now it always finishes when there are no more packages to built,
the single build mode wasn't compatible with the prefer-new option, it required all dependencies to be present, now when a tag is specified on command line, it is able to run in prefer-new mode, the tag is here to allow searching the replacements for the missing builds
running in the prefer-new mode originaly resulted in including the newest build when the exact build wasn't present, often causing dependency problem when a too new build was included, now the closest newer build is included
this is an existing capability, but became more important now, sometimes a build in secondary Koji is successful, but causes additional broken dependencies or simply doesn't work, this is the use-case for "substitute", so the bad build can be replaced by an older (or newer), but good one
And what you can expect in the future? Karsten prepared a patch to print information which failed builds are blocking the most other build and also has logging improvements in development, right now I use the logging feature of screen to capture the output. In the longer term work is being done to integrate koji-shadow with fedmsg and start builds when they finish in primary and not to rely on periodical scans. Naturally additional ideas are welcome, when patches will be attached the better :-)
The koji-shadow tool can run in 2 modes - doing a single build (all missing dependencies will be also built) or scanning a tag and queue all missing builds. I will now describe the improvement koji-shadow received in the previous months and also some existing features.
ARM architectures
And what you can expect in the future? Karsten prepared a patch to print information which failed builds are blocking the most other build and also has logging improvements in development, right now I use the logging feature of screen to capture the output. In the longer term work is being done to integrate koji-shadow with fedmsg and start builds when they finish in primary and not to rely on periodical scans. Naturally additional ideas are welcome, when patches will be attached the better :-)
I'm the maintainer of wxWidgets library in Fedora and I get requests in bugzilla to update wxWidgets to the latest version which is 2.9.4 since July last year. And the answer is still NO, so let me explain it here. wxWidgets is a complex library written in C++ and behaves as a good member of open source community, because it maintains API and ABI stability (using the symbol versioning) across releases during whole stable series like 2.8.x. It means that an application built against one version of the library will work with a newer version without any rebuilds. And this is not true for the 2.9 series, it's a development series where API and ABI is not maintained meaning when the library is updated, all applications must be rebuild and when they fail to build then someone must fix them and there are dozens of them in Fedora. So what are the options? Wait for the wxWidgets 3.0 release, I agree it can take a long time. Another is to use the wxGTK3 packages I prepared for my repository which are installable in parallel to the wxGTK 2.8 series from Fedora. And also any person commited to work with other packager maintainers on fixing wxGTK 2.9 related issues is free to submit wxGTK3 for review and maintain it.
The Tryton team released the regular batch of updates for all supported releases this week and so I have spend a bit more time on packaging them. Because finally there are repositories for Red Hat Enterprise Linux 6 (and clones) for various major versions of Tryton. The policy for Fedora doesn't change, it will always stay on the version that was released with (eg. Fedora 16 has Tryton 2.0), but now it's possible to stay on any Tryton version (>=1.8) on enterprise Linux for the whole time upstream will support it. And now the overview:
| OS | Version | Tryton version | Repository |
|---|---|---|---|
| Fedora | 16 | 2.0 | Fedora |
| 2.4 | Danny.CZ | ||
| 17 | 2.2 | Fedora | |
| 2.4 | Danny.CZ | ||
| 18 | 2.4 | Fedora | |
| RHEL | 6 | 1.8 | EPEL |
| 2.0 | Tryton 2.0 for EL | ||
| 2.2 | Tryton 2.2 for EL | ||
| 2.4 | Danny.CZ for EL |
The Danny.CZ repos will always carry the latest available Tryton version. It also means that when Tryton 2.6 is released I will move the 2.4 version to a separate repository for enterprise Linux. Also work is ongoing on packaging the missing modules that were missing the previous Tryton releases. So stay tuned :-)
As you may know I am a fan of all Atari computers, starting with the 8-bits going over the ST line and ending in the newly developed FireBee. I already provide some Atari related tools and emulators in both Fedora and my add-on repository During browsing on the Internet I have found that Vincent Rivière provides up-to-date cross-tools Ubuntu and Cygwin packages containing compiler, assembler and C and math libraries for the 32-bit line of Ataris and I immediatelly started to think about packaging them for Fedora to expand my support. So starting today the packaged tools for Fedora and RHEL (and clones) are available in my repository.
The obligatory Hello World example (taken from Vincent's web):
The obligatory Hello World example (taken from Vincent's web):
[dan@eagle dan]$ yum list m68k-atari-mint\*
Zavedeny zásuvné moduly: auto-update-debuginfo, downloadonly
Dostupné balíčky
m68k-atari-mint-binutils.x86_64 2.22-1.fc16 danny
m68k-atari-mint-filesystem.noarch 2-2.fc16 danny
m68k-atari-mint-gcc.x86_64 4.6.3-2.fc16 danny
m68k-atari-mint-mintbin.x86_64 0.3-2.20110527.fc16 danny
m68k-atari-mint-mintlib.noarch 0.58.0-4.20111028cvs.fc16 danny
m68k-atari-mint-pml.noarch 2.03-2.fc16 danny
[dan@eagle dan]$ sudo yum install m68k-atari-mint-gcc
[dan@eagle dan]$ cat > hello.c << EOF
> #include <stdio.h>
>
> int main(int argc, char* argv[])
> {
> puts("Hello, world !");
>
> return 0;
> }
> EOF
[dan@eagle dan]$ m68k-atari-mint-gcc hello.c -o hello.tos -O2 -Wl,--traditional-format
[dan@eagle dan]$ ls -l hello.tos
-rwxrwxr-x. 1 dan dan 83690 27. bře 10.19 hello.tos
[dan@eagle dan]$ file hello.tos
hello.tos: Atari ST M68K contiguous executable (txt=50784, dat=1504, bss=2952, sym=30338)
I would like to outline what is the plan for the Fedora Secondary Architecture lab on the Red Hat Developer Conference this Friday and Saturday in Brno. We should have a people working on PPC, ARM and s390 present, so we should be able to answer your questions about installation and other specifics on these arches. We can also discuss the infrastructure side, do some kernel hacking for ARM devices and anything else related to the secondary arches. It really should be an interactive event and not only a presentation of some boring facts, so be active :-)
Dear developers,
many thanks to you for bundling hopefully modified libraries [1] in your open source projects. You can be almost sure that your otherwise useful application won't be part of a major Linux distribution like Fedora or Debian.
Your package maintainers
PS: There are definitely more reasons that complicate the way to a distribution like e.g. imprecise licensing, but the bundled libraries one made me really angry during the weekend. And it was in a such nice application ...
PS2: The article may contain irony, cynicism and others
many thanks to you for bundling hopefully modified libraries [1] in your open source projects. You can be almost sure that your otherwise useful application won't be part of a major Linux distribution like Fedora or Debian.
Your package maintainers
PS: There are definitely more reasons that complicate the way to a distribution like e.g. imprecise licensing, but the bundled libraries one made me really angry during the weekend. And it was in a such nice application ...
PS2: The article may contain irony, cynicism and others
It's again time to upgrade my Fedora 14 installations to something newer (= Fedora 16). I was always doing upgrades with preupgrade since Fedora 8 (only to even numbers, they are more stable :-)) and now I've chosen an online upgrade with yum, because my /boot partition was too small. And the result is - yes, it's doable. Without going to the details, because I didn't write any notes during the process, the steps were:
And voila, Fedora 16 is booting and running. During the Fedora release upgrade I've also switched from Gnome to XFCE desktop environment. Bye bye Gnome, it has been nice years, but Gnome 3 is incompatible with how I do my work.
- install new fedora-release package
- yum update glibc, because there was some dependency error reported by rpm
- yum update - 1.6G in ~2200 packages were downloaded, few packages had to be removed from the F14, they were causing broken dependencies
- grub2 was manually installed using the steps from http://fedoraproject.org/wiki/Featu
res/Grub2#How_To_Test - reboot, in fact the power switch had to be pressed because the soft way was not possible due the change from upstart to systemd
And voila, Fedora 16 is booting and running. During the Fedora release upgrade I've also switched from Gnome to XFCE desktop environment. Bye bye Gnome, it has been nice years, but Gnome 3 is incompatible with how I do my work.
This is a short update how we stand with Fedora 16 on the s390x architecture. And the short answer is it looks good :-). Fedora 16 on s390x is closer to primary (aka x86) Fedora than Fedora 15 was, we have a pre-GA composes that are installable (for existing issues see our wiki, it will be converted to the form of Release Notes), signing of the (50k+) rpms is in progress and will be followed by preparing final repository and installation images.
The visual representation of the progress is here
The visual representation of the progress is here
As you can see the secondary architectures in Fedora (especially s390x, ppc and arm) are keeping the pace with primary Fedora (aka i386 and x86_86) quite well, especially when taking into account the limited resources they have. So if you have positive relation to non-x86 architectures and would like work on secondary architectures in Fedora we have an option for you. Red Hat is hiring a Fedora release engineer with primary focus on the PowerPC platform, where he/she will prepare the testing and final releases, work on the build system infrastructure, work with architecture maintainers on package build failures and much more. But naturally he/she will be in touch also with other architectures because the goal is to share the underlying infrastructure. So if you would be interested in such job or you know someone else who could be interested, please let me know. And if the release engineering is not your area, let me know too :-)
What would other maintainers and developers of the secondary architectures in Fedora say to setting up a meeting at FUDCon in Milano? In addition to discussing and exchanging our expertise regarding Koji, build processes and infrastructure we could do little presentation of our results for other visitors. I would take a software implementation of the mainframe architecture for presenting Fedora/s390x, the logistics for a real hardware would be rather complicated ;-) But for Fedora/ARM a broad scale of devices could be presented, not sure about PowerPC or SPARC hardware.
