Chris Tyler's Blog - Fedora

Looking for a Debugging Mentor

nospam@example.com (Chris Tyler) — Wed, 20 Feb 2013 13:12:46 -0500

I'd love to figure out why my Toshiba Z830's screen-brightness controls work fine after suspend but don't work after hibernate with Fedora 17 (I have two-phase suspend/hibernate set up). I'm comfortable doing debugging but don't even know where to start on this one -- I don't know which subsystems to poke at.

Anyone willing to mentor me through this?

Acessing the armv6hl Koji Buildsystem

nospam@example.com (Chris Tyler) — Mon, 11 Feb 2013 14:24:10 -0500

The Seneca CDOT OSTEP project has been operating a Koji buildsystem for the Fedora ARM Secondary Architecture project, for the armv5tel and armv7hl architectures. These architectures are going to shift to the Fedora Phoenix datacentre Real Soon Now(tm) now that true enterprise-grade ARM server hardware is available.The armv5tel architecture has hit EOL with Fedora 18, but will be supported with updates until a month after the release of Fedora 20; we (the Fedora ARM group) is working towards Primary Architecture status for armv7hl by the Fedora 20 release.

We (Seneca OSTEP) are now also operating a second Koji buildsystem, for the armv6hl architecture. This architecture is really of interest only for the Raspberry Pi at this point in time. This buildsystem is accessible on the web at http://japan.proximity.on.ca/koji/

However, to access the armv6hl buildsystem using the Koji command-line tools, using a Fedora client certificate, a bit of a dance is required. This post outlines the steps...

1. Set up your Fedora packager environment, if you haven't already done so.

2. Add this text to the end of your ~/.fedora-server-ca.cert file:

3. Place this text in /etc/koji/armv6-config:

[koji]

;configuration for koji cli tool

;url of XMLRPC server
server = http://japan.proximity.on.ca/kojihub

;url of web interface
weburl = http://japan.proximity.on.ca/koji

;url of package download site
topurl = http://japan.proximity.on.ca/

;configuration for SSL athentication

;client certificate
cert = ~/.fedora.cert

;certificate of the CA that issued the client certificate
ca = ~/.fedora-upload-ca.cert

;certificate of the CA that issued the HTTP server certificate
serverca = ~/.fedora-server-ca.cert

4. Execute this command: sudo ln -s /usr/bin/arm-koji /usr/local/bin/armv6-koji

5. Ping someone on the OSTEP team via irc://irc.freenode.net/seneca to add your FAS2 username to the Koji instance.

6. Profit! -- You should now be able to issue commands to the armv6hl koji system by typing: armv6-koji command

In due course, we'll get this configured as a standard secondary-arch Koji instance, and you can skip the steps above -- but in the meantime, if you want to help with the armv6hl effort, those are the steps required.

Why the Pi is Great for Teaching and Hacking

nospam@example.com (Chris Tyler) — Fri, 18 Jan 2013 15:03:01 -0500

Today at FUDCon I gave a lightning talk on interfacing devices to the Raspberry Pi, to try and explain why this device is so interesting to both educators and hackers.

Here's a recap of the demo for those who weren't there (or if I missed something); I was using a Pi running the Raspberry Pi Fedora Remix 17, and the point of the demo was to show how simple devices can be controlled (or sensed) directly from the command line (using just four commands: cd, ls, cat, and echo, plus sleep and the bash while...do loop):

1. Output

The Raspberry Pi has a number of General-Purpose Input/Output (GPIO) pins available on a connector on the corner of the board. These can be used as inputs or as outputs, and can be on (binary 1) or off (binary 0). The pinout diagram is available on the web.

Connecting up an output can be as simple as taking an LED (from any electronics part store, or snipped out of a dead PC) and a small resistor (I used a 220 ohm one - red/red/brown) and connecting them to one of the GPIO pins and a ground pin. In the demo I used GPIO 11 and ground, with a tiny breadboard and some male-female jumper wires for convenience.

The software side is pretty simple: there's a directory, /sys/class/gpio, that provides access to the GPIO pins. By default, this directory contains just three entries:

