Moving to Fedora 19 Alpha!

Usually I wait until later in the pre-release cycle — a few weeks before Beta on average — before I move to the pre-release of the next Fedora operating system. But for Fedora 19, I’m too excited to see GNOME 3.8 and all the other improvements, so I tried out the Fedora 19 Test Candidate 2 (TC2) during lunch yesterday. I burned it to a USB key and was happy with what I saw. I decided it was time to move over now and fit in with the cool kids.

 

Getting ready to install

Now, I could have just thrown caution to the wind and installed right away. But since I wanted to move over on my main workhorse laptop, a ThinkPad x220, I really needed to back up my user files first. I hadn’t done that in a month or two (I know, I know!) so this was a must. I figured, if I was going to have a little downtime for the backup, I might as well make it worthwhile and install the Fedora 19 Alpha TC2 while I was at it. Thankfully, this afternoon was free of meetings so it was a good time to be offline for a short while.

I keep my backups in several places, but the easiest one to get to right away, with the fastest write speed, is a portable USB 2.0/FireWire enclosure I keep around for my own backups. It has a 500 GB SATA drive inside and plenty of room for my data. I was already running the Fedora 19 Alpha TC2 using the Live USB. I attached the disk, and of course it was mounted up for my convenience. I used the Disks utility to unlock and mount my home volume from the encrypted hard disk, and used the rsync utility to freshen the backup.

Installing Fedora 19 Alpha TC2

I decided to do a network installation rather than just burning a Live image. There were a bunch of other packages I wanted, and I figured I might as well grab them all during installation; plus, I wanted to see how that process was working. I burned the F19 Alpha TC2 boot.iso to a USB key and booted up.

I was hoping to hold on to my current partitioning setup as part of the installation process. I have a /boot partition on /dev/sda1, and an LVM physical volume with a single volume group, subdivided into separate logical volumes. Some are encrypted, including my /home folder. Unfortunately this is where I ran into my first issue — the current F19 Alpha can’t handle custom partitioning in the installer interface. I don’t believe this is required in the release criteria for an Alpha, so it’s not a huge surprise.

Nor was it a huge impediment; fortunately, the installer GUI is not tied that closely to the OS version or package content anymore. That means I was able to boot off a Fedora 18 boot.iso (written to USB), and simply point to a Fedora 19 mirror as the software source. I used the existing (and working) Fedora 18 installer GUI to do my required custom partitioning, so I could retain my current partition setup. Then I was off to the races, while I worked on other things.

Initial thoughts

There are some cool interface changes during login. A finished desktop screen expands nicely from the center rather than having elements appear gradually in sequence. There is some work being done on an initial setup routine, kind of like an orientation for new users of GNOME 3. It’s still a bit rough, and there are bugs, but you can see where things are going: it’s definitely a useful feature.

I love the fact that the screensaver reports notifications gathered while the screen was off. This would be useful for things like chat where you might want to know whether someone was looking for you before you decide to log in. I’m thinking of quickly getting on the console to answer IRC pings, but I suppose, reading back, it might just as easily be used to avoid people. Heh. But again, neat improvement. Another nice notification improvement: the larger bar introduced in GNOME 3.6 also now confirms for you that you have no new notifications, a nice added visual cue.

The control center has a smorgasbord of upgrades, from a privacy control, to per-application notification settings, to easier to read layouts for numerous controls including NetworkManager. And the overview search now is easier to read as well. And of course, none of the changes sacrifice my ability to navigate around by keyboard instead of mouse, which I really like.

Are there bugs? Sure, although I haven’t hit any identifiable ones yet. I’ll keep playing with the pre-release over the weekend and file some bugs as I poke around into the corners. But so far, I really like what I see, and I think Fedora 19 is going to be a great release!

DevConf.cz event, day 1 part 2.

I’m sure you already saw my post on part 1 of day 1 of DevConf.cz, right? Well, not much time for lunch afterward — this conference is packed with content! It’s also packed with friends from around the world. Here’s a few of mine:

There are about 5 minutes between talks, and a quick 15 minute break in between morning and afternoon sessions. So after said break, I attended the following sessions:

