It seems to me as a general rule that the people who are unpleasant to deal with (or at least all of those I can think of in any of the communities I am involved with) all have the same basic fundamental viewpoint: Assume malice by default.

By this I mean that when they see something and post/tweet/mention it, they approach it from the idea that the community or parts of it are deliberately conspiring, hiding, planning, or doing the thing with “mallice aforethought”, and that the community or parts of it must PROVE that they are not doing so. There also seems a subset that assume some kind of malicious ignorance (“You should google this, since you didn’t you are stupid and wasting my time”).

In contrast the vast majority of people in communities I am involved in either assume nothing (“hey, whats up with this, can you tell me?”) or assume good faith (“This looks like a bug, but perhaps I don’t understand what you are trying to do here, can you explain?”) and are generally quite pleasant to deal with.

I’m sure there are counter examples, but I wonder if in general people agree?

Another related nice change that landed this week is that rpm by default is only going to look for dependencies in .so files that also start in ‘lib’ or ‘ld’ and not just anything ending in .so. So far I’ve not seen any breakage due to this change and it should nicely reduce the number of deps carried in the collection.

Finally, something to note about rawhide testing that I am not sure I have any kind of answer for, but I think is worth exploring: When running rawhide it’s generally a good idea to reboot frequently. New kernels arrive almost daily, and it’s good to check that things all still boot normally (this exercizes at least: dracut, kernel, grub2 or other bootloader, systemd, other stuff that starts only on boot, etc). However, this also means that there’s likely not very many people running rawhide that test longer uptimes. This would exersize things like: updates of long running processes, systemd, memory leaks, logrotation, and other things that collect up and don’t run at boot). I’ve hit several odd systemd issues on upgrade, and I’m sure there’s more out there. Perhaps we should just say that this is what branched is better suited for (as kernels and reasons for update are less frequent there), or perhaps there’s some artificial way to test this, or a vm or the like could be left running to do so. Just something to consider.

Utterly boring this week. I cannot recall any problems here at all.

In branched f19 news, we are moving into Beta freeze today. You can follow along on blockers and freeze exceptions (or propose new ones) at the blockerbugs application. There was a bunch of activity from various desktop sigs in the last week to get their spins down to their target sizes, but I think we are in pretty good shape on that now. Hopefully it will be a smooth and on-time Beta release for once.

Have you submitted a talk?

Fedora is doing a new conference this year: flock

It’s setup more like a traditional conference (sessions proposed in advance) and it’s timed after Fedora 19 comes out, but early in the Fedora 20 cycle, so there’s good ability to plan things for the very next Fedora at it. Also, hopefully lots of folks from around the world will be able to attend. (Next years flock might well be in Europe).

I’ve submitted one talk so far that I thought might be fun an informative:

The life of a Fedora package: “This talk will follow in detail one package through all the steps of it’s life in Fedora and explain what happens at each step and all the systems and applications that deal with packages. Starting from idea, to project, to packaging, to review, importing, building, update, signing, mashi ng, syncing, testing, maintaining, retiring and end of life”

As usual, my problem isn’t what to talk about, but that there are too many things to talk about. I’ve considered a “Intro to Fedora infrastructure” talk, but I’m not sure how interesting people would find it.

I also submitted a ‘sprint’:

Highly available databases: Fedora infrastructure currently depends on serveral database servers, we want to come up with a plan to make them highly available and no longer a single point of failure. postgresql wizards wanted to help us with this sprint!

I’d love to get rid of having to schedule outages when we reboot or work on our database servers.

Anyhow, I might well propose some more sprints/talks/hackfests/workshops before the deadline (May 31st). If there’s something that you would particularly like to see me talk on or run a workshop/hackfest/sprint on, drop me a line and I might be willing to.

Replacing my authoritative server with nsd was pretty easy overall. I could reuse the same zone files, I just had to add a bit of nsd config to load them. My main firewall/gateway machine at home was also functioning as a caching server for machines here, so I had to replace named with nsd only listening on the external interface, and unbound only listening on all the internal interfaces. Worked like a charm. nsd now answers external queries for my domains and unbound does caching for other internal machines.

