pvaneynd: (Default)
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 :).
pvaneynd: (Default)
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

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
pvaneynd: (Default)
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
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
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.
pvaneynd: (Default)
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 ...

CLC v7

Feb. 1st, 2010 09:24 pm
pvaneynd: (Default)
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...
pvaneynd: (Default)
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:", &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:", &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:


and all is now well. Until I need to access an IPv6 device with java of course :-(.
pvaneynd: (Default)
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...
pvaneynd: (Default)
Actually clbuild seems to do the right thing almost all the time.

I've been trying it as a workaround to suggest to users after I remove most of the Common Lisp libraries from Debian. Honestly it is pretty good: you download it, you ask it to install libraries an it will download them from their git/cvs/darcs/whatever repositories. You can ask it to upgrade the libraries or to compile and start slime with the libraries 'known' to asdf.

All in all quite good, even if there is a conflict between the slime in clbuild and the slime from the Debian package.

I think I can suggest this to Debian users without reservations...

Now: why didn't I see more of this on planet.lisp ?
pvaneynd: (Default)
After some consideration I must conclude that the state of the Common Lisp packages in Debian is becoming unreasonable. One of the goals of forming the pkg-common-lisp team was that I would not be a bottleneck, as RL is inflicting more and more damage to my 'Debian playtime'.

Now that Luca left I'm basically the only 'active' (for very small values of active) DD/DM left. (no hard feeling towards anybody, just loads of thanks for the work they did)

I see two alternatives:

  • other people get involved, investigating bugs and sending git/darcs/whatever format patches.

  • we go low impact and remove common-lisp-controller and all Common Lisp libraries, and I/we only package the lisp implementations (clisp, ecl, sbcl, cmucl and perhaps ccl) without any special changes

I don't expect the first alternative to be realistic, so unless proven wrong I'll RFA/RM all the libraries/clc on the 5th of September.
pvaneynd: (Default)
In the last few weeks I needed to write a short utility at $WORK. I decided to use my trusted Common Lisp. Turned out that my old utility still would be ok, but 'upstream' had changed from CSV files to 'json' files.

A short google query, downloading the two libraries that exists to parse these files and within a few minutes I could read and parse the new fileformat.

Don't tell me CL doesn't have libraries...

ObDebian: yes I still need to update cl-irc and package said jason library... it's somewhere in my long todo list.
pvaneynd: (Default)
This year I managed to go to fosdem every day, even at the beer event. Not that I attended many talks: I was quite busy getting the network to work. We got wireless in almost all locations in the end. Setting up and fixing the problems took most of Saturday. On Sunday we added the final 'experimental' room via a wireless bridge link across the square, with the beam over the heads of the people in the queue for Belgian fries.

In the end it all worked and we had only a few configuration and many cable problems. I must say it was more for to 'work' at fosdem then to just be there. May thanks to Jerome Paquay who actually arranged to lend the equipment from our employer (Cisco) and  to configure it. Thanks for AY for ... well being AY.

Next year n-mode? serious uplinks?

pvaneynd: (Default)
I installed the 4.2 KDE from experimental and ... wow. Nicer. Faster. Less display corruption. All in all good.

shame about the crash when I unplug my external display

I can't wait for the 'testing' release :-)

Congratualtions to the KDE and debian-KDE people!
pvaneynd: (Default)

Yes, I browse to billions of self-signed https sites every day so I needed this...
pvaneynd: (Default)
For the last few months I've been running the latest git versions of xf86-video-ati and xf86-video-radeonhd on my $WORK laptop with a Mobility Radeon X1300.

And actually I like them more then fglrx: they crash less and I actually have xrandr support so giving presentations and using the second screen no longer involves reloads of X.

A remaining problem was that they would sig11 when I enable DRI. Yesterday I went investigating and found out that the ati driver was crashing in the line:

Bool RADEONDRIGetVersion(ScrnInfoPtr pScrn)
    /* Low level DRM open */
    fd = drmOpen(RADEON_DRIVER_NAME, busId);

After giving some message that it cannot open /dev/dri/card0. Some research showed that this was because I forgot to load the kernel module. /me hits table.

modprobe radeon and DRI works. Obviously it doesn't do 3D because the mesa library is too old. Installing mesa 7.2 from experimental and I see:

 $ glxinfo | grep direct
direct rendering: Yes

And all the whoos effects... well ... whoos.

Now off to Ana's blog to find out how I can get KDE 4.1 in unstable....
pvaneynd: (Default)
My wife has a laptop running Vista because she wanted to try out the operating system before having to decide on using it at work.

I called her various names because of it, but that didn't help :-).

So we have this setup with an SMC wireless router/AP talking to a Cisco 837 router that does the internet part. Upstairs we have a 'server' that is connected via Powerline IP-over-power, downstairs we have the Dreambox that is connected via a normal Cat5 connection.

In the last few days my wife complained that it was very slow to download media from Frost. Working at TAC having a network problem at home is almost a personal offence :-) so I decide to take a look and I find using iperf the following speeds:

frost (debian) --cat5--> sharrow (debian): 35 Mbit/sec
frost (debian) ---WL-cat5-> sharrow (debian): 18 Mbit/sec
sharrow (debian) ---WL-cat5-> frost (debian): 18 Mbit/sec
sharrow (debian) --cat5---> frost (debian): 35 Mbit/sec
frost (debian) ---WL---> martha-jones (vista): 0.2 Mbit/sec
sharrow (debian) ---WL---> martha-jones (vista): 12 Mbit/sec
sharrow (debian) ---cat5-SMC-WL--> martha-jones (vista): 6 Mbit/sec
martha-jones (vista) --WL-cat5-> frost (debian): 18 Mbit/sec
martha-jones (vista) --WL--> sharrow (debian): 18 Mbit/sec
martha-jones (vista) --WL-cat5-> sharrow (debian): 18 Mbit/sec

This made no sense at all. The speed halved going from a WL->WL to a WL->cat5 connection but only in one direction!

So having isolated the problem to the Vista machine I started looking round and I found a note saying that running netsh interface tcp set global autotuninglevel=disabled in an 'Administrator' cmd window will fix the problem.

Now I'm very weary of changing the TCP/IP options of the operating system. In most cases the 'tips' you see flying round the internet have no meaning at all and sometimes make the situation worse rather then better.

However I did find this on a Microsoft Technet site.... Hmm

So in the end I try it and modify the setting, disconnect and reconnect to the wireless and:

frost (debian) ---WL---> martha-jones (vista): 18 Mbit/sec
sharrow (debian) ---WL---> martha-jones (vista): 18 Mbit/sec
sharrow (debian) ---cat5-SMC-WL--> martha-jones (vista): 18 Mbit/sec

Aah, finally I could tune Vista so that it has the same speed as an untuned Debian machine. I only took me 2 evenings worth of work...
pvaneynd: (Default)
The one problem I have with my server at home now seems to have a fix.

The server has a standard encrypted root, as configured by debian-installer. The issue with this is that after booting I need to go to the console and enter the LUKS password. As I do almost everything remotely this is a pain.

However C'T published a nice article a while ago on how to solve this. The short story is that you install a custom initrd plugin that starts dropbear and waits for the password on the console or via ssh.

Now to install and test this...
pvaneynd: (Default)
After upgrading to 2.6.26 I could not associate with my AP anymore. After searching I noticed that the amount of channels reported by iwlist wlan0 channel had changed. And the channel that my AP was using (13) just disappeared.

I openeded a bug with the iwl people and the end result is: in 2.6.25 the card selected the region for the wireless, in 2.6.26 the cfg80211 system is doing so and the default is 'US'.

So if you are in Europe you need to add a file /etc/modprobe.d/cfg80211-region with as contents:

options cfg80211 ieee80211_regdom=EU


pvaneynd: (Default)

March 2017

12131415 161718
26272829 3031 


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 18th, 2017 10:03 pm
Powered by Dreamwidth Studios