• Esse quam videri.


  • Archives

  • Control Room

  • Categories

Finding old test packages in Koji.

After I answered a question on the devel list today about getting one’s hands on an old testing package for Fedora that had been obsoleted or removed, Josh Boyer one-upped me by providing some easy instructions. I figured I would tip my fedora to him by building a blog post on his work. Nice one, Josh!

When someone builds an official Fedora package, whether it ultimately gets moved to stable or not, there’s a record for it in Koji, the Fedora package build system. You can use the search bar on the Koji website to find the package or build you’re inerested in. In the resulting page, you’ll find the build is labeled with the git commit from which the build came — it’s the long checksum in the “Task” line.

The package may not be there anymore, but that git label is all you need. It represents the position in the repository history from which the packager built that package. You can find that point in history and re-execute the same steps. You can then clone the package’s git repository, reset the HEAD to the proper commit, and send a scratch build to the Koji builder. Once the build is done, you can download the results.

Caveat: It’s possible that other package changes in Fedora might make a build of that exact point in history difficult later. Be aware this solution isn’t perfect, and you may simply want to find an alternate build in Koji that still exists and suits your purpose, or use the latest updates-testing or stable package instead. But in the hopes people find it useful, here are the commands, assuming the package name is “foobar” on Fedora 16 and the git commit of interest in starts with “0123abcd” (and let’s hope I do better than in the last post in which I gave tips):

su -c 'yum install fedora-packager'
cd /tmp
fedpkg clone foobar
cd foobar
fedpkg switch-branch f16
git reset --hard 0123abcd
fedpkg scratch-build
The URL that comes back to your console is the task for that build, and you can use that to drill down into the individual package build tasks as needed later. Remember, scratch builds are not retained for very long, so if you want the package, try to download it relatively soon after you build it.

Here’s another hint: the git reset command above rewrites your index and your working tree, so essentially you “lose” the later history of the repository. However, git is so awesome that this is not a permanent condition. If you really need to reset the git repository back to its original path, you can use git reflog to find the reference to the checkout you did of the “f16″ branch, and reset to it (probably something like this):

git reset --hard HEAD@{1}
Once again, it’s important to point out that the above is not for the faint of heart. If you don’t understand the ramifications of trying withdrawn, obsolete, or deleted packages on your Fedora machine, or packages intended for testing, don’t use them. That being said, testing packages is a really helpful activity, and there are all sorts of easy ways to keep testing contained on your system, such as using virtual guest machines. So the intrepid needn’t be shy!

Note for Fedora 16 early testers.

If you’re like me and you couldn’t wait to see Fedora 16 in its pre-release state, you take on the risk of any pre-release. Sometimes things are broken, or break during the fixing process, with the goal of making everything more awesome in its final form. Today I ran into such a problem, and I wanted to share it. Hopefully this problem should be fixed in the final release; I’ve already filed a bug for this issue and it’s been resolved in a later package.

Currently the Fedora 16 updates-testing version of selinux-policy* packages is 3.10.0-43.fc16. This policy doesn’t adequately cover some file locations used by systemd to handle passphrases on LUKS encrypted file systems. If you use encrypted file systems (at least as provided by the Fedora installer) and usually type your passphrase during the boot process, you’ll probably be affected. The plymouth loader won’t get the request to display the passphrase, and you won’t be able to enter it. So systemd will timeout waiting for the ability to mount those file systems, and your boot will fail with a maintenance prompt.

If you want to get past this problem, provide your root password and then enter the following commands:

systemctl start local-fs.target
systemctl default

This will present the necessary prompt at the console (once per file system), and then try to boot to the default target again. To fix the problem, once you’ve booted successfully, downgrade the affected packages:

yum downgrade selinux-policy\*

That should get you back the 3.10.0-40.fc16 packages, which don’t encompass checks on the affected systemd files and therefore don’t produce the errors.

As I mentioned, this has already been fixed and new testing updates should be out shortly. I wanted to make this particular problem visible since it does actually prevent booting an installable configuration right now, since I know many intrepid testers may run across this blog on our Planet.

Installing Fedora 16 pre-release.

