People say that using bitfields in structs is slow. Of course it reduces memory usage, but the aritmetic is slower than just using pointers.

But my real problem is that if a struct uses bitfields, I can't just pass foo->bar as a pointer. And I hate that. When migrating ls-files to parseopt, I needed to write 3 extra callback functions just because of this.

Grr.

Still preparing for my 'Computer Networks' exam, so I did not do much coding.

LGee just uploaded a few new pictures about his servers, and there are two interesting ones. ;-)

First is this one. And then yes, I must agree that some mainboards are really can't be used a server.

This other one is just interesting - first we though that's a bug in the Frugalware ppc installer, then later it turned out to be a generic Linux-ppc issue.

OK, this was silly.

Yesterday I wanted to reply to a post on the swig mailing list. I found the post on nabble.com, which is way worse than gmane.org, but - I guess - due to SEO black magic Google prefers the previous. So I searched for the mail on gmane.org, appended the usual /raw to the mail, but I still did not get a mbox, to feed it to mutt. Given that I had no idea what do to, I just simply wrote an mbox header, then mutt was able to open it.

And finally it turns out that gmane has a nice export feature. Duh! ;-)

BMH still feeds me with info, he just found a -Qt bug - fortunately the fix was rather trivial.

The nontrivial stuff is that he wants callbacks in the Python bindings and it seems that won't be easy. The reason is that - it seems, I don't have a working implementation yet - we'll need the traditional 'void *data' extra parameters in each callback to support that, since we need to store the Python context pointer somewhere.

Of course first I want to have the whole thing working, before breaking the API with no good reason.

The whole idea is based on this post. The provided examples work fine, at least.

Snip. Dscho mailed me today with a project list about what could I do in Git - the two items are a major merge-recursive rework, the other is about packv4. I could learn a lot with both, my interest is in this order. But that's not yet in coding status, we're just discussing the details ATM.

This came up on the mailing list, and finally resulted in a commit in pacman-g2.git.

The idea is to speed up the pacman -Sy operation just like rsync speeds up not re-transferring already sent data.

Also BMH started to poke me about the bindings privately, so I pushed a few fixes and probably I will continue doing so.

At least if you track git.git's "next" branch. Happy new year! :)

(patch, merge)

I did it in 2oo7 and 2oo6, so I did it this year as well.

Writing such a list takes a lot of time, but I think it worth the effort.

I just noticed that I can ask mkpasswd to not include extra signs (so only [A-Za-z0-9]) in the passwd, and also I can ask it to make it longer, for example:

$ mkpasswd -l 18 -s 0
kweufGtytpIj1ds8bw

Sadly it's quite useful on broken websites where they bail out with an error when my pass contains a ' or a "...

So here they go.

First, I needed a list of packages for rebuild:

wget -O test.html 'http://frugalware.org/packages/?op=file&srch=usr%2Flib%2Fpython2.5&arch=i686&ver=current'
lynx -dump ./test.html|grep ' [0-9]\+\. \['|sed 's/.*\]\(.*\) .*/\1/' > test.list

Then I used the following cycle:

git checkout -f; for i in $(cat ~/test.list); do echo $i; cd ~/git/python26/source/*/$i || continue; sudo makepkg -t python2
6,current -C; git clean -x -d -f; sed -i 's|python>=2.5|python>=2.6|g' FrugalBuild; bumppkg -t python26,current --rebuild "-
 rebuilt with python-2.6" || break; repoman -t python26 -k push; done

When a build failed, I fixed it up manually and used the following aliases:

alias pybuild="sudo makepkg -t python26,current -cu"
alias pypush="repoman -t python26 -k push"
alias pyrec='repoman rec "- rebuilt with python-2.6"'

then removed the already built pkgs from the top of test.list and started the for cycle again.

Once this was done, I did a

git grep 'python>=2.5'

to ensure everything has &gt=2.6 now (except a few cases where a rebuild was not necessary).

Syncing on x86_64 was like this:

I generated the package order with:

git log --reverse --no-merges --pretty=oneline master ^origin/master|sed 's/.* \(.*\)-[^-]\+-[^-]\+-i686/\1/' > build.list

Then I started a for cycle as well, but now just ignoring the failed builds:

git checkout -f; for i in $(cat ~/build.list); do echo $i; cd ~/git/python26/source/*/$i || continue; sudo makepkg -t python26,current -C; git clean -x -d -f; makepkg -dgu; rm -rf src; if sudo makepkg -t python26,current -cu; then repoman -t python26 -k push; else echo $i >> ~/broken.list; fi; done

fortunately less then 5% of all pkgs failed.

OK, that's all.

Started to work on a python26 WIP repo. About 400 packages will need a rebuild, so it'll be fun. I'll publish all the needed scripts here when I'm done - though most of them is in a "use once, then trow away" style.

While waiting for the above scripts, I also started to work on converting git's builtin-apply to parseopt. Ideally it would be trivial, but it really have a lot of options, so probably I won't finish that today, either.