Archive for the 'Fedora' Category

Page 2 of 11

PolicyKit Javascript rules with catchall

So the desktop is ruled by PolicyKit which is awesome. It includes sets of rules about who can run certain actions (such as mounting an internal drive).

The rules are read in lexical order from the /etc/polkit-1/rules.d and /usr/share/polkit-1/rules.d directories.

You can get a list of available actions with the command:
$ pkaction

There may come a time when you want to tweak those rules though, to make management of your system easier. For example, managing virt-manager without a password if you’re in the wheel group (the rule is org.libvirt.unix.manage). If so, you can create one with a name like “10-my-policy.rules” in either directory above.

polkit.addRule(function(action, subject) {
if (action.id == "org.libvirt.unix.manage" &&
subject.isInGroup("wheel") && subject.active) {
return polkit.Result.YES;
}
});

Some related tasks have several actions, like configuring cups:
$ pkaction |grep cups
org.opensuse.cupspkhelper.mechanism.all-edit
org.opensuse.cupspkhelper.mechanism.class-edit
org.opensuse.cupspkhelper.mechanism.devices-get
org.opensuse.cupspkhelper.mechanism.job-edit
org.opensuse.cupspkhelper.mechanism.job-not-owned-edit
org.opensuse.cupspkhelper.mechanism.printer-enable
org.opensuse.cupspkhelper.mechanism.printer-local-edit
org.opensuse.cupspkhelper.mechanism.printer-remote-edit
org.opensuse.cupspkhelper.mechanism.printer-set-default
org.opensuse.cupspkhelper.mechanism.printeraddremove
org.opensuse.cupspkhelper.mechanism.server-settings

Previously, before the new javascript format, one could match all those actions with:
org.opensuse.cupspkhelper.mechanism.*

That doesn’t work with js though, so this is how you can do it:
polkit.addRule(function(action, subject) {
if (action.id.indexOf("org.opensuse.cupspkhelper.mechanism") == 0 &&
subject.isInGroup("wheel") && subject.active) {
return polkit.Result.YES;
}
});

Changes are picked up straight away, so just save the file and test!

Introducing Pharlap, our new driver manager replacement for Jockey

Previous versions of Korora have shipped with Ubuntu’s Jockey for installing drivers like NVIDIA and Catalyst but now we have Pharlap. Jockey has been deprecated upstream in favour of ubuntu-drivers-common, so we thought we’d see if we could make some use of that code base and create a version for Korora/Fedora+RPMFusion.

It seemed to work out well and so it’s included by default in the Korora 20 beta release, although Jockey is still available to install if you so desire. It’s much more lightweight and uses yum-daemon for package management. The packages are pharlap and pharlap-modaliases, both of which are available for Fedora 20 from the Korora repo (including source RPMs).

Pharlap, driver manager

Pharlap, driver manager

We need lots of testing on Pharlap so if you’re keen to help, we would appreciate any feedback. Hopefully at some point we can get it into RPMFusion.

Where did the name come from?

Phar Lap, great racehorse

Phar Lap, great racehorse

Well since we were replacing Jockey, we thought we’d go with a horse theme. Born in 1926, Phar Lap was a New Zealand foaled, Australian-trained thoroughbred racehorse, one of the greatest of all time. Although Phar Lap came last in his first ever race, towards the end of his career he won 32 of 35 races (coming second in two of the others he lost).

In 1932 Phar Lap raced in the Agua Caliente Handicap at Tijuana, Mexico, which was North America’s then richest race. It was his first time racing in America, his first race on dirt tracks and his first start from barrier stalls. He was last out of the gate and started ten lengths behind the leaders, but by the half-mile he was in front and then won the race by three lengths, setting a new track record.

Two weeks later Phar Lap was dead after someone poisoned him with arsenic.

So to honour this great horse, we’ve named the project Pharlap.

Korora 20 (Peach) beta released

The Korora Project is pleased to announce the first beta release of version 20 (codename “Peach”) which is now available for download.

Note: This beta release of Korora is derived from a beta release of Fedora1 and as such there will likely be a larger number of bugs and many software updates.

