[09:12] <mgz> morning all
[09:13] <jelmer> yo yo yo
[09:13] <vila> helli hello
[11:42] <LarstiQ> moin
[11:45] <mgz> hey LarstiQ
[11:49] <LarstiQ> hey mgz :)
[13:10] <jelmer> mgz, vila: I'm taking a long lunch break today, and will work a bit into the evening
[13:35] <mgz> whoops
[13:54] <vila> jelmer: enjoy !
[14:09] <jam1> vila, jelmer: I was just getting a traceback trying to do "bzr lp-open lp:...", is that a known bug?
[14:09] <jam1> (on Windows, it gives an error about the certificate path)
[14:10] <vila> bzr version ?
[14:10] <vila> and running from sources or installer ?
[14:11] <jam> vila: sources, bzr.dev 6446
[14:11] <jam> vila: http://paste.ubuntu.com/873049/
[14:12] <jam> it is true that /etc/ssl/... doesn't exist, but I wouldn't expect it to on Windows.
[14:12] <vila> jam: try again with trunk
[14:13] <vila> jam: reading the release-notes should also give you most of the details
[14:14] <jam> vila: I was just getting a traceback, and wanted to check if it was known before reporting it.
[14:14] <abentley> jelmer: I have a merge request for bzr-pqm up that fixes daily builds.  Do you mind reviewing it?  Should I be asking gz?  https://code.launchpad.net/~abentley/bzr-pqm/config-stack-fixes/+merge/96233
[14:15] <vila> jam: k, several issues related to making urllib the default https implementation has been fixed
[14:15] <jam> vila: well, I've never installed pycurl :)
[14:15] <jam> but sure
[14:15] <jam> I just upgraded and get:
[14:15] <jam> $ bzr lp-open lp:~jameinel/u1db/c-pysync
[14:15] <jam> Not checking SSL certificate for xmlrpc.launchpad.net: 443
[14:15] <jam> Opening https://code.launchpad.net/~jameinel/u1db/c-pysync in web browser
[14:15] <jam> so it looks like it at least handles not finding the certificates
[14:16] <vila> jam: well, my remark also implied actually verifying the ssl certs
[14:16] <vila> jam: I don't remember the details but I think it doesn't verify on windows if it can't find the ca certs
[14:17] <vila> jam: i.e. now you know you're insecure :)
[14:17] <jam> vila: sure. It never used to verify them, which if it can't, it can't. The bigger thing is not giving a huge traceback one way or another. :)
[14:18] <jam> I'm not particularly worried about a MitM collecting my xmlrpc lookups to launchpad to expand lp: urls.
[14:18] <vila> jam: yup, lack of feedback from people running from sources on windows is to blame here I think ;)
[14:19] <jam> vila: well, I'm running source all the time, just not doing "bzr up" quite as often.
[14:19] <jam> and certainly, I rarely do "bzr lp-open lp:.." because usually "bzr lp-open" without arguments doesn what I want.
[14:19] <jam> and *that* doesn't fail, because I have public_branch = http:... set.
[14:19] <vila> haaaa
[14:19] <vila> I was wondering how you could have avoided the issue for so long ;)
[14:21] <vila> jam: it means even an heavy user like you doesn't use https that much... interesting
[14:21] <jam> vila: I use https almost constantly
[14:21] <jam> it wasn't failing for a lot of other cases
[14:22] <jam> because we do client side resolution for most things
[14:22] <jam> apparently lp-open doesn't
[14:22] <vila> jam: well, you *don't* use it that much or you would have encounter the issue sooner
[14:22] <jam> vila: well, I use https, I apparently don't use xmlrpc+https via bzr
[14:23] <vila> hmm, weird, I don't remember specific fixes for xmlrpc...
[14:24] <vila> and  your traceback is clearly in urllib
[14:25] <jam> vila: urllib as triggered from xmlrpc
[14:25] <jam> but sure, I push/pull via ssh
[14:25] <jam> so I don't use bzr transport over https for much of anything
[14:25]  * vila nods
[14:27] <vila> exactly why I found it interesting, most of the traffic for lp goes to the smart server these days so https is less used than I thought
[14:28] <jam> vila: well certainly whatever doesn't go to the smart server would end up going to plain http and not https
[14:28] <jam> and has been that way for a *long* time
[14:28] <jam> I do believe https://bazaar.launchpad.net exists now, *but* it only servers Loggerhead, and not the static files, IIRC
[14:29] <jam> you can go to: https://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes or http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes and get the same content
[14:29] <jam> but you can only go to http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/format
[14:29] <jam> https://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/format is a 404
[15:06] <abentley> mgz: Could you please review https://code.launchpad.net/~abentley/bzr-pqm/config-stack-fixes/+merge/96233 ?
[15:17] <santagada> anyone has an idea why I keep getting bzr killed when trying to branch lp:openobject-addons/6.1 on ec2?
[15:18] <santagada> it is a huge repo but I don't see why this happens
[15:38] <mgz> abentley: sure
[15:42] <mgz> santagada: OOM?
[15:42] <LarstiQ> santagada: do you have access to syslog?
[15:43] <LarstiQ> vila: heya, can you see if there might be backlogged mail for me from the list, or should I ask a sysadmin?
[15:45] <mgz> vila is in the set of admins so he should be able to see (jelmer and I are not though)
[15:48]  * LarstiQ nods
[15:48] <vila> LarstiQ: let me look
[15:49] <vila> . o O (Which of the 16423 unread mails in the 104 mailboxes will give me the right url...)
[15:49] <vila> LarstiQ: bazaar ml ?
[15:49] <LarstiQ> vila: https://lists.canonical.com/mailman/admin/bazaar ?
[15:49] <LarstiQ> vila: ueah
[15:50] <LarstiQ> vila: I had to rush moving my vm, and had a missing mx for too long
[15:51] <vila> LarstiQ: nope, nothing from you
[15:52] <vila> errr, wait, all I can see there is mail blocked for unsubscribed people, that's not what you're after right ?
[15:53] <LarstiQ> vila: no, I'd be something like 'bounces' or undeliverable email
[15:53]  * LarstiQ tries to look at a mailman interface
[15:55] <vila> mailman/admin/bazaar/members?letter=l says you're still subscribed
[15:55] <LarstiQ> vila: ok, that's good
[15:55] <vila> with your dyndns.org address that is
[15:56] <LarstiQ> vila: yeah. That is why it went wrong ;). I'm trying to retire it this month
[15:56] <LarstiQ> ok, so now just need to figure out why I can't even get a password reminder delivered
[15:57] <santagada> LarstiQ, yep
[15:58] <santagada> mgz, good catch
[15:58] <vila> and the bounce settings seems sane: Mailman notify you, the list owner, when bounces cause a member's subscription to be disabled? (Yes) and Mailman notify you, the list owner, when bounces cause a member to be unsubscribed? (Yes)
[15:58] <LarstiQ> good
[15:58] <LarstiQ> vila: thanks!
[15:59] <santagada> yep, the oom is killing the process
[15:59] <santagada> is there any way to tell bzr to not use 600mb of ram?
[15:59] <santagada> bzr 2.4.1 here
[16:00] <santagada> is bzr 2.5b6 better in this regard?
[16:01] <santagada> and the homepage of bzaar is pointing to the old blog... last post is about the move
[16:14] <mgz> santagada: depends how the memory is being used
[16:15] <mgz> what's near the end of .bzr.log before getting killed?
[16:15] <santagada> mgz, where is this file?
[16:15] <mgz> `bzr version` will tell you
[16:17] <mgz> it's perfectly possible for a big branch to use 600mb and repacking tends to trigger maximum usage
[16:17] <santagada> mgz,  456.915  24 bytes left on the HTTP socket
[16:17] <santagada> mgz, so I guess... it was downloading it still
[16:18] <mgz> ...I did mean a bit more context, but yeah, that looks like it was during fetching
[16:18] <mgz> so, try branching not over http would be tip #1
[16:18] <vila> ... and jelmer and I fixed some issues with http buffering (but was it in 2.5 or on trunk...)
[16:19] <mgz> so, bzr+ssh if possible
[16:19]  * vila nods
[16:19] <vila> bzr+ssh should behave better
[16:19] <santagada> but it shouldn't be doing that right?
[16:19] <mgz> the way dumb transports work though, you still end up loading large chunks of remote packfiles and doing operations, which is bad for really big branches
[16:19] <santagada> using 600mb of memory just for buffering a download
[16:20] <santagada> will try bzr+ssh
[16:20] <mgz> it's more the loading large chunk of pack, decompressing it, and trying to do stuff that adds up
[16:20] <santagada> I thought http was not a dumb transport anymore...
[16:21] <mgz> people have in the past had problems with a single mistaken revision, present in the repo but actually removed from the branch,
[16:21] <mgz> that was large but compressed really well,
[16:22] <santagada> to use ssh I need to do bzr launchpad-login, and that is it?
[16:22] <mgz> and http is dumb enough that if it happens to fetch that section of the packfile because parts either side are needed,
[16:22] <mgz> it basically dies to the decompression bomb
[16:22] <mgz> santagada: yup, provided you have a local ssh key registered with launchpad
[16:22] <santagada> isn't there a way to do anonymous ssh?
[16:23] <santagada> I know how ridiculous this sounds, but is just a read
[16:24] <mgz> making people have ssh setup is a pain, particularly for non devs, but it then makes a bunch of other sticky problems just work
[16:25] <santagada> mgz, it is a server machine that is only downloading code... so having a ssh key there is kind of a security problem
[16:25] <santagada> I will create a fake launchpad login then
[16:25] <santagada> :)
[16:25] <santagada> could be called anonymous or download-only
[16:27] <wgz> it doesn't need to be *your* key
[16:28] <santagada> wgz, it needs to be a key that is attached to a user right?
[16:28] <wgz> though, the account you register it with does then give write access to that key for all the projects the account has access to
[16:29] <santagada> wgz, so I should create my own anonymous account for it to work :)
[16:29] <wgz> but for instance, ~bzr-pqm is not a human but has a key
[16:30] <santagada> sorry for being a d*ck. it's just that launchpad+bzr drives me mad from time to time
[16:30] <santagada> like, why the hell this repo is 500mb
[16:31] <wgz> that too is probably a good question :)
[16:31] <santagada> I would bet on a mixture of bzr repos being big and human error
[16:32] <wgz> there's certainly a culture of "just stick everything in svn" that some people have carried over to bzr
[16:32] <wgz> which... can be a bad thing
[16:33] <santagada> well the repo has 150 mb of text in it. still I don't think the repo for some years should be 500mb
[16:34] <vila> last time people did measurements bzr repos sizes were in the same range than git
[16:35] <santagada> vila, I will try to convert this one to git
[16:38] <vila> santagada: let us know the results
[16:43] <jelmer> abentley: sure, I can have a look oif mgz hasn't yet
[16:43] <abentley> jelmer: he got it, but thanks.
[16:44] <wgz> feel free to look anyway :)
[16:47] <santagada> vila, its going to take 40 minutes... but let's see
[17:10] <wgz> jelmer, for bug 949093
[17:12] <wgz> wait, no, misread, he does have his own sv libraries installed
[17:12] <wgz> *snv
[17:12] <wgz> ...
[17:12] <wgz> *svn
[17:12] <wgz> so what we ship with the all-in-one installer is new enough?
[17:18] <sledges> hello
[17:18] <sledges> is there an equivalent of a git commit hash in launchpad, so that e.g. linaro kernel binaries would contain a string somewhere in a binary pointing to an exact state of the source it was compiled from?
[17:28] <santagada> isn't bzr+ssh supposed to be faster? It is both slower in terms of speed on launchpad (10x slower) and is transfering the same ammount of data
[17:37] <santagada> wgz, vila: the process got killed again, was downloading the repo from bzr+ssh and used all the memory again
[17:38] <santagada> last line on the log "550.219  fetching: <SearchResult search:(set(['odo@openerp.com-20120307095627-8e2pf7955wg0jsoo']<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>...], 32283)>"
[17:45] <santagada> any other ideas on how to make it not use <repo size> ram when branching?
[17:45] <mgz> sledges: depending on what you want, the revid is an option
[17:46] <mgz> santagada: there are various cases where bzr+ssh isn't quicker, mostly because both sides do CPU work when splatting bytes is sometimes enough
[17:47] <mgz> santagada: try `bzr branch -r100 BRANCH` then `bzr pull -r200` and so on
[17:47] <sledges> mgz, I have kernel image "Ubuntu 2.6.38-1401.4-linaro-lt-mx5 <IP_ADDRESS>" from official ubuntu-11.10-preinstalled-desktop-armel+mx5.img.gz booting fine on i.MX53QSB, but its source compiled on my HOST halt after "Uncompressing kernel..." (same .config, and only minor gcc version difference) ? (source took from:  http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/linux-linaro-lt-mx5/precise/revision/3
[17:47] <santagada> mgz, yep bzr+ssh seems to be transfering the same ammount of data, and ssh in launchpad ssems to be 10x slower than http
[17:47] <santagada> mgz, what does bzr branch -r100 do?
[17:48] <mgz> gets the first 100 revs.
[17:48] <santagada> seriously that bzr don't do any file buffering and I will have to do it manually?
[17:48] <mgz> sledges: I'm not following... there are lots of reasons compiling the same stuff locally could break for you
[17:49] <mgz> are you trying to submit a bug report with enough details for someone else to repo, or change the current build process in linaro?
[17:50] <mgz> santagada: it mostly helps narrowing down specific problem revisions
[17:50] <sledges> mgz, I'm not asking you to fix my build problems, I am explaining why I need the revid you now mentioned; now how can I fish it out from the only binary I have..
[17:50] <mgz> clearly doing it manually isn't more efficient that what bzr does internally
[17:50] <sledges> in #linaro I've been told that launchpad source state revision might not be the one that was put into ubuntu preinstalled img
[17:50] <mgz> sledges: you'd need to ask the linaro guys how they tag their kernels, I'm not involved with that
[17:51] <santagada> mgz, bzr is using ram to fetch the repository... I don't think it is one particular revision that makes it use 600mb of ram
[17:51] <mgz> unless their build process explicitly embeds some unique indentifier, there's no reason to suspect you could pull one out of their binary
[17:52] <sledges> mgz, Git has the hash tag for every commit, I came here to ask you whether there is an equivalent (see my original question)
[17:52] <mgz> what gets put in the binary is part of the build process, not the version control system though
[17:52] <mgz> nothing in bzr puts revision identifiers in other people's makefiles
[17:53] <sledges> thank you, that answers my question
[17:53] <mgz> it may well be done as a matter of course, but it's not something I'm aware of how to retrieve for projects I don't know the details of
[17:54] <santagada> mgz, bzr is downloading all revisions even if I say bzr branch -r 100
[17:55] <santagada> ahh it was downloading everything because I went back to use http. now on ssh it did branch only the first n revs
[17:56] <mgz> santagada: without actually debugging it in detail, all I can do is offer suggestions, there are methods of getting exactly what is held in memory, but the reaper gets in the way of that
[17:56] <mgz> 100 revs at a time sucks, but does at least rule out certain classes of problem
[17:57] <santagada> mgz, I will do 10000 at a time now
[17:57] <mgz> ...dear god, how big is this thing? :)
[17:57] <santagada> 40k revs
[17:57] <mgz> ehehe
[17:57] <santagada> its a 500mb repo
[17:58] <mgz> most 500mb repos are just from people versioning huge trees
[17:58] <mgz> the emacs-class ones that actually have decades of history are rarer
[17:58] <santagada> this is the case
[17:58] <santagada> 150mb of text files of tons of different things
[17:59] <mgz> anyway, it's probably worth filing a bug/posting to the mailing list about your woes today anyway
[17:59] <santagada> and translated to tons of languages using the launchpad tool
[17:59] <mgz> it's good to have a record of what problems people run into in practice
[17:59] <santagada> mgz, I don't feel like doing that when you see bugs like this marked as wont fix
[18:00] <santagada> mgz, https://bugs.launchpad.net/launchpad/+bug/493389
[18:00] <mgz> well, won't-fix would not be the case here, but a short post about with the rev stats and what you tried and how it failed is probably of more use
[18:01] <mgz> as fuzzy bugs are less useful than just shared knowledge about where problems still exist
[18:01] <santagada> I still think it is not a fuzzy bug, bzr seems to be loading the whole repo in memory while fetching
[18:02] <mgz> I can believe we have room to improve general memory usage for trees as deep as yours still, and people may have more insight
[18:03] <mgz> "whole repo in memory" isn't really a diagnosis, as that's not what bzr actually does
[18:04] <mgz> it probably is holding the entire revision graph in memory, and caching chunks of packfile in uncompressed form
[18:04] <mgz> and probably some other things too
[18:04] <mgz> but that's not the same as just reading all the compressed bytes from disk and leaving them referenced
[18:05] <mgz> right, I started this VM half an hour ago, I really should start using it...
[18:08] <santagada> mgz, so why doesn't it first download the whole repo to .bzr and only then start building the revision graph/doing stuff with the data?
[18:08] <santagada> the fetch phase should use very little ram
[18:09] <santagada> I was able to get it using bzr branch --stacked lp:openobject-addons/6.1 addons
[18:09] <mgz> ideally fetching would just splat bytes over the network
[18:09] <santagada> but only using bzr+ssh, using http it downloads the whole repo anyway
[18:10] <santagada> mgz, exactly
[18:10] <mgz> the reason it doesn't is it's doing lots of work for the other common case, where you only want a subset of revisions from the repo
[18:10] <mgz> which is generally the case for updates, and with launchpad and stacking, is alwasy true even for initial fetches
[18:14] <mgz> stacking on a remote branch is probably not what you want by the way.
[18:14] <santagada> --stacked proved to be a really bad idea when you need to do anything with the repo later as everything is done on the network
[18:14]  * mgz won that race here :)
[18:15] <santagada> so --stacked is a big no on development. but for this particular case (deployment) its ok I guess
[18:15] <santagada> I will only be doing bzr update here
[18:16] <mgz> right, as would just export be perhaps?
[18:16] <santagada> but really bzr branch should be much smarter
[18:16] <mgz> rather than stacking, you could just do a checkout
[18:16] <mgz> which is a bit less voodoo.
[18:16] <santagada> mgz, what is the difference between branch --stacked and checkout?
[18:16] <mgz> though... both those want the 2.5 fixes on launchpad
[18:17] <santagada> mgz, I thought the only diff between branch and checkout is that checkout make the branch bounded to the parent
[18:17] <mgz> a (lightweight) checkout knows the branch lives somewhere else, a stacked branch just falls back to a different location if it can't find a revision locally
[18:18] <santagada> export would not work because we would generally want a faster deploy, and doing a pull+update is usually faster than a whole repo copy
[18:18] <mgz> but as said, both have pretty bad network behaviour, some of which is fixed in bzr 2.5
[18:18] <santagada> mgz, in practice what is the difference?
[18:19] <santagada> that description seemed to mean the same
[18:19] <mgz> a checkout has consistent semantics and performance
[18:19] <santagada> so it always look on the network, and stacked sometimes do?
[18:19] <mgz> (currently consistently bad with 2.4 though)
[18:20] <santagada> I will take stacked any day of the week for anything :)
[18:21] <santagada> mgz, I'm wondering, which would you use on the deployment use case?
[18:22] <mgz> for your case you probably do just want a branch copy, so maybe stacked is sort-of-mostly okay, it's historically been buggier though
[18:22] <mgz> ^hm.
[18:23] <mgz> rsync probably :)
[18:24] <mgz> I'm not sure, there are mixed priorities on deploying from vcs and the things I've needed to do it for have been small enough that it mostly hasn't mattered.
[18:25] <mgz> I think there's been some past discussion on the mailing list on the topic.
[18:27] <mgz> I'll see what I can dig up once I get this build started
[18:29] <mgz> ...I just got email from github about checking ssh keys after the compromise
[18:37] <mgz> am failing to pin the keyword on the donkey
[18:37] <mgz> thought "deployment" would pull up relevent threads... what other terms are used...
[18:38] <kkrev> I ran cygwin update and am getting this all the sudden: ERROR: Don't know how to handle SSH connections. Please set BZR_SSH environment variable.
[18:40] <mgz> if you run `ssh -V` in your cygwin shell what do you get?
[18:41] <kkrev> Actually I think the issue is something else. I get that on pull, but branching from the ssh hosted repository works fine. This is the pull error: 8 [main] python2.6 1412 child_info_fork::abort: unable to remap _chk_map_pyx.dll to same address as parent (00B70000) - try running rebaseall
[18:41] <kkrev> there is no rebaseall command
[18:42] <mgz> that's... not a good sign
[18:43] <mgz> so, as a workaround you can probably move the compiled extention out of the way
[18:43] <mgz> but the cygwin packagers would probably appreciate a bug report
[18:44] <mgz> some cygwin internal machinery is going wrong with one of our (optional) compiled extensions basically
[18:44] <mgz> could be a bug with cygwin's C runtime or with cython, is unlikely to be a bzr issue though
[18:55] <kkrev> the error wasn't lying about running 'rebaseall'. that's a cygwin thing. http://www.heikkitoivonen.net/blog/2008/11/26/cygwin-upgrades-and-rebaseall/
[18:56] <kkrev> it works fine after that. I was just confused by assuming rebaseall was a bzr thing.
[18:56] <mgz> ah, so it's upgrade specific?
[18:56] <mgz> I guess they don't have a good mechanism for updating older packages when they change their core dll
[18:57] <kkrev> right. I had to reboot the machine and run that rebaseall command. no idea exactly what it does, but I assume it updates some dll registry.
[18:59] <mgz> well, as long as it works now :)
[21:34] <mgrandi> i'm having trouble with locks and pushing to github, its worked before, but now it seems to be creating a lock and then saying its locked by someone else, when that person is myself
[21:35] <mgrandi> http://bpaste.net/show/24741/
[21:36] <mgrandi> relevant info in the log file: http://bpaste.net/show/24742/
[21:56] <mgrandi> i need to push this code to github >.>
[22:13] <poolie> hi all
[22:17] <mgrandi> hey
[22:17] <mgrandi> did you see what i posted?
[22:17] <mgrandi> above?
[22:25] <poolie> mgrandi, no
[22:25] <mgrandi> i'm having trouble with locks and pushing to github, its worked before, but now it seems to be creating a lock and then saying its locked by someone else, when that person is myself
[22:25] <mgrandi> 14:35 mgrandi
[22:25] <mgrandi> http://bpaste.net/show/24741/
[22:25] <mgrandi> 14:36 mgrandi
[22:25] <mgrandi> relevant info in the log file: http://bpaste.net/show/24742/
[22:26] <poolie> hm
[22:26] <poolie> this sounds familiar
[22:26] <poolie> are you on 2.5.0?
[22:26] <poolie> i guess, then, file a bug against bzr-git
[22:26] <mgrandi> 2.5b6
[22:29] <mgrandi> ok, any idea on how to get this work temporarily? >.>
[22:32]  * jelmer waves
[22:33] <mgrandi> bzr-git got updated recently, maybe i'll try updating that
[22:33] <jelmer> mgrandi: hmm, that's odd
[22:33] <mgrandi> yeah. it worked fine before
[22:33] <mgrandi> but then i did it today, it repacked the repo
[22:34] <mgrandi> and now it seems to be repacking it when it doesn't need it, and then gets caught in the lock condition
[22:37] <jelmer> mgrandi: I'll have a look when I get back home
[22:37] <mgrandi> ok. i should be around, ask if you have any questions
[22:38] <mgrandi> i am trying with the latest version of bazaar and bzr-git
[22:40] <mgrandi> annnd same thing
[22:42] <spiv> Only if he wants to give the tute sober.
[22:42] <spiv> Oops, wrong window!
[22:43]  * spiv quickly reads scrollback to see if that might have made accidental sense
[22:43] <mgrandi> no
[22:43] <mgrandi> you didnt =P
[22:43]  * jelmer tries to make sense of the word 'tute'
[22:44] <spiv> Short for "tutorial"
[22:44] <mgrandi> how is it short if tutorial has no e in it haha
[22:45] <spiv> Because the magic abbreviation pixies declare it to be so!
[22:45] <mgrandi> bah. got me there.
[22:45] <mgrandi> anyway, jelmer, any idea on how to get around this temporarily? i kinda want to push to github real fast >.>
[22:46] <jelmer> mgrandi: I would try reverting back to an older version of bzr-git temporarily
[22:46] <jelmer> I'll have a look at the issue when I get back home, which should be in anbout 30 min
[22:46] <mgrandi> ah
[22:46]  * jelmer is in a train with a attery that is about to run out
[22:46] <jelmer> my laptop;
[22:46] <jelmer> 's battery that is, not the train's
[22:47] <mgrandi> i shall be here!