I’m a little late this cycle to move my laptop to the Fedora pre-release. (Note the web site doesn’t yet feature the Fedora 16 Beta — that should change next Monday around 10:00 US Eastern time.) I had tried some Live USBs along the way and they were generally looking great, but before now I hadn’t had the spare time to do the installation and test to make sure my various workflow bits were all working normally. Today I finally took the plunge.

Unfortunately, there was one problem standing in my way — an Anaconda bug that pops up in certain pre-existing LVM configurations. Fortunately, the always beneficent Dave Lehman from the Anaconda team had kindly provided an update image for Anaconda that addresses the bug. He even reminds people in the bug how to use it live off the Web with an installation.

That was really helpful for me, because it should be noted I’m actually installing from the current development/16 tree, and not the Fedora 16 Beta RC4, which was declared gold yesterday. So the problem I ran into isn’t likely to happen to other people. The update fixing this problem is in the Beta, but because Dave published this image I could simply install from my local pre-F16 mirror. Which I proceeded to do.

The installation was completely unremarkable aside from this bug, with no extra surprises. I do know that the Anaconda team is working very hard with Máirín Duffy on a UI overhaul. That’s supposed to see the light of day in the next release, Fedora 17. For now we’ll have to content ourselves with the existing UI and things just working as always… ho hum!

After the installation completed, I rebooted. Weirdly the boot seemed a bit faster than it was before, particularly getting from GRUB to the point where I enter a passphrase for my encrypted filesystems. That could easily be some subjective bias, but hey, I was happy anyway. I went through firstboot, provided my user information, and after the SELinux labels and permissions were checked and restored and I finished firstboot, I got the new login screen.

The background picture with the little submarine is really sweet. Last release, Fedora 15 featured the standard GNOME 3 background in the default install, as a tip of the hat to a major milestone release for GNOME. This release, the Fedora Design team was back in action and did a nice job on a stylish background that’s interesting without overwhelming the desktop. And of course, it’s in several fetching shades of blue, my favorite color for many reasons.

But the login dialog itself, part of GNOME 3.2, is also really swank! With smooth animation and fading, it now feels so much more polished from the very beginning of the signon process. I know there are lots of other improvements and cool stuff in GNOME 3.2 and I can’t wait to explore them. I did run into some errors when I logged in, such as the “sad GNOME” even though the interface seemed to work fine. But it’s important to note when I installed, I didn’t include the latest updates of everything in the Beta, so it’s likely I’m seeing problems that are already resolved. I ran an update on the system shortly thereafter to get the latest packages from the updates-testing repository, and I also did a sudo touch /.autorelabel to make sure all the SELinux labels were restored properly on the system, and rebooted. As a result the problems I saw simply vanished.

For now, suffice it to say that I think people will be fairly impressed with the Fedora 16 Beta and can take the opportunity to report bugs as they find them. The most important part of having a free software release that’s done transparently is that it allows you to become part of the process. If you run into a bug, it really helps when you report it. It can be frustrating when something doesn’t work, but it’s important to remember a lot of people are working on this software as part of a gift culture. So help them out in return by politely reporting bugs and, if you have just a little more time to spare on top, work with them to test the solution to resolve it. Your gift will help countless others, just as developers’ gifts help you and me.

Enjoy your weekend!

Trying out Fedora 16 Alpha.

I’m sure there will be plenty of news reports on the wire with Fedora 16 Alpha reviews. I wanted to share a couple brief thoughts, as opposed to a long review. I downloaded a copy of RC5 (which is the candidate that got the gold star) from the stage location and made it into a Live USB stick using the livecd-tools package’s livecd-iso-to-disk tool. These were some things that popped out at me when I was using it:

  • The Design team’s background image is quite striking. Although it’s a little higher energy than some previous desktops, I really like the underwater motif (I liked the underwater background in Fedora 9 too). From what I understand, the login screen should have some significant changes shortly, and that should show off the background well.
  • My ThinkPad x220′s hotkey (Fn+F8) for switching the touchpad on and off now works! This is fantastic because I often find myself brushing the touchpad, which is not recessed, and it can cause me problems in some interfaces. But at the same time, I don’t like turning it off in the BIOS because (1) I do sometimes use it in mouse-only interfaces, and (2) although I have no problems altering BIOS settings, I don’t think users should have to interact with them, especially when they have a clearly labeled keyboard function they should expect to work.
  • Bluetooth wasn’t working for me at all. This was only a brief test and I had no time to track down the problem. It’s quite possible this is a hardware dependent issue specific to my ThinkPad. So this is merely an observation, and if it’s not done already I’ll be looking further into the situation later, and filing an appropriate bug.

