| magcius | Is there any way to undo a commit? | 02:15 |
|---|---|---|
| lifeless | bzr uncommit | 02:19 |
| magcius | lifeless: thanks | 02:40 |
| magcius | uh | 02:55 |
| magcius | 1) are there any loggerhead maintainers in here? (or should I ask in #lp or #lp-dev) | 02:55 |
| magcius | I filed about 2-3 bugs and they're still filed "NEW" | 02:56 |
| lifeless | loggerhead is a little light on maintainers at the moment | 02:56 |
| magcius | ok | 02:56 |
| lifeless | here is as good as any place | 02:56 |
| magcius | uh, I also filed a bug on LP and a bug on bzr. | 02:56 |
| lifeless | how long ago ? | 02:57 |
| magcius | uh | 02:57 |
| magcius | lifeless: April | 02:58 |
| lifeless | and they're still new ? thats unusual | 02:58 |
| lifeless | url? | 02:58 |
| magcius | lifeless: er whoops, thought it was new | 02:58 |
| magcius | lifeless: er, the bzr one has had progress | 02:59 |
| magcius | lifeless: the LP one I believe is "New" | 02:59 |
| lifeless | do you know the number? | 02:59 |
| magcius | lifeless: er, it's Triaged. There's been a tag, but that's it | 02:59 |
| lifeless | there are lots of lp bugs :) | 02:59 |
| magcius | https://bugs.launchpad.net/launchpad-registry/+bug/569356 | 02:59 |
| ubot5 | Launchpad bug 569356 in Launchpad Registry "The download background "sliding door" needs more width. (affected: 1, heat: 3)" [Low,Triaged] | 02:59 |
| magcius | This one seems a very, very easy one to fix | 03:00 |
| magcius | But yeah, the two Loggerhead ones are the ones that I hate the most | 03:00 |
| lifeless | I wish loggerhead had more devs | 03:03 |
| lifeless | :) | 03:03 |
| thumper | lifeless: me too | 03:22 |
| lifeless | thumper: do you have any ideas about where we can find them? | 03:23 |
| lifeless | thumper: could lp-code start owning it again, perhaps? | 03:24 |
| thumper | lifeless: while I'd love to, we don't have any development time to invest | 03:24 |
| thumper | lifeless: we're already letting things slip | 03:24 |
| lifeless | thumper: is that because your team size changed, or your accepted too much work, or something else? | 03:28 |
| thumper | lifeless: primarily team size | 03:29 |
| lifeless | sounds like something that should, in principle, be fixed. | 03:29 |
| lifeless | eventually. | 03:29 |
| thumper | maybe | 03:32 |
| thumper | parly it requires someone who cares about the project | 03:33 |
| lifeless | definitely | 03:33 |
| lifeless | I guess I see the lp-code team as that in the sense that its deployed in LP :) | 03:33 |
| lifeless | maybe thats not enough. | 03:33 |
| thumper | no it is not enough | 03:34 |
| thumper | we don't really use loggerhead | 03:34 |
| thumper | sure, we have it deployed on LP | 03:35 |
| thumper | but I really don't use it that often | 03:35 |
| willmarshall | Git user's question about BZR: I want to branch my current branch, then commit that new branch back to my server while I work on an experimental feature | 05:11 |
| willmarshall | How would I do this? | 05:11 |
| lifeless | bzr branch . ../new; cd new; bzr push $server_url | 05:14 |
| lifeless | or just bzr push $server_url, and then keep working | 05:14 |
| lifeless | if you want to let trunk move on for a while, you might instead do | 05:14 |
| lifeless | bzr branch . ../new; $work_in_new_for_a_while | 05:14 |
| lifeless | bzr merge ../new; bzr commit -m "merge in some progress"; bzr push | 05:15 |
| willmarshall | That worked! Thanks :) | 05:16 |
| lifeless | anytime | 05:16 |
| lifeless | jelmer: ping | 05:28 |
| BlindWolf8 | Hello? | 06:32 |
| lifeless | hi | 06:34 |
| BlindWolf8 | Hey lifeless | 06:46 |
| BlindWolf8 | I wasn't paying attention to the chat. You still here? | 06:47 |
| lifeless | passing through from time to time | 06:47 |
| lifeless | its roughly dinnertime here | 06:47 |
| BlindWolf8 | Gothca. About 1:45 AM here (US EST/EDT) | 06:48 |
| BlindWolf8 | I do have a quick question for you if you have a moment. | 06:48 |
| lifeless | sure; in general just ask your questions | 06:48 |
| lifeless | in this medium, someone will usually answer eventually | 06:49 |
| BlindWolf8 | Would I easily be able to change my repository style once it's made? | 06:49 |
| lifeless | what do you mean by style ? | 06:49 |
| BlindWolf8 | feature branch, colocated, shared repo, etc. | 06:50 |
| lifeless | sure | 06:50 |
| lifeless | the only thing that isn't easy to change is the /format/ - which you shouldn't need to be concerned with at this point | 06:51 |
| BlindWolf8 | If I need to, I'm confused on how to do this as... | 06:51 |
| lifeless | so just go ahead and play | 06:51 |
| BlindWolf8 | 1) I forgot what I chose when setting it up... | 06:51 |
| BlindWolf8 | ...and 2) not files are listed on the seerver. I am not sure if this is normal. | 06:51 |
| lifeless | bzr branches and repositories store their files in .bzr/ | 06:51 |
| BlindWolf8 | *no files | 06:51 |
| BlindWolf8 | yeah, I looked in the .bzr folder on the server | 06:52 |
| lifeless | its a form of database. So your source code is only present on your workstation | 06:52 |
| lifeless | this is normal | 06:52 |
| BlindWolf8 | no files are readable...I'm assuming they're all compressed/packed | 06:52 |
| BlindWolf8 | ah, OK. | 06:52 |
| BlindWolf8 | what would I do in a case in which I wanted the files to be accessible? | 06:52 |
| lifeless | well it depends on why | 06:53 |
| lifeless | for instance | 06:53 |
| lifeless | if you want to deploy to a web server; use the bzr-upload plugin | 06:53 |
| lifeless | if you want to browse the files and history with a web browser, use loggerhead | 06:53 |
| BlindWolf8 | ah, I'm assuming that would update the bzr db and upload the file as well? | 06:53 |
| lifeless | bzr-upload works without the .bzr database | 06:54 |
| lifeless | for security | 06:54 |
| lifeless | it uses a very small record of whats been uploaded so that it can only upload changed files | 06:54 |
| BlindWolf8 | right, but where would it keep revisions? | 06:54 |
| lifeless | bzr-upload ? it has them on your source branch, wherever that is - normally your workstation. | 06:55 |
| BlindWolf8 | ah, OK, so it won't make a .bzr dir on the server for security reasosn, only locally...OK, that makes sense | 06:55 |
| lifeless | collaborating on your source code, and deploying it to a webserver are very different tasks | 06:56 |
| BlindWolf8 | agreed | 06:56 |
| lifeless | does this help? I realise I haven't answered the direct question :) | 06:56 |
| BlindWolf8 | yeah, it helps...I was just shocked as I didn't see any files on the server...just a bit concerned about things being compressed | 06:57 |
| BlindWolf8 | figured that I would need to do something different for webdev, but the doc explains it about 80%...I may have missed something | 06:58 |
| lifeless | if you ssh into your server | 06:58 |
| lifeless | and run 'bzr log -p' you'll see all your patches going back to the start of your history | 06:58 |
| lifeless | (run that in a branch on the server) | 06:58 |
| BlindWolf8 | Also, I'm assuming that all revisions are copied to clients as well? | 06:58 |
| BlindWolf8 | in their .bzr dirs? | 06:59 |
| lifeless | when you do 'bzr branch server localdir' , it copies all the history by default | 06:59 |
| BlindWolf8 | My main concern was that if the server got hacked/fubared, I'd be SOL | 06:59 |
| lifeless | there are options that you can pass to copy less than everything (--stacked, specifically) - but its not the default. | 06:59 |
| BlindWolf8 | I do Pull via the GUI, so I'm assuming it gets all the revs | 06:59 |
| lifeless | yes | 07:00 |
| BlindWolf8 | Good, everyone's up to date and can do a restore if needed | 07:00 |
| lifeless | (unless you made the branch stacked - but I don't think bzr explorer has an option to do that) | 07:00 |
| BlindWolf8 | and the restore will rebuild all the revisions...sweet | 07:00 |
| BlindWolf8 | so Bazaar == RAID, lol | 07:00 |
| fullermd | RAIR. Blood RAIR. | 07:01 |
| * fullermd licks his lips. | 07:01 | |
| BlindWolf8 | 0_\ | 07:01 |
| BlindWolf8 | Anyway, thanks again lifeless | 07:02 |
| BlindWolf8 | I'd be happy to write some docs/tutorials | 07:02 |
| BlindWolf8 | Still here? | 07:04 |
| lifeless | yes | 07:09 |
| BlindWolf8 | OK. When I was having my teammate setup bzr, I had him pull our branch from the repo I setup. | 07:10 |
| BlindWolf8 | bzr prompted him to turn the dir he was putting the files into a repo. I told him to select No, as there seems to be issues with doing that. | 07:10 |
| BlindWolf8 | Why would you want to turn the local dir into a shared repo? | 07:11 |
| BlindWolf8 | Whoops, back. | 07:14 |
| vila | hi all ! | 07:15 |
| BlindWolf8 | hey vila | 07:15 |
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it | ||
| lifeless | BlindWolf8: 'shared' in shared repo refers to 'between branches' not 'between users' | 07:16 |
| lifeless | BlindWolf8: so you want that to make switching between branches fast and efficient | 07:16 |
| vila | BlindWolf8: The repo is where revisions are stored. Once you start having multiple branche of the same project, using a shared repo means all common revisions are stored only once | 07:16 |
| BlindWolf8 | in a common .bzr dir? | 07:17 |
| vila | BlindWolf8: yes | 07:17 |
| lifeless | one .bzr dir for the history, one .bzr per branch, but without history | 07:17 |
| === radoe_ is now known as radoe | ||
| lifeless | the branch ones get their history from the repository .bzr dir | 07:18 |
| BlindWolf8 | then what does each .bzr dir store for each branch? | 07:18 |
| lifeless | the branch configuration, the revision id of the branch's most recent commit and the tags for the branch | 07:19 |
| BlindWolf8 | Before, you mentioned that if I wanted to do webdev, it wouldn't upload the revsision history. What if I wanted to regardless? | 07:21 |
| BlindWolf8 | vila: you've been credited, btw. | 07:22 |
| vila | BlindWolf8: Me ? Credited ? Argh, what did I do wrong again ? :) | 07:23 |
| BlindWolf8 | lol | 07:23 |
| vila | BlindWolf8: bzr-upload aim is to maintain a remote working tree *without* its history, if you want to update a remote working tree whenever its history change, you want the bzr-push-and-update plugin (which requires bzr on the server and an ssh access IIRC) | 07:24 |
| vila | the two plugins work from a different set of constraints and address different needs | 07:25 |
| BlindWolf8 | Thanks for that info. All of this is very helpful. | 07:26 |
| BlindWolf8 | By the way, why would someone want a checkout when they can just bind a branch? | 07:30 |
| vila | BlindWolf8: Don't summon fullermd .... | 07:32 |
| vila | BlindWolf8: a checkout *can* be configured to use a branch on a remote server without any history stored locally | 07:32 |
| fullermd | Who dares invoke the Great and Powerful fullermd?? | 07:33 |
| vila | fullermd: someone wanting clarifications about checkouts and bound branches :-P | 07:36 |
| BlindWolf8 | :-P | 07:36 |
| fullermd | First, you must pass the Seven Trials of Courage. | 07:42 |
| BlindWolf8 | Hey Matt, we're going to incur your wrath | 07:42 |
| BlindWolf8 | so anyways.... | 07:43 |
| BlindWolf8 | binding a branch to a dir makes bzr more like Perforce, which is the first VCS/SCM I used | 07:44 |
| BlindWolf8 | As far as I know, I've got this: http://wiki.bazaar.canonical.com/StandaloneTree | 07:48 |
| BlindWolf8 | on the server, anyways | 07:49 |
| BlindWolf8 | the clients/workers have the same thing, but they have a full revision history (Heavyweight Checkout) | 07:49 |
| BlindWolf8 | the files are also viewable/changable on their machines, and not sotred in the .bzr dir | 07:50 |
| BlindWolf8 | (not sure what to call that...Working Tree?) | 07:50 |
| vila | yes, see http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief | 07:51 |
| BlindWolf8 | Thanks! If you guys need helps in organizing docs or making things clearer, I have a knack for that | 07:53 |
| vila | BlindWolf8: help is always welcome, have a look at https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=doc, or clarify anything you didn't understand in the actual docs :) | 07:55 |
| BlindWolf8 | You guys rock! :-D | 07:57 |
| lifeless | vila: https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/27473 | 08:03 |
| vila | lifeless: Updating diff... :-) | 08:04 |
| lifeless | vila: pull it :) | 08:05 |
| lifeless | vila: I'm going to cook dinner | 08:09 |
| lifeless | vila: but I'd *love* to get this landed | 08:09 |
| lifeless | vila: so if you can pp it for me, that would be most awesome | 08:09 |
| lifeless | I'll pop back in a bit | 08:09 |
| vila | lifeless: enjoy your cooking and don't worry, I *need* this patch | 08:09 |
| vila | lifeless: (I even thought it has already landed :) | 08:10 |
| BlindWolf8 | I'm out. Thanks again you guys! | 08:10 |
| vila | lifeless: 4 tests erroring out, see mp | 08:57 |
| lifeless | thank you | 08:58 |
| lifeless | vila: that will be shallow | 08:59 |
| vila | lifeless: certainly | 08:59 |
| vila | well, hopefully :) | 08:59 |
| saxicek | hello everybody | 08:59 |
| lifeless | vila: they work for me | 09:00 |
| lifeless | vila: disable your non-core plugins | 09:00 |
| vila | lifeless: already done, I've kept only loom... | 09:01 |
| lifeless | :!bzr selftest --no-plugins bzrlib.tests.blackbox.test_push.TestPush.test_push_smart_tags_streaming_acceptance test_switch_lightweight_directory bzrlib.tests.blackbox.test_tags.TestTagging.test_branch_push_pull_merge_copies_tags bzrlib.tes | 09:01 |
| lifeless | ts.blackbox.test_tags.TestTagging.test_list_tags | 09:01 |
| lifeless | bzr selftest: /home/robertc/source/baz/bzr-test-fixes/bzr | 09:01 |
| lifeless | /home/robertc/source/baz/bzr-test-fixes/bzrlib | 09:01 |
| lifeless | bzr-2.2.0dev1 python-2.6.5 Linux-2.6.32-22-generic-x86_64-with-Ubuntu-10.04-lucid | 09:01 |
| lifeless | ---------------------------------------------------------------------- | 09:01 |
| lifeless | Ran 4 tests in 1.207s | 09:01 |
| lifeless | OK | 09:01 |
| vila | !paste | 09:01 |
| ubot5 | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 09:01 |
| vila | http://paste.ubuntu.com/449550/ | 09:03 |
| lool | vila: Heya | 09:04 |
| lool | vila: With whom should I discuss performance of the gcc-linaro branches? | 09:04 |
| vila | lifeless: and even without loom: running 5(?) tests, failed 3 :-/ | 09:05 |
| vila | lool: here should be fine, filing a bug report tagged udd, about the slow checkouts will be even better | 09:05 |
| vila | lool: not finished replying to your emails, but you can try --hardlink too for branch and checkout | 09:06 |
| lool | vila: Would you think it's something fixable, or will we always suffer from the size of history + size of the tree? | 09:06 |
| lool | vila: In my experience, the CPU was maxed for long periods of time during the lenghty operations, not I/O | 09:07 |
| vila | lool: I suspect it's more a tree size bug than an history size one | 09:07 |
| lool | (I'm on SSD BTW) | 09:07 |
| saxicek | Can you guys please help me with setting custom merge app in bazaar explorer? I tried "d:/Program Files/Beyond Compare 3/BComp.exe" %r %b %t %o but I am getting "Error while running merge tool (code 0)" but did not see what it is actually trying to run in the log | 09:07 |
| vila | I got worse performances for massive IO on SSD than on 7200rpm HDs | 09:07 |
| vila | lool: ^ | 09:08 |
| lool | vila: BTW what is the udd tag for? Does it cover code imports or is it just for package imports? Cause here it's a code import branch, not a package import one | 09:08 |
| vila | lool: it's for Ubuntu Distributed Dev | 09:08 |
| lool | vila: Ok; I have a relatively unreliable I/O indicator in my panel which showed modest amount of I/O, and CPU maxed out, so I didn't blame it on I/O but it's not 100% out of the picture I guess | 09:08 |
| vila | lool: if you use the stock performance monitor, setting Red as the color for IOWait instead of the default black will show you some interesting side-effects | 09:09 |
| lool | vila: Yes, one CPU ws 100% busy with both IO wait and actual work | 09:11 |
| vila | lool: try on a regular disk or use a better SSD ;-) The CPU@100% needs to be investigated, filing a bug is the best way to ensure it's not forgotten | 09:13 |
| lifeless | vila: lets let pqm decide ;) | 09:14 |
| vila | lifeless: AttributeError: 'GenericInterBranch' object has no attribute 'tags' looks unambiguous to me | 09:15 |
| jelmer | lifeless: pong | 09:17 |
| lool | vila: bug #593560 | 09:21 |
| ubot5 | Launchpad bug 593560 in Bazaar "Slow performance for many operations on the gcc code import branches (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/593560 | 09:21 |
| vila | lifeless: plus you should be running 5 tests not 4, the 5th one is bzrlib.tests.blackbox.test_tags.TestTagging.test_list_tags_revision_filtering caught by bzrlib.tests.blackbox.test_tags.TestTagging.test_list_tags, are you sure !bzr use the right bzr ? | 09:21 |
| vila | lool: first comment, I didn't noticed it earlier but using *different* projects for gcc-linaro and gcc, defeats the stacking scheme defined on lp, you'd better use the 'gcc' project itself | 09:24 |
| lool | vila: Does it matter for the project series branches, or for the actual branches or both? | 09:25 |
| lifeless | vila: when only two people are speaking pastebin is a nuisance :P | 09:25 |
| lool | vila: I mean, I can have gcc-linaro/4.4 point at ~gcc-linaro-dev/gcc/linaro-4.4 or something like that | 09:26 |
| lifeless | vila: did you pull my branch, or merge it ? | 09:26 |
| vila | lifeless: pull | 09:26 |
| lifeless | vila: aah, yes, ./bzr :P | 09:26 |
| lifeless | ok will fix | 09:26 |
| vila | lool: one stacked-on branch is defined by project on lp AFAIR | 09:27 |
| vila | lool: it's called the devlopment focus on lp I think | 09:27 |
| lool | vila: How would I setup my branches to tell LP that they are stacked on multiple branches of the gcc project | 09:29 |
| lifeless | jelmer: it was InterBranch.pull I was pinging about | 09:29 |
| lifeless | jelmer: its rather odd in trunk | 09:29 |
| lool | vila: IOW that ~gcc-linaro-dev/gcc/linaro-4.4 is stacked on lp:gcc/4.4 and same for 4.5 | 09:29 |
| lifeless | lool: you wouldn't, why do you want to do that ? | 09:29 |
| lool | vila: the gcc development focus is the trunk vcs-import | 09:29 |
| lool | lifeless: Well, gcc development results in yearly releases with relatively lots of changes in 4.4 and 4.5 branches, we're mostly going to work on 4.4 and 4.5 branches as a baseline, maintaining forks basically | 09:30 |
| vila | lool: I don't think you want to do that on lp (nor that you can), either you define branches in the gcc project or you define a development focus in gcc-linaro (the former sounds better to me) | 09:30 |
| lool | the gcc focus of development correctly points at trunk which is always where most development is going on | 09:30 |
| lifeless | lool: sure, but you can have all the history in lp:gcc, so that stacking is always efficient | 09:30 |
| lool | vila: Oh I did define a development focus on gcc-linaro | 09:31 |
| lool | vila: I had to chose a branch, so I picked the 4.4 one | 09:31 |
| lool | lifeless: You don't have history of the 4.4.x and 4.5.x commits surely? | 09:31 |
| vila | lool: wrong :) Then your push for 4.5 needs to carry all the missing revisions | 09:31 |
| lool | lifeless: They are backports at the patch / SVN level upstream, but from bzr pov, they are entirely separate branches | 09:32 |
| vila | lool: no, all the imports are from the same master svn repo, the revisions are shared | 09:32 |
| lifeless | lool: nevertheless, we can, with cron, get all the content into one branch. | 09:32 |
| lool | vila: It's true, but 4.4 and 4.5 will differ significantly, and most of the work will happen in 4.4 right now; if I setup 4.5 as dev focus, I will miss the 4.4 revs when pushing 4.4 based branches | 09:32 |
| lifeless | lool: its 3 lines of python and a pear tree | 09:33 |
| lool | lifeless: awesome, that sounds like something we would want | 09:33 |
| lifeless | lool: stacking is an approximate thing, don't aim for perfection. | 09:33 |
| lifeless | lool: 1 years dev on a 25 year old tree is peanuts | 09:33 |
| lifeless | you'll have many more issues that aren't related to how much is/isn't shared in stacking. | 09:33 |
| lifeless | we're working on that at the moment. | 09:33 |
| lifeless | vila: fixed | 09:35 |
| lifeless | vila: missing .source | 09:35 |
| lool | lifeless: So how would I ask for this cron to be setup, or are you saying that it's probably not going to gain much? | 09:35 |
| lool | vila: I've changed development focus to gcc-linaro/4.5 now | 09:36 |
| lifeless | lool: r1 = bzrlib.repository.Repository.open('lp:gcc-linaro/devfocus'); r2=bzrlib.repository.Repository.open('lp:gcc-linaro/4.4'); r1.fetch(r2) | 09:37 |
| lifeless | lool: repeat as needed | 09:37 |
| lifeless | you need to import bzrlib.repository | 09:37 |
| lifeless | and bzrlib.plugin | 09:37 |
| lifeless | and do bzrlib.plugin.load_plugins() | 09:37 |
| lool | cute | 09:38 |
| lifeless | separated concerns ftw | 09:38 |
| vila | lool: yup, lifeless proposal is the best solution for your case, this way you can load your devfocus branch with whatever you want and pushes will benefit | 09:39 |
| lool | vila: So you were arguing earlier that we should use the gcc project for this stuff instead of the gcc-linaro one, is this still useful if we push revisions like above? | 09:39 |
| vila | lool: and you won't have to think about which of trunk, 4.4 or 4.5 is the best starting point | 09:39 |
| lifeless | lool: it woud model it more accurately in launchpad | 09:39 |
| lool | vila: I should probably load the devfocus branch of gcc-linaro with the gcc/trunk /4.4 and /4.5 revs too, shouldn't I? | 09:40 |
| lifeless | lool: but really, do what makes sense to you | 09:40 |
| vila | lool: no, doesn't matter anymore | 09:40 |
| vila | lool: if you start with trunk, the later ones should be almost covered | 09:40 |
| lool | vila: So the trunk vcs-import contains all the 4.4 and 4.5 revisions because it's the way bzr svn operates? | 09:41 |
| vila | lool: I don't thin kit's related to svn or vcs-import but most of the history of these branches is the same one | 09:42 |
| vila | lifeless: still one failure if I use the loom plugin: ERROR: blackbox.test_switch.TestSwitch.test_switch_lightweight_directory -> TypeError: run() got an unexpected keyword argument 'directory' most probably on loom itself ;) | 09:43 |
| lifeless | vila: yes, trunk breakage with decorated command | 09:45 |
| lifeless | vila: please review, its nearly bedtime | 09:45 |
| lifeless | vila: my problem to have tests passing | 09:45 |
| lifeless | vila: also, a suggestion for lool's bug: ask for data, always ask for data ;) | 09:45 |
| vila | lifeless: .bzr.log ? I was typing an additional comment ;) | 09:47 |
| lifeless | calgrind | 09:48 |
| lifeless | logs are nice | 09:48 |
| lifeless | callgrind is heaven | 09:48 |
| vila | lifeless: tests pass without the loom plugin, review time | 09:48 |
| lifeless | vila: a meta comment for you: I think your priorities are the wrong way around there; its up to the submitter and PQM to care about tests. | 09:49 |
| lifeless | vila: better to review, and *then* note that its got issues, than to put the review back - it breaks the flow up more. | 09:50 |
| vila | lifeless: sure, especially when the submitter run the full test suite before submitting ;-) | 09:51 |
| lool | lifeless: I have flexibility on the naming of the real branches; I chose to create a gcc-linaro project to host tarballs in the future, then it seemed logical to have gcc-linaro/xxx branches | 09:52 |
| lifeless | lool: I think lp would traditionally model that as gcc/linaro-4.5 as the series, which can host tarballs just fine. | 09:53 |
| lool | IIUC, the fact I pushed the "series" branches to /gcc-linaro namespace means they were not stacked on gcc and I payed a price for that, however because I've set the focus of dev to one of these branches, people pushing to gcc-linaro branches wont pay much | 09:54 |
| lifeless | lool: OTOH if you want to be able to say on a bug, 'fixed in linaro gcc 4.5, still open in fsf gcc 4.5' then you must have a separate project at the moment. | 09:54 |
| lool | lifeless: Don't I need ownership of the gcc project for that? | 09:54 |
| lifeless | lool: no | 09:54 |
| lifeless | lool: anyone can create series, or at least they are meant to be able to. | 09:54 |
| lool | Yes, we want to track the bugs separately | 09:54 |
| lool | the fsf bugs are not tracked in Launchpad though | 09:55 |
| lool | Well they are tracked by Launchpad as remote bugs in upstream bugzilla | 09:55 |
| lifeless | right | 09:55 |
| vila | lifeless: Why can you remove InterToBranch5 now ? Did something change or was it an error to introduce it at the time ? | 10:10 |
| lool | vila, lifeless: Hmm one thing I'm thinking could impact performance very badly is ecryptfs | 10:10 |
| lool | I'm using ecryptfs on my whole $HOME; it caused issues in the past with things such as sparse files, but performance was overall comparable to before using that in my experience | 10:11 |
| lool | I should try on another system | 10:12 |
| vila | lifeless: ha, bug #593515, but why didn't your mp reference that ?? | 10:15 |
| ubot5 | Launchpad bug 593515 in Bazaar "InterToBranch5 not used? (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/593515 | 10:15 |
| vila | lifeless: approved | 10:16 |
| lifeless | vila: thanks | 10:20 |
| lifeless | lool: just get callgrind stats | 10:20 |
| lifeless | they should show up stat() if stat time is relevant | 10:20 |
| lifeless | or sha1time, if ecryptfs breaks stat fingerprinting | 10:21 |
| lifeless | vila: you haven't set merge:approve ;) | 10:25 |
| vila | lifeless: pff, patch pilot noob... | 10:27 |
| lifeless | vila: no worries, I shall train you :) | 10:31 |
| vila | hehe, cool | 10:32 |
| lool | lifeless: I ran an "enrich-gcc-linaro-repo" script, took 6mn41s on the first run and 18s on the second run, seems to have done some useful stuff on the first run, so was definitely a good idea, thanks | 11:38 |
| lool | Will cron it now | 11:39 |
| lool | Hmm I should create a separate account with a separate bzr key | 11:43 |
| lool | I wonder how to tell bzr to use a separate launchpad login + ssh key for a single run | 11:49 |
| lool | Overriding BZR_HOME is fine, but ssh won't use $HOME, and I can't find a way to pass random args to ssh from bzr | 11:56 |
| lifeless | ln -s .ssh somewhere ? | 11:56 |
| lifeless | lool: ssh can handle multiple ssh keys to offer, you know :) | 12:00 |
| lifeless | lool: just have the right one on your keyright/passwordless/whatever | 12:00 |
| lool | lifeless: Hmm right, I can just offer the key all the time | 12:32 |
| lool | problem is user name actually, not key | 12:33 |
| lool | it's the unix user I should be using | 12:33 |
| === mrevell is now known as mrevell-lunch | ||
| rumbert | Is there GUI(s) which let you browse repositories without branching/checking out? (not counting HTTP/WWWeb) | 13:15 |
| === mrevell-lunch is now known as mrevell | ||
| lamont | bzr branch bzr+ssh://example.com/ | 14:13 |
| lamont | bzr: ERROR: gnomekeyring.IOError: | 14:13 |
| lamont | W.T.F... | 14:13 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| === beuno is now known as beuno-lunch | ||
| === IslandUsurperAFK is now known as IslandUsurper | ||
| === beuno-lunch is now known as beuno | ||
| === bac` is now known as bac | ||
| === Meths_ is now known as Meths | ||
| === JayFo is now known as JFo | ||
| servilio | hi! can someone please point me out to a documentation on BranchReference's? | 19:27 |
| TresEquis | jelmer: anything I can do to help with lp:480102? | 21:16 |
| TresEquis | I saw you had marked it 'inprogress' over the weekend | 21:16 |
| jelmer | bug 480102? | 21:19 |
| ubot5 | Launchpad bug 480102 in Bazaar Subversion Plugin "assert len(tview) == tview_len (affected: 12, heat: 98)" [High,In progress] https://launchpad.net/bugs/480102 | 21:19 |
| jelmer | TresEquis: one thing that would really help is a trivial python script that reproduced the issue so we can put that into the bzr-svn testsauite | 21:20 |
| TresEquis | jelmer: ugh, I really don't understand how to provoke the error in a nice testcase-ish way | 21:31 |
| jelmer | TresEquis: well, any help reproducing that error in the simplest way possible would be appreciated | 21:32 |
| TresEquis | I know that it appeared to be true that the "blob loader ID" for the failing file in the failing revision was somehow pointing to the older revision | 21:33 |
| TresEquis | so that when the patch was applied, the resulting file didn't match the checksum for the current transaction | 21:33 |
| TresEquis | I just don't know the mechanics well enough to guess how that might occur | 21:35 |
| jelmer | right | 21:36 |
| jelmer | so I know it has something to do with merges | 21:36 |
| TresEquis | I don't know if it is significant, but there is a 'bzr:ancestry:v4' property which shows up in the tree at the point of the apparently-successful merge | 21:49 |
| TresEquis | the one after which the later transaction touching the same files blows up | 21:49 |
| TresEquis | also, svn:mergeinfo shows up at that point | 21:50 |
| jam | mkanat: I pushed a possible fix for bug 586122 for you | 22:02 |
| ubot5 | Launchpad bug 586122 in Meliae "scanner core dumps on loggerhead trunk + python 2.6.2 (affected: 1, heat: 5)" [Undecided,New] https://launchpad.net/bugs/586122 | 22:02 |
| jam | Can you test it out and let me know? | 22:02 |
| mkanat | jam: Awesome! Yes, I will check it out. | 22:02 |
| mkanat | jam: It might be a bit later today; the Bugzilla freeze is tomorrow, so I'm a little busy. | 22:02 |
| jam | mkanat: No rush on my part, everything works here :) | 22:03 |
| mkanat | jam: Okay. :-) | 22:03 |
| lifeless | hi jam | 22:32 |
| jam | hi lifeless | 22:33 |
| assad | i did a merge, but i am getting : 6 conflicts encountered. at the end | 22:34 |
| assad | is the merge done? | 22:34 |
| TresEquis | assad: you need to fix the conficts, 'bzr resolve' them, and commit | 22:35 |
| TresEquis | assad: you need to fix the conficts, 'bzr resolve' them, and commit | 22:35 |
| jam | lifeless: somehow you managed to gather more resources than me, even though I'm fully capped (on all resources right now). | 22:39 |
| jam | I guess you managed to upgrade something faster than me? (and thus spend more resources?) | 22:39 |
| jam | anyway, you now outrank me in bym | 22:39 |
| assad | TresEquis, to fix the conflicts i have to copy the code from the "to be merged with" branch? | 22:40 |
| TresEquis | assad: it's a judgement call | 22:42 |
| TresEquis | you have to figure out what the right course is for each case where there are conflict markers | 22:42 |
| TresEquis | and then riun all your tests to be sure you didn't blow it | 22:43 |
| TresEquis | resolving conflicts in the test code is for extra bonus points | 22:43 |
| lifeless | jam: I don't know - how do I tell that? | 22:43 |
| jam | lifeless: on the bottom, your toon comes before mine, indicating you outrank me | 22:44 |
| lifeless | jam: I have 3/6 lvl 10 goos; and been having a back n forth war with some naively defended person who attacks me and gets 3/4 twigs max | 22:44 |
| lifeless | then I go wipe their entire base out ;P | 22:44 |
| TresEquis | lifeless: you in Kiwiland now? | 22:44 |
| lifeless | TresEquis: Yup | 22:44 |
| jam | lifeless: hmm, maybe it is the extra twigs | 22:44 |
| jam | I've got 6 lvl 10 goos, and a couple other lvl 10 items | 22:45 |
| jam | but I haven't been warring as much :) | 22:45 |
| lifeless | jam: it might be the fighting giving xp | 22:45 |
| jam | also, it takes 3x the build time before a resource repays itself | 22:45 |
| jam | (so a 3-day build time takes 9-days before it produces more) | 22:45 |
| jam | could be | 22:46 |
| jam | I've fought a little, but not a lot | 22:46 |
| mtaylor | mordred@camelot:~/src$ bzr whoami | 22:46 |
| mtaylor | bzr: ERROR: Connection closed: | 22:46 |
| TresEquis | lol | 22:47 |
| jam | mtaylor: I assume you are in a checkout? | 22:47 |
| mtaylor | jam: nope | 22:47 |
| mtaylor | just in a normal directory | 22:47 |
| lifeless | jam: TresEquis I'm in chch, if you're familiar with nz | 22:47 |
| jam | mtaylor: is $HOME a checkout? | 22:47 |
| mtaylor | jam: nope | 22:47 |
| lifeless | mtaylor: are you lying ? | 22:47 |
| jam | you could run with -Derror | 22:47 |
| mtaylor | lifeless: not to my knowledge | 22:47 |
| TresEquis | lifeless: not except from reading maps | 22:48 |
| lifeless | mtaylor: bzr info -v | 22:48 |
| mtaylor | lifeless: mordred@camelot:~/src$ bzr info -v | 22:48 |
| mtaylor | bzr: ERROR: Connection closed: | 22:48 |
| lifeless | file a bug - we need a way to help people debug this. | 22:50 |
| lifeless | secondly, look in .bzr/branch, ../.bzr/branch etc | 22:50 |
| mtaylor | lifeless: searched all the way up the tree - no .bzr dirs anywhere | 22:55 |
| lifeless | mtaylor: that is extremely odd | 22:57 |
| lifeless | mtaylor: strace bzr | 22:57 |
| mtaylor | lifeless: found it - there is an .svn dir | 22:58 |
| mtaylor | lifeless: which is causing bzr-svn to vomit | 22:58 |
| lifeless | mtaylor: oh right, of course | 22:58 |
| lifeless | mtaylor: so, the bug is 'connection errors don't signal why we were making them' | 22:58 |
| lifeless | or something | 22:58 |
| mtaylor | lifeless: ok. | 23:02 |
| lifeless | assuming that that is actually the entire output you've been pasting | 23:03 |
| mtaylor | lifeless: or also - bzr whoami should perhaps not need to connect to anything? | 23:03 |
| mtaylor | lifeless: yes | 23:03 |
| lifeless | whoami can be configured by the branch | 23:03 |
| lifeless | checkouts can reference an external branch | 23:03 |
| lifeless | so no, whoami was doing the right thing | 23:03 |
| lifeless | we could add a whoami --global or something | 23:04 |
| lifeless | but you'd still not be able to commit where you were ;P | 23:04 |
| mtaylor | lifeless: nah - I think you were right before - hinting at the bzr-svn cause would be the right thing here | 23:04 |
| mgz | lifeless: any objection to just backing out testtools r70 when the unicode traceback work is finished? | 23:26 |
| lifeless | mgz: why? it seems clearly less broken than it was | 23:27 |
| lifeless | mgz: I'd be happy to have something less broken than it wsa and is | 23:27 |
| mgz | well, because you're enhancing wrong code there | 23:27 |
| mgz | actually, I think it's worse than that | 23:28 |
| mgz | Python 3 does the right thing (the exceptions are always unicode), and Python 2 needs the input fixing, not a per-str()-call fixup | 23:31 |
| mgz | hardcoding UTF-8 there is the wrong place at any rate, needs to happen in subunit if you want it, otherwise you break the normal output with say, unittest | 23:32 |
| lifeless | so, subunit with multipart attachments already generates unicode exception objects | 23:33 |
| lifeless | r70 in testtools is to *handle* that | 23:33 |
| mgz | okay, I know it was to fix a current issue | 23:33 |
| mgz | but I'm interested in what needs to change when testtools is only creating _StringException objects with unicode args | 23:34 |
| lifeless | as long as we're using a fixed traceback module | 23:35 |
| lifeless | and a subunit with the patch to make unicode string exceptions for non-multipart attachments | 23:35 |
| lifeless | and the matching XXX fixed to encode in utf8 explicitly for non-multipart serialising | 23:35 |
| lifeless | then we shouldn't ever be calling __str__ on a StringException | 23:35 |
| mgz | okay, great, that's what I'm aiming for | 23:36 |
| lifeless | and if we're not calling __str__, then it shouldn't matter | 23:36 |
| lifeless | uhm | 23:36 |
| lifeless | actually, it will matter | 23:36 |
| lifeless | if someone with a different TestResult uses the standard traceback module. | 23:37 |
| mgz | right, this is the case I worry about | 23:37 |
| lifeless | they will run into precisely the same brokenness, unless __str__ *works* | 23:37 |
| mgz | I currently am testing testtools internals with the unittest runner | 23:37 |
| mgz | r70 will break those tests | 23:37 |
| lifeless | and this is the upstream Exception.__str__ bug in python2.x | 23:37 |
| lifeless | mgz: no, r70 will fix it. | 23:37 |
| mgz | no, this is er... the second pass | 23:37 |
| mgz | testtools is formatting the exception | 23:38 |
| lifeless | hmm, I've two uk people timesharing me | 23:38 |
| mgz | and unittest is stringifying the _StringException for the output | 23:38 |
| mgz | I'll retire, this can wait. | 23:38 |
| lifeless | which is broken. It should be unicodifying | 23:38 |
| mgz | right, but it's a broken case that comes up, bzr currently does the same I believe | 23:39 |
| lifeless | the question is, when someone asks for an insane thing, do we: break; encode to their default; encode to utf8; something else | 23:39 |
| mgz | yup. | 23:39 |
| poolie | hi there mgz, lifeless | 23:39 |
| mgz | hey poolie | 23:39 |
| lifeless | mgz: I'm happy to change it to 'use their console encoding' or something, once your patch lands and that is feasible. | 23:39 |
| mgz | so, looked at like that, it boils down to r70 picking "always utf-8" and my compat one doing "ascii and questionmarks" | 23:40 |
| lifeless | hi poolie | 23:40 |
| mgz | where the right thing will be to change it to use unicode till it actually hits the console/whatever other output method | 23:40 |
| lifeless | mgz: right | 23:40 |
| lifeless | mgz: back in 2 minutes | 23:40 |
| BitSprocket | How does one remove a folder from bazaar control? | 23:44 |
| lifeless | mgz: back | 23:44 |
| BitSprocket | How does one remove a folder from bazaar control? | 23:46 |
| poolie | BitSprocket, 'bzr rm --keep' | 23:46 |
| poolie | note that this will propagate to other checkouts as a deletion of that folder | 23:46 |
| BitSprocket | Thanks poolie. It's a private project so no worries. That won't delete any of my files right? | 23:47 |
| BitSprocket | Said differently, I want to keep the files, just remove version control. | 23:47 |
| poolie | that's what --keep does | 23:48 |
| BitSprocket | Sweet, thanks! | 23:48 |
| poolie | you might then want to do 'bzr ignore THING' to avoid it being re-added in future | 23:48 |
| poolie | np | 23:48 |
| BitSprocket | Does that apply to subdirectories/files as well? | 23:49 |
| BitSprocket | Or do I have to do them manually? | 23:49 |
| BitSprocket | ...looks like it took care of it recursively for me... | 23:50 |
| BitSprocket | Well, it doesn't look like it worked after all. What am I missing? | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!