Duncan Mac-Vicar P.

This week arstechnica has a really nice selection of articles:

• Komodo Edit 4.3 was released, which is the first version of this scripting editor released as opensource. The editor is based on Mozilla XUL technology, which talks very good about its extensibility. I could not find a tarball with the source, only svn repository and binary tarballs.

• Nice article about filesystems.

• Article about Firefox 3 memory consumption .

Keeping a permanent build of svn on the build service motivated me to try to build it on other non-SUSE based distros. On the way I discovered not only simple things as different package names, but linking problems, compile errors, etc.

In the past it did not make much sense to try libzypp outside of SUSE as we were trying to catchup with other tools speed. But now that libzypp speed outperforms any other tool in speed, while keeping it complete set of features, we may start thinking about taking over the world. May be other distros want to use libzypp, or why not, the small and powerful sat-solver library alone.

So, since today I got the first successful build of sat-solver/libzypp/zypper on Fedora 8. Mandriva is also close, but I still get a compiler error I should not get when compiling the rpm backend.

At the beginning, it may be a consuming effort, but once it is a continuous process, our software should adopt a more agnostic view of the world and just compile there out of the box. If anyone has the time to test it, I would be interested in the results

By the way, our colleagues at internal tools finished processing the FOSDEM talk’s videos we had in the openSUSE Developer’s room. You can find the ogg video files here. Also you can watch on google video here.

I am not good at keyboard shortcuts. I started using mice very early. Therefore anytime I post a video recording my screen, I get more comments about my stupid ways to clear the screen or move the cursor, than about the content itself.

However, I like to change my habits to be more efficient and I keep trying new stuff, and old stuff too.

I tried learning vim, and I was successful in using it during the last years for console usage and basic file editing. However, I was never able to remember more than opening/saving files and deleting lines. I was using Kate for most of my coding needs. I tried switching from Kate to vim for coding like three or four times without any success.

During this trip, and brought some emacs tutorials with me, in order to give it a try. I was expecting something horrible, but surprise, after a few hours, I could do much more than I was able to do with vim, and I had no big problems with the ctrl-something key shortcuts (I have yet to try on my Microsoft Natural keyboard though).

I am now in the process of setting up some packages I need (code browsing and completion) and till now I am very happy. There are a couple of things that really suck:

• Setting up the environment sucks because you have to do it from scratch. There are no sane defaults for anything. No thing that ask you what do you do, and setup something that makes sense to start with.

• XEmacs and Emacs features.They forked one from the other and at some point XEmacs had more features, but now both have things the other hasn’t and you can’t tell exactly what it is.

• XEmacs and Emacs user interface. I discarded XEmacs because it has this horrible tcl/tk look and feel, like using its own widgets over xlib. It had a experimental gtk user interface based on 1.x, but its status is not really clear. At least our package does not enable it. There are screenshots of Emacs running on OS X that look very sweet. Sad that all efforts of bringing Qt to emacs are more or less dead.

For now, I choose GNU Emacs, just because I have some sense of aesthetics and usability. XEmacs is and look like 1970. With GNU Emacs I only have to suffer of the gtk “original” file dialog but I suffer from it in lot of gtk-infected programs (starting with Firefox) so it is not very serious. I can live with it, and I am sure I can use KDE file dialog by using some lisp magic and the kdialog command.

Other pending issues:

• setting up cedet/ecb to get auto completion and code browsing.

• setting up git mode and learn how to use it

• integrate cmake mode and a sane way to use the compile commands out of the source tree

May be next time I record a video, you will see me using ctrl-L instead of typing “clear”

One of the steps to build more community around YaST is to allow people to try it. Not every user uses factory but lot of people want to try one or more punctual recent features. This is not easy, because developers can’t invest much time making sure the latest developments can work seamlessly outside factory. But we can do more. If it compiles and (available) tests run, then we are more or less sure it should run.

In the last week we have been playing with the YaST and build systems in order to organize some YaST and zypp repositories abandoned in the openSUSE build service.

I introduce to you the new layout:

YaST:SVN are YaST packages submited from our code repository sources on a frequent basis. I am trying to make this as automated as possible, so I have internal scripts that submit packages when the repository compiles. Right now, I use this repo to test code that hasn’t been committed to svn yet, like build fixes on other distributions. YaST:SVN builds on top on another repository, called zypp:svn, which is the zypp stack from svn. The svn series is build for Factory, released versions and also I added Fedora and Mandriva, even if it does not build right now. I think making the stack to work in other distributions is a place where the community can make a big contribution. I made satsolver library to build on Mandriva with about one hour of trial-error work. The value is that all spec file modifications are now in the svn repository and not as patches floating around there.

On the other hand, we have the Backport series. YaST:Backport and zypp:Backport (the first builds on top of the second). These repositories are just package linked to the Factory ones, but the repository builds for 10.3, and I am trying to make it build in other Novell editions (SLE, 10.2, etc) and Mandriva/Fedora as well. We don’t need to update this repository, as it rebuilds when Factory versions are submited, which makes it more stable than the svn series of the repositories.

In the future, If we get enough help from the community to build all packages on something different than factory, I would like to create a Experimental series, which are packages linked to the svn series, plus patches from the community that are made upstream after testing them. That way the svn series of the repositories could turn themselves in being pure svn code, and submitted in a automatic way.

YaST is yours, so your feedback and help is welcome. Right now you can find there a zypp and YaST stack from svn and Factory, built for 10.3. YaST modules are missing yet. If you want to help and have submit access to this repositories, we would gladly do it, just ask for it in our yast-devel or zypp-devel mailing lists.