libdispatch is the userspace component of Apple’s Grand Central Dispatch technology, designed to help write applications that really take advantage of multicore processors without having to fiddle directly with threads and locking (and getting it terribly wrong).

To get that working on Linux, Mark wrote a userspace implementation of the pthread workqueues and a kqueue compatibility library (libkqueue). He also packaged the Blocks runtime (libblocksruntime) for Debian so as to build libdispatch with Blocks support. That means code using libdispatch must be built with CLang (or llvm-gcc-4.2) rather than gcc, as getting Blocks support in gcc in the near future looks highly improbable.

On Mac OS X and FreeBSD, a kernel-based implementation of the pthread workqueues is used; we don’t have that for Linux yet. The all-userspace implementation we have at the moment works really well; there are some caveats, though, but that’s no reason for not starting to play with libdispatch right now!

Try it out, it’s great. Thanks again, Mark!

And the results weren’t good: some images couldn’t be loaded, and it all seemed to be random.

Disabling optimization in both GNU EFI and rEFIt for the x64 builds helped somewhat, at least it made rEFIt reliable enough to be usable.

Now, with this new release, I started getting error messages, requiring a key press before the menu would be displayed. It’s annoying but it’s also very helpful as I now had an error message to work with, and even if the error message wasn’t reliable, it would still point me to some part of the code. The message was: Invalid argument.

On x64, the use of a call wrapper is mandatory because the EFI x64 calling convention doesn’t match the calling convention of the ELF executables we’re building and later disguising as EFI executables. The call wrapper has always been the prime suspect in this issue, it’d be an obvious candidate for anyone looking at this issue.

Today, digging into the issue with some new data, I realized what the problem was: when using the call wrapper, all arguments need to be of the UINT64 type. That’s the type the call wrapper uses when extracting the arguments from its va_list.

Introduce some more macros on top of the call wrapper, build, test: voila, it’s fixed! That was tricky one.

Let’s sum it up for the search engines: all the arguments to the EFI interface called through uefi_call_wrapper() in GNU EFI need to be cast to UINT64.

rEFIt 0.14-1, available in unstable in a couple hours.

Next, I’ll see if I can reenable optimization in both GNU EFI and rEFIt.

The old key ID is F5D65169, the new key ID is FA1E5292; it’s available from the keyservers or my website.

I have put up a transition document, signed with both keys; if you’ve signed my old key, grab it, verify it and if all is OK on your end, please sign the new key.

You’ll notice that one of the old UIDs did not make it to the new key; that’s because I’m not using that email address and don’t actually intend to use it in the future.

Thanks!

It’s been a fun ten years, with ups and downs, and I’m looking forward to what’s coming next.

I’ve asked our customer for its approval for releasing our packaging scripts to the community and got it, so here are our packaging scripts for this version, courtesy of EDF. See the instructions in debian/README.source for what has to be done to turn it into a full source package.

The packaging is based on our previous 6.5.2 packaging, which was itself based (partially, at least) upon the Gento 6.5.2 ebuild. It uses a tweaked vmware-installer to install the products to debian/tmp, then makes use of the vmware-installer database to populate the packages.

I think this method should work with any VMware product using vmware-installer 1.1.

Packages have been built and tested on Etch and Lenny.

Hope it helps! Bugs, comments, questions to the email address listed as Maintainer in debian/control, please :-)

Things that were possible before aren’t possible anymore due to the extreme brokenness of live-initramfs. Nothing that can’t be fixed by some heavy-handed patching here and there, but what a waste of time.

Not happy. Hammer time.

--- md5deep-3.4.orig/debian/source.lintian-overrides
+++ md5deep-3.4/debian/source.lintian-overrides
@@ -0,0 +1,3 @@
+# Avoid warnings if non-uploaders to uploads.
+md5deep source: changelog-should-mention-nmu
+md5deep source: source-nmu-has-incorrect-version-number


You’re doing it wrong.

I had to patch the driver to build with a 2.6.26 kernel, as neither versions of the code would build against that version. Lenny ships with 2.6.26, so that would have meant no dgap drivers on Lenny. I’ve tested the patched driver and haven’t noticed anything obvious while doing so.

The drivers are now built for Lenny; if you need them on Etch, a simple rebuild from source will do. Previous versions are still available in the pool, under the old/ directory.

APT source line, now changed:

deb http://debian.technologeek.org/ lenny non-free

Feedback at the usual address.

The patch you submitted has 0 chance of getting applied, and you know it. It’s nothing more than a bad joke.

The best solution for this issue is most probably to provide a xserver-xorg-nohal package that is a duplicate of xserver-xorg minus the HAL dependency.

#515214, currently wishlist/wontfix.