For the first time we are introducing an Xfce desktop, which was made possible thanks to Maik Adamietz (AKA DarkEra) and others in the community. We would also like to thank Jeremiah Summers (AKA JMiahMan) for his assistance in updating the KDE version as well as Dan Marshall (AKA dan408) for his help with the MATE release. Thank you!

Features

GNOME 3.10

GNOME 3.10 will have a number of new applications and new features that will please GNOME-lovers. This release includes a new music application (gnome-music), a new maps application (gnome-maps), a revamp for the system status menu, and Zimbra support in Evolution. A preview of GNOME on Wayland compositor is also finally available. Refer to the GNOME 3.10 announcement for more details.

KDE Plasma Workspaces 4.11

A modern, stable desktop environment, this release includes faster Nepomuk indexing, improvements to Kontact, KScreen integration in KWin, Metalink/HTTP support for KGet, and much more. Refer to the KDE Plasma Workspaces 4.11 announcement for more details.

But wait, there’s more …

Derived from Fedora 201 beta, Korora benefits from Fedora’s long tradition of bringing the latest technologies to open source software users.

A complete list with details of each new inherited feature is available at the Fedora 20 Accepted Proposals List

  • Application Installer brings a new interface for installing packages in GNOME.
  • NetworkManager should be able to configure bond master and bridge interfaces with commonly used options and recognise their existing configuration on startup without disrupting their operation.
  • Ruby on Rails 4.0, which is the latest version of well know web framework written in Ruby.
  • LVM has introduced thin provisioning technology, which provides greatly improved snapshot functionality in addition to thin provisioning capability. This change will make it possible to configure thin provisioning during OS installation.
  • Plasma-nm replaces the current network applet in KDE with a new one and bring the latest features in NetworkManager to KDE.
  • SSD Cache is updated thanks to the recent kernel to support (fast) SSD caching of (slow) ordinary hard disks.
  • VirtManager user interface for managing virtual machines has the ability to easily manage snapshots.

Contributing

We don’t build Korora inside a box. We need your help! Bug reports are especially helpful – if you encounter any issues, please report them!

Korora is a fantastic, friendly community, and we have many ways in which you can contribute. Please send us feedback in the forums or log a bug report if you have any issues. Of course you can find us on social media like Identi.ca, Twitter, Google+ and Facebook.

What is the Beta release?

The Beta release is the last important milestone before the release of Korora 20. Join us in making this a solid release by downloading, testing, and providing your valuable feedback.

Of course, this is a beta release, meaning that some problems may still be lurking. A list of the problems already known can be found at the Common F20 bugs page.

1 Korora is not provided or supported by the Fedora Project. Official, unmodified Fedora software is available through the Fedora Project website.

Only use lua in %pretrans, not shell

In case I see an error like this again:
Error creating Live CD : Dependency check failed : (('package', '1.1', '1.fc20'), ('/bin/sh', ''), 0, 0, None)

Take a look at %pretrans in the spec file of said package.

We shouldn’t use shell in %pretrans as doing so breaks system installations and kickstarts because %pretrans is run before any dependencies are met.

This is spelled out in Fedora’s Packaging Guidelines.

If we must use %pretrans, we should do so using lua.

Korora 19.1 released

Yesterday we released Korora 19.1 which is a 3 month update to the original 19 release. Anyone already running Korora doesn’t need this, however if you are planning do any more installs we highly recommend downloading this new release as it includes all updates, a few tweaks and fixes a number of bugs. This release also includes versions of the MATE and Cinnamon desktops which we’ve created to gauge community interest.

The 19.1 release features:

  • All updates at time of release, including; KDE 4.11, kernel 3.11.2 and Firefox 24
  • Introduces support for MATE and Cinnamon desktops
  • Replaces rawtherapee raw image editor with darktable
  • Includes lzma compression, fonts-tweak-tool and gnome-documents
  • Fixes a systemd bug where the installer sometimes won’t start

MATE is a fork of GNOME 2, so if you’re pining for the old days and GNOME 3 isn’t your cup of tea, this may be for you.

Cinnamon is a fork of GNOME Shell and implements a more traditional layout with modern technology on top of GNOME 3.

MATE

korora-19.1-mate

CINNAMON

korora-19.1-cinnamon

Thank you to our community members who have helped to make this release possible.

Enjoy!

Fixing GNOME 3 freezes on SandyBridge and later Intel graphics