• Ales Kozumplik spoke about DNF, a next generation package management library and utility for Fedora. There’s an explanatory Fedora wiki page here.
• Michael Schröder presented on the functions of package management in SuSE, including libsolv (which underlies DNF). This included explanations of many of the additional functions in libsolv that can be cherry-picked if appropriate for Fedora.
• Vratislav Podzimek gave a fantastic presentation on the reasons behind and for the Anaconda NewUI. He showed the many problems and maintainability issues with the Anaconda we’ve had for something like 7-8 years in Fedora. He also demonstrated how the new UI presents a simpler, faster way to install in Fedora and even allows you to quickly craft custom “addon” spokes.
• Following this, I attended the Anaconda NewUI discussion in one of the hacklabs. A partial list of discussions that happened there:
  • Confirmed that Anaconda redesign is meant to make it possible for people with little or no Linux experience to use the installer.
  • Someone said that this is perhaps exactly why some experienced people struggle with the new UI. While acknowledging that such users would have to become accustomed to the new UI, apart from two cases (LVM on mdraid and [UPDATE: reserving space in a VG -- see comments below]) at this time the new UI can do everything the old one did. Completing storage configuration is more streamlined for the middle of the bell curve cases, but still can be done for the outlying cases.
  • Quite a bit of discussion about addons and what the vision is for them in Fedora. Chris Lumens expressed this really well; his opinion is that they would only be used in Fedora for things that are really helpful for the Project but in which the Anaconda team has no expertise. In concept, any particular site that wants to use addons would only use one, or maybe two. Throwing lots of addons at a user would be confusing and unhelpful. Anaconda team doesn’t want to set policy about when to use addons, probably this would be a FESCo matter.
  • There are many difficulties with choosing default languages based on simple measurements. Inevitably you end up making the wrong choice for a substantial number of users and it becomes difficult for them to continue or complete their task.
  There was more, but these were some of the major topics I heard while bouncing around trying to publish things to various networks about the conference.
• I also attended the set of short talks for the core OS. Although they were labeled “lightning,” they were a little slower paced, but still good content. I’d like to see the next DevConf.cz include real lightning talks — perhaps 5 minutes, timed mercilessly, and following each other rapidly with a high energy and entertainment level. But the talks themselves were quite good, and included Tomas Mraz on password quality with libpwquality, and Hans de Goede on the current state and future of the Spice protocol and tools. Hans’ demonstrations were especially high in “wow factor,” and featured splitting a window across two diferent guests’ displays, and drag and drop of files from host to guest.

Following the short talks, it was almost time for the conference event. I went back to the hotel to drop off my bag, and several times I narrowly avoided death by sidewalk ice. Thankfully I was walking with Fabian Affolter who would have been able to call for help if I slipped and broke anything important! (I had met up with Fabian and fellow Fedora luminary Gerrold Kassube earlier in the day.)

I quickly headed back out into the cold and a few blocks later, met up with our hundreds of attendees at Klub Fléda. There was a huge variety of good food and, of course, the omnipresent Starobrno beer. There was also live music on stage, with a power trio doing their best to entertain the sedate geeks customarily grouped together 10 meters away from the stage.

I was able to hang out a bit with some of the hardcore hackers doing great work to solve hard problems in the Linux world, including Kay Sievers, Lennart Poettering, and Harald Hoyer. I haven’t seen Lennart and Harald in a number of years — since I was in Berlin for a LinuxTag event. After a few hours, I accompanied Dan “Strikemaker” Walsh back to the hotel where we had a quiet round or two before retiring. All in all, it was a fine day and I was looking forward to day 2.

Speaking of which, stay tuned for a report for the second day of DevConf.cz!

DevConf.cz event, day 1 part 1.

I’ve been at the Red Hat Czech Republic office in Brno this week for meetings and RHEL-related work. But I organized the visit around this weekend’s DevConf.cz event, a conference for free and open source software hackers in Europe. The organizers in the Brno office have done a fabulous job of putting this conference together. I arrived a little later than I wanted, just before the start of the first session. That was mostly because we were out far too late the night before, bowling and having Czech pilsner with friends in the hotel basement bar! Anyway, we joined a small queue where we picked up the agenda, a ticket to the Saturday night event, and a cute gift: Red Hat branded gloves. These would come in handy in the cold and snowy, but beautiful, Brno weather this weekend!

I headed to the first DevConf.cz talk of interest to me, on color management. This talk mainly covered the current state of color management in Linux. It didn’t give me a lot of new information, but it was well done. The speaker did mention some of Richard Hughes’ work on colord. He also mentioned the ColorHug device for calibrating screen displays to get correct color. I need to pick up one of these! He also covered the OpenICC group’s formation. I have to admit, I was still just waking up, and didn’t have as much attention to give here as the topic deserved. So I apologize for the lame recounting here.

