welp's blog » Linux

Mozilla Firefox 3.5 Beta 4 and colour profiles

welp — Sat, 13 Jun 2009 09:37:53 +0000

After upgrading to Fedora 11 (and thus upgrading Firefox to 3.5 Beta 4), I noticed that Firefox was not correctly identifying some of the ICC colour profiles and thus was rendering some of the images incorrectly.

According to this wiki page, it should be a simple matter of going to about:config and changing the value of gfx.color_management.mode to 1, which enables full colour management (default is 2, which enables colour management only on properly tagged images). This, however, does not seem to work…

After looking into the issue, it seems that there’s a bug with the way in which Firefox identifies the colour profiles, resulting in some incorrectly rendered images. Although the bug has been fixed in the trunk release (i.e. the nightly/hourly builds will have the bug-fix), the “proper” versioned releases will not.

From what I can work out, the bug-fix won’t be pushed into the main release until the last minute, and will most likely be put in the 3.5.1 release (or possibly even the 3.6 release!), so if correct colour profiles are important to you, you’re either going to want to start using the hourly/nightly builds or downgrade back to an earlier version of Firefox which doesn’t have the bug.

Retiring, unless otherwise requested.

welp — Sun, 03 May 2009 21:28:53 +0000

My recently-sent email to the -core and -dev mailing lists:

Hi,


I've enjoyed my time with Gentoo, mostly... But these days I've just got

too demotivated to work on it. I might have stayed if Ken69267 posted me

some Lifesavers, but he didn't.  
On a more serious note, the problem seems to be the complete lack of

management in the required places, Gentoo is fast becoming (or more

likely, already is) an anarchic organisation, where it's becoming

nigh-on impossible to keep track of things. 
I see a number of issues with Gentoo these days. The lack of a proper

leadership body. Lack of people working together in unison. The tree

needs to be sorted out: we have >16000 packages, and 200-250 developers,

not all of which are ebuild developers) - We're still using CVS, we do

*not* have the manpower to keep all the packages updated properly using

a centralised VCS. If these issues were fixed, I don't know/care how

they do get fixed, but if they were, I might consider coming back.
If you *really* want me to stay/not retire, and attempt to help fix

these issues, then I guess I can do so if enough people request that of

me. But I will do so purely in a "managerial" position, and will do no

ebuild or other such development.
I'll still hang around in various channels and so on and so forth.
Whatever happens, I do apparently maintain a few misc packages, most of

which are low maintenance. Various herds will now need a new lead

(apologies guys), so that will have to be arranged as well. You will

also need to find another slacker to replace me  
If there isn't a mass revolt against my retirement, so long, and thanks

for all the fish! Otherwise... We'll see.

Thanks, welp

Updating to 4.6 and installing Gentoo/FreeBSD on amd64

welp — Fri, 13 Mar 2009 20:24:33 +0000

Tonight I’m going to (attempt to) update to Xfce-4.6 on my Xfce VM, so I’ll let you know how that goes goes.

On a side note, drizzt has been busy working on stages for Gentoo/FreeBSD on amd64, so I’m probably going to attempt to install that in a VM, and see how we get on with that. With any luck, we’ll hopefully have the ~amd64-fbsd keyword in the tree at this rate!

Fixing up Narcissus’s server

welp — Sun, 08 Mar 2009 19:49:38 +0000

Right, I’ve spent most of the weekend sorting out various Apache/DNS/VirtualHost issues on Narcissus’s new VPS. He’s got five IP addresses pointing at his VPS, and randomly assigned them to the various sites hosted on the server… I wasn’t best pleased with this, so split the sites into various categories, assigned them an IP address based on that, and redid the DNS.

After sorting that lot out, it was time to sort out the filesystem locations where the sites were being hosted. The VirtualHost directives were originally pointing at content in ~user/public_html. I find that this has a number of issues, especially when the user wants to have multiple subdomains, and also when users want to put actual content in their ~user/public_html to be made available via http://foo.bar.com/~user. It is also a lot less centralised, and especially in cases where the user has no account on the server, can lead to a lot of unused user accounts, which I consider to be a security liability. As such, I prefer to host sites in /var/www/$site_name/htdocs with their logfiles stored in /var/www/$site_name/logs. This leads to a system which is much easier to manage as all the sites are centralised. If a user needs to make changes to their site, there’s a symlink created to ~user/sites/$site_name, which leads back to the site in /var.

So, we hacked together a quick script to move sites to the proper location, update the httpd.conf, and ran that, which solved the “problem” fairly quickly.

After doing all of that, I decided to get some content up on our new house website (the group of students I’m living with next year decided to make a website for the house, with aggregated blog feeds, house rules, news, forums (for debating issues and so on), and various uses like that. I decided to use Drupal as a CMS, as I decided it offered most of the functuality which I needed, and have been working on getting that up and running. I’ve still got to sort out the aesthetics side of things, but it should be up and running properly sometime soonish, at which point, I’ll announce it to the world.