# cd /sys/class/gpio
# ls -l
total 0
--w------- 1 root root 4096 Dec 31 1969 export
lrwxrwxrwx 1 root root    0 Dec 31 1969 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
--w------- 1 root root 4096 Dec 31 1969 unexport

Placing a GPIO number in the export file gives us control of that GPIO:

# echo 11 > export

And the kernel responds by creating a directory corresponding to that GPIO pin:

# ls -l
total 0
--w------- 1 root root 4096 Jan 14 18:39 export
lrwxrwxrwx 1 root root    0 Jan 14 18:40 gpio11 -> ../../devices/virtual/gpio/gpio11
lrwxrwxrwx 1 root root    0 Dec 31 1969 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
--w------- 1 root root 4096 Dec 31 1969 unexport

The gpio11 directory contains a number of pseudo-files for controlling the pin:

# cd gpio11
# ls -l
total 0
-rw-r--r-- 1 root root 4096 Jan 14 18:41 active_low
-rw-r--r-- 1 root root 4096 Jan 14 18:41 direction
-rw-r--r-- 1 root root 4096 Jan 14 18:41 edge
drwxr-xr-x 2 root root    0 Jan 14 18:41 power
lrwxrwxrwx 1 root root    0 Jan 14 18:39 subsystem -> ../../../../class/gpio
-rw-r--r-- 1 root root 4096 Jan 14 18:39 uevent
-rw-r--r-- 1 root root 4096 Jan 14 18:41 value

The files we care about are direction and value. The direction is initially set to input (in), which we can see if we cat the direction file:

# cat direction
in

We can change the pin to an output by writing out into that file:

# echo out > direction

The value file will tell us if that pin is off (0) or on (1):

# cat value
0

If you set this value to 1, the LED should turn on:

# echo 1 > value

If it doesn't, you probably have it plugged in backwards. Switch the wires (I'll wait).

Once the LED is on, you should be able to turn it off by setting the value to 0:

# echo 0 > value

From an educational perspective, this is really cool: it makes a concept (bit) tangible.

But turning the light on and off gets boring quickly. The next step is to write a command-line loop to make the LED blink:

# while true; do echo 1 > value; sleep 0.2; echo 0 > value; sleep 0.2; done

What if you want to control something a lot bigger than an LED? Just substitute something like a Powerswitch Tail II for your LED - your Pi connects to an LED inside the tail, and whenever that LED is turned on, the water pump/blender/fan/toaster plugged into the tail starts up.

2. Input

Connecting an input is not any more complicated. In the demo, I hooked up an old Turbo Mode switch (remember those?!) to GPIO 24. In one position, it connected GPIO 24 to 3.3 volts, and in the other position, it connected it to ground.

Using this switch as an input was even easier than controlling the LED:

# cd /sys/class/gpio
# echo 24 > export
# cat gpio24/value
0

... Now toggle the switch! ...

# cat gpio24/value
1

3. Input & Output

Putting both of these together is pretty straightforward. You can control the flashing of the LED using the switch with a line like this:

# while sleep 0.1; do if [ $(<gpio24/value) = "0" ]; then echo 1 > gpio11/value; sleep 0.2; echo 0 > gpio11/value; sleep 0.2; fi; done

For education, these experiments are simple, quick, and don't require a lot of background knowledge: the student needs only a handful of basic bash commands (cd, ls, cat, echo). Unlike an Arduino, the Pi doesn't need a separate system to host development. You also don't need to deal with files, interpreters, shebang lines, permissions, or compilers. But eventually (and usually pretty quickly), students will want to learn those concepts. In order to save their commands across boots, for example, they will soon want to store them in files: voila, scripts!

It's logical and easy to progress from controlling a single LED and reading a single switch to controlling six LEDs - enough for a two-way traffic light - and then you can add things like pedestrian crossing buttons. Or you can use two infrared LEDs and two infrared phototransistors (which act exactly like switches), mounted in a doorway, to count the number of people that have entered and exited from a room, turning on the lights whenever people are present. These types of projects are fun and engaging ways to teach logic, programming, and circuits.