Next I sat in Debarshi Ray’s talk on GNOME Online Accounts (GOA) for users and developers. Debarshi did a great job showing how GOA works in GNOME. He had some videos that show accessing online documents from a local desktop. In the developer section, he also explained some current problems with increasingly popular 2FA schemes, and with specific service integration through GOA. Despite significant issues with some underlying frameworks needed for better GOA support, there are smart people working to solve these issues in GNOME, which was good to hear. This will give the platform a better foothold on the seamless sharing users have learned to expect.

My energy started to flag at this point, so I grabbed a quick cup of caffeinated soda and ran back upstairs to see Tom ‘spot’ Callaway’s talk. His topic was improving the Fedora user experience through design-driven methodology. I saw a version of this talk at FUDCon in Lawrence, Kansas, where it generated excellent audience interaction. I was curious to see how it was received in Brno. I was happy to see a huge turnout for this talk here at DevConf.cz. UPDATE: Spot’s slides are here (ODP format).

Spot talked about focus on user experience as the first step in development process, as opposed to “let’s write code now, and make this pretty later.” This is not a path that many open source development projects take, but it’s one that tends to produce great results for recipients. Spot followed up with some intriguing examples:

• The new HyperKitty system that allows users and contributors to interact in ways they prefer. HyperKitty also can help raise the signal to noise ratio by allowing forum-like ratings of posts.
• A mockup of a Fedora Smorgasbord app-store like application to succeed PackageKit, and abstract away confusing details users don’t need when trying to install or update.
• A mocked up solution to reduce friction when filing bugs, and frustration when dealing with them.
• A Fedora Badges app to produce better user affinity in Fedora. Badges can also give some insight into what users are doing, from running specific applications to participating in community events.

I stayed in the same room to hear Leslie Hawthorn talk about negotiation theory in FOSS projects. (You can find an excellent summary of the topic in this post on Leslie’s blog.) A fundamental lesson I took away was often we prevent a great result because we care more about a conversation’s outcome than our goals. Leslie is an entertaining and engaging speaker and I really enjoyed this talk. Hopefully I’ll get to hang out with her a bit at DevConf.cz. I feel like we’ve crossed paths often before, but somehow miss each other through happenstance.

And since I just used the word “happenstance,” I think it’s time to end this post and get lunch. Stay tuned for part 2 of DevConf.cz day 1!

PulseCaster 0.1.9 is released!

Yup, 0.1.9 has finally made it out the door. Here’s the tarball and the git repo. There are also updated packages coming shortly in Fedora 17, 18, and Rawhide. If you want to help test those to get them out sooner, look here for the package for your Fedora release.

Plus, did you know there’s a Facebook page for PulseCaster? Visit it, like it, and feel the love.

PulseCaster 0.1.9: The gruesome details

I have no witty release name attached to any of the releases, so let’s call this “The One Where We Figured Out How to Give People an Expert Option and Translations, Too.” Some of the secret features you’ll find in this release:

• An expert option
• Translations

OK, I’m being a bit snarky here. Mainly I’m trying to play all nonchalant about how long it actually took me to get around to working on another release. Here’s a better listing of new stuff in 0.1.9:

• PulseCaster now uses GTK+ 3.0.
• PulseCaster also now uses PyGObject and GObject introspection for most stuff. The GStreamer bits are still a bit rough in the gir code. Specifically I found it difficult to get at messages on the bus. I’ll keep working on that, possibly for 0.2.
• There’s now an expert option that writes the recorded streams to two separate files in lossless FLAC format, so you can mix your own recording later. The default mode still writes a single Ogg Vorbis file, which suffices for most people. (The code here’s more than a bit hacky and needs to be cleaned up in 0.2.)
• Using the excellent Transifex service, translations are now part of PulseCaster! Many thanks to the wonderful volunteer translators around the world who contributed translations to the release, and to the Transifex folks for their great service.

Future work

Some of the features on the current roadmap:

• Clean up messy separate-stream code (see above)
• Provide a recording pause button
• Do some volume leveling and/or compression to help recordings sound better
• Provide more helpful information on disk space available/used

