Doug Goldstein

There’s a few reasons for this. Mainly because I’m disenfranchised by the development process. Also, many Gentoo users and developers dislike HAL and are against it so I’m constantly fighting an uphill battle. But mainly it’s the development process.

For a long time I’ve felt that the development has been very one sided, by one individual. No design review, no peer review just simple code dumps every few weeks or months. Feedback is always encouraged but never read and acted upon. Bug reports go ignored.

I brought this up in the past in on the HAL ML, here. Issues with another mandatory component of HAL having code stagnating and then big code drops were brought up by a Debian developer, countered by a Fedora developer, SuSE disproves the counter as do I and another Fedora developer disagree with the counter, all in all a fun thread. Then we have David making a big code drop to which, a Debian developer and I expressed similar concerns with on the thread. And on the #hal IRC channel,  another SuSE developer and Mandriva developer expressed similar concerns.

This was followed up by an IRC conversation with Rob Taylor which I have included here, the conversation takes place after receiving my reply to the last thread I’ve linked.

My biggest issue is that HAL and friends are suppose to be a FreeDesktop.org project that provides a simple and universal API to all DEs and really anything that needs hardware information and it’s designed behind closed doors and a lot of code is written behind closed doors. It’s depended on and used in projects when it’s not mature enough, for example GNOME using the 0.4 version of HAL. If David’s latest rewrite takes place that will be 3 full rewrites before it’s even hit 1.0.

Now if app was written in an open source manner, a lot of issues and problems could be addressed with the design from the get go and the code could be properly peer reviewed and we could move forward from there. Instead we have distros commonly shipping HAL with over a dozen some odd patches, not to mention the patches necessary to it’s associated utilities. I bring this point up for a very good reason, the front of FreeDesktop.org’s website states, “freedesktop.org is open source / open discussion software projects working on interoperability and shared technology for X Window System desktops.” Yet HAL developers will clearly admit that this project does not follow this principles and even argue that it should not follow those principles.

Because of these issues, I have given up on HAL and will no longer maintain it. In fact, I’m no longer interested in having it installed on my system. It’s time to choose another DE to use instead of GNOME.

Filed under: Gentopia, HAL, Linux
4 Comments

So this week’s GWN was published with info about D-Bus, however no one ever mentioned anything to me about it. The first and only notice of it I received in e-mail was on 12/12 but this is from 12/11. For those that say it was published 12/13, Ok fine. But I was already off the computer by the 12/12 notice and didn’t receive it until 12/13 and I did reply back with some fixes which did not make it to print. I can’t speak for when steev saw the GWN, but as far as I’m concerned neither of us knew in time to catch this.
So here we go with the list:

1. sys-apps/dbus-1.0.1-r2 was released with more then just ~amd64. It was released as ~arch to all arches that had were on sys-apps/dbus-0.62-r1. Which was every arch except m68k, mips, ppc-macos, sparc-fbsd, and x86-fbsd. However x86-fbsd was added since D-Bus now supports FreeBSD properly in the 1.0.x series. mips has since been added as well.
2. A security issue was published on 12/12 about D-Bus and consequently 1.0.2 was released. The 1.0.1 ebuilds were removed and only 1.0.2 is available so the article was already out of date before it’s official publishing. The security fix has also been backported to sys-apps/dbus-0.62-r2, which most arches have marked stable.
3. Do not emerge all the binding packages, every package out there is suppose to depend on the specific binding package that you need. If it does not, there was a bug created for this, bug #154521.
4. There was no “radical” shift in the API. APIs that have been marked deprecated since 0.30 were finally removed for the release. Applications that were 100% API proper with 0.62 will work 100%. Only problem comes with applications that were not coded properly, yes HAL is one of those apps. The exception being Mono based apps where the bindings are different, however most packages that are being maintained upstream have been updated to use the new bindings. Bugs have been created in Bugzilla in all these instances, however most Gentoo maintainers have not corrected the issue.
5. Learn to run revdep-rebuild when the einfo/elog/ewarn tells you to run it. Also, read the possible parameters you can pass to revdep-rebuild. -x allows for new versions of pre-existing packages. Some packages might have rev-bumps for the new D-Bus and you’ll need to pull those new versions down. Also, some USE flags might have changed. Use the -v option. And lastly, toss a -a on there so you can review what it’s about to do. All in all, revdep-rebuild -avx is probably what you’re looking for.
6. Yes, for GNOME users there are a lot of packages to recompile. This is because gnome-vfs depends on D-Bus and most GNOME applications link in gnome-vfs. This is what makes –as-needed so attractive. That and getting GNOME to stop linking in D-Bus when the application that’s linking it in doesn’t even use D-Bus, it uses gnome-vfs.

And lastly as a final wrap up, D-Bus 1.0.x will be the new and only supported version shortly after the New Year, once the 1.0.x has been cooking in the Portage tree for 30 days.

Filed under: General, Gentopia, Linux
No Comments

While the D-Bus big whig developers Havoc Pennington and John (J5) Palmieri have been working hard at bringing us a 1.0 release, steev and the rest of the Gentopia gang have been working hard at bringing you some of the pre-1.0 releases to the Portage tree. There are some snags and roadblocks along the way.

