| === zyga-xchat is now known as zyga | ||
| mgz | morning all | 09:12 |
|---|---|---|
| jelmer | yo yo yo | 09:13 |
| vila | helli hello | 09:13 |
| LarstiQ | moin | 11:42 |
| mgz | hey LarstiQ | 11:45 |
| LarstiQ | hey mgz :) | 11:49 |
| === zyga is now known as zyga-afk | ||
| === zyga-afk is now known as zyga | ||
| jelmer | mgz, vila: I'm taking a long lunch break today, and will work a bit into the evening | 13:10 |
| mgz | whoops | 13:35 |
| vila | jelmer: enjoy ! | 13:54 |
| 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:09 |
| === jam1 is now known as jam | ||
| vila | bzr version ? | 14:10 |
| vila | and running from sources or installer ? | 14:10 |
| jam | vila: sources, bzr.dev 6446 | 14:11 |
| jam | vila: http://paste.ubuntu.com/873049/ | 14:11 |
| 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:12 |
| vila | jam: reading the release-notes should also give you most of the details | 14:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| vila | hmm, weird, I don't remember specific fixes for xmlrpc... | 14:23 |
| vila | and your traceback is clearly in urllib | 14:24 |
| 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:25 | |
| 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:27 |
| 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:28 |
| 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 | 14:29 |
| abentley | mgz: Could you please review https://code.launchpad.net/~abentley/bzr-pqm/config-stack-fixes/+merge/96233 ? | 15:06 |
| santagada | anyone has an idea why I keep getting bzr killed when trying to branch lp:openobject-addons/6.1 on ec2? | 15:17 |
| santagada | it is a huge repo but I don't see why this happens | 15:18 |
| === mrevell_ is now known as mrevell | ||
| mgz | abentley: sure | 15:38 |
| mgz | santagada: OOM? | 15:42 |
| LarstiQ | santagada: do you have access to syslog? | 15:42 |
| LarstiQ | vila: heya, can you see if there might be backlogged mail for me from the list, or should I ask a sysadmin? | 15:43 |
| mgz | vila is in the set of admins so he should be able to see (jelmer and I are not though) | 15:45 |
| * LarstiQ nods | 15:48 | |
| vila | LarstiQ: let me look | 15:48 |
| 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:49 |
| LarstiQ | vila: I had to rush moving my vm, and had a missing mx for too long | 15:50 |
| vila | LarstiQ: nope, nothing from you | 15:51 |
| vila | errr, wait, all I can see there is mail blocked for unsubscribed people, that's not what you're after right ? | 15:52 |
| LarstiQ | vila: no, I'd be something like 'bounces' or undeliverable email | 15:53 |
| * LarstiQ tries to look at a mailman interface | 15:53 | |
| 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:55 |
| 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:56 |
| santagada | LarstiQ, yep | 15:57 |
| 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:58 |
| 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 | 15:59 |
| santagada | is bzr 2.5b6 better in this regard? | 16:00 |
| santagada | and the homepage of bzaar is pointing to the old blog... last post is about the move | 16:01 |
| mgz | santagada: depends how the memory is being used | 16:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| santagada | I know how ridiculous this sounds, but is just a read | 16:23 |
| 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:24 |
| 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:25 |
| wgz | it doesn't need to be *your* key | 16:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| vila | last time people did measurements bzr repos sizes were in the same range than git | 16:34 |
| santagada | vila, I will try to convert this one to git | 16:35 |
| vila | santagada: let us know the results | 16:38 |
| jelmer | abentley: sure, I can have a look oif mgz hasn't yet | 16:43 |
| abentley | jelmer: he got it, but thanks. | 16:43 |
| wgz | feel free to look anyway :) | 16:44 |
| santagada | vila, its going to take 40 minutes... but let's see | 16:47 |
| === deryck is now known as deryck[lunch] | ||
| wgz | jelmer, for bug 949093 | 17:10 |
| ubot5 | Launchpad bug 949093 in Bazaar "bazaar and subversion clashed" [Undecided,New] https://launchpad.net/bugs/949093 | 17:10 |
| 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:12 |
| 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:18 |
| === zyga is now known as zyga-food | ||
| 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:28 |
| santagada | wgz, vila: the process got killed again, was downloading the repo from bzr+ssh and used all the memory again | 17:37 |
| santagada | last line on the log "550.219 fetching: <SearchResult search:(set(['odo@openerp.com-20120307095627-8e2pf7955wg0jsoo']), ['hmo@tinyerp.com-20081124140910-4mqqv4qzd2rasrst', 'sma@tinyerp.com-20090924065200-nwj675pes1mole3d', 'fp@tinyerp.com-20090122131004-s39c7drfwbm8kggw', 'olt@tinyerp.com-20090126152714-d24104dspg0pyi8h', 'stephane@tinyerp.com-20090130202409-7dp454o39h2lo2pf', ...], 32283)>" | 17:38 |
| 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:45 |
| 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:46 |
| 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 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 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| santagada | mgz, bzr is downloading all revisions even if I say bzr branch -r 100 | 17:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 17:59 |
| santagada | mgz, https://bugs.launchpad.net/launchpad/+bug/493389 | 18:00 |
| ubot5 | Ubuntu bug 493389 in Launchpad itself "launchpad should offer anonymous bzr+ssh" [Undecided,Won't fix] | 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:00 |
| 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:01 |
| 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:02 |
| mgz | "whole repo in memory" isn't really a diagnosis, as that's not what bzr actually does | 18:03 |
| 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:04 |
| mgz | right, I started this VM half an hour ago, I really should start using it... | 18:05 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:14 | |
| === zyga-food is now known as zyga | ||
| 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:15 |
| 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:16 |
| 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:17 |
| 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 |
| === deryck[lunch] is now known as deryck | ||
| santagada | mgz, in practice what is the difference? | 18:18 |
| 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:19 |
| santagada | I will take stacked any day of the week for anything :) | 18:20 |
| santagada | mgz, I'm wondering, which would you use on the deployment use case? | 18:21 |
| 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:22 |
| mgz | rsync probably :) | 18:23 |
| 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:24 |
| mgz | I think there's been some past discussion on the mailing list on the topic. | 18:25 |
| mgz | I'll see what I can dig up once I get this build started | 18:27 |
| mgz | ...I just got email from github about checking ssh keys after the compromise | 18:29 |
| 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:37 |
| 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:38 |
| mgz | if you run `ssh -V` in your cygwin shell what do you get? | 18:40 |
| 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:41 |
| mgz | that's... not a good sign | 18:42 |
| 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:43 |
| 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:44 |
| 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:55 |
| 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:56 |
| 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:57 |
| mgz | well, as long as it works now :) | 18:59 |
| === yofel_ is now known as yofel | ||
| 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:34 |
| mgrandi | http://bpaste.net/show/24741/ | 21:35 |
| mgrandi | relevant info in the log file: http://bpaste.net/show/24742/ | 21:36 |
| mgrandi | i need to push this code to github >.> | 21:56 |
| poolie | hi all | 22:13 |
| mgrandi | hey | 22:17 |
| mgrandi | did you see what i posted? | 22:17 |
| mgrandi | above? | 22:17 |
| 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:25 |
| 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:26 |
| mgrandi | ok, any idea on how to get this work temporarily? >.> | 22:29 |
| * jelmer waves | 22:32 | |
| 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:33 |
| mgrandi | and now it seems to be repacking it when it doesn't need it, and then gets caught in the lock condition | 22:34 |
| 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:37 |
| mgrandi | i am trying with the latest version of bazaar and bzr-git | 22:38 |
| mgrandi | annnd same thing | 22:40 |
| spiv | Only if he wants to give the tute sober. | 22:42 |
| spiv | Oops, wrong window! | 22:42 |
| * 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:43 | |
| spiv | Short for "tutorial" | 22:44 |
| mgrandi | how is it short if tutorial has no e in it haha | 22:44 |
| 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:45 |
| 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:46 |
| mgrandi | i shall be here! | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!