Index ¦ Archives ¦ RSS > Tag: en

pacman-g2 -Qt bug

Estimated read time: 1 minutes

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.


pacman -Sy: rsync-like optimization

Estimated read time: 1 minutes

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.


git-apply now uses parseopt

Estimated read time: 1 minutes

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

(patch, merge)


A goal list for 2oo7

Estimated read time: 1 minutes

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.


mkpasswd

Estimated read time: 1 minutes

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


Scripts used in the Python-2.6 mass rebuild

Estimated read time: 2 minutes

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.


Python 2.6

Estimated read time: 1 minutes

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.


darcs-fast-export 0.8

Estimated read time: 1 minutes

Whoa, lots of stuff happened.

darcs-fast-export 0.8 is out and it passes the big-zoo test. (In short AFAIK darcs2git goes to an infinite loop for big repos, the others just produce corrupted results, and d-f-e is the first that can pass that test.)

I just noticed a bit expensive (since you'll be billed an international fee), but useful sms2irc method, by using sms4skype + bitlbee-skype. :)

Oh and a trick. We at Frugalware use a hook to update the working dir after every push, so that the new (in git 1.6.1) warning when pushing to a non-bare repo is bogus. The way to disable it is in git-config, manpage, but here it is:

git config receive.denycurrentbranch ignore


Frugalware Xmas logo

Estimated read time: 1 minutes

phayz just pushed out a special Frugalware logo for Xmas, I like it. :)

BTW it's interesting, my sister got an English bible and it claims that "to make it easier to read it more fluently and accurately, it's 'anglicised'." Not sure if that's really true, especially that young people like me typically learn a lot of words and expressions from movies and series...


Frugalware darcs repo in the darcs "big-zoo"

Estimated read time: 1 minutes

"big-zoo" is a collection of darcs repos, the darcs developers do benchmarks using this collection from release to release.

Recently our old Frugalware repo has been added, which is good, for multiple reasons.

First, now I can say that the reference for a good darcs exporter is the big-zoo, our old repo contains weird patches which were not yet part of "big-zoo" so far. Not that I'm evil, but I want to show that currently darcs-fast-export is the only exporter that can correctly convert all the repos in "big-zoo".

Second, it is a huge repo, so developers can how see the corner cases where darcs is really slow for a huge repo - though the GHC one was already included which is almost as big as our one and the most annoying cases are already optimized recently. (No, of course I can't compare it to git, I compare it to darcs-1.x.)

© Miklos Vajna. Built using Pelican. Theme by Giulio Fidente on github.