=== zyga-xchat is now known as zyga [09:12] morning all [09:13] yo yo yo [09:13] helli hello [11:42] moin [11:45] hey LarstiQ [11:49] hey mgz :) === zyga is now known as zyga-afk === zyga-afk is now known as zyga [13:10] mgz, vila: I'm taking a long lunch break today, and will work a bit into the evening [13:35] whoops [13:54] jelmer: enjoy ! [14:09] vila, jelmer: I was just getting a traceback trying to do "bzr lp-open lp:...", is that a known bug? [14:09] (on Windows, it gives an error about the certificate path) === jam1 is now known as jam [14:10] bzr version ? [14:10] and running from sources or installer ? [14:11] vila: sources, bzr.dev 6446 [14:11] vila: http://paste.ubuntu.com/873049/ [14:12] it is true that /etc/ssl/... doesn't exist, but I wouldn't expect it to on Windows. [14:12] jam: try again with trunk [14:13] jam: reading the release-notes should also give you most of the details [14:14] vila: I was just getting a traceback, and wanted to check if it was known before reporting it. [14:14] 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] jam: k, several issues related to making urllib the default https implementation has been fixed [14:15] vila: well, I've never installed pycurl :) [14:15] but sure [14:15] I just upgraded and get: [14:15] $ bzr lp-open lp:~jameinel/u1db/c-pysync [14:15] Not checking SSL certificate for xmlrpc.launchpad.net: 443 [14:15] Opening https://code.launchpad.net/~jameinel/u1db/c-pysync in web browser [14:15] so it looks like it at least handles not finding the certificates [14:16] jam: well, my remark also implied actually verifying the ssl certs [14:16] 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] jam: i.e. now you know you're insecure :) [14:17] 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] I'm not particularly worried about a MitM collecting my xmlrpc lookups to launchpad to expand lp: urls. [14:18] jam: yup, lack of feedback from people running from sources on windows is to blame here I think ;) [14:19] vila: well, I'm running source all the time, just not doing "bzr up" quite as often. [14:19] and certainly, I rarely do "bzr lp-open lp:.." because usually "bzr lp-open" without arguments doesn what I want. [14:19] and *that* doesn't fail, because I have public_branch = http:... set. [14:19] haaaa [14:19] I was wondering how you could have avoided the issue for so long ;) [14:21] jam: it means even an heavy user like you doesn't use https that much... interesting [14:21] vila: I use https almost constantly [14:21] it wasn't failing for a lot of other cases [14:22] because we do client side resolution for most things [14:22] apparently lp-open doesn't [14:22] jam: well, you *don't* use it that much or you would have encounter the issue sooner [14:22] vila: well, I use https, I apparently don't use xmlrpc+https via bzr [14:23] hmm, weird, I don't remember specific fixes for xmlrpc... [14:24] and your traceback is clearly in urllib [14:25] vila: urllib as triggered from xmlrpc [14:25] but sure, I push/pull via ssh [14:25] so I don't use bzr transport over https for much of anything [14:25] * vila nods [14:27] 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] vila: well certainly whatever doesn't go to the smart server would end up going to plain http and not https [14:28] and has been that way for a *long* time [14:28] I do believe https://bazaar.launchpad.net exists now, *but* it only servers Loggerhead, and not the static files, IIRC [14:29] 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] but you can only go to http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/format [14:29] https://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/format is a 404 [15:06] mgz: Could you please review https://code.launchpad.net/~abentley/bzr-pqm/config-stack-fixes/+merge/96233 ? [15:17] anyone has an idea why I keep getting bzr killed when trying to branch lp:openobject-addons/6.1 on ec2? [15:18] it is a huge repo but I don't see why this happens === mrevell_ is now known as mrevell [15:38] abentley: sure [15:42] santagada: OOM? [15:42] santagada: do you have access to syslog? [15:43] vila: heya, can you see if there might be backlogged mail for me from the list, or should I ask a sysadmin? [15:45] 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] LarstiQ: let me look [15:49] . o O (Which of the 16423 unread mails in the 104 mailboxes will give me the right url...) [15:49] LarstiQ: bazaar ml ? [15:49] vila: https://lists.canonical.com/mailman/admin/bazaar ? [15:49] vila: ueah [15:50] vila: I had to rush moving my vm, and had a missing mx for too long [15:51] LarstiQ: nope, nothing from you [15:52] errr, wait, all I can see there is mail blocked for unsubscribed people, that's not what you're after right ? [15:53] vila: no, I'd be something like 'bounces' or undeliverable email [15:53] * LarstiQ tries to look at a mailman interface [15:55] mailman/admin/bazaar/members?letter=l says you're still subscribed [15:55] vila: ok, that's good [15:55] with your dyndns.org address that is [15:56] vila: yeah. That is why it went wrong ;). I'm trying to retire it this month [15:56] ok, so now just need to figure out why I can't even get a password reminder delivered [15:57] LarstiQ, yep [15:58] mgz, good catch [15:58] 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] good [15:58] vila: thanks! [15:59] yep, the oom is killing the process [15:59] is there any way to tell bzr to not use 600mb of ram? [15:59] bzr 2.4.1 here [16:00] is bzr 2.5b6 better in this regard? [16:01] and the homepage of bzaar is pointing to the old blog... last post is about the move [16:14] santagada: depends how the memory is being used [16:15] what's near the end of .bzr.log before getting killed? [16:15] mgz, where is this file? [16:15] `bzr version` will tell you [16:17] it's perfectly possible for a big branch to use 600mb and repacking tends to trigger maximum usage [16:17] mgz, 456.915 24 bytes left on the HTTP socket [16:17] mgz, so I guess... it was downloading it still [16:18] ...I did mean a bit more context, but yeah, that looks like it was during fetching [16:18] so, try branching not over http would be tip #1 [16:18] ... and jelmer and I fixed some issues with http buffering (but was it in 2.5 or on trunk...) [16:19] so, bzr+ssh if possible [16:19] * vila nods [16:19] bzr+ssh should behave better [16:19] but it shouldn't be doing that right? [16:19] 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] using 600mb of memory just for buffering a download [16:20] will try bzr+ssh [16:20] it's more the loading large chunk of pack, decompressing it, and trying to do stuff that adds up [16:20] I thought http was not a dumb transport anymore... [16:21] people have in the past had problems with a single mistaken revision, present in the repo but actually removed from the branch, [16:21] that was large but compressed really well, [16:22] to use ssh I need to do bzr launchpad-login, and that is it? [16:22] and http is dumb enough that if it happens to fetch that section of the packfile because parts either side are needed, [16:22] it basically dies to the decompression bomb [16:22] santagada: yup, provided you have a local ssh key registered with launchpad [16:22] isn't there a way to do anonymous ssh? [16:23] I know how ridiculous this sounds, but is just a read [16:24] 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] 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] I will create a fake launchpad login then [16:25] :) [16:25] could be called anonymous or download-only [16:27] it doesn't need to be *your* key [16:28] wgz, it needs to be a key that is attached to a user right? [16:28] 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] wgz, so I should create my own anonymous account for it to work :) [16:29] but for instance, ~bzr-pqm is not a human but has a key [16:30] sorry for being a d*ck. it's just that launchpad+bzr drives me mad from time to time [16:30] like, why the hell this repo is 500mb [16:31] that too is probably a good question :) [16:31] I would bet on a mixture of bzr repos being big and human error [16:32] there's certainly a culture of "just stick everything in svn" that some people have carried over to bzr [16:32] which... can be a bad thing [16:33] 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] last time people did measurements bzr repos sizes were in the same range than git [16:35] vila, I will try to convert this one to git [16:38] santagada: let us know the results [16:43] abentley: sure, I can have a look oif mgz hasn't yet [16:43] jelmer: he got it, but thanks. [16:44] feel free to look anyway :) [16:47] vila, its going to take 40 minutes... but let's see === deryck is now known as deryck[lunch] [17:10] jelmer, for bug 949093 [17:10] Launchpad bug 949093 in Bazaar "bazaar and subversion clashed" [Undecided,New] https://launchpad.net/bugs/949093 [17:12] wait, no, misread, he does have his own sv libraries installed [17:12] *snv [17:12] ... [17:12] *svn [17:12] so what we ship with the all-in-one installer is new enough? [17:18] hello [17:18] 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? === zyga is now known as zyga-food [17:28] 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] wgz, vila: the process got killed again, was downloading the repo from bzr+ssh and used all the memory again [17:38] last line on the log "550.219 fetching: " [17:45] any other ideas on how to make it not use ram when branching? [17:45] sledges: depending on what you want, the revid is an option [17:46] 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] santagada: try `bzr branch -r100 BRANCH` then `bzr pull -r200` and so on [17:47] mgz, I have kernel image "Ubuntu 2.6.38-1401.4-linaro-lt-mx5 2.6.38.8" 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] 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] mgz, what does bzr branch -r100 do? [17:48] gets the first 100 revs. [17:48] seriously that bzr don't do any file buffering and I will have to do it manually? [17:48] sledges: I'm not following... there are lots of reasons compiling the same stuff locally could break for you [17:49] 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] santagada: it mostly helps narrowing down specific problem revisions [17:50] 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] clearly doing it manually isn't more efficient that what bzr does internally [17:50] 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] sledges: you'd need to ask the linaro guys how they tag their kernels, I'm not involved with that [17:51] 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] 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] 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] what gets put in the binary is part of the build process, not the version control system though [17:52] nothing in bzr puts revision identifiers in other people's makefiles [17:53] thank you, that answers my question [17:53] 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] mgz, bzr is downloading all revisions even if I say bzr branch -r 100 [17:55] 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] 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] 100 revs at a time sucks, but does at least rule out certain classes of problem [17:57] mgz, I will do 10000 at a time now [17:57] ...dear god, how big is this thing? :) [17:57] 40k revs [17:57] ehehe [17:57] its a 500mb repo [17:58] most 500mb repos are just from people versioning huge trees [17:58] the emacs-class ones that actually have decades of history are rarer [17:58] this is the case [17:58] 150mb of text files of tons of different things [17:59] anyway, it's probably worth filing a bug/posting to the mailing list about your woes today anyway [17:59] and translated to tons of languages using the launchpad tool [17:59] it's good to have a record of what problems people run into in practice [17:59] mgz, I don't feel like doing that when you see bugs like this marked as wont fix [18:00] mgz, https://bugs.launchpad.net/launchpad/+bug/493389 [18:00] Ubuntu bug 493389 in Launchpad itself "launchpad should offer anonymous bzr+ssh" [Undecided,Won't fix] [18:00] 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] as fuzzy bugs are less useful than just shared knowledge about where problems still exist [18:01] I still think it is not a fuzzy bug, bzr seems to be loading the whole repo in memory while fetching [18:02] 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] "whole repo in memory" isn't really a diagnosis, as that's not what bzr actually does [18:04] it probably is holding the entire revision graph in memory, and caching chunks of packfile in uncompressed form [18:04] and probably some other things too [18:04] but that's not the same as just reading all the compressed bytes from disk and leaving them referenced [18:05] right, I started this VM half an hour ago, I really should start using it... [18:08] 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] the fetch phase should use very little ram [18:09] I was able to get it using bzr branch --stacked lp:openobject-addons/6.1 addons [18:09] ideally fetching would just splat bytes over the network [18:09] but only using bzr+ssh, using http it downloads the whole repo anyway [18:10] mgz, exactly [18:10] 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] which is generally the case for updates, and with launchpad and stacking, is alwasy true even for initial fetches [18:14] stacking on a remote branch is probably not what you want by the way. [18:14] --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 :) === zyga-food is now known as zyga [18:15] so --stacked is a big no on development. but for this particular case (deployment) its ok I guess [18:15] I will only be doing bzr update here [18:16] right, as would just export be perhaps? [18:16] but really bzr branch should be much smarter [18:16] rather than stacking, you could just do a checkout [18:16] which is a bit less voodoo. [18:16] mgz, what is the difference between branch --stacked and checkout? [18:16] though... both those want the 2.5 fixes on launchpad [18:17] mgz, I thought the only diff between branch and checkout is that checkout make the branch bounded to the parent [18:17] 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] 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] but as said, both have pretty bad network behaviour, some of which is fixed in bzr 2.5 === deryck[lunch] is now known as deryck [18:18] mgz, in practice what is the difference? [18:19] that description seemed to mean the same [18:19] a checkout has consistent semantics and performance [18:19] so it always look on the network, and stacked sometimes do? [18:19] (currently consistently bad with 2.4 though) [18:20] I will take stacked any day of the week for anything :) [18:21] mgz, I'm wondering, which would you use on the deployment use case? [18:22] 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] ^hm. [18:23] rsync probably :) [18:24] 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] I think there's been some past discussion on the mailing list on the topic. [18:27] I'll see what I can dig up once I get this build started [18:29] ...I just got email from github about checking ssh keys after the compromise [18:37] am failing to pin the keyword on the donkey [18:37] thought "deployment" would pull up relevent threads... what other terms are used... [18:38] 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] if you run `ssh -V` in your cygwin shell what do you get? [18:41] 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] there is no rebaseall command [18:42] that's... not a good sign [18:43] so, as a workaround you can probably move the compiled extention out of the way [18:43] but the cygwin packagers would probably appreciate a bug report [18:44] some cygwin internal machinery is going wrong with one of our (optional) compiled extensions basically [18:44] could be a bug with cygwin's C runtime or with cython, is unlikely to be a bzr issue though [18:55] 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] it works fine after that. I was just confused by assuming rebaseall was a bzr thing. [18:56] ah, so it's upgrade specific? [18:56] I guess they don't have a good mechanism for updating older packages when they change their core dll [18:57] 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] well, as long as it works now :) === yofel_ is now known as yofel [21:34] 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] http://bpaste.net/show/24741/ [21:36] relevant info in the log file: http://bpaste.net/show/24742/ [21:56] i need to push this code to github >.> [22:13] hi all [22:17] hey [22:17] did you see what i posted? [22:17] above? [22:25] mgrandi, no [22:25] 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] 14:35 mgrandi [22:25] http://bpaste.net/show/24741/ [22:25] 14:36 mgrandi [22:25] relevant info in the log file: http://bpaste.net/show/24742/ [22:26] hm [22:26] this sounds familiar [22:26] are you on 2.5.0? [22:26] i guess, then, file a bug against bzr-git [22:26] 2.5b6 [22:29] ok, any idea on how to get this work temporarily? >.> [22:32] * jelmer waves [22:33] bzr-git got updated recently, maybe i'll try updating that [22:33] mgrandi: hmm, that's odd [22:33] yeah. it worked fine before [22:33] but then i did it today, it repacked the repo [22:34] and now it seems to be repacking it when it doesn't need it, and then gets caught in the lock condition [22:37] mgrandi: I'll have a look when I get back home [22:37] ok. i should be around, ask if you have any questions [22:38] i am trying with the latest version of bazaar and bzr-git [22:40] annnd same thing [22:42] Only if he wants to give the tute sober. [22:42] Oops, wrong window! [22:43] * spiv quickly reads scrollback to see if that might have made accidental sense [22:43] no [22:43] you didnt =P [22:43] * jelmer tries to make sense of the word 'tute' [22:44] Short for "tutorial" [22:44] how is it short if tutorial has no e in it haha [22:45] Because the magic abbreviation pixies declare it to be so! [22:45] bah. got me there. [22:45] anyway, jelmer, any idea on how to get around this temporarily? i kinda want to push to github real fast >.> [22:46] mgrandi: I would try reverting back to an older version of bzr-git temporarily [22:46] I'll have a look at the issue when I get back home, which should be in anbout 30 min [22:46] ah [22:46] * jelmer is in a train with a attery that is about to run out [22:46] my laptop; [22:46] 's battery that is, not the train's [22:47] i shall be here!