I had a graphic designer produce a banner for me a while back. Of course the font he used isn't part of the standard Linux font packages (AFAIK), so I had find a way to add it to my machine.
I was expecting a nice easy, drop into font directory style of installation. Well it was pretty much that easy.
Copied the .ttf file to /usr/share/fonts
As root, run fc-cache. Use the -v flag to get a list of what gets noticed then you will see if your new font gets picked up.
I put mine in /usr/share/fonts/local to keep the ones I add separate from those installed by Fedora.
Wednesday 17 October 2012
Thursday 9 August 2012
DigiKam and Fedora 17
Since Picasa support for Linux has been withdrawn by Linux (it was only ever partial support tbh as it runs under Wine) I've been on the lookout for new photo management software.
I've tried Shotwell, that seems to do a reasonable job but not comprehensive. It would be ok if I hadn't been pointed towards DigiKam by a blog entry somewere comparing packages.
Both shotwell and digikam can be installed direct from the Fedora repositories using yum.
DigiKam seems to have a much greater range for features. Shotwell worked well enough, what it does it does well. I'm going to try DigiKam for a while now and see how I get on.
One quirk of DigiKam in Fedora 17 is that out of the box there didn't seem to be anyway to export images to another folder ready for burning to disc or uploading to a website.
A bit of reading later and an installation of "kipi-plugins" later I seem to have a plethora of export options.
I now have options to upload images directly to a variety of website (Flickr, Facebook, ImgShack, PicassaWeb, SmugMug the list goes on and on!) as well as local export (eg as HTML presentation, email client, IM client ....) but still not yet found a simple "take these photos and export to this place on disc" option!
It does seem odd to me that such fundamental functionality isn't included in DigiKam straight from the repositories. Even if that was just a matter of saying kipi-plugins is a dependency of DigiKam.
EDIT:
Found it!
Apparently to export files to a local directory I have to go through "export -> Export to remote computer". Hardly intuitive but it works!
I've tried Shotwell, that seems to do a reasonable job but not comprehensive. It would be ok if I hadn't been pointed towards DigiKam by a blog entry somewere comparing packages.
Both shotwell and digikam can be installed direct from the Fedora repositories using yum.
DigiKam seems to have a much greater range for features. Shotwell worked well enough, what it does it does well. I'm going to try DigiKam for a while now and see how I get on.
One quirk of DigiKam in Fedora 17 is that out of the box there didn't seem to be anyway to export images to another folder ready for burning to disc or uploading to a website.
A bit of reading later and an installation of "kipi-plugins" later I seem to have a plethora of export options.
I now have options to upload images directly to a variety of website (Flickr, Facebook, ImgShack, PicassaWeb, SmugMug the list goes on and on!) as well as local export (eg as HTML presentation, email client, IM client ....) but still not yet found a simple "take these photos and export to this place on disc" option!
It does seem odd to me that such fundamental functionality isn't included in DigiKam straight from the repositories. Even if that was just a matter of saying kipi-plugins is a dependency of DigiKam.
EDIT:
Found it!
Apparently to export files to a local directory I have to go through "export -> Export to remote computer". Hardly intuitive but it works!
Tuesday 3 July 2012
Fedora 17, Eclipse and Javascript
I forget why or how I ended up in the situation but I recently ended up switching from a downloaded Eclipse installation to using the Fedora repository version of Eclipse.
So I'm now flying Juno Eclipse. Installed bunch of packages to let me do Java and PHP work in Eclipse:
So great, I have a shiny Juno installation that lets me do PHP work (not tested Java builds yet...) , woohoo!
So how do I get Javascript editing working?
When I was using Eclipse downloaded directly from the Eclipse project I just needed to install WTP (I think), so I went looking for that and found a few likely candidates:
So when I get this PHP contract out of the way I may be switching back to a 'proper' Eclipse installation direct from the Eclipse project.
Unless any Fedora people out there can hold my hand through my Eclipse Juno Javascript editing setup needs? ;)
So I'm now flying Juno Eclipse. Installed bunch of packages to let me do Java and PHP work in Eclipse:
[root@bigfoot html]# rpm -qa | grep eclipseeclipse-pde-4.2.0-0.22.I201205031800.fc17.x86_64eclipse-rcp-4.2.0-0.22.I201205031800.fc17.x86_64eclipse-phpeclipse-1.2.3-4.fc17.noarcheclipse-emf-xsd-2.8.0-0.7.e674bb28ad412fc9bc786f2f9b3c157eb2cbdae0.fc17.noarcheclipse-swt-4.2.0-0.22.I201205031800.fc17.x86_64eclipse-dtp-1.10-0.1.M6.fc17.noarcheclipse-gef-3.8.0-0.3.20120402.fc17.noarcheclipse-platform-4.2.0-0.22.I201205031800.fc17.x86_64eclipse-emf-core-2.8.0-0.22.I201205031800.fc17.x86_64eclipse-emf-2.8.0-0.7.e674bb28ad412fc9bc786f2f9b3c157eb2cbdae0.fc17.noarchicu4j-eclipse-4.4.2.2-11.fc17.noarcheclipse-jdt-4.2.0-0.22.I201205031800.fc17.x86_64[root@bigfoot html]#
So great, I have a shiny Juno installation that lets me do PHP work (not tested Java builds yet...) , woohoo!
So how do I get Javascript editing working?
When I was using Eclipse downloaded directly from the Eclipse project I just needed to install WTP (I think), so I went looking for that and found a few likely candidates:
yum install eclipse-wtp-common eclipse-wtp-servertools eclipse-wtp-sourceeditingNow when I fire up Eclipse Juno, it starts, but I get all sorts of error messages about null pointers and not being able to initialise plugin properly. I guess those packages aren't quite right somehow.
So when I get this PHP contract out of the way I may be switching back to a 'proper' Eclipse installation direct from the Eclipse project.
Unless any Fedora people out there can hold my hand through my Eclipse Juno Javascript editing setup needs? ;)
Friday 1 June 2012
More Gnome3 / Fedora 17 woe
I used use a handy feature of Gnome 3 (there is something about it I like!) which let me use the power key (aka windows key) to perform a quick search for the file by it's name.
So when I knew the filename pressing that key and typing the filename would open it quickly instead of ploughing through directories in my file explorer. It seems either the Fedora17 upgrade or the Gnome 3.4 upgrade that came with it, has disabled this feature.
Any ideas Linux people?
So when I knew the filename pressing that key and typing the filename would open it quickly instead of ploughing through directories in my file explorer. It seems either the Fedora17 upgrade or the Gnome 3.4 upgrade that came with it, has disabled this feature.
Any ideas Linux people?
Wednesday 30 May 2012
Fedora 17 upgrade - not the best experience
I have been running Fedora Linux for a reason. It tends to get new + shiny stuff before other distros. New & Shiny = good.
Of course to offset the goodness of new and shiny you will occasionally get issues. The upgrade from FC16 to FC17 seems to create its fair share of issues!
After running the preupgrade process and rebooting:
Of course to offset the goodness of new and shiny you will occasionally get issues. The upgrade from FC16 to FC17 seems to create its fair share of issues!
After running the preupgrade process and rebooting:
- Only FC16 kernels listed in grub menu
- Some aspects of system have clearly changed, uname - r returns an FC16 kernel
Oh dear. This is going to be 'fun'!
Following some handy info from a post in FedoraForum.org I rebooted and edited the grub config at boot time (press e when grub meu is shown - you left that couple of second delay in your grub config right? ;) ). Changed all references from FC16 to FC17 and I now appear to have booted a FC17 kernel.
Now if I query rpm to see what state I'm in regarding packages:
[root@bigfoot /]# rpm -qa | grep fc16
plexus-maven-plugin-1.3.8-5.fc16.noarch
compiz-gnome-0.9.5.92.1-0.2.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc16.x86_64
alacarte-0.13.2-3.fc16.noarch
yum-3.4.3-24.fc16.noarch
felix-parent-1.2.1-6.fc16.noarch
netbeans-ide-6.9-5.fc16.noarch
plexus-sec-dispatcher-1.4-4.fc16.noarch
compiz-plugins-main-0.9.5.92-1.fc16.x86_64
mdadm-3.2.3-7.fc16.x86_64
compiz-gtk-0.9.5.92.1-0.2.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc16.x86_64
async-http-client-1.6.1-1.fc16.noarch
pmd-4.2.5-11.fc16.noarch
libcompizconfig-0.9.5.92-1.fc16.x86_64
cscope-15.7a-9.fc16.x86_64
libva-freeworld-1.0.14-1.fc16.x86_64
netbeans-cvsclient-6.9-5.fc16.noarch
plexus-xmlrpc-1.0-0.7.b4.3.fc16.noarch
telepathy-butterfly-0.5.15-4.fc16.noarch
compiz-0.9.5.92.1-0.2.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc16.x86_64
libgdiplus-2.10-2.fc16.x86_64
Some of those I'm quite happy to remove (eg NetBeans packages), some I'm not so sure on (Compiz - maybe needed by my Gnome installation) and others I am quite concerned about - anyone fancy running 'yum remove yum'? No, me either.
So it's off to the inspect theyum conf files and make sure nothing points at a FC16 repo before updating and trying to clean up these errant packages.
Looking at the man page for yum it seems there is a handy synchronization command that I'm hoping will sort some of these package issues out, and indeed it did. It seems I had more than just FC16 packages that hadn't been updated, yum found a FC13 and even a FC12 package!
I'll have to use this syncho command more often.
[root@bigfoot yum.repos.d]# yum distribution-synchronization
Loaded plugins: presto, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package cscope.x86_64 0:15.7a-8.fc17 will be a downgrade
---> Package cscope.x86_64 0:15.7a-9.fc16 will be erased
---> Package mdadm.x86_64 0:3.2.3-6.fc17 will be a downgrade
---> Package mdadm.x86_64 0:3.2.3-7.fc16 will be erased
---> Package ndesk-dbus.x86_64 0:0.6.1a-10.fc17 will be a downgrade
---> Package ndesk-dbus.x86_64 0:0.6.1b-1.fc13 will be erased
---> Package vbetool.x86_64 0:1.2.1-2.fc17 will be a downgrade
---> Package vbetool.x86_64 0:1.2.2-1.fc12 will be erased
---> Package yum.noarch 0:3.4.3-23.fc17 will be a downgrade
---> Package yum.noarch 0:3.4.3-24.fc16 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
Looking at the man page for yum it seems there is a handy synchronization command that I'm hoping will sort some of these package issues out, and indeed it did. It seems I had more than just FC16 packages that hadn't been updated, yum found a FC13 and even a FC12 package!
I'll have to use this syncho command more often.
[root@bigfoot yum.repos.d]# yum distribution-synchronization
Loaded plugins: presto, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package cscope.x86_64 0:15.7a-8.fc17 will be a downgrade
---> Package cscope.x86_64 0:15.7a-9.fc16 will be erased
---> Package mdadm.x86_64 0:3.2.3-6.fc17 will be a downgrade
---> Package mdadm.x86_64 0:3.2.3-7.fc16 will be erased
---> Package ndesk-dbus.x86_64 0:0.6.1a-10.fc17 will be a downgrade
---> Package ndesk-dbus.x86_64 0:0.6.1b-1.fc13 will be erased
---> Package vbetool.x86_64 0:1.2.1-2.fc17 will be a downgrade
---> Package vbetool.x86_64 0:1.2.2-1.fc12 will be erased
---> Package yum.noarch 0:3.4.3-23.fc17 will be a downgrade
---> Package yum.noarch 0:3.4.3-24.fc16 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
Subscribe to:
Posts (Atom)