Sorry for the late notice, but today is i18n Test Day in Freenode #fedora-test-day! The awesome Fedora i18n folks will be around all day, testing the language support of Fedora 22 and helping out anyone else who is interested in contributing.

If you're a Fedora user and you can use a computer in a language other than US English, please come along and help if you can spare a bit of time!

If you don’t know how to use IRC, you can read these instructions, or just use WebIRC.

Ahoy, Fedora testers: this week is one of our regular 'test weeks' with multiple related test days. This week will see the localization (l10n) and internationalization (i18n) Test Days for Fedora 22. The always-awesome l10n and i18n teams have been organizing these as usual so I haven't been too involved, but they're looking to be along the same lines as usual. If you're a Fedora user whose native language is something other than English, it'd be great if you could come along to one or both Test Days and help out!

Experienced folks will be around to help in #fedora-test-day on Freenode IRC, and you'll be able to do all or most of the testing with a Fedora 22 live image, no need to install it permanently. If you don’t know how to use IRC, you can read these instructions, or just use WebIRC.

LVM, huh? Always seems like kind of an unnecessary complication.

Except, really it's kind of awesome.

I've done some hardware refreshing here at HA Towers lately. I replaced the virtual machine host box I built a couple of years back; it was running OK, but I keep wanting to play with new things and its hard 16GB RAM limit was starting to get too small. So I built a new VM host box, using a Core i7-4790 on an Asus H97M-E motherboard with 32GB of RAM. (I also upgraded the box I'm using to host my openQA instance - it's also now running an i7-4790, but only has 16GB of RAM, the most its motherboard can take).