• With D-Bus-0.90 (pre-1.0 beta1) and higher the D-Bus bindings are broken out from the main package. This means that packages will now have to depend on their specific bindings rather then D-Bus itself, so all the depends in the Portage tree need to be updated. The following depend is correct: || ( >=category/binding-0.71 ( =sys-apps/dbus-0.60 or 0.33 ) )
• As a warning note, dbus-core is now called “dbus” yet again as of version 0.94. A move entry has been put into the tree to help people migrate but once again, the package is masked. I really don’t want to hear it if it breaks your system or rapes your cat. It’s a masked package, if you can’t deal with the breakage and fix the two pieces, you shouldn’t use it anyway.
• Since the bindings are broken out of the main package, upstream has chosen to maintain only the specific ones they use. Since John and Havoc are Gnome guys the glib bindings received official love and since Gnome people love Python, the Python bindings have received love as well. The rest of the bindings have been cast off like redheaded step children, especially the Mono bindings which are making a come back as dbus-sharp. Trolltech has taken up the QT4 bindings, which have some issues but since my job at work involves commercial Trolltech licenses I was able to kick some dbus issues right to the guys where it needed to go. The last set of bindings are the qt3 bindings, which we’re just using a copy of the old qt3 bindings for now.
• D-Bus upstream has currently 7, possibly 8 items on their list prior to their release. They’re saying none of these will involve functionality/compatibility breaks but it sure sounds like it. It’s really starting to feel like it was suddenly decided that dbus needs to move to 1.0 and it needs to be there NOW but without any planning going into what it’s actually going to take or the time frame or the testing required. (see HAL issues towards the bottom)
• D-Bus will require a rebuild of anything linking to it since the libtool so version # has changed.
• Applications need to get ported to the new bindings since now people have either re-written or re-factored bindings which now makes some work and some break.
• API deprecation. The stuff deprecated from ages ago in D-Bus has finally been dropped. A LOT of packages are going to be caught off guard by this one, even HAL was caught off guard and the same maintainers that maintain D-Bus are part of the HAL project.
• David Zeuthen and his ever changing HAL depends and goals and targets which fails to get documented properly anywhere… “We need pam_console this week? PolicyKit next? hal-info the week after that? Wait.. that data won’t be in HAL… oh wait… now it is… but wait.. let’s move it’s location. Oh well Redhat doesn’t feel like HAL should provide that any more so you will have to have an external app provide that data… sure we know that lots of HAL consuming apps require that data and will now break but we’re going to ship this release without it. We’ll provide an external application, only in CVS because it’s no where near stable that will provide HAL with this data…” This has lead to at least one issue between me and Aaron Bockover, author of the popular Banshee, which I use personally, where each of us insisted we were doing it right be referring to different parts of the HAL docs

Filed under: General, Gentopia, Linux
No Comments

So I’m getting really annoyed with Gentoo Experimental. The Gentopia overlay has been up and down so often, the connection hasn’t been reliable at all. Now finally it’s suppose to be steady like a rock but many people can’t access it even though I can. So basically this is a plea for help.

Can anyone provide us some reliable hosting?

Filed under: General, Gentopia, Linux
4 Comments

So after hearing weekly calls from the Gnome Herd to disband Project Gentopia, I just read a blog post from a Debian developer and was shocked to read that they have a Project Utopia, which is what Gentopia is named after. And their Gnome team (aka herd) and KDE team are working with their Utopia team on coordination and actually allowing the Utopia team to help them and working on making transitions happen properly. Unlike Gentoo where we’re constantly fought and dragged through the mud. Downright shocking… rather then fighting help and working as a well oiled and coordinated machine they’re working together. I guess this is why Debian is always rock solid and Gentoo always has that hackish feel.

http://oskuro.net/blog/freesoftware/gnome-2.12-unstable-2005-12-15-14-19

Oh and for those who are curious, I consider “Debian unstable” similar to our ~ARCH tagging. Debian unstable will actually have newer versions of some packages then our ~ARCH teams currently have. AND AND AND!!!! Here’s the shocker… Debian stable actually works! Unlike Gentoo “stable”, which doesn’t compile or work and users constantly e-mail me complaining but I’m forced to reply “Sorry, the currently marked stable version is horribly broken… I have made requests to up the stable marked version to something that will compile but the ARCH teams aren’t marking anything. And upstream laughs at any issues with the currently marked stable because there were known problems with it, hence why newer versions are released.” (this is dbus 0.23 -> 0.23.4)

Anyway, it’s random rant/complaint from me. I do however need to blog some more about relevant stuff.

Filed under: General, Gentopia, Linux
6 Comments

dbus & hal aficionados will be happy, I’ve unmasked dbus-0.3x and hal-0.5.x on Gentoo. So they should be hitting a ~arch near you. Please update and test your software. Please test USB plugging functionality. These new releases will be required for the new Gnome release.

Filed under: General, Gentopia, Linux
2 Comments

