KDE4 Won't Start
Could not connect to D-Bus server: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute dbus-launch to autolaunch D-Bus session
But when I run dbus-launch it works fine. I'm sure it's probably something simple, but I'm about ready to give up.
ginger ale
It finished brewing this morning (by our estimation). We let it refrigerate during the day, and just now opened and tried it. It was pretty good.
Next time, we'll probably use fewer limes, so it's less citrusy; more ginger; and more yeast, so it comes out fizzier.
Not bad at all for a first try!
Exchange Connector & Evolution 2.12
This release is special, personally, as:
This is the best release made after the initial 1.x days of Ximian Connector. It all started from the days of SLED Betas - getting Beta customers to test and report issues, fix and provide packages to reverify. Exchange connector has become quite stable and just like other softwares, with some bugs. Connector has a better summary support, optimized n/w bandwidth usage, majorly rewritten folder loading/refreshing techniques, on-demand-public folder loading and newly implemented mail/calendar delegation feature that enables your colleague to handle your mail/appointments when you are away from office .
Thanks to all the customers/community users who provided test accounts to debug complex issues that are otherwise not possible to debug and fix. Remarkable improvement has gone into Connector in this release, especially in a state where people started recommending to use IMAP to access their Exchange mails instead of Connector.
Special thanks to Dan Winship for his time and help in answering my libsoup and connector related questions.
Okay. I haven't yet mentioned why this is a special release to me. ;-) This is my maiden release as Exchange Connector Maintainer. I took up the task with solving performance and stability issues as number-one-priorty than adding features and with much pride I declare this to be one of the best releases of Exchange Connector.
Some of the performance work that has gone into this release, for your joy.
[1] - Folder loading optimization
[2] - On demand loading of folders (esp. public folders)
Watch out for more optimization work to be done in Exchange connector module.
Onething, I tried hard to accomplish is the Exchange 2007 support - which will be a part of 2.14 release of Evolution.
Back from the OpenOffice.
Good to meet people in person.
Talked at lot about
- Harmonization between ODF and OOXML,
- Trade-off between Standardization and Innovation and
- Interoperability wrt. ODF<->ODF and ODT<->.DOC
Some pics from the conference:
(Thanks Peter for great evening.)
(Thanks to the people at the ODF Camp)
(Thanks to Kohei, Hubert and Noel for the great time at the XXVII MOSTRADA DE VINS I CAVES DE CATALUNYA)
I hope I can find some time to go into more details.
a humble suggestion
Seriously. Talk Like A Pirate Hour: it's the new hotness.
Free Software driver for AMD (ATI) RadeonHD released
Last night we have pushed out the initial developers release of the RadeonHD driver for ATI's RADEON R5xx and R6xx chipsets. After a long dark period of no specifications AMD has decided to not only make code but also specifications available to the free software community.
So far we have seen specifications to do mode setting and possibly a little bit of video overlay. The specs cover most of what is needed to enable different outputs (VGA DAC, TMDA for DVI and LVDS for panels) TV out is not yet on the plate.
Also they allow to implement video overlays (classical color key overlays).
People are wondering if AMD's move was a one time PR blitz to muffle their biggest critics in the free software community.
My personal take on this is: I don't think so.
AMD has a long history of successful cooperation with the free software community. This cooperation was crucial for the success of their x86-64 project (we are only beginning to see versions of MS Windows appear which are 64bit capable).
In the past 4 month our X Developer Team at SUSE has worked extensively with AMD to make these things happen. We have only been dealing with people form AMD with technical background - no marketing people were involved.
Everyone involved has shown a great willingness and worked hard during long hours to do whatever it takes to open up the
specs and provide whatever it takes to get a free driver going.
Yes, we did encounter delays. Most of them were due to fact that what has happened here is a novelty in the graphics chipset
industry. Tools had to be implemented, processes had to be created, legal issues had to be resolved.
How did it all start?
Around mid of April (4 1/2 month ago) I have been contacted by AMD and asked to put together a proposal how an open source driver for the latest generation of ATI hardware could become reality. Our team wrote a proposal which included as two major goals:
- involving the free software community in the development process early on
- make chipset documentation available to the community with no strings (read NDA) attached.
Linux Vendors
To most Linux OS vendors like us at SUSE the unavailability of a free driver has created a huge burden. At SUSE we have made the conscious decision to not ship any non free software with out base product (even without this policy in place the GPL violation issue in the kernel would have prevented us as an OS vendor to ship the proprietary driver with our base product).
This however meant we were not able to ship a proper driver for a widely used range of hardware with our product.
We at Novell as a company we worked extensively with ATI and later on with our partner AMD to explain the dilemma and find ways to change this situation. Most of these discussions have not taken place in the public eye. After all it be bad style if business partners gave each other advice in public on how to do business.
Why did it happen right now?
Changes in paradigms like what we have seen here don't happen over night. As for any commercial entity there needs to be some business justification as such steps require effort and thus cost money.
Business justifications evolve either when the business model of a company or the business environment changes.
Here both things have happened:
- ATI has been purchased by AMD. AMD had a different business model in the Linux and free software market than ATI had.
- The business environment has changed: the b2b market (and this has been the market where conclusive data existed in terms of how much it is paying the bills) requires a free driver more than before.
To me AMD's move looks like a great opportunity. For the first time in many years graphics chipset documentation is made available to a broad public without the requirement of any NDA.
In fact I have a hard time to remember when I was able to download graphics chipset specs from a manufacturers web site without having to go through a pile of paper work.
AMD puts itself somewhat ahead of other graphics chipset vendors: In contrast to other free drivers for which only code but no documentation exists this approach allows a broad development community to poke bits and registers in crazy new ways to try out crazy things things that are not on the plate of those who are paying for the driver development.
Even if we won't see all results from these hacks appear immediately in the next release of the driver I expect it to kick off a lot of new development.
For a long time our community was somewhat cut off from the the information what state-of-the-art hardware was capable of. New features were limited to what hardware manufacturers - even those who developed free software drivers - considered to be a must-have for their drivers. This all is going to change now.
frantically moving to gnome 2.20.0
So far, it's proving to be rather light work, and really not all that frantic, although we do intend to finish this update very soon. The mail Gary sent last week has the details.
The fine work done by the GNOME release team makes this relatively easy, so many thanks to them.
Office 2.
I'm just back from the Office 2.0 conference in San Francisco. I was participating in a panel discussion about Document Formats:
Very nice crowd the Office 2.0 guys. They really taught me to think more about collaboration.
Many thanks for the nice presentations. (And for the insight that most of you use OpenOffice.org to convert between HTML and the other file formats ;-))
Ahh -- and almost forget. I will look into OpenSAM. Promised. Sounds really like a good idea for OpenOffice.org supporting it.
Howto use Git and svn together
In these days I’ve heard lot of rumors around Git. After reading some manual/tutorial/guide I discovered that it can be really useful, especially if you spend lot of time coding off-line (that’s my situation).
This is a really small howto that describes how to work on a project versioned with svn (maybe taken from KDE repository ;) ) using git.
What’re the advantages?
Since Git is a distributed revision control system (while svn is a centralized one) you can perform commits, brances, merges,… on your local working dir without being connected to internet.
Next time you’ll be online, you will be able to “push” your changes back to the central svn server.
Steps to follow:
You’ve to:
- install git and git-svn
- create the working dir:
mkdir strigi - init your git working dir:
cd strigi && git-svn init https://svn.kde.org/home/kde/trunk/kdesupport/strigigit-svn init command is followed by the address of the svn repository (in this case we point to strigi’s repository) - Find a commit regarding the project (you can get it from cia version control). Warning: the command git-log will show project’s history starting from this revision.
- Perform the command
git-svn fetch -rREVISIONWhere REVISION is the number obtained before. - Update your working dir:
git-svn rebaseNow you’ll be able to work on your project using git as revision control system.
To keep update your working copy just perform:
git-svn rebase
You can **commit your changes ** to the svn server using the command:
git-svn dcommit
In this way each commit made with git will be “transformed” into a svn one.
Solve git-svn rebase problems
While adding new cool features to your program, you may experiment some
problem when synchronizing with the main development tree. In fact you have to
commit all local modifications (using the git-commit command) before
invoking git-svn rebase.
Sometimes it isn’t reasonable since your changes are not yet ready to be committed (you haven’t finished/tested/improved your work). But don’t worry, git has a native solution also for this problem, just follow these steps:
- put aside your changes using the command:
git-stash - update your working copy using:
git-svn rebaseas usual - take back your changes typing:
git-stash apply - clear “the stash” typing:
git-stash clearAfter the first step all your uncommitted changes will disappear from the working copy, so you’ll be able to perform the rebase command without problems.
For further informations read git-stash man page.
That’s all.
A special mention goes to Thiago Macieira for his help.