Vincent Danen recently posted about email handling ( http://linsec.ca/blog/2014/01/23/email-tagging/ ) and since I have been dealing with emails since about 1994 or so I (wow, I must be old) thought I would share my setup and thoughts. First, I run my own mail server, so I use greylisting and spamassassin on incoming emails to cut spam down. Things caught by greylisting I never see, and mails marked as spam by my server spamassassin I save, but file into a spam box. In practice I only look in there if there's something someone says they sent me, but I can't find. It's been many years since anything legit was in there however. Spamassassin does a pretty good job with a good bayes db and all the other various tests it runs. I'm also currently running an RC ( spamassassin-3.4.0 rc5 ). Hopefully a final 3.4.0 will be out very soon. This spam box gets about 100-200 spams a day in it. These spams are the bottom of the barrel "Make money fast" type.  After the mail comes in on my server it uses uucp (yes, really) over tcp/vpn to get to my laptop. I set this up many years ago and it works pretty great. I probibly should just move to offline imap like everyone else, but there are some nice advantages to this setup (very good disconnected, gracefully handles resuming, can prioritize), so I keep using it. If my laptop is connected to the main server via vpn, the emails transfer as they arrive. If it's not for some reason, they wait there until the laptop connects and sends a 'give me all pending emails' (which it does when the vpn connects). Once it reaches my laptop, I read my mail with claws mail. I also have the claws mail bogofilter plugin enabled, so it culls another cut of spam off the top into a spam folder. This filtering only gets around 5-10 spams a day or less. These are usually different languages that spamassassin didn't catch, or things that are more 'human' seeming than the first cut. Once claws has run bogofilter on things, my default filtering comes into play. All lists are filtered to their own folders. Nagios gets its own folder. System mails (root, postmaster, admin, etc) all go to their own. This leaves things directly to me and bugzilla going to my main folder. I always start reading my main folder first, then move on to system accounts, and only then lists. If I reply to something and need to wait for a reply to take any further action, I file that email away to a folder for the person I sent the reply to. If I answer a bugzilla bug I put the orig bug mail and my reply into a bugzilla folder. The idea is to keep my main mailbox down to 'things I need to take action on or reply to'. When going through list emails or things I have filtered into other folders than my main inbox, I take advantage of claws-mail's 'mark' function. If there's something I want to reply to but it's going to take time or thought to write it up, I mark it and go on. Then, usually later in the day when I have time, I go back and look at all the marked emails. A fair bit of the time, someone else already replied with something like what I was intending to, so I just remove the mark and go on. If not, I compose a reply and unmark the email once it's sent. Sometimes something has been marked for a long time and I go back and decide it's not worth reopening the discussion, so I just unmark it. Every month or two, I go and use the claws-mail archive plugin on in particular the lists that gather more than 10,000 emails a month or so. Linux kernel, fedora-scm-commits, and a few others. This keeps things nice and speedy when reading. I also use claws-mail's color labels on some lists. For example on the xfce commits list I have claws mark all the transifex/i18n commits in green, since I don't care as much about them as code changes. On the linux kernel list (which I often don't have time to really read, I have it color label posts by some folks, like linus or fedora kernel maintainers). Additionally to all this, I use claws-mail's RSSyl to read rss feeds. This allows me to easily mark things in rss feeds I want to reply to later or read when I have more time (for example, Vincent's blog post to which this is a reply, so I can unmark that post now). Also, I read my work email (via imap) and gmail (via imap) in this same setup. claws-mail lets me pick which account to use to reply to something and I can have them all marked and in the same place. This setup has worked nicely for me for a while, but of course, your mileage may vary. :)

Skipped last week as things were very busy ramping up from the holidays, so this is a double edition. ;) The selinux execstack/execmem issue turned out to be all due to a krb5 package bug. I had dismissed this because I don't use kerberos here, and didn't note that all the things complaining were linked to krb5-libs anyhow. ;) As soon as that fix pushed back out and a selinux relabel later I was back to enforcing on my rawhide laptop. Late last week there was another unfortunate abi bump, this time in satyr package, which is used by abrt. This time the maintainers expected to rebuild the entire deps, but ran into problems in rawhide building one of the packages in the list. This is a good place to run mockchain and re-build stacks of deps locally before pushing into rawhide to make sure they all build ok. Yesterday, I pushed a change to the redhat-rpm-macros package that changes the way the %configure macro is expanded. This was a hacky fix for packages that had set the %_hardended_build flag, but used libtool. Due to the way libtool expanded things the resulting package would not be hardened. With this fix now they should be the next time they are rebuilt. So far I have not heard any issues with this change, but be aware and please do file bugs on it if you run accross one. Also Yesterday at the weekly re-eng irc meeting I brought up the idea again of working on improving the rawhide compose process. There's some likely pretty easy to implement gains short term in reporting: Just show if images worked or not, report on the livecd and appliance runs. Longer term I think we can add some ways to gate bad updates to prevent them from rolling out to rawhide users. This will take more discussion and planning, but there's ways to do this. I'll explore this more in next weeks post. In the mean time happy rawhiding.