My main internal webserver/mail server machine also was running named and serving some internal only zones. nsd doesn’t have any kind of ‘views’ setup like named has so I had to ponder on this for a bit until I noticed that unbound can also optionally have local data. I just setup my zones there in unbound as local-data and it then was able to do what I needed (basically I need my domains to resolve to the internal ip’s on that machine so apache is happy, etc). It can also easily resolve *.example.com to whatever single ip you like. Very handy. The only downside of this is that dnssec doesn’t work right with local-data. Perhaps if I signed the zones with the same keys at the external site it could, but not sure it’s worth the trouble.

Unbound also has a nifty control program (non surprisingly called unbound-control) that can let you do things like flush cache for just a single specifc zone or host, setup a forward over a vpn or other link for just _some_ domains, etc. It’s really nice and flexable.

Both unbound and nsd as very dnssec aware and will try and validate as much as possible. Also, nsd has rate limiting built in so it’s resistant to DOS or DDOS amplification attacks.

So, if you are looking to replace bind, nsd seems to work nicely for authoritative and unbound does great for recursive.

The 3.9.0 kernel came out, and quickly was replaced with 3.10.0 git snapshots. So far they have been all running just fine here, although there was a few there that had some problems with wired ethernet.

Xfce 4.10.1 updates came out. These are just bugfix/translation updates for the existing 4.10.x Xfce stable stream. The more important fixes we were already carrying as backported patches, so there’s nothing too thrilling here. Updates are out for f18 and f19, please do karma them up if they work for you. Rawhide had the packages monday.

There was some yum breakage last thursday. Luckily for me I didn’t update early in the day so I saw the reports and was able to update the fixed yum from koji before applying my daily updates. This is another nice way to be on rawhide and a bit more conservative, just wait and update late in the day so others will hit the big problems before you do and provide solutions. (It’s also another great reason to be on the test list to see those kinds of things).

Ran into an odd dig core dump issue (try: “dig fedoraproject.org +sigchase +topdown” and see the cores pile up). Unfortunately, abrt didn’t want to file it for me, so I will have to do a bit more digging and make sure it’s filed.

A fedora community member on g+ whipped up (pun intended) a rawhide wallpaper thats pretty cool: https://plus.google.com/116680320767812371369/posts/JTy5m3YhPAJ is the post.

Until next week… move em up.

Another pretty dull week here in rawhide land. The updates flow has been pretty heavy, but breakage has not been.

There’s a very likely fix to a xfce4-session crash that some folks had been seeing in f19/rawhide. It was quite an anoying bug to deal with (you would be using your desktop and then, bam, back to lightdm). I really hope it’s fixed. If not, please do file it or note it on one of the open bugs.

Kernel 3.9.0 final was released, and rawhide has moved on to 3.10.

Looking forward to some more quiet weeks.

The lvm2 issue I ran into last week with /home not mounting on boot was quickly answered by lvm2 maintainers. I had a workaround quickly and then a real fix landed in a few days. The issue also affected f19, so the fix landed there too. Good work. See bug 952782 for more info.

I continue to see a strange systemd bug where when I update systemd packages, it forgets about the inhibits from xfce4-power-manager. The net effect is that if I do a systemd package update, closing my laptop lid starts suspending (which I really really dislike). See bug 928962 to follow along on that one.

Otherwise again, pretty smooth sailing.

Some recent change, likely in lvm2, has caused my encrypted /home lv to not be activated right on boot. Root and swap come up fine and the encrypted volume is unlocked, but for some reason /home doesn’t get activated. As a work around you can add a timeout to /etc/fstab: “defaults,x-systemd.device-timeout=30″ and then when the mount times out, you login to the emergency shell and ‘vgchange -ay’ and ‘mount /home’ and then control-d to continue boot. I’ve filed a bug on this, so hopefully it will get fixed up soon.

Otherwise pretty boring stream of updates this last week… and rawhide keeps rolling along.

A pretty boring week in rawhide again.

webkitgtk was updated to 2.0.0 after a bit of tweaking on banshee. With 2.0.0, webkitgtk switches to using gstreamer1 packages instead of the old gstreamer-0.10 versions. Banshee was linking against webkitgtk and old gstreamer (which would result in crashes). Luckily there were patches porting it to newer gstreamer and folks were able to get those all working.

There’s still a number of broken deps in the rawhide and branched reports. I sure wish maintainers would be quicker about dealing with them.

Nothing else really leaps to mind, it’s been pretty smooth sailing…