Sadly, I don’t have quite as much time to do deep testing of Fedora as I used to. So the above is basically a minimal report from about 3 minutes of usage I was able to fit in a couple nights ago. But I can say I’m looking forward to doing more! Remember that if you’re testing and finding problems, we need bugs! Without them it’s really hard to make a better product. So do your part for free software, and report them. :-)

Nice work to all those involved thus far with the release and all the collateral that goes with it.

Fedora 15 rocks on ThinkPad.

On Friday my new Lenovo ThinkPad x220 arrived and of course in the evening after I finished work, I was jonesing to put Fedora 15 on it. The machine is a type 4286CTO (Smolt info here). I started by booting into the BIOS and checking the options as shipped by Lenovo. There wasn’t much to change here, other than to enable hardware virtualization so I could more easily run KVM on the laptop should I choose to do so later. I didn’t enable the extra direct IO option, VT-d, because I’ve seen it cause weird installation problems in a lot of cases.

While I was starting to work on my new laptop, I also took the time to refresh my backup of data on the laptop I’ve been using, a ThinkPad x201 graciously lent to me by Tim Burke when my Dell XPS M1330 started to go belly-up a couple months ago. I used rsync to sync everything to a large USB drive.

Then I grabbed a spare 64-bit Fedora 15 Live USB key with the standard Desktop image and booted from it, just to see what I might expect from an installed system. I was impressed (but not really surprised) to see that everything worked great out of the box (with one trivial exception I’ll cover below). Not only the standard stuff like video hardware acceleration, special keyboard buttons, Bluetooth, sound, and suspend/resume, but also stuff like the webcam (at full resolution) and wireless. So I tried an installation from the Live key, and everything went fine — and fast, due to the new 2nd-generation “Sandy Bridge” Core i7 processor on this notebook.

Booting that went flawlessly, so I decided to try a more full-featured install over the network. I copied the pxelinux images for the kernel (vmlinuz) and initial ramdisk (initrd.img) to the /boot folder, edited the /boot/grub/grub.conf file to add a boot stanza, set the new boot stanza to be the default, and then restarted. Spoiler: this installation also went flawlessly. When it came time to deal with the package configuration, I did two things:

  1. Using the installer’s ability to edit repository configuration as part of the interactive installation, I pointed the installation at my home network, for speed purposes — having made sure my local mirror of content was updated with the latest content already.
  2. I made sure the “Updates” repository was turned on (and also pointed at local content). This would save me having to do a separate update after installation.

In minutes I had a working system. Using some of the yum-fu from an earlier post, I added in missing packages that were on my previous system.

Now came time to restore my user data. However, I decided to forego using the USB drive for restoration, because here I was with two relatively speedy laptops, each equipped with a gigabit Ethernet network interface. Nowadays these interfaces don’t need special loopback or null cables; they can autosense direct connections and adjust accordingly. So I cabled the notebooks together and used the easy NetworkManager tool to set up the wired interfaces with manual addresses on the same IPv4 network.

A quick check with ping showed I was ready to go, so I ran rsync over SSH to pull all the user data (in /home) from one box to another. This step probably saved me about half the time that the USB copy would have cost thanks to greater bandwidth over gigabit Ethernet versus USB 2.0. (The new laptop has USB 3.0 but the backup drive I have is USB 2.0.)

One of these days I’ll get around to puppetizing my home network, but I just don’t have the time for it these days. So my last step was manually grabbing an assortment of configuration info from my old laptop:

  • Stuff from /etc/NetworkManager/dispatcher.d/ and /etc/postfix/ to support my laptop email solution (start here if you want to learn more about it)
  • Some web server configuration files from /etc/httpd/conf.d/ so I can run my local sandboxes of Drupal
  • A little more info from /etc/NetworkManager/system-connections/ where I have some system-wide connection profiles