This will likely be the last of my week in rawhide blog posts this year. First some thoughts about recent holiday breakage in rawhide, and then some retrospective. Right as everyone left for the holiday's this year, rawhide suffered from a number of bugs. Firstly a selinux issue causing lots of things to fail with execstack/execmem errors. This would cause things to not come up right on boot, or at the very least make it so you couldn't login. Running in permissive mode until this bug is fixed is sadly the workaround at least at the moment. With the release of Fedora 20, a number of QA folks have moved up to rawhide and run into a number of issues in the gnome stack in particular. Adam Williamson has updated the rawhidewatch blog with several of them. We really need to try harder as a distro to be more careful with builds. yes, particularly in rawhide. Any of the following are things we should be working to detect and avoid:

• ABI/API bumps of packages where the maintainer doesn't announce them in advance. The policy is for the maintainer to announce these in advance and (wherever possible) rebuild affected packages or at least get an ack from maintainers of those that they will rebuild them. There's just no excuse for pushing a build with no announcement and wandering off.
• Pushing a critical build or something that requires a bunch of rebuilds you can't do on a weekend or holiday. If your package is minor sure, work whenever you can, but pushing things like a libpng rebuild on a friday afternoon, or pushing a new gnome build before leaving on holiday for 2 weeks when you know it's not ready is not ideal.

Things we should be doing more of:

• Eating our own rawhide-food. If we had more folks running gnome in rawhide they would have seen some of these issues as they happened, not after the fact. In general, more coverage would be great. I think we need to make sure in the fedora.next world to have people actively using the rawhide version of the 'products' day to day.
• Asking for help. If you have a package and it has broken deps and you don't know how to fix it, please ask on the devel list. There's people around who are able and willing to help if they know there's an issue going on that isn't solved.
• Announcing/Coordinating. Tell folks when there's an ABI bump, file bugs when you see broken things.
• Automation. As always we should look at putting some checks in place for rawhide to help prevent some of the issues we run into, it's just a matter of deciding on the tooling and finding time to implement it.

So, looking back on the year there have been a number of hiccups and bugs and issues, but overall rawhide has been very usable day to day for me for the most part. I really hope I can help more folks start using it day to day as well to increase our testing and fix things much faster before they go to any 'stable' Fedora release. With the fedora.next stuff upcoming I think we will probibly see more folks move to rawhide simply because they want the newest things and f21 isn't going to be along as fast as it would have been in the past. Here's looking forward to another exciting year of rawhide. :)

Well, we are a little less than 1/2 way through the holidays here (at least for me), and I thought I would post about some misc geekery I have been working on in between eating too much, watching movies and playing games. Since about November when we started the crunch to release Fedora 20, I have been adding little things to a 'toplay' file. These are things I didn't have time for but thought were interesting and should look into/play around with. The list is still long, but we aren't even half way done with holidays, so I hope I get more of them looked into. So far I have:

• Upgraded my phone to CM11 nightlies. I put this off because it needed a wipe and I just didn't want to take the time to mess with it. I took nandroid and titanium backups, then wiped it out and upgraded it. Still a but of tweaking to do, but overall I am liking CM11 and the nightlies have been stable enough for me. I do always make a backup when I update, so I can always go back a day if there's a big problem. I guess this is similar to running rawhide on my laptop. ;)
• In the phone upgrade I did not re-install google authenticator, but switched all my one time pad needs over to FreeOTP. A lot of people seem unaware that google took authenticator closed source a while back, but they did. FreeOTP is 100% free and also written by some folks at Red Hat. You can find it in the play store, and code/etc at: https://fedorahosted.org/freeotp/
• I poked a bit at some broken deps in rawhide, but still need to look at most of them. It would sure be nice to get that list down to well... none.
• I did some rawhide downgrading and rebooting and isolated the versions of selinux-policy and libselinux in rawhide that are causing tons of things to fail with execmem and execstack errors. Hopefully that will get fixed up soon. In the mean time, running permissive mode. ;( See this bug for more info.
• Upgraded wordpress plugins and themes and associated junk on my wordpress site. I keep the main package updated (with the Fedora provided package), but I sometimes slack on updating all the other stuff that has to be done manually. As a side note, some of the instructions for some plugins is INSANE, things like "chmod -R 777 to properly install this plugin". No thanks.
• Got mostly caught up on updating various of my packages (calibre, xfce4-terminal, new ansible with galaxy commands, etc) and responding to bugzillas.
• I got all setup for using copr for my latest calibre builds. Please see the copr at: http://copr-fe.cloud.fedoraproject.org/coprs/kevin/calibre/ I'm not sure best how to transition from the fedorapeople repo, as redirects aren't going to work easily. I might just remove it and place a README there for folks to pick up the new location, or come up with something better as I suspect a number of folks might be migrating like that.
• Non Linux or Fedora related: Finished Diablo 3, ate far too much good food. :)

