This certainly comes a little late, but it took me this long to finally look into it, and I'm glad I did, so let's share.
As you may know, with Firefox 24 the behavior of the "Click to Activate" feature
for plugins, most notably Flash, was changed. I don't remember when it was first
introduced, and am too lazy to go look for it, but for a little while know there
has been an option
plugins.click_to_play that one could/should set to
in order to have plugins not enabled by default.
And if/when you wanted to activate something, all you had to do was click on it. This would not enable the plugin for the whole page, but just that one element you clicked on.
As they explained, Mozilla did change this behavior - apparently too confusing for some users - and now there's a supposedly much better UI, I suppose.
First of all, I've shared before a PKGBUILD to build kalu from its branch next on github, but I had yet to upload it the the AUR. I'm not sure why I hadn't, but this has now been done.
So if you want to test the next version of kalu, you just need to switch from kalu to kalu-git in the AUR. And speaking of the next version of kalu, you can now send it "commands" simply by writing to a FIFO.
A new version of kalu is available, with a few fixes and the simulation in case
as previously discussed, as well as support for
\e in template variables,
which can be useful if you're running kalu as CLI application, to use
Also, following the GTK 3.10 upgrade and for those who didn't downgrade or patch their GTK, i.e. are missing their icons in menus & buttons, I've also added a config tweak to forces them back.
A new version of journal-triggerd is available, fixing a possible segfault when certain loading rules, and some other little changes :
Failing to load a rule will now simply be announced & the file skipped. Only if no rule could be loaded will journal-triggerd not start.
Added support for
$'FIELDon trigger, that allows to not include the field's value as-in, but put it between single quote (shell-compatible style).
Recently GNOME 3.10 was pushed to the Arch Linux repos. I don't really care about GNOME as I don't use it, but with a GNOME release usually also come new versions of a few independent components such as GLib or GTK+.
Unfortunately, it seems GNOME developers have no problem trying to force their decisions not only to their users, but also users of any application using GTK+ regardless of their DE.
Specifically, this upgrade wasn't easy (to me) when it comes to icons. After the upgrade, I had quite a few icons broken, and lots of buttons & menus where icons were simply missing altogether.
Running Arch Linux, I've now been using systemd's journal as logging engine for a little while. This isn't about how good/bad it is, or how it compares to other solutions (e.g. syslog).
I'm using the journal, and for a little while now I've been wondering about having a few things automatically triggered when certain messages are logged. I looked for a tool to do that, but couldn't find one.
There are a few tools that will do that sort of things, but they're made for very specific things, for instance listen for failed SSH login attempts, and will (temporary) ban an IP after a while or something.
For a little while now I've been using a little module of my own to handle switching DPMS off automatically when playing, but as I recently upgraded to VLC 2.1 it broke.
I had to have a look at this again, and after fixing it I figured I might as well share this, since I hadn't really done so yet, in case it might turn useful to someone else, maybe you.
Every once in a while, kalu will not be able to tell you what upgrades are available. This isn't due to a bug, or because there's something wrong anywhere, it's simply because there is (at least) one conflict.
A conflict often isn't a big deal, and handling it is quite simple, but it requires your intervention, and that's why kalu can't list the upgrades: because you need to decide whether or not to replace one package with another, for example.
This was always a little annoying to me, because then kalu failed to do its first objective: inform about what upgrades are available, what will happen should a system upgrade be performed.
Sure, one can go on Arch's website, check the recent package updates and manually figure things out, but that defeats the purpose of having a tool to do the job for you.
One could also just start a sysupgrade, but it forces you to sync your databases, which basically means you then have to perform the whole operation right now. What if you just wanted to know what would need to be done (including every upgrades unrelated to the conflict), and then make an informed decision, about when you'll perform the sysupgrade?
A new version of kalu is available, which will now set a user-agent to be used for all its connections, including those done via ALPM (i.e. synchronizing databases, but also downloading packages when using kalu's sysupgrader).
It's not a bad thing to do, and will even fix issues some have been having with e.g. infinality-bundle repos, where lack of user-agent resulted in a download error (HTTP 406).
A new version of pacdep is out, fixing optional dependencies not working since pacman 4.1.0, and introducing a new option to show the "dependency path" for each package, inspired by karol's request for pactree.
Using option --show-path will show the (shorter) "dependency path" for each of the listed dependency, that is showing why a dependency is there, up to the main package.
This can be useful to understand why a dependency is listed, if it appears as dependency of a dependency of yet another dependency of the main package.