Chris Tyler's Blog - JustFedora Planet

When is an SRPM not Architecture-neutral?

nospam@example.com (Chris Tyler) — Fri, 23 Nov 2012 22:13:55 -0500

Source RPM packages -- SRPMs -- have an architecture of "src". In other words, a source RPM is a source RPM, with no architecture associated with it. There's an assumption that the package is architecture-neutral in source form, and only become architecture-specific when built into a binary RPM (unless it builds into a "noarch" RPM, which is the case with scripts, fonts, graphics, and data files).

An SRPM contains source code (typically a tarball, and sometimes patch files) and a spec file which serves as manifest and build-recipe, plus metadata generated from the spec file when the SRPM is built -- including dependencies (which, unlike binary RPMs, are actually the build dependencies).

However, the build dependencies may vary by platform. If package foo is built against bar and baz, and baz exists on some architectures but not others, then the spec file may be written to build without baz (and the accompanying features that baz enables) on some architectures. The corresponding BuildRequires lines will also be made conditional on the architecture -- and this make total sense. However, querying an SRPM on a given platform may give incorrect build dependency information for that platform if the SRPM was built on another platform -- and only rebuilding the SRPM on the target arch will correct the rpm metadata (and possibly render it incorrect for other platforms). Thus, I've come to realize, SRPMs are not truly architecture-neutral -- and I'm not sure if all our tools take this into consideration.

Edit: I know that not all of our tools take this into consideration.

Continue reading "When is an SRPM not Architecture-neutral?"

Raspberry Pi Fedora Remix 14 - Release Event this Wednesday!

nospam@example.com (Chris Tyler) — Mon, 20 Feb 2012 11:04:45 -0500

The computer education, hardware hacking/maker, and open source worlds are all eagerly anticipating the release of the $35 Raspberry Pi computer before the end of the month. In preparation for the hardware release, tthe Raspberry Pi Fedora Remix 14 distribution is being released this Wednesday, February 22.

Full details of the event are on the CDOT wiki. Everyone's invited, and I hope to see you there!

Update: Fixed link above.

Fedora ARM on the Raspberry Pi at Seneca CDOT

nospam@example.com (Chris Tyler) — Wed, 19 Oct 2011 16:53:37 -0400

What happens when you combine a $25/$35 computer, a major Linux distro's secondary arch effort, and a college that's deep into open source?

You get Fedora-ARM running on the Raspberry Pi at Seneca CDOT!

Here's a tiny video peek...

&amp;lt;/p&amp;gt;

&amp;lt;/body&amp;gt;
&amp;lt;/html&amp;gt;

There's a lot of optimization still to be done (including X11) but look forward to a Raspberry Pi Fedora image (spin/remix), Fedora 15 for ARM, and the Raspberry Pi device itself all being available next month.

(In or near Toronto? There are three talks related to Fedora ARM and/or the Raspberry Pi at FSOSS next week).

Gnome 3: Not Ready for Prime Time in Fedora 15

nospam@example.com (Chris Tyler) — Sat, 23 Apr 2011 12:19:17 -0400

I've been intrigued by the Gnome 3 desktop and the design decisions that the Gnome project has decided to test. Hearing some members of the Gnome community explain the design decisions in person was very interesting, and helpful when transitioning to the Gnome shell. And I'm proud that the Fedora Project is continuing to lead by incorporating new technologies and designs First.

But I've been using Gnome 3 in the Fedora 15 alpha and beta releases for a while now, and I'm convinced that Gnome 3 is not ready for prime time yet, at least as implemented in Fedora 15 (and this is completely separate from the issue of whether the Gnome 3 design changes are good or bad, and whether the Gnome community is ignoring the needs and wants of the users and downstreams -- both subjects of much debate). As one example, multi-monitor setups are not working as expected, at least for me. In fact, it's a stretch to say that they're working at all:

