Just in case anyone else happens to stumble on this random error message when building CUPS locally:
./cupsd: symbol lookup error: ./cupsd: undefined symbol: cupsArrayNew3
Just remember to do make install before you try running cupsd.
Just in case anyone else happens to stumble on this random error message when building CUPS locally:
./cupsd: symbol lookup error: ./cupsd: undefined symbol: cupsArrayNew3
Just remember to do make install before you try running cupsd.
One of the best parts of working at Red Hat is that you are encouraged to do things properly, even if they take a long time. I guess the logic is that if you’re going to be supporting the code in RHEL for years and years, then it pays to do it the right way, and not use some evil hack that’s going to break for a customer at some inopportune time.
As some of you might know, I’ve been hacking on colord for a few months (at the same time as PackageKit, upower and GNOME3!) and am now starting to get some upstream progress. To fix color management when printing, we really need to integrate with quite a few layers. This afternoon I rewrote pstoraster and pdftoraster into gstoraster, and added the required hooks to get the ICC profile from colord. I’ve still got to do the same for foomatic-rip, and then that’s the “query” side of the problem finished.
The next part, is to finish the work done by Tim Waugh, so that CUPS registers devices and embedded profiles with colord. With all the patches in place, it basically means that making a printer color managed becomes trivial.
Thanks go to Till Kamppeter for reviewing the different iterations of the ghostscript filter code patch, and initially pointing me in the right direction. Now I’ll brave CUPS upstream and try to get the other patch accepted there.
This is probably all a bit late for GNOME 3 and Fedora 15, but you can be sure that GNOME 3.2 and Fedora 16 will look consistently beautiful across all different types of devices. If you are feeling brave and want to try it out, try the “icc” branch of cups, the “colord” branch of gnome-color-manager, and the recently released colord 0.1.3.
Imitation is the sincerest form of flattery: YUM is getting a DBus API.
Dear rpmfusion. Please build codec packages for Red Hat Enterprise Linux 6. My wife is stuck in bed and wants to watch a movie.
Thanks, The Hughes Family.
In GNOME 3.0, we’re defaulting to suspending the computer when the user shuts the lid, and not providing any preferences combobox to change this. This is what the UI designers for GNOME 3.0 want, and is probably a step in the right direction. We really can’t keep working around bugs in the kernel with extra UI controls.
This will upset people who are docked or using a laptop for a presentation with a projector. Worry not! If you have more than one active screen connected to the machine, then we’re going to just disable the internal screen and not suspend until the second screen is removed.
This will upset some macbook owners if they connect a projector and then shut the lid. Some macbook laptops overheat when the lid is closed and not suspended, leaving the owner with a hot white glooopy mess when they finish their presentation. This is something we can do something about, but I need the help of the community to work out what makes and models need to be blacklisted.
If you own a laptop that gets very hot and starts to smell like hot plastic if you shut the lid without suspending, please send me the output of dmidecode and I’ll add the entry into upower. Thanks.
EDIT: Comments are now closed. Please see this entry from Allan Day.
For three days last week I attended a conference on application installing in Germany, hosted by Vincent Untz and the other guys from Novell. There were experts sent from Fedora, Ubuntu, Debian, Suse, and Mageia. From Fedora both I and Florian Festi attended.
The idea of the conference was to talk about defining some APIs we can share, to discuss interchange formats, and talking to the UI designers to make installing and removing software on Linux suck less.
We’ve put a few detailed documents with architecture plan on the wiki and Vincent has also uploaded all the notes from the meeting to the same location.
For more information still, there was a presentation we gave at the end of the conference. It’s nearly an hour and gets pretty technical, so get coffee before if you click the video.
Thanks again to Red Hat for sponsoring my travel and hotel expenses.
In the last couple of months, I’ve been talking quite a bit with Tim Waugh about color management of printers, and how to achieve working CM with CUPS. At the moment, gnome-color-manager locates CUPS devices and allows the user to calibrate them and assign profiles, but CUPS doesn’t actually use the assigned profiles for printing. Oops.
Needless to say, the combination of CUPS, ghostscript and other complicated little-known parts of the printing stack make this look almost impossible. OSX uses CUPS and CM works really well on printers using Apple products — and so it must be possible. We need to make it work on Linux too before Linux can become a serious option for artists and media professionals.
OSX uses a system-wide framework called ColorSync that does all the device<->profile mapping, and allows the user to change the ICC color profile for each device, and also allows the user to choose internal profiles listed in the printer definition file. ColorSync works really well, and is an integral piece of the OSX operating system.
GCM is a session process that provides session programs access to the per-user color management settings. Because GCM is running in the session it can integrate deeply into the GNOME desktop environment and is not particularly security sensitive. But, because the framework is per-session, system frameworks like CUPS cannot access the data, and we also have to rely on cludges like naming the display ICC file to be the same as the device ID and putting it in a well know location to be able to have a color corrected GDM screen. Urgh.
So, we need a trivial device<->profile daemon that works like a subset of ColorSync that the session GCM instances can use for defaults and also set profiles system wide for projects like CUPS. Over the Christmas holidays I wrote a small dameon called colord that provides a way for applications (or other daemons) to create, destroy and assign devices and profiles.
colord doesn’t do any file parsing or anything terribly unsafe, it’s just a simple system activated system DBus PolicyKit enabled daemon that has a simple database of devices that can reference specific profiles. Profiles are optionally assigned ICC profiles, and also have qualifiers that can be used to match them. For instance, a qualifier could be Epson.RGB.300dpi, which would match from the qualifier search of “Epson*”.
One thing to note: colord isn’t anything related to systemd. The name was chosen because colordaemon was too long to type and ColorManager and ColorKit names were already taken. It’s also intentionally techy, as users are not going to have to interact with colord whatsoever.
At the moment there is a test GTK application for developers and color geeks shipped in the colord package, but long term GCM is just going to use colord and all the configuration and settings will be done in the session by GCM itself.
Tim is working on the CUPS parts as I speak, and hopefully we can have something working in a few days. Exciting times.
This week, I’ve spent a bit of time working on a network panel for the new control center. The old network settings configuration dialog allowed you to do everything to anything, and most users (myself included) only touched a fraction of one percent of the functionality, and the complexity of other other controls made the UI very difficult and unintuative to use.
In the design research we’ve looked at what other OS’s do, such as Meego, OSX, etc and have started working on some design mockups. The network control panel will probably change quite a lot in GNOME 3 from what I’m showing here, based on user feedback and designers doing proper mockups. So, onto the interesting bit:
It’s all work in progress, and comments welcome. It’s using NetworkManager as a backend. Woot.
Last week I sat down and implemented some of the gnome-control-center mockups for GNOME 3.
This is the screen mockup, which as the name suggests, is all the settings related to the screen.
We’ve also made the power panel much, much easier to use. All the power-user settings are still available in GSettings, if you’re the geeky sort who likes to tweak. The conclusion we’ve come to, is that we should fix drivers, rather than provide workarounds for hardware bugs in the UI.
This is all available right now if you compile using jhbuild, and will be available in Fedora rawhide soon.
Yesterday I merged a patch to PackageKit which added the UpgradeSystem() method to the transaction interface. This is the natural compliment of the GetDistropUgrades() method which was added last year. This allows a session user to upgrade the OS using the same familiar PackageKit tools, and without doing dumb things like asking for the admin pasword and running GTK and python graphically as the root user.
In Fedora, we use a package called preupgrade. This was created by Will Woods and Seth Vidal in 2008, and I was asked to maintain it last year. I’ve been helped by James Laska, which has been very much appreciated. Preupgrade has been fixed up a few times, but the majority of the code is the same as when I inherited it. Preupgrade was a nearly-good-enough monolithic lump of code that kinda worked.
In my humble opinion, Fedora (and all other distros) are too small to maintain such mission critical stuff such as distribution upgraders. The PackageKit project has shown people that by distributions combining forces, they can share frontends and write different small backends and free up developers for other things. As a team, we have a better quality product than the results of one developer on one distribution.
So I figured preupgrade should have the same love. 99% of the preupgrade code is GUI interface code and this was easily converted to C, and to use PackageKit. The result of this is in gnome-packagekit git master, with a new tool gpk-distro-upgrade.
Don’t go and try this code just yet. None of the preupgrade backend code has been moved to the yum backend, although I don’t assume I’ll have many problems, and plan to do this later in the week. If you want to test this use the “dummy” backend, although this won’t actually perform any changes of course.
Hopefully some of the other distros can play with gpk-distro-upgrade and improve it. Hopefully the translators will file bugs about the bad English, and translate it to 50 languages. Hopefully another distro will port their os updater to use this new functionality and find bugs or speed up the common code a little.
All I know is preupgrade will live on as part of PackageKit, and now it’s targeted at a bigger audience than just the few million of Fedora users.