pvaneynd

Fosdem 2012

2012-01-17T06:19:36Z

For some reason my involvement with Fosdem is going up, not down.

So I will certainly be there, find me hacking the network again. Learning QoS in a trial by fire :).

comments

Debian on kfreebsd weirdness

2011-05-11T03:38:53Z

I've installed Debian sid in a FreeBSD 8.2 jail and I'm seeing this weird effect:

root@debian:~# aptitude upgrade
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
                                         
User defined signal 1
root@debian:~#

This will randomly kill the normal aptitude gui, while other things like vim or dpkg-reconfigure using the 'dialog' gui will work normally.

Google is useless. strace doesn't work. ktrace gives
21131 100410 aptitude-curses CALL stat(0x9ef968,0x7fffffffe810) 21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0" 21131 100410 aptitude-curses STRU invalid record 21131 100410 aptitude-curses RET stat 0 21131 100410 aptitude-curses CALL open(0x9ef968,O_NONBLOCK,0) 21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0" 21131 100410 aptitude-curses RET open 3 21131 100410 aptitude-curses CALL fstat(0x3,0x7fffffffe810) 21131 100410 aptitude-curses STRU invalid record 21131 100410 aptitude-curses RET fstat 0 21131 100410 aptitude-curses CALL fcntl(0x3,<invalid=2>,FD_CLOEXEC) 21131 100410 aptitude-curses RET fcntl 0 21131 100410 aptitude-curses CALL getdents(0x3,0x1b9e630,0x20000) 21131 100410 aptitude-curses RET getdents 24/0x18 21131 100410 aptitude-curses CALL getdents(0x3,0x1b9e630,0x20000) 21131 100410 aptitude-curses RET getdents 0 21131 100410 aptitude-curses CALL close(0x3) 21131 100410 aptitude-curses RET close 0 21131 100410 aptitude-curses CALL rmdir(0x9ef968) 21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0" 21131 100410 aptitude-curses RET rmdir 0 21131 100410 aptitude-curses CALL write(0x28,0x7fffffffeb20,0x38) 21131 100410 aptitude-curses GIO fd 40 wrote 56 bytes 0x0000 4026 a000 0800 0000 0200 0000 0800 0000 0000 0000 0800 0000 0000 0000 0000 0000 2818 0803 0800 0000 a0f9 9d00 0000 0000 0100 0000 |@&..............................(...................| 0x0034 0000 0000 |....| 21131 100410 aptitude-curses RET write 56/0x38 21131 100410 aptitude-curses CALL sigprocmask(SIG_SETMASK,0,0x7fffffffeaf0) 21131 100410 aptitude-curses RET sigprocmask 0 21131 100410 aptitude-curses PSIG SIGUSR1 SIG_DFL

Anybody has an idea?

root@debian:~# uname -a GNU/kFreeBSD debian.home 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Wed Apr 6 09:52:09 CEST 2011 root@frost.local:/usr/obj/usr/src/sys/PEVANEYN x86_64 amd64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GNU/kFreeBSD

comments

how to grow a zfs file system

2011-03-28T07:53:57Z

I'm experimenting with zfs at home, for the moment on top of my md/lvm setup, and I ran out of disk space. Growing the lv is pretty easy:

frost:~# lvextend --size +110G /dev/new-vg/zfs-test Extending logical volume zfs-test to 120.00 GiB Logical volume zfs-test successfully resized frost:~# zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zfs-pool 9.94G 9.78G 161M 98% 1.00x ONLINE -

Hmm it did not notice the 110GB extra, so I did:

frost:~# zpool export zfs-pool frost:~# zpool import zfs-pool frost:~# zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zfs-pool 120G 9.78G 110G 8% 1.00x ONLINE -

so simply doing an import/export is enough.

I'm looking at zfs to have a better idea of what btrfs will mean in the future for us.

comments

google me: changing the branch in a bare git repository

2011-02-26T09:34:27Z

If you are using something like git.debian.org to share repositories and you have done major surgery that makes that 'master' became invalid this is easy to fix in your local repository:

git checkout new-master
git branch -D master
git branch -m new-master master

but what do you do with the bare repository on git.debian.org? Well you can do:

git branch -m master old-master
git branch -m new-master master
git symbolic-ref HEAD refs/heads/master
git branch -D old-master

of course anybody who was following this git repository now has problems ...

comments

CLC v7

2010-02-01T20:38:23Z

With a lot of help from Faré and James Y Knight we have now the incredible disappearing common-lisp-controller v7. We went from 617 to 267 lines which in fact are only 193 lines excluding comments and empty lines...

Using the new features of cl-asdf version 1.500 and higher the implementation of CLC is now merely setting a few variables and putting a few files into place. As an added bonus I added clbuild integration, so now people can download and update libraries with ease.

Still todo:

there is an bug (#567912) that the first call to (clc:clc-require :<foo>) will fail with clisp due to a loop where there is no looping...
We still need to find a way to precompile libraries
Because asdf is now taking care of placing the fasl file in the correct place, we cannot remove fasls for a specific implementation or library, so we nuke them all. Not optimal.

.

Still a nice improvement, I hope to find some time at fosdem to work on the other issues...

comments

java studdenly started failing

2009-12-09T08:30:47Z

Yesterday webex started failing for me. I did not change anything related to java recently so I was a little perplexed.

Checking it turns out that even the standard test your java page failed. strace revealed the nice error:

$ grep ffff /tmp/TRA 6938 connect(22, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:72.5.124.95", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28 <unfinished ...> 6938 connect(22, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:72.5.124.95", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)

Notice that I don't have IPv6 connectivity!

Googling it turns out that you can disable IPv6 in java by modifying to ~/.java/deployment/deployment.properties the line:

deployment.javaws.jre.0.args=-Djava.net.preferIPv4Stack\=true

and all is now well. Until I need to access an IPv6 device with java of course :-(.

comments

on the lack of future for cmucl in Debian

2009-11-24T05:56:31Z

Following the announcement of the source+throw away binaries route for uploading packages I've had a brief discussion with our FTP team.

The implications of the new method would be that if you upload a package it will automatically be recompiled from source by using the packages already in the system.

For cmucl which needs cmucl to recompile itself it means that we can only use the previous version of cmucl in the archive, not the one we are just uploading. This won't work as the compiling cmucl needs to be hand-patched to be more 'like' the new version, otherwise you cannot rebuild it.

The conclusion of this discussion is that systems like cmucl are no longer possible under this new system.

The FTP team suggested to change cmucl to be able to do this. Needless to say we already have this, after several years of hard effort by multiple people, it's just called sbcl.

So in the end the 'everybody uses C' camp won and cmucl on Debian will die a quiet death. It's a sad end for a system hand-patched from PDP10's to modern CPU's over the coarse of almost 30 years...

comments