On my laptop/netbook, logging in with an external monitor connected results in Gnome 3 running in degraded mode, with Gnome 2-style menus. Logging in without an external monitor connected, and connecting it after login, results in a usable configuration - at least all of the real estate is accessible.
I run with the external display above my laptop. Maximizing a window on the external display results in it filling the rightmost 1/3 of the screen. Unmaximized windows may be moved, but only to positions where the right edge of the window is within the right-most 1/3 of the screen. You can fill the screen by placing the window all the way to the right and dragging a corner to the left side, though. There are many other behaviours which are just weird.
The Activities button is on the laptop screen, but the touch-to-activate-Activities corner is on the external monitor.
Rearranging the position of the monitors using the Displays setting tool results in badly torn, messed up images. They resolve to something that looks almost usable a fraction of a second before the Does this look right? dialog gives up and reverts me to the original configuration, with my desktop backgrounds missing.

This is 2011, and multi-monitor configurations are not a novelty any more. In fact, they're the norm where I work, and I use external monitors with my laptops and netbooks all the time

Perhaps some of these issues are video driver problems, and Gnome 3 isn't to blame. But the problems with Gnome 3 are not limited to just multi-display configurations; for example: GDM's list of users does not scroll properly when the list is long (I went to file a bug on that one, but was disheartened searching through the 253 other open Fedora GDM bugs to see if it was already reported). If something goes wrong during the login process, a message appears telling you that something went wrong, but offering no way to find out what went wrong -- not even through a "Details..." button -- and the only action available to the user is to click a button marked "Ok" (I can't login? It's definitely not OK). The icons at the top of the screen respond to left- and right-click in the same way -- except for the iBus icon -- where's the consistency in that?

I don't want to be a gloomy Eeyeore (though I understand the temptation to become one) but I really don't think we're close to release-ready with Gnome 3 in F15.

Running Fedora ARM without ARM Hardware, Made Easy

nospam@example.com (Chris Tyler) — Mon, 28 Feb 2011 16:41:16 -0500

The Fedora ARM secondary architecture project reached a significant milestone last week with Paul's announcement of the beta 1 release.

Interested in ARM but lacking ARM hardware? Not a problem! Fedora includes support for ARM virtual machines, and I'm packaged up a preconfigured ARM VM for your convenience:

ARM virtual machine package: http://scotland.proximity.on.ca/arm/armvm/noarch/armvm-f13beta1-15.fc13.noarch.rpm
Repo config for staying up-to-date on ARM VM releases: http://scotland.proximity.on.ca/arm/armvm/noarch/armvm-release-1-1.fc13.noarch.rpm

The armvm package will install a preconfigured ARM virtual machine named "f13-arm-beta1" with a 2GB image and a 128MB memory footprint. Since x86_64 processors don't provide hardware support for ARM processor virtualization, the ARM VM will run slowly compared to i386/x86_64 VMs, but the performance should be tolerable on most machines (Atom netbooks excepted). You can manage the VM with virsh or virt-manager. I've tested these packages on F13 and F14, but not on F15 Alpha yet. (By the way: the root password on the VM is "fedoraarm").

Enjoy!

(Please don't forget that both the Fedora ARM beta release and the armvm package are very definitely at the pre-release/beta stage of maturity. In particular, updating the armvm package will REPLACE your arm VM with a new image - beware!).

PandaBoard Building Fedora-ARM

nospam@example.com (Chris Tyler) — Mon, 07 Feb 2011 23:48:17 -0500

We're adding a group of dual-core, 1GHz, 1GB PanadaBoards to the Fedora-ARM build farm. Paul Whalen and I hacked up the PandaBoard builder filesystem at FUDCon and I tested it with the farm on Thursday -- so far, it appears to build about twice as fast as the older GuruPlug builders. The PandaBoard's randomly-assigned-at-boot MAC addresses did force us to take a new approach to builder identity, though, because our previous approach of serving the identity via DHCP was no longer practical.

We ordered a total of 15 PandaBoards; 12 have arrived, and the others should be shipped shortly.Two are being set aside for testing, and we'll get the other ten building as soon as possible.

Our plan is to stack the boards on threaded rods, powered by an ATX power supply; the stack will be run on its side (with the boards oriented vertically) to aid in convection cooling. More photos to follow as we get this running! (Yes, that is a Powered by Fedora badge on there )