| poolie | hi all | 00:19 |
|---|---|---|
| jelmer | hi poolie | 00:30 |
| poolie | hi there jelmer, how are you? | 00:33 |
| jelmer | thanks, had a good weekend, and today I finally got the impression I'm getting to the last of these vf-specific tests that need to be moved | 00:35 |
| poolie | great | 00:35 |
| jelmer | With the new extensions in subunit I'm going to set up a ratchet (?) to get the number down further and see the progress | 00:36 |
| jelmer | poolie: and how are you? are you on the road yet? | 00:36 |
| poolie | in a few hours | 00:36 |
| poolie | pretty good, just doing all the little chores before travelling | 00:36 |
| spiv | Hi all. | 01:19 |
| spiv | Nothing like a mysteriously locked up X to start the morning! | 01:19 |
| lifeless | \i/ | 01:19 |
| === cinerama_ is now known as cinerama | ||
| lifeless | jelmer: why does the subunit recipe not use the subunit debian packaging branch ? | 01:45 |
| jelmer | lifeless: that's how jml set it up hystorically, I don't think he has access to the debian branch | 01:46 |
| lifeless | ok, changing it | 01:46 |
| jelmer | *historically | 01:47 |
| lifeless | jelmer: https://code.launchpad.net/~testing-cabal/+archive/archive/+buildjob/2517596/+files/buildlog.txt.gz is what got me looking at this | 01:51 |
| lifeless | note the massive conflicts | 01:51 |
| lifeless | we should perhaps use nest-part in fact | 01:51 |
| jelmer | lifeless: Did you see I pushed an updated branch earlier tonight? | 01:51 |
| lifeless | yes, and it had commits on it | 01:52 |
| lifeless | which suggests its wrong :) | 01:52 |
| jelmer | what's wrong about a branch with commits, isn't that the whole point ? :-P | 01:52 |
| lifeless | not for recipes | 01:52 |
| lifeless | the point of recipes is to use the packaging data as much as possible | 01:52 |
| lifeless | and fix things upstream | 01:53 |
| jelmer | I merged upstream, I didn't make any additional changes to the upstream code | 01:53 |
| lifeless | jelmer: right, but you needed to merge upstream because the packaging data has previously had changes leading to these conflicts | 01:53 |
| lifeless | no? | 01:54 |
| jelmer | lifeless: right | 01:55 |
| jelmer | I'm not sure why we have those extra changes in the packaging branch | 01:56 |
| lifeless | well, we don't in my packaging branch | 01:56 |
| jelmer | lifeless: you mean the one on alioth? | 01:56 |
| lifeless | jelmer: there is none on alioth | 01:57 |
| jelmer | bzr info apt:subunit | 01:57 |
| lifeless | lp:~lifeless/debian/sid/subunit/sid | 01:57 |
| lifeless | hymm, there is | 01:58 |
| lifeless | but thats stale | 01:58 |
| lifeless | jelmer: so looking at that | 02:01 |
| lifeless | I'm unhappy with 0.0.6-2 | 02:01 |
| lifeless | jelmer: I have not had a single good experience with source format 3 | 02:01 |
| lifeless | jelmer: why did you change it ? | 02:02 |
| lifeless | jelmer: I mean, I'm glad you're doing stuff there but that particular change is disruptive (as is the dh_python2 change) | 02:04 |
| lifeless | jelmer: it must be very late for you | 02:04 |
| lifeless | jelmer: so I'm happy to talk about this your morning | 02:04 |
| lifeless | jelmer: (and I only now remember you actually stepped up and became maintainer, looking at log of debian/control) | 02:05 |
| lifeless | jelmer: I've put lp:~testing-cabal/debian/sid/subunit/daily-builds up as a stable url so we don't go making new branches every release (because one branch builds for all releases we need to figure out how to do compatibility in one place anyhow) | 02:09 |
| lifeless | jelmer: I really have to run to the chemist, sorry if any of the above is weird/nonsequitor/annoying | 02:15 |
| poolie | hi spiv | 02:56 |
| spiv | Hi poolie | 03:01 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| jam | morning all | 08:12 |
| jam | spiv: if you're still around, any luck with the concurrent repacking issue? | 08:13 |
| spiv | jam: https://bugs.launchpad.net/bzr/+bug/772935 temporarily queue-jumped | 08:45 |
| ubot5 | Ubuntu bug 772935 in Bazaar "ErrorFromSmartServer: Absent factory for StaticTuple" [High,Confirmed] | 08:45 |
| jam | sure | 08:45 |
| spiv | Basically with the concurrent packing one I want to refactor the heck out of pack_repo.py to make the logic much more testable | 08:46 |
| spiv | (without having to resort to e.g. trying to run two threads with precise timing) | 08:47 |
| spiv | jam: btw, I've created lp:bzr-repodebug, which collects some of the ad hoc scripts/plugins I've made or seen in the past | 08:59 |
| spiv | jam: because it's too hard to find them in random people's +junk months later, but not quite worth making projects for each of them | 09:00 |
| spiv | It's currently got check-chk, chk-used-by, fetch-all-records, fix-missing-keys-for-stacking, mirror-revs-into, repo-has-keys and repo-keys commands | 09:00 |
| bialix | hi guys | 09:06 |
| bialix | C:\work\Bazaar\plugins\format1\__init__.py:13: DeprecationWarning: __builtin__.type.set_default_format was deprecated in version 2.4.0. | 09:06 |
| bialix | workingtree.WorkingTreeFormat.set_default_format(workingtree.WorkingTreeFormat5()) | 09:06 |
| bialix | what's wrong? | 09:06 |
| bialix | and why it complains about __builtin__? | 09:07 |
| bialix | that's with bzr.exe 2.4.b1 | 09:07 |
| spiv | That message does seem a bit wrong | 09:08 |
| bialix | spiv: the line from my plugin is: workingtree.WorkingTreeFormat.set_default_format(workingtree.WorkingTreeFormat5()) | 09:10 |
| bialix | so I should use set_default for 2.4, right? | 09:17 |
| spiv | bialix: I think so | 09:17 |
| spiv | bialix: probably that deprecation needs to use @deprecated_function instead of @deprecated_method, or deprecated_method needs fixing to handle classmethods better, or something. | 09:18 |
| spiv | Or maybe move @classmethod after the @deprecated_method line? Anyway, that message is clearly a bug. | 09:19 |
| bialix | spiv: should I file a bug report? | 09:22 |
| === cbz_ is now known as cbz | ||
| === zyga-afk is now known as zyga | ||
| bialix | guys, why does bzr 2.4b1 print too much info about plugins on traceback? | 11:35 |
| bialix | is there any knob I can modify to get the old behavior? | 11:35 |
| bialix | Bug 776272 | 11:36 |
| ubot5 | Launchpad bug 776272 in Bazaar "bzr 2.4b1: on traceback bzr prints too much info about plugins" [Critical,Confirmed] https://launchpad.net/bugs/776272 | 11:36 |
| maxb | bialix: Try 2.4b2? | 11:59 |
| bialix | no windows installer available yet :-( | 12:00 |
| lifeless | jelmer: hi | 12:14 |
| jelmer | lifeless: hi | 12:20 |
| lifeless | jelmer: sorry I went skewiff your last night | 12:20 |
| jelmer | lifeless: sorry for not responding yesterday | 12:20 |
| lifeless | jelmer: no worries, it was v. late for you | 12:20 |
| lifeless | jelmer: so, I'm glad you are maintaining subunit | 12:20 |
| lifeless | jelmer: I'm worried that in the -2 change we can't build it for CAT in the canonical datacentre anymore | 12:21 |
| lifeless | because: source format 3, and dh_python2 | 12:21 |
| lifeless | I don't know what to do about those. For all the packages I'm still maintainer of I'm basically using source format 1 by choice and the oldest-supported python buildchain. | 12:22 |
| lifeless | jelmer: do you have an ideas about how to deal with that? | 12:24 |
| jelmer | lifeless: I think those changes make sense if we're considering just Debian (e.g. bugs have been filed about upgrading to dh_python2) | 12:24 |
| jelmer | lifeless: I can symphatize with whoever is doing the backporting though, happy to go back for the moment if that helps elsewhere | 12:25 |
| lifeless | jelmer: mmmm, perhaps, if we don't care about debian backports | 12:25 |
| lifeless | jelmer: the CAT archive can't build source package 3, so at least for me using source format 1 is better (and it works fine with bzr maintenance too) | 12:25 |
| lifeless | jelmer: I'm not sure what the dh_python2 backports story is; I've assumed its 'backport debhelper and hope', but I may be wrong | 12:26 |
| jelmer | lifeless: dh_python2/source 3 should work fine in squeeze too IIUC | 12:26 |
| jelmer | either way, I don't particularly mind going back for the moment | 12:29 |
| lifeless | jelmer: squeeze has 2.6.6-3, but -6 was the dh_python landing AFAICT | 12:29 |
| lifeless | jelmer: please, I think that would be good | 12:29 |
| lifeless | jelmer: the source format is the key thing | 12:30 |
| lifeless | jelmer: the CAT dak archive doesn't handle format three at all. Full stop. | 12:30 |
| jelmer | lifeless: 2.6.6-3~ is the minimum version according to the wiki | 12:30 |
| lifeless | jelmer: ah, interesting; | 12:30 |
| lifeless | jelmer: talk to lamont if you want to know the limitations of CAT more | 12:32 |
| jelmer | lifeless: I've been there... :) | 12:32 |
| jelmer | I backported a newer bzr-builder to it a while back | 12:32 |
| lifeless | fun :) | 12:33 |
| lamont | it's lucid+security+updates, and then we try to minimize what else we drag in. packages not in lucid are much easier to bring in, after that it's a question of "who else may break if we pick this up?" | 12:37 |
| maxb | Unless the package does something interesting, backporting a dh7 dh_python2 package is probably just a matter of swapping --with python2 for --with python-support | 12:38 |
| maxb | (and reducing builddeps) | 12:38 |
| maxb | dh_python2 doesn't live in debhelper, it lives in the python-defaults source package (a bit perversely) | 12:42 |
| jdobrien | why would launchpad display the message: The name 'u1rest' has been blocked by the Launchpad administrators. | 12:54 |
| jdobrien | it seems to meet the criteria on the project page | 12:54 |
| jelmer | jdobrien: might be that the u1 prefix is blocked? | 12:55 |
| jelmer | jdobrien: #launchpad is probably a better place for this question | 12:55 |
| jdobrien | jelmer, oh sorry | 12:55 |
| jelmer | no problem, it's just that you're more likely to get a useful answer there :) | 12:56 |
| jelmer | or I can speculate wildly, if you prefer | 12:57 |
| jelmer | jam: hi | 13:49 |
| jelmer | jam: Do you know in what situation I could see _LazyGroupCompressFactory._manager being set to None? | 13:50 |
| vanguard | is there some way to always use --strict for commit and push? | 13:50 |
| jelmer | I'm getting a confusing error in get_bytes_as() | 13:50 |
| jelmer | vanguard: I just have an alias that aliases "commit" to "commit --strict" | 13:51 |
| jelmer | I think there's also an option that can do it for you, but I forget what it is :) | 13:51 |
| vanguard | jelmer: alias in bashrc? | 13:52 |
| jelmer | vanguard: in ~/.bazaar/bazaar.conf - see "bzr alias" | 13:52 |
| vanguard | jelmer: thanks! | 13:54 |
| Dr_Al | I've got a few (fairly elementary) questions about writing some new test code. | 14:50 |
| Dr_Al | This is related to the bug in setting the parent location with switch -b | 14:51 |
| Dr_Al | Bug 513709 | 14:51 |
| ubot5 | Launchpad bug 513709 in Bazaar ""switch -b" sets incorrect parent for heavyweight checkout" [Low,Confirmed] https://launchpad.net/bugs/513709 | 14:51 |
| Dr_Al | I'm starting to write a test harness to demonstrate this behaviour, but my experience with bzrlib is a bit limited. | 14:52 |
| Dr_Al | According to the Bazaar Testing Guide: "Use the bzrlib library when setting up tests and when evaluating the side-effects of the command. ". Therefore, I'm trying to use bzrlib to create a treeless repository with a trunk (or whatever) branch inside it (to match the example in the bug report) | 14:52 |
| Dr_Al | At the moment, I'm writing the test code in test_switch.py (in the blackbox directory) and I've started by using self.make_repository('repo_lw', shared=True), but I can't see how to specify the tree-less behaviour. | 14:53 |
| Dr_Al | Also, what's a good way to get used to using bzrlib (e.g. finding out how to create a branch in the new repository and how to check a branch out to a working folder elsewhere? | 14:54 |
| Dr_Al | It's taking me quite a while to get my head round the different types that are rreturned by the various bzrlib functions. | 14:54 |
| jelmer | hi Dr_al | 15:00 |
| jelmer | Dr_Al: tree-less behaviour would be done with repo.set_make_working_trees() | 15:00 |
| jelmer | Dr_Al: To test that bug you probably need to add an extra blackbox test for "bzr switch -b" - the other ones are in bzrlib/tests/blackbox/test_switch.py | 15:01 |
| jelmer | The other tests should hopefully give you a bit of inspiration | 15:01 |
| Dr_Al | jelmer: Thanks: set_make_working_trees looks good. | 15:03 |
| === maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | ||
| Dr_Al | jelmer: I'm already working in test_switch.py as I said. I've managed to create the repository, but every time I want to do something extra, I seem to be spending an inordinate amount of time searching classes, parent-classes, grand-parent classes etc for a function that might do what I want. In test_switch.py, most of the functions seem to use make_branch_and_tree, which isn't quite what I want | 15:05 |
| jelmer | Dr_Al: I guess it always takes a bit of getting used to | 15:06 |
| Dr_Al | I could (assuming I could extract the path of the repo from the CHKInventoryRepository object that make_repository returns) just use run_bzr to do all the bits and pieces that I want to do, but that seems to be against the spirit of the Testing Guide quote that I posted. | 15:06 |
| jelmer | Dr_Al: Using run_bzr is fine in the blackbox tests | 15:07 |
| jelmer | Dr_Al: that bit of the testing guide applies to the non-blackbox stuff | 15:07 |
| Dr_Al | jelmer: Really?? It's item 3 on the list of points under the section title "Blackbox (UI) tests"! | 15:07 |
| Dr_Al | Most of the other tests in test_switch seem to do all the preparation with bzrlib and then use run_bzr for the one command that they're testing | 15:08 |
| jelmer | hmm, ok.. that's not my experience in other blackbox commands. perhaps I'm not aware of the best practices in this regard.. | 15:09 |
| Dr_Al | Fair enough! | 15:09 |
| jelmer | jam, vila; ^ | 15:09 |
| vila | jelmer: you're right | 15:10 |
| vila | Dr_Al: ley me check the guide 8-) | 15:10 |
| Dr_Al | Regardless of best practice, is there a good way of interrogating bzrlib? It seems daft that I'm having to go through classes, parent classes etc ad nauseum to determine the way to do some fairly basic stuff like creating a branch in the repository. | 15:10 |
| Dr_Al | I'm sure I'm missing some really obvious bit of documentation... | 15:11 |
| Dr_Al | vila: Thanks! | 15:11 |
| jelmer | Dr_Al: I usually look for other examples in the code that do similar things as I need to - if you need to create a bound branch you can grep for tests that use bound branches (they'll have something like that in their name) | 15:11 |
| jelmer | Dr_Al: Why do you need to create a shared repository, is that relevant for that bug? | 15:12 |
| vila | Dr_Al: right, it may be a bit ambiguous in the guide, but the general rule is that for blackbox tests you mainly rely on run_bzr | 15:13 |
| vanguard | how can I populate a tree via FTP? | 15:13 |
| vila | Dr_Al: UI tests are a bit of a special case as *sometimes* it's easier to tweak directly with bzrlib | 15:13 |
| vanguard | I want to upload my website with a simple `bzr push` | 15:13 |
| Dr_Al | jelmer: The short answer is: I'm not sure. I'm basing the test case on the way that we (the company at which I work) use Bazaar. This is with a shared treeless repository on a network drive with feature branches inside it. We then use heavyweight checkouts and 'switch -b' / 'switch' to pick branches. | 15:13 |
| vila | vanguard: try 'bzr upload' instead from the bzr-upload plugin | 15:13 |
| Dr_Al | vila: Okay, fair enough... I'll do it with run_bzr. It certainly makes my life easier! | 15:13 |
| vila | Dr_Al: once you submit your proposal, the reviewer may gives you better ideas and hints (if needed), but don't make your life harder *before* that ;) | 15:14 |
| Dr_Al | For verifying whether the test has passed (i.e. whether the parent is set correctly), is it better to parse 'bzr info' or to use bzrlib to (somehow) open the branch and interrogate the parent location. My instinct says the latter, but then that may end up being quite complicated! | 15:15 |
| Dr_Al | vila: Can't argue with that! | 15:15 |
| vila | branch.get_parent_location() (from memory) | 15:15 |
| vila | bah, one of those ... | 15:16 |
| vila | branch.get_parent() | 15:16 |
| Dr_Al | jelmer: (continuing earlier comment: sorry, got distracted)... therefore, I thought it was more appropriate to make the test case match the behaviour we were looking for... | 15:16 |
| Dr_Al | vila: thank yoU! | 15:16 |
| Dr_Al | vila: Now I just need to open the branch (created with run_bzr), but don't worry, I'll do some digging... | 15:17 |
| vila | that should be something along bzrlib.branch.Branch.open_containing(path)[0] | 15:18 |
| vanguard | vila: that is super handy, thx! | 15:18 |
| vila | Dr_Al: bzrlib.builtins is the source of all good bits when you're searching for high level usages of bzrlib internals | 15:18 |
| Dr_Al | vila: Great, thanks | 15:20 |
| Dr_Al | I'm (fairly obviously) nowhere near ready to propose this for merging (having only written the test harness), but is there any chance someone could have a look at my test harness code (http://bazaar.launchpad.net/~abudden/bzr/switch_parent_513709/revision/5817) and check that I'm writing code in an acceptable style and that the code looks reasonable at first glance? | 15:47 |
| vila | Dr_Al: rough review: | 15:53 |
| vila | instead of a _test_xxx method, split it into an assert<Result>(relevant params) and probably a test script (see bzrlib.tests.test_script.py) | 15:54 |
| vila | never use os.chdir, run_bzr accept a work_dir parameter | 15:55 |
| Dr_Al | vila: Thanks... I'll have a look at that. | 15:56 |
| vila | the split stuff seems... a bit complex, can't you achieve that with a *single* split ? | 15:57 |
| vila | ha, a single class there... | 15:58 |
| Dr_Al | I'd like to, but I couldn't see an easy way. split only produces two entries rather than a list (as I was expecting). | 15:58 |
| vila | Dr_Al: you may create a dedicated class for your tests so that they could share a setUp method that will create the needed stuff up to... the run_bzr('checkout'... | 15:59 |
| vila | Dr_Al: so that you create two test_ methods in this new class, one for heavy and the other for light | 16:00 |
| Dr_Al | I considered parent.split(os.path.sep) or parent.split('/'), but I wasn't sure which would be correct for Windows | 16:00 |
| vila | Dr_Al: bzrlib.osutils is your friend there | 16:00 |
| Dr_Al | That was my original plan actually (dedicated class), but it seemed more natural to use test_switch. I'll look at refactoring it into its own class tomorrow. | 16:00 |
| Dr_Al | Aha... hadn't seen bzrlib.osutils. | 16:00 |
| Dr_Al | Thanks vila. I've got to go now, but I may be back asking more (hopefully gradually less stupid) questions tomorrow. | 16:01 |
| vila | Dr_Al: in the end you should end up with two *short* tests that will outline your intent and be trivial to grasp | 16:01 |
| vila | there is no stupid questions... | 16:01 |
| vila | Dr_Al: oh I see, you copy _test_switch_explicit_nick.... shudder | 16:02 |
| chriscauser__ | Hi Everyone. I'm just throwing it out there to see what people think. I've written a small script which I'm using to show bzr branch information at the bash prompt. The code is at http://bazaar.launchpad.net/~chy-causer/bzr/bzr-term-info/view/head:/__main__.py . I know that bzr shell offers similar stuff but I wanted to know if anything similar exists and if not, if there was any need for it | 16:39 |
| chriscauser__ | Eagle eyed people may notice that this script was originally hosted by Github, and for that I apologize :$ | 16:40 |
| === Ursinha is now known as Ursinha-afk | ||
| vanguard | chriscauser__: looks nice, I build something like that using bash, not that elegant ... | 17:19 |
| === Ursinha-afk is now known as Ursinha | ||
| chriscauser__ | vanguard: My initial version was in bash! It was a little too slow if I wanted to check to see if the working tree was dirty though which is why I dropped down to Python | 17:21 |
| vanguard | chriscauser__: I just checked whether there is a .bzr directory. And then I just checked whether `bzr status` had any output | 17:22 |
| chriscauser__ | Yeah, that's what I started with but doing it in python gave me a (off the top of my head) ~35-40% speed boost | 17:23 |
| === Ursinha is now known as Ursinha-lunch | ||
| vanguard | chriscauser__: checking for the dir is prtty easy, but the status slow it down really bad, especially on a cold start | 17:23 |
| chriscauser__ | vanguard: Yeah :( | 17:24 |
| vanguard | chriscauser__: the only cool thing is that I could easily adapt the script to git, hg, svn … it does all the checks and tells me which SCM is used in this folder :) | 17:26 |
| chriscauser__ | vanguard: Ah! Well, my bash prompt contains $(get_bzr_info)$(get_hg_info)$(get_git_info) so it works for all three of them. The only thing is that if a directory is versioned using two version control systems, it's shown twice, but that's a really fringe problem :) | 17:29 |
| vanguard | chriscauser__: using two SCM is a fringe itself I'd say. | 17:29 |
| vanguard | chriscauser__: my script would just show the first one that applied, I guess bzr if it was bzr+git | 17:30 |
| chriscauser__ | vanguard: Oh well :) Glad you like it and hope it may be of some use to you in the future. I'll be working on showing conflicts next | 17:31 |
| === Ursinha-lunch is now known as Ursinha | ||
| vila | chriscauser__: You want wt.has_changes() | 18:17 |
| vila | yeah, talking to yourself again... | 18:17 |
| === CardinalFang_ is now known as CardinalFang | ||
| vila | jelmer: loom broken... never mind, you already landed a fix ;) Gee, almost 3 weeks ago even :-D | 18:38 |
| jelmer | :) | 18:39 |
| achiang | what is the easiest way to get a diff of all the files in a directory compared to an earlier revision? unified diff is fine, but maybe a gui tool would be useful too | 18:43 |
| vila | achiang: bzr diff -r<revno> | 18:44 |
| achiang | oh, that's it? | 18:44 |
| vila | yeah | 18:44 |
| vila | it's even 'bzr diff' only to look at your uncommitted changes | 18:44 |
| achiang | pretty easy. :) | 18:44 |
| vila | see 'bzr diff --help' for more | 18:45 |
| achiang | well, i'm doing code archaeology, so i don't have uncommited changes per se | 18:45 |
| achiang | vila: what is the name of the gui bzr diff tool? | 18:45 |
| vila | good, archeology is all about not breaking anything ;) | 18:45 |
| vila | bzr qlog from the qbzr plugin ? | 18:46 |
| achiang | hm, ok. i think i have that, thanks | 18:46 |
| vila | bah, bzr qdiff I meant | 18:47 |
| vila | bzr qdiff --help for details | 18:47 |
| achiang | vila: thanks | 18:47 |
| binary_crayon | Hello, I would like to install Bazaar Explorer from source. How may I install QBzr as dependency? I am using Mac OS X. Thanks | 18:56 |
| === medberry is now known as med_out | ||
| === med_out is now known as medberry | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| ckontros | I pulled a branch, made 1 change and tried to push. Got this: http://paste.ubuntu.com/603012 I'm using bzr from the Natty repo. | 23:35 |
| ckontros | Not I looked up "rich-root support" and then tried a "bzr upgrade --rich-root-pack ." Said branch was v.7 and I couldnt go to v.6. SO Im stuck. | 23:37 |
| ckontros | So Im stuck. ANy ideas? | 23:38 |
| glyph | ckontros: "the natty repo"? Do you mean "in natty" or "from https://launchpad.net/~bzr/+archive/ppa, and I'm using natty" | 23:48 |
| ckontros | glyph: BZR from official natty repos. | 23:48 |
| ckontros | Not PPA. | 23:50 |
| lifeless | ckontros: 'bzr info -v' and paste the repository line please | 23:50 |
| glyph | ckontros: OK. | 23:50 |
| ckontros | lifeless: http://paste.ubuntu.com/603021 | 23:52 |
| lifeless | ckontros: you're already using rick roots | 23:53 |
| lifeless | ckontros: note that the rick root pack format is much slower than the 2a format | 23:53 |
| lifeless | ckontros: ok, the *remote* branch is the one that is using an old format | 23:54 |
| lifeless | lp:~ubuntustudio-dev/ubuntustudio-default-settings/UbuntuStudio is what needs upgrading | 23:54 |
| ckontros | lifeless: Gotcha. | 23:54 |
| lifeless | ckontros: don't pass '--rich-root-pack' | 23:54 |
| lifeless | ckontros: you may have a number of related branches to upgrade; the launchpad UI has an 'upgrade this branch' button | 23:55 |
| lifeless | ckontros: if you do upgrade them all yoiu should also upgrade your local branch | 23:55 |
| * ckontros looks | 23:55 | |
| lifeless | just run 'bzr upgrade' in it | 23:55 |
| ckontros | After I pull it clean? (and local?) | 23:56 |
| lifeless | sure | 23:57 |
| lifeless | each branch of this project needs to be upgraded separately | 23:57 |
| ckontros | See, I hit this before and actually tried that 1st thing. | 23:57 |
| ckontros | See, something's odd. Im a member of ubuntustudio-dev and it says I cant upload to this branch on the page. https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/ubuntustudio-default-settings/oneiric | 23:58 |
| ckontros | james-w looks to have done something last. | 23:59 |
| lifeless | that branch is owned by ~ubuntu-branches - its the official packaging branch for that packagin - you need package upload rights to push to that branch | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!