I had this problem in Korora/Fedora 19 and the fix appears to be enabling SNA (Sandybridge’s New Acceleration) acceleration for the card instead of the older UXA (Unified Acceleration Architecture).

It’s simple to do, just add the following contents to /etc/X11/xorg.conf.d/10-intel.conf file then restart X or reboot.
Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "AccelMethod" "sna"
EndSection

ZDNet on Korora 19, “If you make the effort to try it, you are likely to love it.”

After reviewing Fedora 19, J.A. Watson does a hands on with Korora 19.

Once installed, Korora has worked flawlessly for me. Every system, every bit of hardware, every driver — they have all worked straight out of the box. If you’re not into reading release announcements and such to find out what the differences [between Fedora and Korora] are, just install it and then browse around in the menus a bit. It includes a truly impressive array of pre-installed software, in every category. If you make the effort to try it, you are likely to love it.

Korora 19 (Bruce) released

Well, the cat’s out of the bag! Korora 19 (Bruce) is now available for download, which for the first time ever coincides with the same release of Fedora :-)

See the official Korora Release announcement for more details.

Why does yumdb include packages I haven’t explicitly installed?

Yesterday I posted how to list packages you’ve explicitly installed using yum, but some people have written in to say the command shows packages that they never explicitly installed. Some examples are, things like ModemManager and firmware packages.

I think the reason for this is that yumdb is including default and mandatory packages from when you install a group. I guess that makes sense, if you install a group then you’re telling it you want all of the packages there (but you shouldn’t get any deps).

For example, most systems probably have @hardware-support group installed, which is where ipw220-firmware comes from:
$ sudo yum groupinfo hardware-support |grep ipw2200
=ipw2200-firmware

Similarly, for ModemManager, it’ll be part of default @dial-up group.
$ sudo yum groupinfo dial-up |grep Modem
=ModemManager

So the only way around this I can see is to not install groups, because installing a group tells it to install whatever is in the list.

It would be great however, if yumdb supported a “group” type..

-c

How to list packages you have explicitly installed using yum

If you’re after a way to list all the packages you have explicitly installed (rather than packages that have been pulled in as a dependency) then you can do that with yumdb (thanks to Panu on #yum for the tip) which is powered by a new database added in 2009.

List packages you chose to install:
yumdb search reason user

List packages which were installed as deps:
yumdb search reason dep

Let’s go through an example, installing gnash which pulls in a few deps on my system:
Installed:
gnash.x86_64 1:0.8.10-8.fc19
 
Dependency Installed:
agg.x86_64 0:2.5-16.fc19 boost-iostreams.x86_64 0:1.53.0-6.fc19 boost-serialization.x86_64 0:1.53.0-6.fc19 gtkglext-libs.x86_64 0:1.2.0-18.fc18 pangox-compat.x86_64 0:0.0.2-2.fc19

As you can see, I got 5 dependencies, so let’s check whether yumdb got it right:
yumdb search reason dep |egrep "agg|boost-iostreams|boost-serialization|gtkglext-libs|pangox-compat"
 
agg-2.5-16.fc19.x86_64
boost-iostreams-1.53.0-6.fc19.x86_64
boost-serialization-1.53.0-6.fc19.x86_64
gtkglext-libs-1.2.0-18.fc18.x86_64
pangox-compat-0.0.2-2.fc19.x86_64

Yep, looks good. What about gnash?
yumdb search reason user |grep gnash
 
1:gnash-0.8.10-8.fc19.x86_64

Update:
Some people have written in to say the command shows packages that they never explicitly installed, things like ModemManager and firware packages.

I think the reason for this is that yumdb is including default and mandatory packages from when you install a group. I guess that makes sense, if you install a group then you’re telling it you want all of the packages there (but you shouldn’t get any deps).

For example, most systems probably have @hardware-support group installed, which is where ipw220-firmware comes from:
$ sudo yum groupinfo hardware-support |grep ipw2200
=ipw2200-firmware

Similarly, for ModemManager, it’ll be part of default @dial-up group.
$ sudo yum groupinfo dial-up |grep Modem
=ModemManager

So only way around this I can see is to not install groups, because installing a group tells it to install whatever is in the list.

It would be great if yumdb supported “group” type..

-c