The old vmhost had a 128GB RAID-1 array made up of two Samsung 840 Pro SSDs, but I was also starting to run out of space on that. So, the new one has a 240GB RAID-1 array of Intel 730 SSDs (I'd have gone for 850 Pros, but Samsung sure bumped the price).

So now I had two 128GB SSDs lying around the place. Turns out I also had another one lying around (as a spare for the old vmhost RAID array). Also, I was running out of space on my desktop, which had a single 128GB SSD (a Crucial C300, which is probably getting on a bit in years as well).

Hum! Seems like I could put all those drives to use...

So I shoved the three drives I now had spare into my desktop (took some creative SATA power cable juggling...) and built a RAID-5 array out of them. Now I have 256GB of somewhat fault-tolerant storage! But all my data's still sitting on the single 128GB SSD that's getting on a bit...

Fortunately, it was also all in LVM volumes. And hey, turns out LVM is pretty awesome. You can add a new drive - or, in this case, RAID set - to the volume group as a new PV, on the fly. You can then transfer your existing LVs from the existing PV (in my case, the old 128GB SSD) to the new PV (the RAID-5 array) - on the fly, and atomically (i.e. if it all goes tits-up half-way through, you're not screwed). You can then resize the LVs, on the fly. And thanks to resize2fs, you can grow the ext4 filesystems that sit on the LVs...on the fly.

So I was able to migrate my entire running system from a single SSD to a newly-created RAID-5 array and resize it to take advantage of the extra space - without rebooting the system, or even unmounting a single partition.

That's pretty neat!

Now the old SSD can hang around as a spare.

(So far as /boot goes, I created a partition for it on one of the new disks ahead of time and dd'ed the existing partition onto the new one, which preserves the UUID).

Fedora 22 Alpha

The big news this week is definitely that Fedora 22 Alpha is released! We even managed to ship this one on time, though as it's an Alpha, it is of course not bug-free. For me the nicest thing about Fedora 22 is all the improvements in GNOME 3.16, which Alpha has a pre-release of. The new notification system is a huge improvement. I'm fighting some bugs in Evolution's new composer, but mostly it's working out.

Ipsilon Test Day

We also have the next Fedora 22 Test Day coming up tomorrow, Ipsilon Test Day. This is one of those pretty specialized events that requires some interest in and probably knowledge of a specialist area; it also requires a fairly powerful test system with a decent amount of spare disk space.

Ipsilon provides SSO services together with separate identity management systems; it's being implemented into Fedora's identity/authentication system to replace Fedoauth (or this may have already happened, I'm not quite sure on the timelines!). It's one of those things where you go to some website, and you need to log in, and you get redirected through an authentication system that might be shared with lots of other websites - like when you log in to various Fedora sites through the shared Fedora authentication process.

If you're already interested in FreeIPA and might be interested in looking at web application-focused SSO on top of it, you may well be interested in this Test Day. So come join us in #fedora-test-day on Freenode IRC and help out!

openQA automated install testing for Fedora

Personally, I've been working on our openQA-based automated install testing system for the last few days.

Waaaaaaaaait, I hear you say, Fedora has an automated install testing system?

Well, it does now. We are still expecting Taskotron to be our long-term story in this area, but after the awesome Richard Brown demonstrated the feasibility of getting a quick-and-dirty Fedora deployment of openQA running, some of the Red Hat folks working on Fedora QA in our Brno office - Jan Sedlak and Josef Skladanka - threw together an implementation in literally a few days, as a stopgap measure until Taskotron is ready.

The original couple of deployments of the system are behind the Red Hat firewall, just because it works out easier for the devs that way, but I now have my own instance which is running on my own servers and is entirely public; you can look in on all my experiments there. (Please don't download any really huge files from it - all the images I'm testing are available from the public Fedora servers and mirrors, and I have limited bandwidth).

The Fedora tests and the dispatcher and other miscellaneous bits are available, and there's a deployment guide - click on InstallGuide.txt, I'm not giving a direct link because BitBucket doesn't seem to make it possible to do a direct link to the current master revision of an individual file - if you're feeling adventurous and want to set up your own deployment. We are running our instances on openSUSE at the moment, because packaging openQA for Fedora and making any necessary adjustments to its layout would sort of defeat the object of a quick-and-dirty system. And hey, openSUSE is a pretty cool distro too! We're all friends.

The first thing I did was make the system use fedfind for locating, downloading and identifying (in terms of version and payload) images. This had the benefit of making it work for builds other than Rawhide nightlies.

I have my own forks of the tests and tools where I'm keeping topic branches for the work I'm doing. Currently I'm working on the live branches, where I'm implementing testing of live images (and really just uncoupling the system from some expectations it has about only testing one image per build per arch in general). It's mostly done, and I'm hoping to get it merged in soon. After that I'm probably going to work on getting the system to report bugs when it encounters crashes. It's painful sometimes figuring out how to do stuff in perl, but mostly it's been pretty fun working with the system; you can argue that a test system based on screenshot recognition is silly, but really, just about any form of automated testing for interactive interfaces is silly in some way or another, and at least this one's out there and working.

The openQA devs have been very open to questions and suggestions, so thanks to them! I have a couple of trivial commits upstream to fix issues I noticed while running the development packages on my instance.

When you look at Fedora 22 (and later?) release validation pages, results you see from 'coconut' and 'colada' are from the openQA instances - 'coconut' results are from the deployments managed by the main devs, and 'colada' results are from my deployment.

ownCloud updates

Finally, before I dived into openQA I did find a bit of time to work on ownCloud. I got ownCloud 8 into good enough shape (I think!) to go in Rawhide and Fedora 22: it's now in Rawhide, and there's an update pending for Fedora 22.

The other distro which gets a major update is EPEL 6; there's an update pending for 7.0.4 (current stable for EPEL 6 is OC 6).

7.0.4-3 is also pending as an update for the stable Fedora releases and EPEL 7; for those releases it's a minor update which mostly tweaks the Apache HTTP configuration file handling. I came up with a new layout which, as well as making the App Store actually work, should make it easier to 'fire and forget' a typical ownCloud deployment's HTTP configuration; after you do the initial setup, you can run ln -s /etc/httpd/conf.d/owncloud-access.conf.avail /etc/httpd/conf.d/z-owncloud-access.conf to open up access from anywhere, and you won't have to manually check config files on future upgrades, because I'll keep owncloud-access.conf.avail up to date with any directory/path changes that crop up in future releases. If you have an existing ownCloud install and you'd like to 'migrate', I recommend:

• Move any customizations you have to the HTTP configuration into an override file, e.g. /etc/httpd/conf.d/z-owncloud-local.conf
• Restore the clean packaged copy of /etc/httpd/conf.d/owncloud.conf
• Run ln -s /etc/httpd/conf.d/owncloud-access.conf.avail /etc/httpd/conf.d/z-owncloud-access.conf (assuming you want to allow access from any host!)
• Never edit any of the packaged files in future (including the .inc and .avail file(s)), always do customizations in override files

Happy Clouding!

Hey folks!

For any ownCloud'ians out there; I worked some more on the OC 8 packages for Fedora today and I think they're in reasonably testable shape now. I just updated my production deployment and it worked first time.

IMPORTANT: back up really, really carefully before testing these out. They should work, but I want to get more testing to be sure. This is what you'll be doing. Please, please make sure beforehand that if the upgrade breaks completely, you have everything you need to recover. Ideally, test these on a dev instance or test machine or something.

Please ensure you have this line in /etc/owncloud/config.php before updating:

 'check_for_working_htaccess' => false,

or else the OC updater will refuse to run. I will probably add a belt-and-braces fix for this later, but it's a good idea to have that set in any case. It has been part of the default config in the package for some time, but very old installations may not have it.

If you have edited /etc/httpd/conf.d/owncloud.conf at all please merge in the changes from the package before attempting to access the server. There are substantial changes in the Apache config files. I have tried to make them easier to work with. If all you need to do is make the OC installation accessible (override the config that makes it only accessible from localhost out of the box), you do not need to modify owncloud.conf at all, all you have to do is:

ln -s /etc/httpd/conf.d/owncloud-access.conf.avail /etc/httpd/conf.d/z-owncloud-access.conf

if you previously enabled global access in any other way I recommend switching to this one, as it will ensure things keep working in future without you needing to do anything, but you can see the directories you need to allow access to in that file if you want to do it any other way. /var/lib/owncloud/apps must be allowed and must be Aliased to /owncloud/appstore-apps (or else installing apps from the 'app store' won't work, and you're really going to need it to, see below). /var/lib/owncloud/assets should be allowed and should be Aliased to /owncloud/assets (though this only matters if you enable the asset-pipeline.enabled setting in config.php).

Please keep owncloud.conf (and all the .inc files in the package) unmodified if at all possible, and use a separate file to make any overrides you want to the configuration. This way when I need to update owncloud.conf in future you will get the changes automatically.

After upgrading you will find that most of your apps have disappeared. Don't panic! ownCloud just decided to move a lot of apps that were previously shipped in the tarball (including even Contacts and Calendar) into the 'app store'. You can go into the 'Apps' screen as an admin user and enable the apps you need. When you enable them, all your existing data and configuration for them should reappear, they will not be blank.

I am considering whether to provide packages for some of the core apps or even add them back to the ownCloud package itself, but for now, installing them from the app store should work fine - as long as you followed the instructions above about making sure the Apache config snippets are up to date.

The packages are available in my side repo for Fedora 21 and 22 (I've symlinked 22 to 'rawhide' as well, as the 22 builds should probably work for Rawhide). Get the repo file and place it in /etc/yum.repos.d to enable the repo.

Hi there folks!

Between testing and working on my current work-related-ish pet projects fedfind and python-wikitcms/relval, I haven't had much time for Fedlet or the ownCloud package lately. However, I finally managed to squeeze in a few hours to work on them this week.

Fedlet

The Fedlet repository now has a 3.20-pre kernel build that more or less works, for me, in testing. It seems like perhaps it's buggier than 3.18 was, but it at least built and it boots and it has sound and wifi and power status on the V8P. I did throw in a patch which may help with the RPMB bugs. For me it seems slower than 3.18 and touch input is rather worse than it was before, but I haven't had time to look into that in any detail yet. I have built a test Fedora 22-based image which boots, but given the apparent state of 3.20 and the pre-Alpha state of F22 at present I'm not going to release it.

I also set up a public copy of the actual repo from which the Fedlet kernel is built. You can clone that repo and check out the baytrail branch and you have the actual build bits right there. There's one small caveat: I make a few changes right before actually building which are never checked into the repo. They are:

1. Add the changelog
2. make config-release
3. sed -i -e 's,%define debugbuildsenabled 1,%define debugbuildsenabled 0,g' kernel.spec

Step 2 disables debugging in the kernel build (which you really want, on slow Fedlet-ish hardware) and step 3 says not to build a separate kernel-debug package with debugging turned on. Obviously if you actually want kernel debugging to do some...kernel debugging...you can skip 2 and/or 3.

I don't check those changes in because they tend to make merging from upstream (Fedora kernel package) much messier. Aside from that, though, all the substantial stuff is checked in. Mostly the delta is down to patch files now; there's only a couple of changed CONFIG settings any more.

ownCloud

I'm working on getting the ownCloud packages up to the recently-released 8.0. Major OC releases always require quite a bit of gardening downstream. I now have a side repo for OC 8 available; for now there's only a repo for Fedora 22, but you could use it for Rawhide too, and it'll be easy to add at least Fedora 21 soon.

The repo contains OC 8 packages plus Pimple 3.0 (which OC 8 needs) and Doctrine DBAL 2.5.1 with a change that seems to break ownCloud partly reverted.

So far it's at the point where a clean deployment with sqlite as the database works, and you can install apps from the 'app store'. This is important as some apps that were previously part of the core - notably Contacts, Calendar, and Documents - have been moved to the store. I am not sure whether to provide packages for these or even roll them back into the main owncloud package, but for now I'm following upstream.

I haven't yet tested any other database, and I have not tested upgrading an existing install. It goes without saying that you should only do anything at all with this repository on a test setup. :)

You can use oc8-httpd-sqlite.ks to do a full turnkey test install; as usual for my OC test kickstarts, running an F22 install with that kickstart will give you a box with OC running and accessible from any system right out of the box, with insecure admin account (admin/admin) and database credentials, never use my test kickstarts unmodified in production or on any box which is publicly accessible. The kickstarts for other databases need a quick tweak which I'll get around to tomorrow as I test them.

As part of the OC 8 work I wound up overhauling the Apache config layout quite heavily; I needed to fix a few bugs and update it with the latest upstream changes, and took the opportunity to use some Include directives to make it rather cleaner. I've sent a modest proposal about standardizing config snippets intended for inclusion to devel@.

And with that, to bed!

Last week I wrote about some font stuff, mentioning along the way that it was prompted by an issue in freetype. If a font has no native bold version, Freetype can produce one algorithmically when an app asks for bold text. This mechanism makes the glyphs wider. This is a bit of a problem for monospace (fixed-width) fonts, because the whole point is that their character widths should always be consistent, so blocks of characters will align correctly.

I did actually try and figure out how to make freetype do this - which it calls 'emboldening' - without widening glyphs, but wasn't able to figure it out, so instead I suggested a change to fontconfig which simply disables the emboldening entirely for fixed-width fonts. I sent this upstream. In response, someone very kindly stepped up and figured out how to do it properly: that someone is Raimund Steger, and here's his blog post on the topic.

So if you've been annoyed by this issue, you can build freetype with the patch from his post, and - joy of joys - you'll still get bold characters in Droid Sans Mono or Inconsolata, but they'll no longer be wider than regular ones!

I then worked out that the infamous Infinality had actually come up with something functionally identical in his patch set four years ago, but then changed it to simply disable widening for all fonts, as he apparently prefers it that way. That's obviously a much more 'subjective' change than disabling it for fixed-width fonts only, and it seems like no-one ever quite joined the dots and suggested the more objective improvement upstream. Details on that here, if you're interested.

I suggested to Raimund that he submit the change to freetype, so here's hoping it'll get picked up by upstream and save anyone else from encountering this in future!

EDIT: A further follow-up: Raimund submitted his patch to freetype, but it was rejected by Werner Lemberg on the grounds that it is actually most appropriately fixed 'one level higher than FreeType', i.e. in the platform/toolkit layer, i.e. in Cairo and Qt (to cover the major cases). So I've filed a Cairo bug. I tested KDE's behaviour, and it seems...interesting: I've filed a bug there as well.

That's right, we're kicking off the Fedora 22 Test Day cycle soon, with an Anaconda/DNF Test Day!

One of the planned Changes in Fedora 22 is to make DNF the default console package manager, instead of yum. As part of this, we have been converting Anaconda, the Fedora installer, to use DNF rather than yum. At present, in Fedora 22 images, anaconda will use DNF by default but the yum code is still present and switchable with a kernel parameter (inst.nodnf).

We have some concerns, though, about the extent to which this change might cause problems. The anaconda team had the idea of running an early Test Day to try and test out as much of the repository and package configuration capabilities of the installer as we can, and also to produce some kickstarts which can be used in automated regression testing.

So our plan for the day is to get folks together and just exercise the package management bits of the installer as much as we can, trying to use all the interactive paths (GUI and CLI) and test out all the various kickstart directives relating to repository and package configuration.

There are some planned tests - mostly validation tests - on the Test Day results page, but a big part of the event will be unplanned 'exploratory' testing, just trying things out, identifying issues, finding bugs, and producing kickstarts.

If you have time on Thursday, and especially if you're somewhat familiar with anaconda and kickstarts (but even if you're not!), please do join in! We will be standing by all day European and North American time in #fedora-test-day on Freenode IRC to help you out with testing and discuss any bugs you come across. If you don’t know how to use IRC, you can read these instructions, or just use WebIRC.

Here's a fun yak shave I had this morning!

I started out running pylint on fedfind and finding several cases where it said my hanging indents were off. When I looked at the column count instead of eyeballing them, indeed they were - but when I matched the column count, it didn't look right at all.

After scratching my head for a bit, I figured it out. gedit bolds certain things when doing syntax highlighting. I've been using Droid Sans Mono as my monospace font. That doesn't have a bold version, so fontconfig asks freetype to generate one artificially. When freetype generates a bold version of a font, it doesn't match the glyph widths.

I'm not the first person to notice this.

There are various ways I could deal with this, but I'm not a huge font geek so the first thing I thought was 'eh, I'll just change fonts'. I looked through the list for ones which have matching glyph widths when bolded, and found that Liberation Mono and DejaVu Sans Mono seem to fit the bill. I don't really like Liberation much, and DejaVu Sans Mono is the Fedora default, so I figured I'd go with that.

Then I remembered one of the things that caused me to switch away from it in the first place: it seemed like when I used it, my monospace text in Evolution looked completely different from anything else. So dramatically different I thought it was some kind of bug causing the wrong font to be used.

After poking around at it for a bit, though, it turns out it's subtler than that. With Fedora's font libraries, at 96dpi, at 11 point size, DejaVu Sans Mono looks drastically different with 'medium' hinting compared to how it looks with 'slight' hinting. Here's medium:

And here's slight:

Crazy, huh? After fiddling around with settings for a bit, I figured I was seeing slight hinting in gedit and GNOME Terminal and Firefox, but medium hinting in Evolution. From there it was but a short leap to figure out that...Evolution doesn't respect GNOME's font configuration.

I was tweaking the settings in GNOME Tweak Tool's Fonts pane. You can set the desired hinting and antialiasing configuration here, as well as default font faces and sizes. I don't know the details of what this is actually setting and how exactly GNOME applies it to applications, but it seems like just about everything picked it up...except Evolution. Fedora's default setting is medium, but I much prefer slight; medium distorts things too much for me. (There's an obvious bug where the dot on the lower-case 'i' character in the Ubuntu font doesn't match with the stem, for instance). So I'd been setting it to Slight. All along, I'd been seeing different hinting in Evolution to everything else, but it just happens it wasn't totally obvious for anything but the monospace font.

As it happens, once I figured out what was going on, I knew the way to force Evolution to use slight hinting too: configure it at the fontconfig level. I created a file /etc/fonts/conf.d/99-happyassassin-slight-hint.conf (following my personal convention of putting 'happyassassin' in every site config file, and numbering it 99 so all the rules which disable hinting entirely for specific fonts override it) with this content:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fontconfig SYSTEM "../fonts.dtd">
<fontconfig>
  <!--  /etc/fonts/conf.d/99-happyassassin-medium-hint-dejavu-sans-mono.conf

        Use slight hinting for all (except overridden later).

 -->
  <match target="font">
    <edit name="hintstyle">
      <const>hintslight</const>
    </edit>
  </match>
</fontconfig>

and boom, now Evolution uses slight hinting too. All my fonts look consistent between Evo and everything else, and I can use DejaVu Sans Mono without being irritated by the discrepancy.

There's just one problem remaining...I actually kinda like how DejaVu Sans Mono looks with medium hinting! (though honestly, the look with 'slight' seems truer to the font in general; it's just a bit tall for my liking). But I haven't yet figured out a way to make the system use medium hinting just for that font, but slight for everything else. You can express it in fontconfig configuration, but I think GNOME's setting seems to be a universal one that overrides the fontconfig one, so doing so has no effect as the GNOME value overrides it for most apps (the ones that respect GNOME's setting). I haven't checked into that in detail, though, so I may be off the mark there too.

So after all that I can get back to re-indenting my code. :)

Edit: Here's an alternative 'fix': create a font config file (mine's /etc/fonts/conf.d/99-happyassassin-disable-mono-bold.conf) with this content:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<!-- 
 Disable artificial bold for fixed-width fonts
 -->

        <match target="font">
                <!-- don't embolden fixed-width, as it changes the width -->
                <test name="spacing" compare="eq">
                        <const>mono</const>
                </test>
                <edit name="embolden" mode="assign">
                        <bool>false</bool>
                </edit>
        </match>
</fontconfig>

I believe this may not affect apps that use Xft directly, but it at least fixes it for most apps. This disables the synthetic emboldening feature for fixed-width fonts. In a way it's 'cleaner' to adjust 90-synthetic.conf to not apply to fixed-width fonts, but the problem with that is it'll get overridden when your distro updates fontconfig. I have submitted a patch to 90-synthetic.conf upstream for discussion.

So I got my 'Fedora Finder' thing into releasable shape. You can read more on the fedfind page. It's available from the same repo as python-wikitcms and relval - if you have that repo set up, just do yum install fedfind, and you too can find Fedora!

Some examples from the fedfind page:

fedfind images --release 21
fedfind images --release 21 --milestone Beta
fedfind images --release 21 --milestone Final --compose RC5
fedfind images --date 20150204
fedfind images --release 5 --arch x86_64,ppc
fedfind images --release 15 --search desk