| *** gtristan has quit IRC | 05:26 | |
| *** gtristan has joined #baserock | 05:56 | |
| *** paulw has joined #baserock | 08:23 | |
| *** edcragg has joined #baserock | 08:30 | |
| *** ssam2 has joined #baserock | 08:36 | |
| *** ChanServ sets mode: +v ssam2 | 08:36 | |
| *** toscalix has joined #baserock | 08:39 | |
| *** bruce_ has joined #baserock | 08:42 | |
| *** rdale has joined #baserock | 08:45 | |
| *** edcragg has quit IRC | 08:55 | |
| *** bashrc has joined #baserock | 09:09 | |
| gtristan | paulsherwood, I see that recently sandbox.py 'install' was patched to report an error if cache.get_cache() returns False, instead of trying to build a path with the boolean False return... any clues as to why this would happen, though ? | 09:17 |
|---|---|---|
| * gtristan recalls working around this problem weeks ago, and now is hitting the error but having a hard time figuring out why it's happening | 09:18 | |
| paulsherwood | erk :/ | 09:18 |
| paulsherwood | i was looking at this last night | 09:19 |
| paulsherwood | for example https://github.com/devcurmudgeon/ybd/issues/149 | 09:19 |
| paulsherwood | i don't know what's happening there tbh | 09:20 |
| paulsherwood | gtristan: could you try with the previous release, please? | 09:21 |
| paulsherwood | (but i fear that it will do the can't concatenate bool + str fail) | 09:21 |
| gtristan | I was trying with 15.49 which blindly builds a path and causes an error, and then upgraded to the "nice" error :) | 09:22 |
| paulsherwood | ah, ok | 09:22 |
| paulsherwood | could you paste your log? | 09:24 |
| paulsherwood | gtristan: i assume you're root? | 09:26 |
| *** CTtpollard has quit IRC | 09:26 | |
| gtristan | http://paste.baserock.org/somesofeci | 09:27 |
| gtristan | problem is, this is pretty experimental territory :-/ | 09:27 |
| *** CTtpollard has joined #baserock | 09:28 | |
| paulsherwood | ack. | 09:28 |
| gtristan | I built stage1-binutils alright and it created an artifact, then; I gutted build-essential to remove all the stage1/stage2 cross stuff, and am trying to hardwire the build env to use the installed distcc on aboriginal | 09:28 |
| * gtristan runs off for feeding, will return shortly... | 09:32 | |
| * paulsherwood is breakfasting... this is not improving the taste of my food :-) | 09:32 | |
| *** faybrocklebank has quit IRC | 09:36 | |
| *** fay_ has joined #baserock | 09:36 | |
| *** fay_ is now known as faybrocklebank | 09:37 | |
| *** gtristan has quit IRC | 09:37 | |
| *** CTtpollard has quit IRC | 09:37 | |
| *** edcragg has joined #baserock | 09:39 | |
| *** CTtpollard has joined #baserock | 09:40 | |
| *** jonathanmaw has joined #baserock | 09:46 | |
| *** rdale has quit IRC | 09:53 | |
| *** rdale has joined #baserock | 09:54 | |
| pedroalvarez | radiofree: well... it looks like gdp-hmi dididn't work before upgrading the components... sorry for the noise with this... | 09:59 |
| pedroalvarez | (in x86, btw) | 10:00 |
| pedroalvarez | it might work in arm, I dont know | 10:00 |
| radiofree | hmm | 10:00 |
| radiofree | ah! | 10:00 |
| radiofree | maybe... | 10:00 |
| radiofree | how is weston started? | 10:00 |
| pedroalvarez | ExecStart=/usr/bin/weston-launch -u root -- --log=/tmp/weston.log --backend="fbdev-backend.so" | 10:01 |
| radiofree | ah, so still with the fbdev backend | 10:01 |
| radiofree | does stock desktop-shell work? | 10:01 |
| radiofree | launch weston with --no-config (i think, check man weston) | 10:01 |
| radiofree | then try launch weston-simple-egl | 10:01 |
| *** CTtpollard has quit IRC | 10:02 | |
| radiofree | there were some upgrades to mesa recently that allowed you to use the drm backend in qemu, potentially could have caused issues with the fbdev backend (though i'm not sure why...) | 10:02 |
| *** CTtpollard has joined #baserock | 10:06 | |
| radiofree | i could try it on a jetson if you want? | 10:06 |
| *** franred has quit IRC | 10:08 | |
| *** CTtpollard has quit IRC | 10:09 | |
| *** gtristan has joined #baserock | 10:10 | |
| *** CTtpollard has joined #baserock | 10:13 | |
| *** franred has joined #baserock | 10:13 | |
| *** franred_ has joined #baserock | 10:14 | |
| radiofree | hmm linux32 stopped working on this mustang after the kernel upgrade | 10:14 |
| *** franred_ has quit IRC | 10:15 | |
| *** nowster has joined #baserock | 10:21 | |
| paulsherwood | gtristan: i'm a bit stumped on this get_cache returning false thing... i can't reproduce it | 10:29 |
| *** Lachlan1975 has joined #baserock | 10:29 | |
| gtristan | yeah I figured you cant reproduce :-/ | 10:35 |
| gtristan | ok so how do you get a shell in the build staging area instead of running the build ? | 10:49 |
| tiagogomes__ | morph creates a script that allows you to enter a chroot with the build environment for some chunk. setup. ybd could provide the same functionality | 10:52 |
| * gtristan wonders if it's as easy as invoking 'bash' somewhere... but suspects there is some redirection going on which will prevent that from working | 10:54 | |
| paulsherwood | gtristan: you could exit 1, then chroot into the staging area ? | 10:55 |
| tiagogomes__ | that doesn't setup the build environment (e.g. environment variables) | 10:56 |
| radiofree | linux32 issue was due to it prefering /bin/linux32 (busybox) over /usr/bin/linux32 (util-linux) for some reason | 10:56 |
| tiagogomes__ | doesn't the one that gets chosen depends on $PATH? | 10:57 |
| gtristan | right, I'm mostly concerned with what the mounts are and what the env vars are | 10:57 |
| gtristan | i.e. the real build env it would have ended up with | 10:57 |
| paulsherwood | ack. the build env is recorded in the log, maybe you could copy that and source it? | 10:58 |
| gtristan | paulsherwood, iirc ybd builds stuff in /tmp/... is there a way to make it happen in all in ${base}/tmp ? | 10:58 |
| paulsherwood | gtristan: it should all happen in ${base}/tmp | 10:59 |
| gtristan | hmm | 10:59 |
| tiagogomes__ | chroot script example for morph: http://paste.baserock.org/uquyotinuy | 10:59 |
| gtristan | that shouldnt be a problem then (I think my /tmp is not writable) | 10:59 |
| paulsherwood | tiagogomes__: tvm | 10:59 |
| paulsherwood | gtristan: your log says '/home/ybd/tmp is directory for tmp' | 11:00 |
| gtristan | yeah, it is | 11:00 |
| gtristan | so as long as it really builds in /home/ybd/tmp, and not in /tmp, it shouldnt be a problem | 11:01 |
| paulsherwood | :) | 11:01 |
| paulsherwood | gtristan: you could set log-verbose: True, maybe that will give a bit of extra info | 11:01 |
| gtristan | good hint | 11:05 |
| *** tiagogomes__ has quit IRC | 11:05 | |
| paulsherwood | i'm clutching at straws, tbh :/ | 11:05 |
| *** edcragg has quit IRC | 11:07 | |
| gtristan | honestly I know the env vars which are are printed and which ybd says its setting up, and I see the code which is setting them up... but when you dont trust it... would be great to have a real shell that ybd setup for a build to know for sure whats up in there | 11:07 |
| paulsherwood | i agree | 11:09 |
| *** edcragg has joined #baserock | 11:09 | |
| gtristan | I think what is happening, is that 'make' is not found in that shell | 11:09 |
| gtristan | not sure why that would result in the get_cache() failure though :-/ | 11:10 |
| * paulsherwood wonders how a python program can throw its user into a shell | 11:11 | |
| gtristan | jhbuild does it | 11:11 |
| radiofree | wouldn't you just call the same command you use to do the build, but instead of "cd foo.build/ && make" (or whatever) you just run /bin/sh ? | 11:12 |
| gtristan | https://git.gnome.org/browse/jhbuild/tree/jhbuild/commands/base.py#n409 | 11:12 |
| radiofree | the morph log used to give you the linux-user-chroot command that failed, you could just copy that and run sh | 11:12 |
| gtristan | radiofree, right I think so | 11:12 |
| radiofree | but yes "foo failed, would you like to enter this and prod about?" would be great | 11:13 |
| gtristan | radiofree, the only thing I wonder is with all the redirection and mounting and chrooting, if that shell will be accessible to the one who invoked ybd ;-) | 11:13 |
| radiofree | (and is great in jhbuild) | 11:13 |
| gtristan | ok this is weird | 11:19 |
| *** tiagogomes__ has joined #baserock | 11:20 | |
| radiofree | paulsherwood: todays ybd error | 11:21 |
| gtristan | ah, I missed another possible False return... lets see | 11:21 |
| gtristan | in any case, the cache_key() is producing something | 11:21 |
| radiofree | http://fpaste.org/309737/52597729/ | 11:22 |
| radiofree | "sh -c 'python setup.py build' | 11:22 |
| radiofree | clone: Invalid argument" | 11:22 |
| *** paulw has quit IRC | 11:24 | |
| paulsherwood | radiofree: that looks like something in the chunk? | 11:25 |
| paulsherwood | (but i may be wrong... this is not my finest hour) | 11:25 |
| *** jonathanmaw has quit IRC | 11:26 | |
| radiofree | hmm | 11:27 |
| *** jonathanmaw has joined #baserock | 11:27 | |
| radiofree | isn't that "clone" error usually related to chroot/container issues? | 11:28 |
| radiofree | it's actually happening on everything | 11:30 |
| paulsherwood | i can't remember seeing 'clone' mentioned before | 11:31 |
| radiofree | this is in a armv7lhf chroot on a aarch64 dev board | 11:31 |
| radiofree | after upgrading to 4.4 | 11:31 |
| paulsherwood | with latest ybd? | 11:31 |
| radiofree | yes | 11:31 |
| paulsherwood | radiofree: building what? i can try the same on on a pre 4.4 box | 11:33 |
| radiofree | building anything | 11:34 |
| radiofree | this time it's perl | 11:34 |
| radiofree | i'll switch back to 4.1 and see if it goes away | 11:34 |
| radiofree | i wonder if it has anything to do with me logging in via terminal | 11:37 |
| radiofree | i've always done it over ssh previously | 11:37 |
| radiofree | the environment is different when i login via the serial | 11:37 |
| radiofree | my chroot script would have *never* worked via serial... so i guess i've never done it like this | 11:37 |
| radiofree | however things seem to be working here | 11:38 |
| paulsherwood | ssam2: i wonder if it would be possible/sensible to have sandboxlib support opening up a shell? | 11:42 |
| paulsherwood | (for the usecase gtristan described above) | 11:42 |
| ssam2 | paulsherwood: if the chroot contains a shell already, then that is super easy | 11:43 |
| ssam2 | paulsherwood: just run it | 11:43 |
| ssam2 | paulsherwood: if it doesn't, then it's quite hard because we'd have to somehow inject a shell into the sandbox that worked | 11:43 |
| *** jonathanmaw has quit IRC | 11:44 | |
| ssam2 | paulsherwood: but ybd could simply try to run '/bin/sh' in the sandbox if something fails to build.. would be worth trying. | 11:44 |
| *** jonathanmaw has joined #baserock | 11:44 | |
| radiofree | paulsherwood: https://irclogs.baserock.org/%23baserock.2014-10-30.log.html#t2014-10-30T14:15:15 | 11:45 |
| radiofree | would appear to be (of course) my fault | 11:46 |
| gtristan | ok so where is the artifact directory *supposed* to be created ? | 11:54 |
| gtristan | not in assembly.py:setup() ? | 11:54 |
| gtristan | err sandbox.py | 11:54 |
| radiofree | paulsherwood: ok, fixed, CONFIG_NET_NS is absolutely essential | 11:57 |
| radiofree | it wasn't a bug in ybd anyway | 11:57 |
| paulsherwood | radiofree: yay! :) | 11:57 |
| paulsherwood | gtristan: https://github.com/devcurmudgeon/ybd/blob/master/ybd/app.py#L132 creates the top-level directories, including the artifacts directory | 12:00 |
| paulsherwood | but are you asking about the sandboxes? | 12:00 |
| gtristan | paulsherwood, yeah, I'm asking where does the $base/$cachekey directory get created | 12:01 |
| paulsherwood | ssam2: i tried that... it sits there silently | 12:01 |
| gtristan | or, I suspect it is moved from $base/tmp/$sandboxdir after a build ? | 12:01 |
| gtristan | err, where $base/artifacts/$cachekey is created I mean, of course | 12:01 |
| gtristan | that's the one which doesnt exist when get_cache() is called | 12:02 |
| paulsherwood | https://github.com/devcurmudgeon/ybd/blob/f00d7c963c33eb63649d31ef5776ce0ee643e75e/ybd/cache.py#L134 | 12:03 |
| paulsherwood | this is a bit convoluted, because it needs to be atomic and multi-instance | 12:03 |
| paulsherwood | so the actual cache artifact is $base/artifacts/$cachekey/$cachekey, which ends up in place when we rename $base/tmp/$random to $base/artifacts/$cachekey | 12:05 |
| gtristan | so after a build, we rename $base/tmp/$random to $base/artifacts/$cachekey ? | 12:07 |
| paulsherwood | (and by this point we've also untarred the artifact, so if the tar was corrupted, no artifact arrives) | 12:07 |
| gtristan | but that is not the referenced line right ? cause that is where we unpack a tarbal | 12:07 |
| paulsherwood | that referenced line is where the rename happens | 12:07 |
| gtristan | ok, so we build, then we tar, then we untar and rename | 12:08 |
| paulsherwood | so that's the point when the artifac springs into existence | 12:08 |
| paulsherwood | correct | 12:08 |
| gtristan | so cache.py:cache() must be called at some point before cache.py:get_cache() | 12:09 |
| paulsherwood | well, n artifact can be created by cache.py:cache() or by fetching from artifact cache ... get_remote() | 12:10 |
| paulsherwood | in the get_remote() case cache() would not be called, iirc | 12:10 |
| gtristan | right, assuming nothing exists yet of course :) | 12:11 |
| paulsherwood | yup | 12:11 |
| paulsherwood | my current hunch is that an exception is happening, but it's being eaten | 12:12 |
| gtristan | yeah | 12:12 |
| radiofree | what exactly does the "[135/206/375]" in a ybd tell me? | 12:15 |
| radiofree | there's 375 things to build, of which 206 have been built/there's a cache | 12:15 |
| radiofree | so 169 things need building? and 135 of those 169 are complete? | 12:15 |
| pedroalvarez | 375 components in total, 206 you have to actually build, and you are building the number 135 | 12:15 |
| radiofree | ah | 12:15 |
| pedroalvarez | (IIRC) | 12:16 |
| paulsherwood | doing job 135 of 206 jobs this run, of total 375 jobs required to build foo | 12:16 |
| radiofree | yes that makes much more sense, thanks | 12:16 |
| ssam2 | paulsherwood: try passing stdout=sys.stdout and stderr=sys.stderr to sandboxlib.run_sandbox() when running the shell | 12:17 |
| ssam2 | hmm.. probably needs a way to forward stdin too | 12:18 |
| ssam2 | i guess it's not so simple | 12:18 |
| paulsherwood | yup | 12:18 |
| ssam2 | this is ugly in a way because some sandboxing methods might not make this possible at all | 12:18 |
| ssam2 | well, not simple anyway | 12:18 |
| paulsherwood | gtristan: pls could you try http://paste.baserock.org/senijayine | 12:18 |
| ssam2 | e.g. if you were using a lightweight VM for sandboxing, or something | 12:18 |
| paulsherwood | ssam2: yup, but not as ugly as ybd reimplementing the call itself? :) | 12:19 |
| gtristan | paulsherwood, ok... fwiw, in my case, it seems cache() is not getting called, but get_cache() is... and I expect the build failed, but have no indication that it did | 12:19 |
| paulsherwood | gtristan: ack. i'm hoping that tweak to claim() may give a hint | 12:20 |
| ssam2 | paulsherwood: true.. it would be better for sandboxlib to expose a 'run_sandboxed_interactive()' function that just might not work in all cases | 12:22 |
| gtristan | I think/suspect a build command is failing, i.e. ybd should get an error trying to execute 'make', which I suspect is not found | 12:23 |
| gtristan | haha: NameError: global name 'true' is not defined | 12:24 |
| gtristan | I guess maybe you mean True | 12:24 |
| paulsherwood | yup | 12:25 |
| paulsherwood | but ybd normally will spot build errors and report them properly, i think? | 12:26 |
| gtristan | I *think* so too | 12:33 |
| gtristan | it's possible it doesnt even have a shell though | 12:33 |
| gtristan | so it might for instance... blindly launch the build commands in the inexistent shell and then expect to read the error back with something special | 12:34 |
| gtristan | no difference with that patch fwiw :-/ | 12:34 |
| gtristan | oddly it removes the work directory it created | 12:35 |
| * gtristan tries stopping the thing while its working | 12:35 | |
| gtristan | paulsherwood, where does executor get assigned in sandbox.py ? | 12:37 |
| paulsherwood | https://github.com/devcurmudgeon/ybd/blob/master/ybd/sandbox.py#L91 | 12:38 |
| gtristan | that makes it assigned to something ? | 12:39 |
| gtristan | oh | 12:39 |
| gtristan | ok better question; what is it ? | 12:39 |
| paulsherwood | https://github.com/devcurmudgeon/ybd/blob/92727a5770592b433a9081af8d99e8883444fba5/ybd/__main__.py#L53 | 12:40 |
| gtristan | ah | 12:40 |
| paulsherwood | sandboxlib decides wther it's linux-user-chroot or chroot | 12:40 |
| paulsherwood | gtristan: i assume no l-u-c on your system? | 12:41 |
| gtristan | no | 12:42 |
| gtristan | no l-u-c | 12:42 |
| * gtristan searches in https://github.com/collective/sandboxlib | 12:42 | |
| gtristan | but not sure that's the right place | 12:42 |
| paulsherwood | https://github.com/codethinklabs/sandboxlib | 12:43 |
| gtristan | ah yeah that's where I installed it from | 12:43 |
| gtristan | ok so, I'll look deeper into this... looks like around here: https://github.com/CodethinkLabs/sandboxlib/blob/master/sandboxlib/chroot.py#L203 ... it's questionable whether the exception is reported correctly in the case that no shell is available to run the commands in the chroot | 12:48 |
| gtristan | well, not quite sure, I'll have to debug around there anyway | 12:48 |
| radiofree | would anyone mind me (on x86) i) moving extlinux.conf to /extlinux/ rather than / or ii) creating a symlink /extlinux.conf -> /extlinux/extlinux.conf if 1 doesn't work | 12:58 |
| radiofree | i'm trying to work about introducing even more configuration options (namely) EXTLINUX_CONFIG_PATH | 12:58 |
| pedroalvarez | I would be worried if upgrades stop working, but no, I don't mind | 13:01 |
| radiofree | i) doesn't work | 13:02 |
| radiofree | syslinux obviously expects it to be in / | 13:02 |
| radiofree | ii works | 13:03 |
| *** rdale has quit IRC | 13:15 | |
| *** gtristan has quit IRC | 13:26 | |
| *** rdale has joined #baserock | 13:28 | |
| *** gtristan has joined #baserock | 13:42 | |
| radiofree | oh no! | 13:48 |
| radiofree | ssam2: "sam-jetson-mason" was that the one with known file system corruption? | 13:48 |
| radiofree | [87386.749943] systemd-journald[156]: Failed to write entry (12 items, 309 bytes), ignoring: Read-only file system | 13:49 |
| rdale | is baserock-dev the 'official' mailing list for discussing the evolving ybd design - or is there another one? | 13:51 |
| paulsherwood | rdale: please use baserock-dev, yes | 13:51 |
| rdale | ok. the reasone i ask is that i've just found out that it only uses a single sandbox temp dir for building everything, instead of a different one for every chunk. i don't know when that changed | 13:52 |
| rdale | it means that artifact splitting can't possibly be done at build time and has to be done at system assembly time | 13:57 |
| paulsherwood | rdale: that's not true? | 14:04 |
| rdale | ah ok | 14:05 |
| paulsherwood | each chunk gets its own sandboxdir | 14:05 |
| paulsherwood | but splitting *should* be done at system assembly time, imo | 14:05 |
| rdale | right | 14:05 |
| rdale | sorry, your right about the sandbox paths - i'm logging the destpath in the _process_tree() function and initially it seemed to be always the same tmp sandbox, but now it isn't | 14:07 |
| rdale | i need to go back and analyse my debugging log to see whats happening. what i don't understand is how sandbox.install() is pulling in the build dependencies - it seems to only copy the files for the current chunk. in previous versions it iterated thru build-depends and content copying their files | 14:09 |
| ssam2 | radiofree: yeah sam-jetson-mason goes read-only every few days | 14:20 |
| ssam2 | perhaps because i resized the root btrfs partition too much. i got greedy! | 14:21 |
| radiofree | yes i think that's the cause of that | 14:21 |
| radiofree | i'll have to do a guide on how to move / to the ssd so you have more space for upgrades | 14:22 |
| radiofree | it's pretty easy | 14:22 |
| radiofree | i think it's pretty easy anyway.... | 14:22 |
| paulsherwood | rdale: the loop is in assembly... assembly.py:preinstall | 14:28 |
| paulsherwood | eg https://github.com/devcurmudgeon/ybd/blob/master/ybd/assembly.py#L84 | 14:28 |
| ssam2 | radiofree: (3) on http://wiki.baserock.org/guides/baserock-jetson/ mentions this already | 14:30 |
| rdale | ok, thanks i've got it. i said in my stand up notes this morning that i was waiting for a 'lightbulb' moment, and i think it just happened | 14:30 |
| paulsherwood | :) | 14:33 |
| *** bashrc has quit IRC | 14:41 | |
| *** bashrc has joined #baserock | 14:43 | |
| *** bashrc has quit IRC | 15:01 | |
| *** bashrc has joined #baserock | 15:06 | |
| radiofree | what exactly is "menu.c32"? | 15:11 |
| radiofree | oh ok, it is needed, for the menu that pops up in syslinux when there's > 1 systems to select | 15:12 |
| * pedroalvarez nods | 15:19 | |
| radiofree | get_partition_by_mountpoint() isn't a very useful function if the mountpoint doesn't actually exist, since it just returns any old thing | 15:48 |
| radiofree | actually it's probably me doing something wrong | 15:52 |
| radiofree | no, it's the function that is wrong | 16:03 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/extensions/pyfdisk.py#n464 | 16:03 |
| radiofree | only will ever return "/", i've fixed this | 16:03 |
| edcragg | radiofree: iirc that is supposed to return a Partition class | 16:07 |
| radiofree | edcragg: if i call it with "/boot" it will only ever return "/" | 16:12 |
| radiofree | which kind of defeats the purpose of having a function that returns by mountpoint? | 16:12 |
| radiofree | my patch was http://fpaste.org/309862/45261518/ | 16:13 |
| *** gtristan has quit IRC | 16:18 | |
| *** gtristan has joined #baserock | 16:28 | |
| franred | radiofree, gerrit? | 16:30 |
| edcragg | radiofree: yep, that works... thanks :) | 16:30 |
| radiofree | franred: i'll post it with the jetson/potentially any board with u-boot sysboot support patches | 16:31 |
| franred | radiofree, cool, thanks :) | 16:32 |
| *** bruce_ has quit IRC | 16:32 | |
| *** gtristan has quit IRC | 17:13 | |
| *** ssam2 has quit IRC | 17:24 | |
| *** edcragg has quit IRC | 17:31 | |
| *** gtristan has joined #baserock | 17:34 | |
| *** jonathanmaw has quit IRC | 18:04 | |
| *** bashrc has quit IRC | 18:05 | |
| pedroalvarez | radiofree: so, yeah, GDP is broken in x86, so my changes weren't causing any error.. | 18:28 |
| *** Lachlan1975 has quit IRC | 18:29 | |
| pedroalvarez | The changes gdp-hmi changes are enough to make it compile, and show something, but something is wrong. The launcher doesn't take the whole screen, and then the apps don't take the whole launcher... Idk.. | 18:29 |
| *** rdale has quit IRC | 18:30 | |
| radiofree | pedroalvarez: try launch weston with the drm backend | 18:43 |
| radiofree | if you have javiers kernel patches + mesa updates that should work in qemu now | 18:43 |
| *** toscalix has quit IRC | 20:45 | |
| *** edcragg has joined #baserock | 21:20 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!