And with that, I was ready to go. Actual “me time” expended on all this was less than an hour, if you count both installations, post-configuration tasks, and miscellaneous piddling around in the middle. Of course I wandered off and did other things while the data copying was going on, so I’m not counting that time.

As I mentioned, everything worked perfectly on the installed system with one tiny exception. Even the fingerprint scanner was set up in a matter of seconds, using the handy GNOME 3 “My Account” tool. Interestingly, if you’re one of the poor unfortunate unwashed using Windows 7 (even the so-called “Ultimate” edition), both the webcam and the fingerprint scanner have to have extra drivers installed if you want to use them. But in Fedora? Nope. It all works 100% out of the box. What’s the exception then? The only thing that’s not functioning yet is the new “microphone mute” function button. The button does issue a key press signal, but it’s not captured by anything yet. This is also an “extra driver needed” for Windows users, but true to form, the new button is already on its way to working out of the box in Linux, thanks to the awesome work of community members. My bet is you’ll see this enabled in a kernel update in Fedora 15, or at worst in Fedora 16 which will be out in a few months.

Hopefully this will be helpful to anyone who’s considering one of these fine laptops. ThinkPads are kind of the Cadillac of laptops for IT worker bees, in my opinion. Or maybe I mean Toyota truck? Anyway, they’re tough, reliable, full-featured and in the case of the X series, highly portable. And they work absolutely great with Fedora and Linux in general. Happy hacking!

A fun day… for some hacking.

Over the course of the day, I:

  • Tweaked the package complement on my workstation where last night I did an installation of the Fedora 15 pre-release tree
  • Identified some weirdness in my local Eclipse environment and got things in better shape for later work
  • Got a good start on some user documentation for PulseCaster
  • Took my daughter to the skate rink, and managed to skate for at least a little while before realizing I was having a rough time because my kingpin bolts are just way too freakin’ tight
  • Figured out how to adjust said kingpin bolts and made a note to take care of that before next week
  • Took my son out for some errands and lunch — a nice trip and a good chance to exercise my patience muscles
  • As a reward, bought some beer and a couple decent malbecs
  • After returning home, cleared out some obsolete packages hanging around in Bodhi and begging for death
  • Built and pushed a new update of PulseCaster to fix some bugs
  • Built and pushed a refreshed upstream version of xmlstarlet
  • Played with the dog
  • Came back and turned up a French trance station I got into recently (for some reason, monotonous, non-vocal electronica seems to help me work more efficiently… probably since there are few lyrics to listen to and digest mentally)
  • Went through some email to reduce backlog for Monday
  • Triaged a crummy gnome-system-monitor bug affecting people with more than 4 CPU cores (like me)
  • Had dinner with the family (Eleya made a fabulous corned beef, first timer but it was pretty much perfect!)
  • Came back to the desk to find that the superhuman Matthias Clasen had fixed the gnome-system-monitor bug in question, and built and pushed an update out
  • Installed said update with many thanks to Matthias, tested, and provided feedback

So of course, my definition of hacking is not nearly what some of my colleagues manage daily. But I feel like attacking some of this stuff on weekends and working on my own GNOME-ish projects are starting to give me a better fundamental understanding of some of the plumbing at work in the desktop. And of course, it gives me a wh0le new appreciation for it as well. I’m now rocking GNOME 3.0 pre-releases on both my main systems here at home, my laptop and my big workstation, and loving it.

I’ve contributed a few bug reports and to a small portion of the GNOME 3.0 user documentation for this release. It was lots of fun and made me feel connected with the release process for something I use every day that will be an intrinsic part of Fedora 15 when it arrives. It’s a great feeling to be just cranking on some little bits to help others, and just as much as ever, I know that if everyone does the same, free software has a future that is even brighter than the (already well-lit) present.

Eager beaver, no. 38.