As always, you can find the PulseCaster site at http://pulsecaster.org — bugs and enhancement requests are welcome. Input from users helped to drive (eventually!) the work for this release, so a tip of the hat to them for participating!

Changing font size in GNOME 3.4 on Fedora 17.

Someone asked me a few weeks ago whether I knew how to change the default font size in GNOME 3 on Fedora. I have all my boxes on Fedora 17 since before the release, with GNOME 3.4. I had to admit that I’d never looked for how to change the font size in GNOME, but it seemed like something you might want to do, especially on extremely small or large displays. I hadn’t bothered to write this up, but I thought given a news story this morning that it might be useful to others.

I had no clue where to start. So how did I find it? I went to the Overview mode by hitting the super key (you could also use the Activities hot spot or Alt+F1). Then I started typing: f o n t. The first thing that comes up in the menu is the Universal Access setting. I opened it up (I just hit Enter, but you could mouse to it just as easily), and sure enough, under the “Seeing” tab there’s a setting for the default font size!

Not why but why not.

When you’re working on any project that’s Fedora related, and you need to ask questions of a team, the default should be to communicate the question on a public forum. If the conversation isn’t open and transparent, there needs to be a good reason why not. “Default to open” is a pretty well-known mantra in FOSS so this shouldn’t be too surprising or controversial.

There are certainly times where private discussion is warranted. Dispute settling (not to mention disclosure) is often best done privately. If you have to relate personal or security sensitive details of some sort, putting them on a list for eternal archiving may not be appropriate. There are other good examples out there. But in all these cases, it’s important to minimize their impact on public communication. In other words, strive to filter those bits that are best kept private, and keep the rest in an open and transparent discussion.

Every communication of an idea, discussion of implementation details, and canvassing for opinions is a chance to involve others in what you’re doing. If you keep it private, you’re missing out on one of the chief benefits of the open source way — involving others and enabling them to help you as well as themselves. The question is never “Why does this discussion need to be open?” — it’s “Is there any good reason this discussion shouldn’t be open?” And if necessary, as a follow on, “How can I separate the private part of this discussion so it doesn’t keep the rest from being open?”

As the Fedora community continues to grow and spread, we need to continue to teach this aspect to new members — and those who are experienced must lead by example.

Congratulations on Fedora 17!

I wanted to extend a hearty congratulations to the whole Fedora community on another great release.

I’ve already been using the Beefy Miracle since before Beta, and I’m very impressed with its stability and ease of use. A special pat on the back to Robyn Bergeron for her first release as the Fedora Project Leader. I remember well that the FPL’s first release is always filled with stress and anxiety, even though the whole community always works hard to ensure a smooth release. Robyn, now that you have your first release in the rear view mirror,* you should definitely relish the moment. (OK, you had to give me just one hot dog joke.)

There are a huge number of features in this release — thank you to all the developers and maintainers both upstream and in the Fedora community who helped make them possible. Fedora is possible because of the great work done upstream in the free software community and I’m grateful every day for the awesome software that allows me to freely pursue work and play using Fedora. If you haven’t seen the bonanza of awesomeness in this release, you should definitely check out the feature list.

Nice work, everyone — enjoy Fedora 17 and then, I guess, it’ll be time to get cracking on Fedora 18!

• Remember, objects may be closer than they appear.

Discoveries, no. 577.

This past week I discovered the following awesome things:

• Moving from a 10-year-old DOCSIS 2.0 modem to a DOCSIS 3.0 modem, assuming your cable ISP is remotely in tune with the times, will make your bandwidth better.
• Moving from a 7-year-old (?) Linksys WRT54GL a/b/g wireless router to a new Netgear WNR3500L b/g/n wireless router, assuming you have a laptop with wireless-N, is well worth the investment (and the Netgear is equally hackable with open firmware).
• If you had a stressful day, playing Rancor Rampage on Kinect Star Wars with your kids is a great way to take the edge off.

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!

Autotitles in screen.

This comes in really handy in ~/.screenrc:

shelltitle '$ |bash'

Then add this in ~/.bashrc:

export PROMPT_COMMAND='[ "$TERM" == "screen" ] && echo -n -e "\033k\033\\"'

Restart screen in a fresh bash session and enjoy.

UPDATE: I stupidly screwed up the screenrc line because I did it from memory instead of copypasta. No cookie for me!

UPDATE #2: Aha, found that something in the innards of my blog software was removing an extra backslash that was needed in the export command above. Sorry for the mess.