So I probably should post this since the re-direct link is broken right now. Gentopia has moved to it’s new home. The hosting should be much faster, especially for our European friends. Gentopia is now hosted by Gentoo Experimental.

You can find Gentopia at http://gentopia.gentooexperimental.org.

To update your SVN overlay to the new Gentopia run the following command:

cd /usr/local/gentopia && svn sw --relocate https://dev.cardoe.com/gentopia/svn/overlay https://gentopia.gentooexperimental.org/svn/overlay

If you’re a new comer to Gentopia, just run the following command.

cd /usr/local && svn co https://gentopia.gentooexperimental.org/svn/overlay gentopia

Sorry about the unannounced change.

Filed under: General, Gentopia
4 Comments

So yesterday I posted about how I felt about the GTK+ USE flag situation. Today I’m going to revisit the issue a little bit. Here’s a link if you didn’t read the previous rant, GTK+ USE flag hell part 1.

Basically, Gentopia is going to take care of the USE flag changes. We’ll host all the ebuilds with the changed USE flags and then we’ll work on bringing the change to Portage. It makes sense because it allows us to develop outside of the Portage tree and to test software to make sure it’s solid. (You know… that whole Gentopia ideal.)

Just as a note for the KDE & QT people. Hopefully you’ll take note of this GTK+ USE flag situation because I think it’ll affect you guys as well when QT4 hits the streets and some packages upgrade and some don’t.

Filed under: General, Gentopia, Linux, Modular X
1 Comment

Here’s the solution to the GTK+ USE flag issue. The final solution because I’m tired of all the debate and in-action on the mailing lists I am posting this here. I hope we can quickly discuss it and dismiss all issues with it and I can implement it this weekend while I am being mauled by the hurricane.

Remove entirely the “gtk” USE flag. It’s ambiguous and pointless. The proper USE flags should be gtk1 and gtk2. Turn off gtk1 for the desktop profile and leave gtk2 on in the desktop profile by default. As far as I’m concerned, GTK+ 1.x is depreciated and does not need to be pulled in needlessly.

What’s that mean? If you want any GTK+ support, you turn on gtk1 and gtk2 in your USE flags. If you only want GTK+ 2.x support, you turn on gtk2 in your USE flags and leave off gtk1. If you want only GTK+ 1.x support, you turn on the gtk1 and leave off gtk2. If you don’t want GTK+ on your system you leave both USE flags off. Simple. Easy to understand. No ambiguity.

Oh no what about GTK+ 3.x people say. Well first off, that’s a long way off. Do they even have a roadmap that shows breaking ABI & API compatibility? Not as far as I know. But plain and simple, you add a gtk3 USE flag and it’s pretty obvious.

What about when a package supports both? Well the USE flags sort it out pretty easy.

What about when a package supports both and both are turned on? Let’s take easytag for an example. Well guess what, the maintainer knows the package well. So he/she makes an educated judgment. For example, when easytag GTK+ 2.x support first hit the streets, it was pretty experimental so it would have been wise that the ebuild maintainer make GTK+ 1.x the default if both USE flags were on. However now that the GTK+ 2.x support is pretty solid, it would be wise for the maintainer to switch to GTK+ 2.x to be the default? Why because it looks better and presents Gentoo as a desktop and a functional userbase better. Because most users are going to have a GTK+ 2.x based desktop (i.e. Gnome 2.x) if they use GTK+ and as such will have configured it to their liking and suddenly easytag will conform to their visual layout that they are comfortable with. It won’t stick out like a sore thumb like GTK+ 1.x does.

I hope this covers all scenarios and we can start making this change ASAP because it needs to happen 2 years ago.

Any questions? Feel free to post a comment here and I’ll answer it.

Filed under: General, Gentopia, Linux, Modular X
13 Comments

Perfect example of what the Project Gentopia team is talking about just happened early today. As I’ve said many times, our goal is to provide a test bed and development ground for the groundbreaking features coming to the users desktops. This is not an effort to step on devs toes, it’s an effort to improve Gentoo and software as a whole. Gentopia has provided numerous patches upstream to Gnome CVS and Freedesktop.org CVS in advance of up coming versions.

What did we do that I’m blogging about? We finally got HAL and DBUS into the Portage tree. While these new version are p.mask’d they are still going to form and important basis for the features you and I want to see on your KDE and/or Gnome desktop.

In addition to the HAL & DBUS updates today, we’ve provided the following today. We have provided a sprinkling of modular X dependencies to the Portage tree. Updates to Cairo & Glitz so now the latest Cairo supports Glitz. Some fix ups for Firefox/Mozilla/Thunderbird users using GTK+ 2.8.

This is not a post crying for credit. I couldn’t careless. It’s a post for those that say “What do you want to do with Gentopia?” This, develop the next generation/versions desktop applications for use on Gentoo. As we get more developers actually write more of this software ourselves. In fact, a couple Gnome (non-Gentoo developers) have gained interest in Gentoo as a result of our project and are interested in joining up. This can only mean more quality software on Gentoo boxes.

Filed under: General, Gentopia, Linux
No Comments