I was really eager to get my laptop onto the branch that will become Fedora 15. A recently uncovered bug (possibly in glibc), along with another unrelated problem (in pygobject?), are preventing installs via the nightly composed ISO images of the pre-release. So if you’re on Fedora 14, and want to get on the new branch, you could do this:

  1. Back up your data and at least your /etc directory. You never know what you might wish you’d kept!
  2. Also run the following command to save the names of your installed packages: rpm -qa –qf ‘%{NAME}\n’ > /home/rpmnames-old.txt
  3. Download the Fedora 15 Alpha release, Desktop Live spin, in your choice of 32- or 64-bit, and install. In a moment you’ll update everything.
  4. After you start up and run through the normal setups, don’t bother logging in at the GUI yet. Hit Ctrl+Alt+F2 to switch to a text terminal. Login as root, or else use sudo with the following commands.
  5. Install any -release type repository RPMs you may want. I keep copies of these hanging around for just such occasions.
  6. Get the names of the newly installed packages: rpm -qa –qf ‘%{NAME}\n’ > /home/rpmnames-new.txt
  7. Run: yum –skip-broken install `diff -u /home/rpmnames-old.txt /home/rpmnames-new.txt | tail -n +4 | grep ‘^-’ | cut -c 2-`

Note this is not a perfect solution. Releases change, and some packages may not be available in the new release that were in the old one. You may want to rerun steps 6 and 7 a couple days later if there are any broken dependencies that foil you from installing everything you wanted. Or alternately, you might want to stick in a step 6.5, which runs a few yum groupinstall commands to make step 7 shorter. This isn’t a panacea, it’s just a quick way to get up and running if you want to try out the new hotness but are stymied by the bugs listed above.

And of course, you could just download the entire Alpha DVD and point it at  so you won’t have to twiddle as much afterward; quite a few services that run by default in a DVD install, like sshd, aren’t necessarily enabled by default in an installation from the Live image. The above is just a quick way to get started if you know you’ll be doing further installation testing or other hackery later anyway. And it will give you a good flavor for the awesome new GNOME environment.

What if you want recapture your user account and password? Just refer back to your backup you made. Do not simply restore it over the new /etc files. You could really get hosed that way. Instead do something like this. I’m going to assume you only have a couple of users on your system, starting with userid 500 per normal:

mkdir /tmp/restore && cd /tmp/restore
tar xf /path/to/etc-backup.tar.gz   # Got backup?
for i in $(grep ':50[0-9]:' etc/passwd | cut -d: -f1); do
  for f in passwd shadow group gshadow; do
    grep ^$i etc/$f >> /etc/$f
  done
done

Here’s something I also recommend: move your user’s ~/.gconf directory to a backup before you login the first time. Try the spiffy new GNOME 3 out in its default settings. If you need to tweak or restore, you still have the old settings to which you can refer. But it’s worth trying everything as it was intended out of the box. I’m totally excited to run the pre-release so I can rock the new GNOME Shell. Pretty soon I’ll start working on a new branch of PulseCaster that will use the new PyGObject available in Fedora 15, and maybe a few of the cool new GTK+ 3 bits I’ve seen might be helpful in the  new UI.

Enjoy!

Test day for systemd tomorrow.

Tomorrow, Tuesday September 7, there will be a Test Day for the new systemd init facility in Fedora 14. You can find the participants on IRC Freenode at #fedora-test-day.

Participating in a test day is simple, and you don’t even need to have the Fedora 14 prerelease installed on your system to participate. We have a nightly Live image that you’ll be able to download and run from USB to do all the testing. If you do have a prerelease of Fedora installed, though, you’ll want to make sure it’s updated with the latest software.

These Test Days are a marvelous way for the whole community to participate in the development of new and innovative software for Linux users everywhere. Whenever we have these test days, we communicate the issues we find to the upstream so they can make the software better for everyone. That’s the open source way at work.

You might also be interested to know that soon we’ll be having test days for the free graphical (Xorg) drivers for Nouveau, Radeon, and Intel graphics cards the days of September 28-30. These drivers have been making huge progress over the last few releases of Fedora, and the Test Days have definitely helped. Just about anyone can run the tests for these drivers and help us squash out bugs in your favorite system’s video card.

Please join us for systemd testing tomorrow, and keep your eyes peeled for news about other exciting test days. You can help make free software even better!

Fedora 14 Alpha is go!

As John posted last night, Fedora 14 Alpha was declared ready for release next week. Although there was a one-week slip to handle the fact that our blocker list wasn’t clear, Fedora developers and testers in the community have worked hard together both to resolve the remaining issues and make sure that our Alpha would pass the release criteria. There were a number of developers who hopped in to fix things quickly to yield package builds that would clear the runway, so thanks to all of you guys.