After a while, students want to do something they can't easily do in bash, like drive a GPIO faster, or poll some complex combination of pins and they're on to Python (or C, or Perl, or any of a multitude of other languages).

When students/hackers/makers want to connect something more complex than can be easily interfaced through GPIO, the Pi offers serial ports (you can put a message on an LCD display with two bash commands), I²C, and SPI interfaces. And although the ARM processor in the Pi is fairly slow, it is fast enough to do interesting things like speech synthesis and machine vision.

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 links

nospam@example.com (Chris Tyler) — Wed, 29 Feb 2012 17:38:21 -0500

The Raspberry Pi hardware went on sale last night, and as with every other event related to the Pi, pandemonium ensued!

The educational, tech, and mainstream media is starting to take note. Here are some links to local coverage of the Pi and our work on the software for it:

Update 2012-03-03 - additional links:

Radio Canada International - Masala Canada
CBC News - Lang and O'Leary Exchange (segment starts at 47:05)

Update 2012-03-10 - additional links:

MindShare Learning Report - March 2012

To clarify Seneca's involvement, because it may not be clear from the press coverage:

The Raspberry Pi Foundation created the Raspberry Pi hardware, and has licensed its production to a pair of UK-based production and distribution companies, Farnell (which has wordwide subsidiaries including Newark here in Canada) and RS Components (Allied Electronics in Canada).
The Centre for Development of Open Technology (CDOT) within Seneca College works with the Fedora ARM group within the Fedora Project to produce a build of Fedora for ARM devices. One of our roles is the creation and operation of the build system, a cluster of more than 60 ARM-based computers used to build the ARM software.
My research group at CDOT and my Software Build and Release (SBR600) classes at Seneca worked together to produce the Raspberry Pi Fedora Remix, which takes the Fedora ARM software and adds a small number of additional software packages needed for use on the Pi. We tested the remix on an alpha (pre-production) board provided by the Foundation.

Information about the Remix may be found on the Seneca CDOT wiki.

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.

Raspberry Pi Giveaway at FUDcon Blacksburg

nospam@example.com (Chris Tyler) — Sun, 15 Jan 2012 10:26:59 -0500

If you received a Raspberry Pi certificate at FUDcon Blacksburg, please send me an e-mail (ctyler@fp.o) with your certificate number and I'll mail you a coupon code that you can redeem at RaspberryPi.com

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.

Fedora ARM PandaStack

nospam@example.com (Chris Tyler) — Wed, 09 Mar 2011 13:19:58 -0500

The PandaStack I mentioned previously - a stack of PandaBoards mounted on threaded rods, powered by a modular ATX power supply - is now a fully-functional part of the Fedora ARM project koji buildsystem.

For anyone interested in building a similar stack, here's the parts list and assembly instructions:

15 PandaBoards (or whatever quantity you wish to stack; the photo here shows 11 boards, since we have temporarily removed 4 for various device driver test projects)
15 barrel connectors
1 ATX 750W modular power supply (note: higher-rated power supplies may not have more current available on the +5v rail, which is what is used in this project)
4 threaded #4-40 stainless steel rods. (Note: BeagleBoards accept a #6-32 thread, but PandaBoards have smaller mounting holes).
1 pack (100) 0.25" nylon spacers
1 pack (50) 1.25" nylon spacers
2 packs (10) stainless steel acorn nuts
SD cards, ethernet cables, network switch
hacksaw, soldering iron, solder, wire strippers, heat-shrink tubing, heat-shrink gun (or embossing craft gun), multimeter

Cut the threaded rods to size with the hacksaw. Stack the boards on the rods, reversing the orientation of every second board so that it is upside down with the ethernet jack facing the opposite side of the stack; this will result in ethernet and power jacks down two opposite sides of the stack, with serial ports on another side and no connectors on the remaining side (which is the "bottom" of the stack). Use the 1.25" spacers between adjacent boards in a right-side-up/upside-down pair, and the 0.25" spacers between pairs. The grounding strips on the top of each ethernet/USB connector tower will just touch the plastic cases of the LED drive transistors on the adjacent board in each pair. Fasten the stack with the acorn nuts.

