Archive for the 'Debian' Category

Grand Central Dispatch available in Debian

Published on July 17, 2010 in Debian and Hacks. Closed

Thanks to the work of Mark Heily, both upstream and in Debian, this week saw the arrival of libdispatch in Debian.

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!

rEFIt on x64: finally fixed

Published on April 21, 2010 in Debian. Closed

When I got my Mac Mini, one of the very first things I did was to test the Debian build of rEFIt on the machine, given the EFI firmware is x64 on the newer machines whereas it’s ia32 on my MacBookPro; it was the very first time I could test the x64 build.

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.

Transitioning to a new RSA key

Published on March 5, 2010 in Debian. Closed

After weeks of trying to get around to doing that, I am finally starting the process of replacing my 10-year old 1024 bits DSA key with a shiny new 4096 bits RSA key.

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!

Ten years

Published on February 5, 2010 in Debian. Closed

Ten years ago, pretty much to the day, I was installing my first Debian system, a frozen Potato, using a release-candidate version of the boot-floppies. A few days later, I was reading the Policy, New Maintainer’s Guide and Developer’s Reference while building my first package.

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

VMware Workstation 7.0.0 packaging

Published on December 31, 2009 in Debian and Hacks. Closed

I’ve spent the last week packaging VMware Workstation 7.0.0 at work. Looking around on the net, I’ve been unable to find anything helpful about packaging this new version, so it seems nobody’s got around to packaging it yet.

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 :-)

Why oh why…

Published on September 10, 2009 in Debian and Rants. Closed

… did FAI switch to that stinking pile of shit known as live-initramfs?

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.

How to not use lintian overrides

Published on July 9, 2009 in Debian. Closed

Look what just got added to all the packages maintained by the Debian Forensics team:

--- 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.

Digi AccelePort drivers updated to 1.3-15; now for Lenny

Published on June 30, 2009 in Debian. Closed

This is yet another “beta” release from Digi from a few months ago.

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.

No patch is better than useless patch

Published on April 12, 2009 in Debian. Closed

Joerg,

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.

HAL-haters heads up: #515214

Published on April 10, 2009 in Debian. Closed

Don’t like HAL? X.org now forces it upon you via xserver-xorg.

#515214, currently wishlist/wontfix.