Hopefully over the rest of the break I can start digging into some packages/applications that I have had on my list for ages... repmgr, CRIU, buildbot, phabricator, and others. Hope everyone else is having a relaxing holiday season.

Fedora 20 is released tomorrow! (16UTC) In the mean time a few notes: If you have installed a prerelease version at any point in the past:

• Thanks for helping us test! I hope you reported any bugs or issues you ran into and that we were able to at least address the most serious of them for you.
• Please take a minute to go and run: 'su -c 'chmod 0550 /root''. This is due to an issue in pre-release versions of Fedora 20. See https://fedoraproject.org/wiki/Common_F20_bugs#prerelease-root-perms for more information.
• If you haven't already, you should run a 'yum distro-sync' or reenable the updates-testing repository if you wish to help us test updates. See: http://www.scrye.com/wordpress/nirik/2013/12/01/updates-testing-and-final-freeze-time-again for more information.

If you plan on installing or upgrading tomorrow or after:

• Please read through the common bugs page: https://fedoraproject.org/wiki/Common_F20_bugs QA folks have done a great job of explaining and listing workarounds for common bugs. If you at least skim through this page you could save yourself a fair bit of time.
• Take a read through the release notes: http://docs.fedoraproject.org/en-US/Fedora/20/html-single/Release_Notes/index.html lots of good information there as to what has changed.
• For questions, as always, take a look at the install guide, wiki pages and then ask for help on the fedora users list, #fedora on irc or ask.fedoraproject.org.

Looking forward to a great release!

As of a few days ago, virt-manager is working again in rawhide. ;) Crobinso tracked down the builds needed (a gtk3 and pygobject3 build). This just goes to show that bugs where there are a lot of interrelated components are difficult to get traction on and get solved. At least some of the delay was also my fault, as I adding the last bug/issue to the previous solved one instead of opening a new bug, and maintainer(s) were not clear that it was still not working. If you're a package maintainer, you may have gotten a new bug on your rawhide package that it doesn't build with "-Werror=format-security". These will be great to get cleaned up. See https://fedoraproject.org/wiki/Format-Security-FAQ for all the fun details. Ran into a fun bug this last week that turned out to be in glibc (as far as I can tell). I built locally a midori package with webkit2/gtk3 which I do from time to time to see how well the port is coming along. The build finished fine, but starting it resulting in spewing: "Failed to create shared memory file /WK2SharedMemory.NNNNNNNNN" and not working. I then tried epiphany with the same result. Digging around with gdb, I finally got that it was failing in glibc. Looking at changes in the rawhide glibc, I narrowed in on some shm_open changes they made recently. I'm still not sure why the code isn't working right there, but it is not. I filed a upstream glibc bug on it: https://sourceware.org/bugzilla/show_bug.cgi?id=16274 so far with no answer. Hopefully they will look into it soon. Otherwise rawhide is rolling along as always. :)

If you have a Fedora 20 install and updated recently, you may or may not have noticed that the updates-testing repo is now disabled. It’s enabled for testing during most of the pre-release cycle of Fedora, but as we get close to release time (and we are), updates-testing is disabled. So, if you are a tester/qa person/wanting to help test in the run up to release you may wish to re-enable updates-testing (a simple: ‘su -c ‘yum-config-manager –enable updates-testing” should do). You can then update and use the excellent ‘fedora-easy-karma’ tool to provide testing feedback. If you are not interested in testing things out, and want to just have your install more or less as it will be when it’s released, you may want to run a ‘yum distro-sync’. This should downgrade your packages to the base versions from any you have installed from updates-testing. If you don’t do this you may run into odd problems about packages not available or mismatches when trying to install 32bit packages on a 64bit install or the like.

Another few weeks of rawhide and a few things to note:

• virt-manager continues to be broken. I had hopes that there was light at the end of the tunnel, but it seems not. It now starts up fine, but doesn't display any of your connections or let you use them. This is another pygobject3 issue. Some folks have downgraded pygobject3 and gtk3 to work around it. Hopefully there will be some progress soon, this is getting pretty silly.
• A new giflib landed (briefly) in rawhide. This broke a bunch more packages than the maintainer was thinking it would. They have backed it out until it can be handled properly.
• The 3.13 rc kernels are working fine here on my rawhide laptop.
• No other particularly exciting breakage that I can recall recently.
• There are now nightly rawhide and branched live images and arm images! See: http://koji.fedoraproject.org/koji/tasks?state=all&view=tree&method=appliance&order=-id for disk images and http://koji.fedoraproject.org/koji/tasks?state=all&view=tree&method=livecd&order=-id for live images. These appear some hours after the branched/rawhide compose completes.
• The rawhide compose has moved earlier. We wanted to give more time for images to compose, so we moved rawhide to start at 05:15UTC now.

Happy rawhiding.

So, a little while ago I got a Lenovo Yoga 2 Pro. This laptop has a touchscreen on it. I didn't think I would pretty much ever use it, but it came along with the package. So, I decided to look around in the Linux world and see if I could make the touchscreen work to the point I would find it usable. The yoga is a bit of a strange thing in the laptop world, as you can fold the screen back all the way. So, you get "tent mode" where the screen is back 270 degrees or so and a "tablet mode" when the screen is folded all the way back against the keyboard. When the laptop is in "tablet mode" the firmware turns off the keyboard (so you don't hit any keys when you are holding it), but (at least under Linux) doesn't turn off the touchpad. If you simply use xrandr to rotate the screen, the touchpad doesn't really re-orient correctly. A quick web search pointed me to a simple script by Elf Sternberg: http://www.elfsternberg.com/2013/05/25/thinkpad-yoga-ubuntu-12/ that works great on the yoga 2 pro as well. I might well add to it to disable the touchpad if I rotate the screen. On-screen keyboards: There's a number of them available in Fedora, but most of them are horrible. Due to the high screen resolution on this laptop (3200x1800), any on-screen keyboard that doesn't allow me to resize or set the font is a no go (unless I want to use a toothpick to select keys). I finally settled on eekboard as the best of the lot, but then someone mentioned to me that cellwriter (a handwriting recognition software) also had a nice on-screen keyboard. It's not bad. Has lots of keys and allows me to at least resize it to 1400 pixels wide. Adding a launcher for it in the Xfce panel and things are mostly set. One drawback is that it's pretty impossible to move windows around without the touchpad, so wherever you have the keyboard set to appear, it's going to be on top of that content, which can be anoying. I have not found a way to make it just pop up the keyboard when there's some kind of text entry field, but that would sure be a nice enhancement. Next up was gesture support. There's a nice application called 'easystroke' available. It's pretty flexable. You can set it to use just the touchscreen for gestures (not the touchpad) and use button 1 on the mouse for making them. You can also have global gestures, or tie them to specific applications. I really wish the multitouch stuff for the touchscreen would work, having two finger and three finger buttons and edge scrolling would be very nice, but sadly, X just sees it as button 1 press/move and thats it. You can install xie and use that with easystroke however to get it to do button presses or other crazy events. :) The downside to grestures is that you have to sit there and define all the ones you need and then remember what they are. Still it can be handy for some things. I've also not been able to pin it down by sometimes when easystroke is running mouse clicks don't work right. ;( For application support: Firefox has a extension called "Grab and Drag" that can let you use the touchscreen to move around in web pages. However, if you are using that and easystroke things can get a bit muddled. Calibre will let you go back and forward in a book if you are in 'full screen' mode in the ebook reader. That works ok, but unfortunately, you have to hit 'escape' to exit that mode, and you can't really do that unless you make a gesture for it. So, after playing around, the Linux tablet experence is no where near what you would find on a dedicated tablet, but it will actually be ok for things like reading ebooks, web browsing and watching things, etc. Also, the yoga 2 pro is a bit large in tablet mode (its a 13" screen), making it not as light and nice as a smaller tablet (like the nexus 7 or such).

Rawhide continues to be nice and boring for the most part. Just a few things to note from the last week: There was an update to upower that bumped the api/abi. This broke a number of packages. Most of them just needed a simple rebuild, but there's likely still some fallout from this. In practical terms it's not too big a problem, but something to be watching for in applications you use that query upower for power information. virt-manager doesn't start anymore. This is bug 1024569 and a good example of how things are intertwined. The actual bug is a regression in pygobject3. Thats now fixed up, but there's a issue with it's checks against the new gtk3 and gobject introspection which makes it hard to build. ;) It should be sorted out in the next few days, but in the mean time it's a bit anoying for those of us that use virt-manager a fair bit. Kudos to the libvirt folks tracking down what was going on.