Gather the barrel connectors in groups of five. Connect each group to the +5 volt (pin 1) and ground (pin 2/3) leads of a molex connector from the ATX power supply (cutting off the cable connected to the molex connector, and ensuring that the barrel connectors are wired center-positive). Solder, then insulate with shrink-wrap tubing. Take the motherboard connector of the power supply, pull off all of the leads except pins 8 (PWR_OK) and 16 (PS_ON), solder those leads together, and insulate with shrink-wrap tubing. Plug the molex and motherboard connectors into the ATX supply.

Place the stack on its side on a wire shelf for convection cooling. Test the power supply leads to ensure you're getting a solid +5 volts, burn and insert your SD cards, connect your ethernet cables, and connect the boards one at a time to the power supply unit with the barrel connectors.

Enjoy your silent tower of computing power!

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!).

PandaStack

nospam@example.com (Chris Tyler) — Tue, 22 Feb 2011 09:43:47 -0500

Our "PandaStack" of PandaBoard builders (shown here with 9 of the 15 builders installed) is now ready to run as part of the Fedora ARM build farm. However, I've run into a weird problem -- the ATX power supply I bought to power the boards works fine with 1-3 boards, but Something Bad happens when a fourth board is connected. It's not a capacity issue as far as I can see; it seems to be related to noise. Time to borrow a scope and take a close look at waveforms ... in the meantime, we'll power some of the boards with the ATX supply and some with stand-alone power bricks.

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 )

Fedora, Seneca, and FUDCon Tempe

nospam@example.com (Chris Tyler) — Thu, 27 Jan 2011 01:13:27 -0500

This semester is the fourth time that I've run the Software Build and Release (SBR600) course at Seneca College, and we have record enrollment a full house! This course is one of a number of open source courses connected with the Centre for Development of Open Technology; it is a professional option in our Computer Systems Technology program, which focuses on network and system administration, and it has two goals:

Teach software build and release (aka Release Engineering/Build Team) principles, technology, and skills
Teach how to contribute effectively in an open source community

In this course, I use the Fedora build and release process as a illustration of how large-scale build and release works, something which is only possible because of the transparent nature of open source processes. I also use Fedora as a community which is open to worthwhile contributions from any interested participants. In these first three weeks of the course, we've examined building from source, RPM packaging, the use of mock for build dependency testing, the use of koji for multi-platform testing, signing packages, and creating package repositories. The remainder of the semester is largely project-based.

The students are currently researching and selecting projects from a short list of potential projects which have been screened for manageable size and practical real-world value. This semester, many of these projects are focused on the Fedora ARM secondary architecture, since the ARM buildsystem is physically located at Seneca, but some projects are related to different areas within Fedora (or, in one case, Fedora+Mozilla). In all cases, the students are expected to work with the community, use community communication tools and practices, and ultimately, advance the state of the respective area to which their project contributes. That means that if new software is packaged, it will be put through package review and end up in Fedora; if scripts or programs are written, they will be reviewed and committed upstream; and if documentation is written, it will end up in an appropriate and accessible place such as the wiki.

On Friday, ten SBR600 students will be traveling with Paul Whalen and me to FUDCon Tempe eight students from the current semester and two from the previous semester. They're looking forward to making connections with other Fedorans, hearing about the latest and greatest technology, hacking, and generally starting down the road to becoming active contributors.

Please join us! -- I invite you to check out what we're doing, either in the usual Fedora places or in the #seneca channel on Freenode, on the Seneca wiki, or on Planet CDOT.

ARM Spam!

nospam@example.com (Chris Tyler) — Thu, 05 Aug 2010 11:50:48 -0400

My apologies to anyone experiencing a large volume of build notifications from the fedora-arm koji system. We're attempting to build F13 and are experiencing a lot of build failures (as expected).

I've added some dependency checking to the build script (big thanks to Seth Vidal for the yum code snippets!) which should make it a bit smarter about build order. Build notifications have been turned off until we get the failures down to reasonable levels.