I also wanted to take a moment to say how impressively the QA team has beefed up the definition of these criteria. Not only that, but the team continues to take opportunities to refine them whenever we hit a question that’s difficult to answer under the current criteria. We still can improve our effectiveness at turning the combination of the blocker bug list and the criteria into getting response from developers where needed, but that’s more of a shared issue. As with our criteria and our schedule, we continue to improve these processes in an iterative way, and openly to boot.

Here’s one place where everyone will be able to pitch in — making sure that any common issues in the Alpha are properly noted. We have a wiki page for common Fedora 14 issues, and it’s very important for us to keep it updated for all those trying out the pre-releases. If you’re in doubt whether it’s a common issue, that’s OK. There are some notes on that wiki page on how to add your issue:

  • Add it yourself, if you have wiki access. Please follow the style and guidelines explained in the comments in the page source. (You’ll see them when you start to edit.)
  • Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, add a comment to the bug that includes
    1. a summary of the problem
    2. any known workarounds
    3. an assessment on the impact to Fedora users

If in doubt, we’d rather see the issue than not. :-)

The Alpha release is meant for advanced users and Fedora participants to download and test. It’s not code-complete, meaning a few things may be broken. We want and need your help to identify, report, and resolve these problems. As always, the best way to do that is to file bugs! Random blog entries, tweets/dents, and mail may be interesting, but to track the problems to resolution, bugs are the right way to go. We look forward to your participation as always — if you’re not already installing from the pre-release tree, you’ll be able to pick up the official images next Tuesday, August 24.

In summary, nice job to everyone involved, and I’m looking forward to switching a few systems here at home to F14 Alpha!

Never a dull moment, no. 98.

So much going on today!

At 10:00 am US Eastern time (1400 UTC), Fedora 13 Beta is released. The Beta is our last milestone before the final release of Fedora 13. We’d like to have as many people test it as possible. It’s available in a “Live ISO” format you can write not only to CD DVD, but also to a USB key, and boot off the USB key. I really prefer the USB key, because you can update the key with fixes as you use it using the “persistence” feature. It also gives you nifty options we created along the way, like an encrypted user data area, very fast booting, and very fast installation to hard disk as well. Who loves ya, baby?

The Beta announcement will show you where to get the pre-release, see a list of known problems, and file any new ones you might encounter. You can find instructions for Live USB creation on our wiki.

Also, today starts our Graphics Test Week, beginning with the Nouveau NVidia driver. Graphics drivers affect almost everyone who uses Linux, so this is a fantastic opportunity for you to help make a difference. We’re having one today for Nouveau, tomorrow for the Radeon ATI card driver, and on Thursday for Intel graphics cards. How do you do it? Very easily, it turns out — you join IRC Freenode at #fedora-test-day to participate. Just about anyone can help, because all the tests are fully documented already. You just follow a simple set of instructions, and if you encounter a problem, the QA crew will help you get a bug filed.

But what if you don’t run Fedora? No problem! There are Live ISO images available for the test day as well, meaning you don’t have to install Fedora to participate. And why would you want to help if, heaven forfend, you don’t use Fedora? Because even if you use another distribution, your time is still worthwhile — because Fedora works hard to send changes upstream to the driver developers, so the entire Linux community benefits. That’s how collaboration and open source work. It’s not about hoarding, it’s about sharing.

Adam Williamson, a Fedora QA contributor and seemingly unstoppable force in community testing and quality, wrote more about the Video Test Week here. (There’s also a Phoronix article here and a LWN article here as well.)

By the way, to see what kind of graphics card you have, you can open up a terminal and type or copy/paste this command:

/sbin/lspci | grep -i vga
And be sure to download and try out the Fedora 13 Beta today. You can find the downloads here, and the announcement here.

UPDATE: The ever-helpful Josh Boyer reminded me that the Fedora 13 Beta, Live Desktop edition, needs a DVD because of size reasons, although this won’t be the case for the final release of Fedora 13. Seriously, use the USB, it’s awesome.

© 2002-2014 Paul W. Frields License: CC BY-SA 3.0. Some rights reserved. -- Copyright notice by Blog Copyright