08:38:05 # Life dpep_template_hardcoded is not accepting '-d' options, thus without a template file, it's not using the description. It will need to change.
08:08:44 # Life debootstrap debugging. It feels rather annoying to have to debug something someone has rewritten and never worked; to debug something that is rewritten and never worked, I need to guess at the intention of how it was to be implemented. /usr/sbin/debootstrap --variant=buildd sid . http://ring.asahi-net.or.jp/archives/linux/debian/debian. I've tracked it down to a line that is giving me an error where it shoulnd't be, but no idea yet on how to fix it.
08:47:14 # Life dpatch-edit-patch debugging. There are so many features that I didn't know about, and their existence restricts what can be done. It would be really nice to deprecate everything that seems unworthwhile. Having a system-wide configuration file for dpatch being able to specify a stamp-dir is a little over-featured. Also, stamp-dir really needs to be configured per-source, not per-system; and why not per-Debian? (as in all Debian dpatch-using packages agree on debian/patched/).
08:44:25 # Life I've implemented dpatch-edit-patch testsuite. There are a few bugs in the implementation of current dpatch-edit-patch, and I'd like to approach the problem in a one-by-one approach. In my opinion, it's a tool that is widely used, and should be in a maintenance mode.
08:17:52 # Life debootstrap seems to be unable to debootstrap sid with variant buildd. It just emits a message 'E: Couldn't find these debs: 0'
21:04:27 # Life Debugging debootstrap a bit more, I found a bit more info. I am guessing that it's obtaining the list of every single package in Debian while it's searching for Build-Essential packages. Sigh...
10:23:57 # Life Played a bit with dpatch. I've added a testsuite for dpatch-edit-patch, since the documentation and code was a bit different from reality. There are obscure features that seem to be untested, and I think it will really benefit well from a regression test.
20:56:28 # Life I've felt an urge to check out what kind of memory handling C programs were using. I've created a test program that loops around and malloc/frees different memory sizes. To my surprise it was freeing back some of the malloc'd regions to the OS. However, since it's seeing different address for smaller mallocs, I am suspecting that it's not freeing smaller mallocs. This behavior agrees with how glibc source is written, and probably the intention. Nice.
/*BINFMTC: */ #include <stdio.h> #include <stdlib.h> main() { int i; while (1) { for (i=1; ; i<<=1) { void*ptr; ptr=malloc(i); if (!ptr) break; printf ("%i %p\n", i, ptr); free(ptr); } } }
1 0x804a008 2 0x804a008 4 0x804a008 8 0x804a008 16 0x804a018 32 0x804a030 64 0x804a058 128 0x804a0a0 256 0x804a008 512 0x804a008 1024 0x804a008 2048 0x804a008 4096 0x804a008 8192 0x804a008 16384 0x804a008 32768 0x804a008 65536 0x804a008 131072 0x804a008 262144 0xb7f49008 524288 0xb7f09008 1048576 0xb7e89008 2097152 0xb7d89008 4194304 0xb7b89008 8388608 0xb7789008 16777216 0xb6f89008 33554432 0xb5f89008 67108864 0xb3f89008 134217728 0xaff89008 268435456 0xa7f89008 536870912 0x97f89008 1073741824 0x77f89008 [snip] 1 0xb7e00480 2 0xb7e00480 4 0xb7e00480 8 0xb7e00480 16 0xb7e00490 32 0xb7e004a8 64 0xb7e004d0 128 0xb7e00518 256 0xb7e00480 512 0xb7e00480 1024 0xb7e00480 2048 0xb7e00480 4096 0xb7e00480 8192 0xb7e00480 16384 0xb7e00480 32768 0xb7e00480 65536 0xb7e00480 131072 0xb7e00480 262144 0xb7f49008 524288 0xb7f09008 1048576 0xb7cff008 2097152 0xb7bff008 4194304 0xb79ff008 8388608 0xb75ff008 16777216 0xb6dff008 33554432 0xb5dff008 67108864 0xb3dff008 134217728 0xafdff008 268435456 0xa7dff008 536870912 0x97dff008 1073741824 0x77dff008
Then I thought I'd like to make sure address space is mapped as I expect it to be. I've ran the program inside gdb and stopped it in middle of a glibc function, and took a backtrace, and compared with how the kernel thinks about it.
(gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4515fb36 in munmap () from /lib/tls/i686/cmov/libc.so.6 #2 0x450fcd3c in malloc_set_state () from /lib/tls/i686/cmov/libc.so.6 #3 0x08048446 in main () $ cat /proc/6905/maps 08048000-08049000 r-xp 00000000 00:0d 9350 /tmp/a.out 08049000-0804a000 rw-p 00000000 00:0d 9350 /tmp/a.out 0804a000-0806b000 rw-p 0804a000 00:00 0 [heap] 45072000-45088000 r-xp 00000000 03:03 1929540 /lib/ld-2.3.2.so 45088000-45089000 rw-p 00015000 03:03 1929540 /lib/ld-2.3.2.so 4508b000-451b5000 r-xp 00000000 03:03 1929543 /lib/tls/i686/cmov/libc-2.3.2.so 451b5000-451be000 rw-p 00129000 03:03 1929543 /lib/tls/i686/cmov/libc-2.3.2.so 451be000-451c0000 rw-p 451be000 00:00 0 b7e00000-b7e21000 rw-p b7e00000 00:00 0 b7e21000-b7f00000 ---p b7e21000 00:00 0 b7f24000-b7f25000 rw-p b7f24000 00:00 0 b7f36000-b7f38000 rw-p b7f36000 00:00 0 bfb23000-bfb38000 rw-p bfb23000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso]21:07:51 # Life At CodeFestJapan 2005, akr implemented a ruby script redirect-process which redirects the output of an already-running process. I wanted to try and reimplement it with shell, and here is a one-liner. The stdout of the process of which PID is specified on PARAM= is output as the stdout. PARAM=12519 gdb -batch -n -x <( echo -e "attach $PARAM\nprint dup2(open(\"/proc/$$/fd/1\", 1), 1)" )
22:15:12 # Life Somebody in Japan made a mascot character for Ubuntu in accordance to the Japanese Anime tradition, and created a wallpaper. I wonder what Debu-tan will look like; if Ubuntu-tan is like this.
09:09:20 # Life Last night we had the 6th Tokyo area Debian study meeting. kmuto talked about Debian installer, and eto talked about dsys and update-alternatives. It's nice to hear hackers talk about their toy projects. There's always something new to hear.
18:08:41 # Life Debugging on pbuilder and other things that have been pending. Bug triage. Humph, not too bad a weekend. Having done a Debain study meeting puts me so motivated to get bugs fixed.
06:58:14 # Life Gees, just as I when I woke up, I've seen the 'debian-announce: Debian GNU/Linux 3.1 released' headline flashing by. Great work folks! I find it impressive that it actually happened today.
17:25:06 # Life Apparently, I've only been sending my revocation certificate by mail, and not uploaded to any of the keyservers; I've sent it out to the public keyservers now.
02:14:24 # Life binfmtc now supports pascal and fortran. release 0.5.
15:20:38 # Life Result of Code Fest Japan 2005. After the 24 hours of intensive hacking, I'm taking pbuilder in a better shape than it was before. I've hacked testsuite support into pbuilder, and reasonably confident that it's starting to work. Guys here have discussed about possibility of getting debconf in Japan a possibility, and although the financials look uneasy, it could be a reality.
08:53:22 # Life I will be attending CodeFestJapan 2005 today. It's going to start from 17:00 JST today and 17:00 JST tomorrow, a 24-hour hackathon. I'm planning on processing my backlogs on Debian work and getting things normal.
22:52:31 # Life Considering cost for debconf if it is held in Japan. Roughly, we're looking at 150 people, 10 days. This leads to around Y 20,000,000. Which feels rather difficult.
08:44:39 # Life This weekend I will be attending CodeFestJapan 2005, which is an 24-hour endurance hacking event. It will start at 5pm, and I don't think I will really be able to stay up another 24 hours starting from that, but that's that. Hoping to get much hacking done.
$Id: 200506.html.en,v 1.24 2005/06/29 23:33:54 dancer Exp $