ubotu | New bug: #111826 in bzr-gtk "Broken menu items in nautilus integration " [Low,Fix committed] https://launchpad.net/bugs/111826 | 00:01 |
---|---|---|
ubotu | New bug: #149061 in bzr-gtk "Cannot view diff of first revision" [Medium,Fix committed] https://launchpad.net/bugs/149061 | 00:01 |
radix | PenguinOfDoom: bzr branch lp:~subol-hackers/subol/shared.dev | 00:28 |
radix | oops, mischan | 00:28 |
poolie | hi radix! | 00:36 |
radix | yo poolie :-) | 00:37 |
RAOF | Heya radix! | 00:42 |
radix | wow, it's a party | 00:42 |
radix | Hi RAOF :) | 00:42 |
RAOF | :) | 00:42 |
poolie | lifeless: what are your thoughts on rich-root-pack conversion bugs and 1.3? | 00:43 |
* Odd_Bloke pumps out the beats. | 00:44 | |
* TFKyle pumps out the beasts | 00:47 | |
* j1mc jumps to the pumped out beats | 00:49 | |
TFKyle | (aka. party-goers) | 00:49 |
lifeless | poolie: 1.3 is time based, I don't think those things are related | 00:59 |
lifeless | poolie: as the conversion issues are not regressions | 01:00 |
j1mc | lifeless: just wanted to say thank you for your explanations yesterday. you were very helpful. the history is now correct, and i've used bzr bind to ensure i won't have the same problem again. | 01:01 |
poolie | in other words go ahead without it | 01:01 |
lifeless | j1mc: cool | 01:01 |
j1mc | :) | 01:01 |
lifeless | poolie: yah | 01:01 |
=== kiko is now known as kiko-zzz | ||
=== mw is now known as mw|out | ||
lifeless | poolie: what do you think | 01:09 |
poolie | it does seem to have been present for a while | 01:10 |
lifeless | bbiab food ftw | 01:13 |
lifeless | squid folk are liking bzr fwiw | 01:37 |
lifeless | need to do some tweaks to bb for them | 01:37 |
lifeless | use the right bugtracker | 01:37 |
lifeless | and allow anonymous email voting | 01:37 |
hunmonk | anybody have a sec to help me w/ an rspush error i'm getting? | 03:00 |
lifeless | sure | 03:00 |
hunmonk | lifeless: 504 colossus$~/Sites/apartmentlines.com/www: bzr rspush watchdog:bzr/apartmentlines.com | 03:01 |
hunmonk | bzr: ERROR: Rsync could not use the specified location. Please ensure that "watchdog:bzr/apartmentlines.com/" is of the form "machine:/path" | 03:01 |
hunmonk | lifeless: if i run scp foo watchdog:bzr/apartmentlines.com | 03:01 |
hunmonk | lifeless: works perfectly | 03:01 |
hunmonk | lifeless: so i'm a bit confused what the issue is | 03:02 |
lifeless | hmm | 03:02 |
Odd_Bloke | hunmonk: The path you're giving isn't absolute, which the error message would suggest is required. | 03:02 |
lifeless | well spotted | 03:03 |
hunmonk | Odd_Bloke: full path doens't work, either | 03:03 |
lifeless | also, are you aware of push-and-update ? its a plugin | 03:03 |
lifeless | I would look in .bzr.log and see if anyting interesting is there | 03:03 |
lifeless | also perhaps try strace and snarf the actual rsync command line being tried | 03:03 |
hunmonk | lifeless: where is .bzr.log? | 03:06 |
hunmonk | home dir? | 03:06 |
* hunmonk looks | 03:06 | |
hunmonk | yup | 03:06 |
hunmonk | lifeless: http://pastebin.ca/949874 | 03:12 |
lifeless | rsync is erroring | 03:14 |
lifeless | strace is your friend | 03:14 |
hunmonk | lifeless: lol. no strace on my mac | 03:15 |
hunmonk | lifeless: guess it's time to hit fink... | 03:15 |
lifeless | truss perhaps ? | 03:15 |
hunmonk | nope | 03:15 |
lifeless | got to me some equivalent | 03:16 |
bob2 | dtrace11 | 03:16 |
lifeless | anyhow, rsync is existing with status 12 | 03:16 |
hunmonk | lifeless: doesn't scp use rsync as well? | 03:17 |
bob2 | no, scp is like cat over ssh | 03:17 |
lifeless | hunmonk: no | 03:17 |
hunmonk | oh | 03:17 |
mwhudson | 'ktrace' | 03:17 |
mwhudson | i think | 03:17 |
fullermd | I'd expect rsync is spitting an error somewhere. Try just running it manually. | 03:18 |
hunmonk | fullermd: yeah, that was my next thought as well | 03:18 |
hunmonk | lifeless: rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-30/rsync/io.c(359) | 03:20 |
hunmonk | lifeless: i've never seen that before :| | 03:20 |
fullermd | Why, of course! You forget to giblinetch the huntra in the config file. Duh | 03:21 |
bob2 | could any of your login scripts on the remote machine be printing something out? | 03:21 |
hunmonk | bob2: maybe | 03:22 |
hunmonk | lol | 03:27 |
hunmonk | lifeless: found the problem | 03:27 |
hunmonk | lifeless: no rsync installed on destination server :) | 03:27 |
abentley | lifeless: Do you want to preserve the code style differences between the loom plugin and bazaar? | 03:41 |
jml | I sense some restrained frustration there :) | 03:47 |
jml | poolie: how's the release going? | 04:04 |
jml | poolie: also, where's the branch for it? | 04:06 |
lifeless | abentley: which ones? | 04:07 |
abentley | The imports are the main thing I'm noticing. | 04:07 |
poolie | jml, http://bazaar-vcs.org/bzr/bzr.1.3 | 04:08 |
abentley | In bazaar proper, we hardly ever do "import bzrlib.merge", for example. | 04:08 |
abentley | It would be "from bzrlib import merge as _mod_merge" | 04:08 |
lifeless | abentley: oh, its because loom is old code | 04:08 |
abentley | Or possibly a direct object import. | 04:09 |
lifeless | abentley: it was written in the same style as bzr of the time | 04:09 |
* jml registers | 04:09 | |
abentley | By which I take it it's fine to use current Bazaar style in it? | 04:09 |
lifeless | totally | 04:09 |
abentley | Cool. | 04:09 |
abentley | I'm running into a test case failure because we can't represent a tree whose last_revision is NULL_REVISION that has pending merges. I think I'm going to drop it, but we should really fix that in Bazaar. | 04:11 |
lifeless | uhm | 04:16 |
lifeless | whats the reason for it ? | 04:16 |
lifeless | like is it an existing test | 04:16 |
lifeless | or a new one, and if new whats the use case? | 04:16 |
abentley | No, I'm writing a new test, and I got an unexpected error. | 04:17 |
abentley | I'm doing up_thread(); up_thread() | 04:17 |
abentley | The second up_thread raises cannot switch threads with anout of date tree. Please run bzr update. | 04:17 |
abentley | The underlying cause is that when last_revision is NULL_REVISION, tree.get_parents() is [] | 04:18 |
abentley | So adding a pending merge sets the lefthand parent. | 04:19 |
lifeless | right, thats currently by design | 04:20 |
lifeless | its consistent with our history storage too | 04:20 |
abentley | Well, intentional or not, it's a limitation on what Bazaar can do, and it's occasionally reported as a bug. | 04:22 |
lifeless | so I'm guessing your use case looks like | 04:23 |
abentley | And in this case, it's causing looms to give an error that doesn't make a lot of sense. | 04:23 |
lifeless | loomify, create-thread, down-thread, commit, up-thread | 04:23 |
abentley | And then up-thread again. | 04:23 |
lifeless | I would say in this case that up-thread leaving the new-thread the same as the bottom thread is actually fine | 04:23 |
abentley | So you're saying that if up-thread changes the last_revision, it should change it on the branch also? | 04:24 |
lifeless | uhm | 04:24 |
abentley | The bottom thread has a new revision. | 04:24 |
abentley | Call it X | 04:24 |
abentley | bzr up-thread will set X as the tree's last revision, but will set the branch's last_revision to NULL_REVISION | 04:25 |
abentley | You are saying it should set the branch's last_revision to X as well? | 04:26 |
lifeless | I think it should set X as the threads last revision in this specific case; which will change the branch's last-revision as teh branch is just reflecting the thread state. | 04:27 |
abentley | lifeless: What mechanism sets a thread's last revision? All I see being set is the branch and tree. | 04:31 |
lifeless | set_threads & _set_last_loom | 04:33 |
lifeless | see for instance LoomSupport.record_thread | 04:36 |
lifeless | thats the api you probably want to use here | 04:36 |
abentley | lifeless: up_thread is currently doing Branch.generate_revision_history. Swapping Branch.record_thread in breaks things horribly | 04:45 |
abentley | I'll leave it generating revision history, and update it so it sets it to X when appropriate. | 04:47 |
lifeless | abentley: you need both | 04:50 |
lifeless | abentley: here's why. | 04:50 |
lifeless | there is some duplicate data in the current loom branches, because of lazy-robert. | 04:51 |
lifeless | the duplicate data is the current branch tip in .bzr/branch/last-revision, and the current thread version of the same data in .bzr/branch/current-loom[branch.nick] | 04:51 |
lifeless | up-thread is normally just setting the last-revision to match the thread, but now it has to (sometimes) update the thread too | 04:52 |
abentley | But hardly anything updates the thread copy, right? | 04:52 |
abentley | Why isn't that calamitous? | 04:52 |
lifeless | abentley: with a last-loom format update to record the revno in each thread, we could drop last-revision from disk and remove the duplication | 04:55 |
lifeless | abentley: its not alamitous because looms hook in very lightly, and try to preserve regular branch behaviour as much as possible. | 04:56 |
abentley | But commit doesn't update the thread copy, so why should up-thread update the thread copy? | 04:56 |
lifeless | commit updates it | 05:01 |
lifeless | now I need to remember how | 05:01 |
lifeless | or if it doesn't then thats an interesting bug | 05:02 |
abentley | I was just assuming that the behavior was lazy enough that it didn't matter. | 05:02 |
lifeless | unlock does it | 05:04 |
lifeless | read the unlock code | 05:04 |
lifeless | so yes, you can be lazy here. | 05:04 |
lifeless | and just set branch.last_revision | 05:04 |
lifeless | as long as you'll be on the right thread when the branch is unlocked | 05:04 |
* poolie starts 1.3 packaging | 05:05 | |
poolie | lifeless, abentley: any opinions on my mail about testing for unreleased locks? | 05:09 |
abentley | As long as we do it, I don't care how. | 05:12 |
poolie | i think i will keep a list of held locks | 05:13 |
poolie | which is essentially what we're getting python to do for us, but in a flaky way | 05:13 |
lifeless | poolie: did we not plan this at allhands? | 05:13 |
lifeless | poolie: I thought the plan was to - provide a global event anyone can subscribe to which fires on lock and unlock | 05:13 |
poolie | it rings a bell, i can't recall what was decided though? i think we said what i just said | 05:13 |
lifeless | poolie: then add to the root TestCase a subscriber to that which accumulates lock/unlock events. And finally an addCleanup that asserts they are all matched. | 05:14 |
lifeless | this is better than a global list of locks | 05:14 |
poolie | k | 05:15 |
lifeless | its better because we can then write tests that test the number of locks actually taken/released by a command | 05:17 |
lifeless | and things like that | 05:17 |
poolie | right, that sounds good | 05:17 |
lifeless | it also doesn't depend on gc() having been run before the test finishes, or no-loops, and other such implementation details | 05:18 |
poolie | sure | 05:18 |
poolie | it's a strict superset | 05:18 |
poolie | of what i was proposing | 05:19 |
poolie | i'll send a patch for it | 05:19 |
lifeless | sweet | 05:19 |
lifeless | stab stab stab get_revision_graph | 05:20 |
poolie | "that, and a pair of testicles" | 05:20 |
poolie | makes me smile every time i make a release | 05:20 |
poolie | vale jdub | 05:20 |
poolie | welcome back tim | 05:26 |
poolie | it turns out jam's renvo code has some bugs. | 05:32 |
abentley | At least it doesn't have a pair of testicles. | 05:35 |
lifeless | who knows | 05:42 |
lifeless | hno in squid called bb bundlebunny the other day | 05:42 |
abentley | hehe. | 05:42 |
Odd_Bloke | jml: I'm struggling to get ``bzr merged-branches`` working at all. If I have a 'bzr' directory with 'bzr.dev' and my topic branches under it, how can I get it to tell me which of those topic branches have been merged? | 05:51 |
bob2 | that wasn't supported according to the release announcement | 05:53 |
lifeless | k, time to call it a week. | 05:54 |
lifeless | shee you folk tuesday; except for poolie of course :) | 05:54 |
bob2 | don't od on eggs | 05:54 |
Odd_Bloke | bob2: Right, but I can't work out what _was_ supported. | 05:55 |
lifeless | bob2: *blink* | 05:55 |
Odd_Bloke | lifeless: Happy Easter! | 05:55 |
bob2 | Odd_Bloke: ~/repository/bazaar/bzr/{trunk,fix-bug-41921921,make-foo-baz}, afaict | 05:56 |
poolie | hello bob, odd | 05:56 |
Odd_Bloke | bob2: Right, so I have a symlink from trunk to bzr.dev now, but am still getting odd errors. | 05:56 |
bob2 | Odd_Bloke: ah, sorry, I imagined a comma (with 'bzr.dev', and my topic branches under it) | 05:57 |
abentley | lifeless: Okay, I've merged in the up-thread stuff. Shall I do export-loom (with no default) too? | 06:03 |
lifeless | abentley: yes please; please be sure to do a merge into the trunk, or use a bound branch - I'd like the mainline to be like bzr's with only the result of feature branches, now that loom is released | 06:09 |
poolie | gack | 06:09 |
abentley | lifeless: Sure, I understand. | 06:09 |
abentley | To be safe, you should set append_revisions_only | 06:10 |
lifeless | how do I do that | 06:10 |
lifeless | is there an api call? | 06:10 |
lifeless | also, append_revisions_only doesn't enforce all that I want ;) | 06:10 |
poolie | bug 202778 killed my 1.3 merge | 06:10 |
ubotu | Launchpad bug 202778 in bzr "false test failure when run in a directory containing the version name" [High,Confirmed] https://launchpad.net/bugs/202778 | 06:10 |
poolie | oh well | 06:10 |
abentley | lifeless: Branch.set_append_revisions_only | 06:10 |
lifeless | it only prevents pivots; it doesn't prevent push as opposed to merge + commit | 06:11 |
abentley | Oh. Perhaps that's another flag we should support. | 06:11 |
abentley | Branch.set_commit_only_merges ? | 06:12 |
lifeless | abentley: something like that would represent want I want yes | 06:13 |
lifeless | abentley: but anyhoo I'm off | 06:13 |
* lifeless waves | 06:13 | |
abentley | Happy bunny time. | 06:13 |
peteshinners | Anyone have luck getting the eclipse plugin up? The updates site has no files according to eclipse? | 06:14 |
poolie | i'm going to trivial in http://pastebin.ubuntu.com/5915/ | 06:15 |
abentley | r=abentley | 06:16 |
poolie | thanks | 06:16 |
abentley | I think that could give a false success, though. | 06:19 |
poolie | that's true though | 06:19 |
abentley | If there was a file, but the version number was wrong. | 06:19 |
poolie | particularly on the directory name | 06:19 |
poolie | exactly | 06:19 |
poolie | maybe i should check it's in the first line | 06:19 |
poolie | or indeed the exact format of the first line | 06:20 |
poolie | hm | 06:20 |
abentley | Either one sounds good. I lean towards the second. | 06:21 |
poolie | good point, thanks | 06:21 |
poolie | are you in an unusual timezone or sleep pattern? | 06:21 |
poolie | http://pastebin.ubuntu.com/5916/ instead then | 06:28 |
Odd_Bloke | The comment seems superfluous now. | 06:29 |
poolie | you're right, thanks | 06:30 |
abentley | poolie: sleep pattern. | 06:34 |
Odd_Bloke | jml: I've done some work on the merged-branches plugin that's at https://code.launchpad.net/~daniel-thewatkins/+junk/merged-branches | 06:56 |
Odd_Bloke | It now takes a target branch and a directory (which defaults to '.'), uses a transport and has some better user feedback. | 06:57 |
jml | Odd_Bloke: thanks. | 07:18 |
* jml looks | 07:18 | |
Odd_Bloke | jml: I'm writing some tests ATM. :) | 07:22 |
jml | Odd_Bloke: thanks! | 07:23 |
poolie | ok i'm done, good nightall | 07:24 |
poolie | jml, 1.3 is out | 07:24 |
jml | poolie: thanks- | 07:24 |
poolie | jml, the tarball is up but the merge has not completed yet | 07:24 |
poolie | :/ | 07:24 |
jml | poolie: no worries | 07:25 |
jml | poolie: I'll probably submit it tomorrow anyway | 07:25 |
Odd_Bloke | poolie: Congrats! :) | 07:25 |
poolie | oh one more thing | 07:25 |
jml | yes? | 07:25 |
=== poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.3 is out 20 Mar | http://launchpad.net/bzr/1.3/1.3 | ||
poolie | that. | 07:25 |
poolie | cheers | 07:26 |
jml | heh heh | 07:26 |
poolie | actually i'm going to visit Oksh briefly | 07:26 |
poolie | see you | 07:26 |
=== RichardL_ is now known as rml | ||
Odd_Bloke | jml: Some rudimentary tests have been pushed. | 07:30 |
=== thekorn_ is now known as thekorn | ||
* awilkins yawns | 10:43 | |
awilkins | Dammit, 0400 hackathons do not suit me in my old age | 10:43 |
ubotu | New bug: #204211 in bzr-svn (universe) "Displays a version warning on every operation" [Undecided,New] https://launchpad.net/bugs/204211 | 11:56 |
=== kiko-zzz is now known as kiko | ||
nekohayo | mmmh, is there a way to use bzr-svn without the breakalot rich-root-format? or convert rich-root into pack-92 or something? | 12:52 |
dato | nekohayo: no, bzr-svn needs rich-root. what's your problem with it? | 12:53 |
nekohayo | well, the fact that it seems to break :) https://bugs.launchpad.net/bzr/+bug/177874 | 12:54 |
ubotu | Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Medium,Confirmed] | 12:54 |
nekohayo | so I was wondering if there was a way around it | 12:55 |
nekohayo | more precisely I am the one who reported https://bugs.launchpad.net/bzr/+bug/202884 | 12:56 |
ubotu | Launchpad bug 202884 in bzr "can't merge (dup-of: 177874)" [Undecided,New] | 12:56 |
ubotu | Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Medium,Confirmed] | 12:56 |
abentley | nekohayo: There are some problems with upgrading to it. I'm not aware of any problems for branches that are already in it. | 13:33 |
nekohayo | abentley: well merging dirstate into rich-root fails | 13:34 |
Qhestion | why is the description of a command in the output of "bzr help" indented to column 19 (starting with 1)?? shouldnt that be 20 ?? | 13:34 |
Qhestion | http://en.wikipedia.org/wiki/Off-by-one_error ?? | 13:35 |
abentley | nekohayo: Are you talking about the general case, or about the Bazaar source tree? | 13:35 |
nekohayo | what do you mean? | 13:35 |
abentley | The Bazaar source tree has some weirdness in it that is going to require extra care to upgrade. | 13:35 |
=== mrevell is now known as mrevell-lunch | ||
abentley | The bug you referenced is an upgrade of the source tree to Bazaar itself. | 13:36 |
abentley | Now you're talking about merge of dirstate failing. | 13:37 |
abentley | But I don't know if you're talking about the Bazaar source base in particular, or some other source base. | 13:37 |
nekohayo | abentley: yeah, my bug is #202884, but it was marked a duplicate | 13:37 |
abentley | nekohayo: Is this a really old branch? | 13:40 |
nekohayo | abentley: the one in rich-root is a freshly made one from svn, and the other one is dating back from the summer I think | 13:41 |
abentley | So the revision in the example is from 2007-05-17. At that time, we supported unique root ids in our development version, for a while. I don't believe it was in any released version. | 13:44 |
nekohayo | abentley: that is what makes things break? | 13:45 |
nekohayo | any way to have bzr convert that? | 13:45 |
abentley | That's what's been diagnosed so far. | 13:45 |
abentley | I haven't looked at your particular branch. | 13:45 |
abentley | Though I was going to. | 13:46 |
abentley | To answer your original question, rich-root is mandatory for bzr-svn. It was created especially for bzr-svn. | 13:46 |
nekohayo | aah, that explains. the fact that there are multiple formats kind of puzzled me | 13:47 |
abentley | nekohayo: I have inspected your branch, and it does have a unique id for the tree root. So it's the same *root* cause :-) | 13:49 |
nekohayo | what is that unique id thing? | 13:49 |
nekohayo | isn't an "ID" unique by definition ?_? | 13:50 |
abentley | In pre-2007 trees, the root directory always has an ID of "TREE_ROOT" | 13:51 |
abentley | Trees created in the rich-root format always have unique IDs. | 13:51 |
abentley | We're working on making a rich-root format the default. It will be a slight tweak of rich-root-pack. | 13:53 |
nekohayo | abentley: so can this be converted or salvaged without using the method "create a giant patch and lose history"? | 13:58 |
abentley | We haven't yet got a solid patch that fixes it. You might be able to re-generate the history using rebase. | 14:02 |
abentley | This would preserve metadata such as your comments, but would generate new revision-ids. | 14:03 |
nekohayo | oh, but once such a patch comes in bzr, it should heal itself ? | 14:03 |
abentley | Yes, we'll support that conversion one way or another. | 14:04 |
=== mrevell-lunch is now known as mrevell | ||
=== ja1 is now known as jam_ | ||
=== jam_ is now known as ja1 | ||
=== ja1 is now known as jam | ||
=== mw|out is now known as mw | ||
ubotu | New bug: #125751 in bzr-svn "Push raises exception about invalid property changes" [Medium,Fix released] https://launchpad.net/bugs/125751 | 15:26 |
lnxtech | Which repository format has the best performance (or will be the new standard in future releases)? I will be the only developer using the repo so I'm not concerned about backwards compatibility. | 15:40 |
dato | lnxtech: the current default, pack-0.92 | 15:43 |
lnxtech | thanks | 15:45 |
=== kiko is now known as kiko-afk | ||
stammi | hi | 16:41 |
statik | poolie: i don't see any ops in this channel, i suspect announcer is still banned. i've fixed it now, know what I should do to get the ban lifted? | 16:42 |
* jdong taps jelmer's shoulder... | 16:45 | |
jdong | bzr co on bzr-svn doesn't exactly create a "bound branch" , does it? | 16:45 |
ubotu | New bug: #204320 in bzr ""bzr patch" internal error" [Undecided,New] https://launchpad.net/bugs/204320 | 16:46 |
jdong | I tried a bzr co svn+file:///some/svn/repo on system foo, then on bar I did bzr co sftp://foo/bzr/checkout | 16:46 |
jdong | then when on bar I tried to ci, I got some sort of svn assertion error | 16:46 |
jdong | then I checked bzr info and apparently everything was some sort of svn format, not standard rich-root-pack bzr branches | 16:47 |
abentley | staik: The ops don't usually fly their flag. Hmm, how do I get ops again? | 16:53 |
dato | /msg ChanServ op #bzr abentley | 16:53 |
dato | I think | 16:53 |
jam | abentley: well /op user is used to give ops to 'user', but I think you have to be op first :) | 16:54 |
abentley | Anyone know the syntax for listing/altering bans? | 16:55 |
abentley | help /op | 16:58 |
jam | abentley: looking at plain help, I only see /kick, and no /ban | 16:58 |
abentley | I think it's a mode you set on a wildcard. | 16:58 |
jam | abentley: then '/help mode' | 16:58 |
abentley | something like /mode +b *announcer* | 16:59 |
jam | So /mode -b nick | 16:59 |
jam | something like that | 16:59 |
Parker- | /mode -b *!*announce@* | 17:00 |
stammi | is there any chance to check out a svn repository with bzr via https? | 17:00 |
stammi | it seems to fail, while svn works | 17:01 |
stammi | i tried bzr svn-import https://subversion..... as well as bzr co | 17:02 |
stammi | it responds with 401 Auth required | 17:02 |
james_w | stammi: try svn+https://... | 17:03 |
abentley | statik: How you like it now? | 17:04 |
Parker- | /mode -b *!announce@165.198.204.68.cfl.res.rr.com | 17:05 |
Parker- | ;) | 17:05 |
stammi | it says "No Repository found at ... use bzr branch" if i do so there comes a legthy error which essentially says SubversionException: ("Undefined tunnel scheme 'https'" | 17:05 |
Parker- | abentley, after that there is no bans | 17:05 |
statik | abentley: thank you, we should see it work when the next PQM commit mail comes through | 17:05 |
dato | statik: shouldn't it join the channel first? | 17:06 |
dato | or will it auto-join by then? | 17:06 |
statik | dato: it is supposed to auto-join when it has something to announce | 17:06 |
dato | ok | 17:06 |
abentley | statik: Okay, holler if it doesn't work. | 17:06 |
* stammi just recently noticesd to be out of vcs for the next two weeks | 17:07 | |
statik | but, I don't really have a good way to see the response from the IRC server to the IRC-talking part of the bot, I'm just re-using radix's publish-bot | 17:07 |
statik | abentley: thanks for the help | 17:07 |
j^ | hi, is it possible to import tags from svn? | 17:17 |
jelmer | j^: yes, but only as branches not as bzr tags yet | 17:24 |
jelmer | stammi: Looks like your subversion library wasn't built with http support | 17:25 |
jelmer | jdong: still there? | 17:26 |
jdong | jelmer: yeppers | 17:27 |
jelmer | jdong: you can't make a checkout of a checkout in bzr | 17:27 |
j^ | jelmer, i was hoping for bzr tags, getting the revision numbers and creating the tags should not be to hard | 17:27 |
jdong | jelmer: oh. | 17:27 |
jelmer | (which if I understand correctly, is what you're trying to do) | 17:27 |
jdong | jelmer: I didn't know that :) well that explains a lot | 17:27 |
stammi | jelmer, have ubuntu 7.10 and installed bzr-svn | 17:27 |
stammi | and its https not http | 17:28 |
jelmer | stammi: the svn+https:// / svn+http:// syntax was broken in bzr-svn 0.4.1, which is what is in gutsy | 17:28 |
stammi | jelmer, so i should just manually install bzr from the homepage? | 17:28 |
j^ | there is a newer version in guty-backports | 17:28 |
stammi | ahh ok | 17:29 |
stammi | thx jelmer | 17:32 |
jelmer | j^: it's not trivial since tags may be in different locations across svn repositories | 17:44 |
j^ | true, is there a way to map svn revision to the one used in bzr, that way one could collect the revision numbers and run a script to apply the tags, right now i would have to look up the commit message, find the one in bzr and map the revision that way | 17:46 |
jelmer | j^: just taking the revision in which the tag was created in svn won't help | 17:47 |
jelmer | since that will be a revision that's not actually in your bzr branch | 17:48 |
jelmer | you would have to take the revision from which the tag was created | 17:48 |
jelmer | but that's not going to be correct in a lot of cases either, since the revision that created the tag could also have slightly modified it | 17:48 |
=== thekorn_ is now known as thekorn | ||
=== jw2328_ is now known as james_w | ||
j^ | what could cause | 17:55 |
j^ | SubversionException: ("PROPFIND request failed on '/!svn/bc/12853/trunk/foobar'", 175007) | 17:55 |
jelmer | does "svn log -r12853 <repos-url>" work? | 17:57 |
j^ | ------------------------------------------------------------------------ | 17:59 |
j^ | is all i get | 17:59 |
=== lamont` is now known as lamont | ||
jelmer | j^: is this a public branch? | 18:03 |
j^ | at that revision there is nothing in svn log, its one before the trunk was moved from a branch | 18:04 |
j^ | https://svn.xiph.org/trunk/theora | 18:04 |
jam | statik: you should have a new pqm email | 18:30 |
jam | I just had a patch merged | 18:30 |
statik | jam: cool, i hope we see an announcement in a couple of minutes | 18:31 |
grutte_pier | Does anyone know what happened to the webserve plug-in? | 18:40 |
james_w | grutte_pier: it's still going | 18:41 |
grutte_pier | So which url should i branch from then? on the webpage there is a 'download' link and an 'URL to branch' link | 18:43 |
grutte_pier | the former gets me an 500-error (Internal Error) | 18:43 |
grutte_pier | the latter gets me the source-code of some webpage | 18:43 |
james_w | https://code.launchpad.net/~bzr/bzr-webserve/webserve-dev | 18:43 |
grutte_pier | thanks a lot! Is there a way that I could or should have found this link myself? | 18:45 |
james_w | grutte_pier: I'm not sure, maybe we should contact the author to update his webpage. | 18:46 |
james_w | Note that launchpad is just mirroring his branch, so I imagine that he has reorganised things at some point and not updated the webpage. | 18:46 |
grutte_pier | sounds like something that could easily happen..... | 18:51 |
blueyed | What's the reason that e.g. "bzr status" does not list the files relative to the current working directory, but to the branch root? | 19:10 |
blueyed | It's not as easy to select filenames for further actions then, e.g. by doubleclicking them. | 19:11 |
LeoNerd | Because there might be more files modified than just within cwd | 19:12 |
LeoNerd | So how do you display those? | 19:13 |
blueyed | LeoNerd: well, good point for commands on the branch, but with e.g. "bzr st ." there's a path given.. | 19:14 |
blueyed | otherwise they could get prepended with "../" anyway. | 19:14 |
yacc | What's the recommened way to push a local bzr branch to a fresh (not yet existing) SVN url? | 19:15 |
ubotu | New bug: #204370 in bzr "bzr bombs during push to svn" [Undecided,New] https://launchpad.net/bugs/204370 | 19:15 |
yacc | nice ubotu detected my bug report ;) | 19:15 |
fbond | Hi, using bzr-svn I get "CHECKOUT of ...: authorization failed" when trying to push to the repository... | 19:25 |
fbond | bzr-svn 0.4.7 | 19:25 |
fbond | bzr 1.2.0 | 19:25 |
fbond | What do I need to do? | 19:25 |
fbond | svn has my credentials cached already. | 19:25 |
fbond | I'm pushing over http | 19:25 |
yacc | ahhh, the newest version of bzr-svn works for bzr 1.1 *weep* | 19:25 |
fbond | yacc: but not for 1.2.0? | 19:26 |
yacc | Well, the wiki page shows only versions for up to 1.1 ;( | 19:34 |
yacc | Please anybody tell me that there is svn support for current bzr versions? | 19:38 |
nekohayo | hm, is there people working primarily on bzr-gtk? | 20:02 |
ubotu | New bug: #151825 in bzr-gtk "jumping progressbars" [Undecided,New] https://launchpad.net/bugs/151825 | 20:03 |
ubotu | New bug: #125144 in bzr-gtk "Crashes when directory contains broken symlink" [Undecided,Confirmed] https://launchpad.net/bugs/125144 | 20:06 |
jelmer | nekohayo: yeah | 20:09 |
nekohayo | ok, so I assume my pile of bugs (a few of them with patches) were not seen | 20:11 |
nekohayo | so I'm changing them all to be assigned to bzr-gtk | 20:11 |
yacc | fbond: ok, the branch seems to be maintained :) => but the current head seems to work only with bzr >= 1.3 ;) | 20:24 |
yacc | It still bombs :( | 20:32 |
awmcclain | Is it possible to import a single file into my repo? | 20:40 |
awmcclain | Or do I have to import the containing directory like SVN? | 20:41 |
yacc | awmcclain: any repo is a directory so logically speaking your question does not make much sense ;) | 20:54 |
awmcclain | yacc: s/repo/branch | 20:55 |
awmcclain | :P | 20:55 |
yacc | Yeah, still your question makes no sense ;) | 20:55 |
awmcclain | Is it possible to commit a single file which does not live under an existing branch into a branch. I'm pretty sure the answer is no. | 20:56 |
awmcclain | Hrm. Can you check out or branch a subset of a working tree? | 20:57 |
dato | those are two different questions? | 20:58 |
awmcclain | yes | 20:58 |
dato | ok | 20:58 |
dato | (b) you can't do partial checkouts | 20:58 |
awmcclain | hrm | 20:58 |
awmcclain | Okee doke. | 20:58 |
dato | (a) I'm failing to see your question, how's what you ask different to `bzr add $FILE` ? | 20:58 |
awmcclain | dato: Becauase I'm guess bzr add $FILE will only work if the containing directory is in a working tree | 20:59 |
awmcclain | I'm trying to collect a bunch of conf files scattered about into source control | 20:59 |
dato | well | 21:00 |
dato | the file has to be underneath the branch, of course | 21:00 |
awmcclain | I'll just put them in a directory and then move from there | 21:00 |
yacc | bzr: ERROR: Revision {('andreas@andi-lap-20080318110425-b4uvstmj62j90z2s',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xb6c6a30c>". | 21:12 |
yacc | on upgrade --rich-root-pack | 21:12 |
Peng | yacc: Known issue. | 21:12 |
yacc | Yeah, but what do I do, considering that I should deliver my stuff today? | 21:13 |
=== kiko-afk is now known as kiko | ||
yacc | Trying to do a svn-push I'm getting an error too :( | 21:13 |
Peng | yacc: I don't know of a solution. | 21:14 |
yacc | Well, I can try to revert to bzr 1.1, and see if that helps, ... | 21:14 |
Peng | I dunno. | 21:15 |
kiko | abentley, ping? | 21:20 |
abentley | kiko: pong | 21:20 |
kiko | abentley, do you have any advice for yacc's problem above? | 21:20 |
abentley | At this point, we don't have a fix for that. | 21:22 |
kiko | abentley, what's the source of the problem? | 21:22 |
yacc | abentley: basically bzr svn-push craps out with the "SubversionException: ('At least one property change failed; repository is unchanged', 175008)" problem ;( | 21:23 |
* yacc had such high hopes to have escaped svk, ... | 21:23 | |
abentley | Wait, which is your bug? SubversionException or Revision not present? | 21:24 |
yacc | abentley: SubversionException. README in bzr-svn (I think, might been google) suggested that an upgrade --rich-root-pack might be useful, ... | 21:25 |
abentley | Which version of bzr-svn have you been using? | 21:26 |
yacc | head of stable with bzr 1.3 | 21:26 |
yacc | Now I'm downgrading to bzr 1.1rc1 in Debian, that include bzr-svn 0.4.7 I think. | 21:26 |
yacc | Well, bzr1.1 gives me the "at least one property changed" traceback too :( | 21:27 |
abentley | bzr plugins should tell you the version number | 21:28 |
yacc | 0.4.7 | 21:28 |
yacc | and bzr 1.1 | 21:28 |
yacc | Same error as it was with bzr 1.3/stable-head | 21:28 |
abentley | So "stable-head" doesn't help me understand what's going on. | 21:29 |
abentley | There was a major change at 0.4, and if you're using something earlier, the scenario is completely different. | 21:29 |
yacc | stable head == an hour old pull from the branchurl on the plugins wiki page. | 21:29 |
yacc | No it's the newest one. | 21:30 |
dato | yacc: trunk, or the bzr-0.4 branch? | 21:31 |
yacc | http://people.samba.org/bzr/jelmer/bzr-svn/stable/ | 21:31 |
abentley | Okay, so if you do bzr info -v in your branch, what does it say about formats? | 21:32 |
yacc | dato: no idea which branch is stored at that url. | 21:32 |
yacc | you mean the one that I try to push to svn? | 21:32 |
abentley | yacc: yes | 21:32 |
yacc | control: Meta directory format 1 | 21:32 |
yacc | working tree: Working tree format 4 | 21:33 |
yacc | branch: Branch format 6 | 21:33 |
yacc | repository: Packs containing knits without subtree support | 21:33 |
abentley | So is this a branch that you originated in Bazaar? | 21:33 |
yacc | Yes, it orginated from a bzr init (with bzr 1.1rc1) | 21:33 |
yacc | I wonder if it would help to push an empty bzr branch first to the SVN url, ... | 21:34 |
yacc | any ideas how to get the stuff into svn? | 21:35 |
abentley | Could you run this and tell me what the output is? | 21:36 |
abentley | python -c 'from bzrlib.workingtree import WorkingTree; wt=WorkingTree.open("."); wt.lock_read(); print wt.inventory.root.file_id; wt.unlock()' | 21:36 |
abentley | You need to run it in your working tree. | 21:36 |
yacc | TREE_ROOT | 21:37 |
abentley | Well, that's normal. I don't know why upgrade would be a problem. | 21:38 |
abentley | I don't think you'll be able to push into svn until you change your format. | 21:39 |
yacc | Well, it complains that a version does not exist where it expects it. but technically speaking the upgrade is less of an issue for me, bzr-svn is :( | 21:39 |
yacc | To which format? | 21:39 |
abentley | I would recomment rich-root-pack. | 21:39 |
yacc | Well, rich-root-pack and rich-root both complain about non-existing versions, and it seems to be a known bug :( | 21:40 |
dato | abentley: fwiw pushing from !rich-root to svn works just fine. I use it in one of my projects. | 21:41 |
abentley | dato: Ah, okay. It's been a while since I used bzr-svn. | 21:41 |
yacc | Any hints that I can try? | 21:41 |
abentley | We probably need Jelmer to debug the SubversionException. | 21:42 |
abentley | jelmer: ping | 21:43 |
abentley | It sounds like the upgrade's not necessary, and we're planning to fix it for branches like yours. | 21:43 |
yacc | Which timezone jelmer is in? | 21:43 |
dato | CET | 21:44 |
james_w | UTC+1 I think. | 21:44 |
james_w | hi dato | 21:44 |
abentley | yacc: One thing you could try is running "reconcile". | 21:44 |
yacc | reconcile? | 21:45 |
abentley | ie "bzr reconcile". | 21:45 |
dato | hi james_w. I meant to ask you the other day, were you in dc7? | 21:45 |
james_w | dato: nope. | 21:45 |
yacc | abentley: what does reconcile do? | 21:46 |
dato | ok. then no regrets I didn't meet you :-P | 21:46 |
yacc | abentley: same SubversionError :( | 21:46 |
james_w | dato: :-) | 21:46 |
james_w | dato: are you going to dc8? | 21:46 |
abentley | yacc: Running reconcile in your repository gives you a SubversionError? | 21:46 |
yacc | no, but doing a svn+push after the reconcile. | 21:47 |
yacc | the reconcile did fine. | 21:47 |
abentley | bzr reconcile corrects some kinds of data inconsistency. | 21:47 |
yacc | Whatever it did. | 21:47 |
dato | james_w: it's going to be a bit complicated, but so has been the previous 3 times and I always managed. but maybe I'm overconfident this time. :-) | 21:47 |
abentley | Does the upgrade work? | 21:47 |
yacc | abentley: but the upgrade to rich root pack did work :) | 21:47 |
yacc | The question is if that will help the svn+push or not. | 21:48 |
yacc | Nope, same thing as before. | 21:48 |
abentley | I don't know enough about bzr-svn to understand that error. | 21:49 |
abentley | I'm glad the upgrade worked, but you may want to go back. | 21:50 |
abentley | It depends on whether you're expecting to pull/merge from bzr-svn. | 21:51 |
yacc | Well, for the moment I'm the only one that will be commiting around that svn path ;) | 21:52 |
yacc | I might try it out if pushing to my private svn repo works. | 21:52 |
abentley | Probably you should stick with it. | 21:52 |
abentley | Existing projects shouldn't convert to rich-root-pack unless all their members are willing to upgrade. | 21:53 |
abentley | But yours is a new project, so it doesn't matter. | 21:53 |
yacc | abentley: basically, I'm having a high level of aversion against svn, svk and git-svn, that doesn't leave many options when you need to work with a svn repo ;( | 21:53 |
yacc | abentley: mine is a project where nobody but me will see the bzr branch, because all other will be pulling it from svn. | 21:54 |
abentley | What's the command you're running? push or svn-push? | 21:54 |
yacc | svn-push | 21:54 |
yacc | push gives an IndexError. | 21:54 |
yacc | Googling the error returns basically only the bzr-svn problems and one old svn error which was fixed back then by upgrading the svn client version, ... | 21:55 |
abentley | yacc: Do the permissions on your SVN repo forbid changing revision properties? | 21:55 |
yacc | abentley: as this is a public svn repo server, I have no idea. | 21:56 |
yacc | abentley: but that's an interesting theory. | 21:56 |
abentley | I know it's a configurable option. | 21:56 |
yacc | abentley: It will most probably forbid changing revprop. | 21:56 |
dato | both for SVN and bzr-svn | 21:56 |
dato | i.e. bzr-svn does not do it by default | 21:57 |
yacc | abentley: Actually it's a hook that decides which properties you are allowed to change. | 21:57 |
yacc | dato: What? | 21:57 |
dato | my understanding is that bzr-svn uses properties in a way that is allowed by default in SVN repositories | 21:57 |
dato | and then it has a switch to override svn:date and svn:author, but I don't know if this was abentley meant or not | 21:58 |
yacc | dato: which switches. | 21:58 |
dato | or maybe your repo is forbiding even the kind of safe properties bzr-svn needs, though it sounds unlikely | 21:59 |
yacc | svn:date won't be overrideable in that repo for sure. | 21:59 |
dato | % grep override ~/.bazaar/bazaar.conf | 21:59 |
dato | override-svn-revprops = True | 21:59 |
yacc | dato: I have no bazaar.conf ;) | 22:00 |
dato | k | 22:00 |
abentley | yacc: You are allowed to create one :-) | 22:00 |
yacc | abentley: yeah, but where do I learn about the options/sections (assuming that it's a ConfigParser thing) | 22:01 |
abentley | It's ini format. There are no mandatory sections. | 22:01 |
abentley | bzr help configuration will tell you about Bazaar's options, but not bzr-svn's. | 22:02 |
yacc | Yeah, but where does that override-svn--revprops belong to? | 22:02 |
dato | I have in [DEFAULT] | 22:02 |
abentley | But DEFAULT is optional. | 22:03 |
yacc | Now, it would be highly interesting what the default for it is. | 22:03 |
dato | aha | 22:03 |
dato | I'm sure it defaults to False | 22:03 |
abentley | You can just have a single-line file with "override-svn-revprops = True" | 22:03 |
yacc | Well, technically it defaults to None, but yes that's false too *g* | 22:05 |
yacc | Ok, the SubversionError is raised in something that looks like a decorator that catches SVN exceptions. | 22:05 |
yacc | How does one set the debug.debug_flags in bzr? | 22:07 |
abentley | With -Dfoo | 22:08 |
abentley | where foo is the flag you want to set. | 22:08 |
yacc | So let's see what bzr-svn is doing before it the bad thing happens :) | 22:10 |
yacc | abentley: see you are bad. You made me start debugging myself, | 22:10 |
yacc | ;) | 22:11 |
abentley | You could also try doing import pdb; pdb.set_trace() in the final else clause of convert_error | 22:12 |
yacc | Well, it's one of these then: | 22:12 |
yacc | setting revision property 'bzr:file-ids' to '\tTREE_ROOT\n.bzrignore\tbzrignore-20080314001943-npoqulq31axmxa8g-1\nez_setup.py\tez_setup.py-20080314002020-4ktxnl1abormwysn-1\nsetup.py\tsetup.py-20080314002020-4ktxnl1abormwysn-2\nlookery\tlookery-20080314002159-q2mdytaryo7wbdcf-1\nlookery/__init__.py\t__init__.py-20080314002211-5qqxrkuk0wqqoyvi-1\nlookery/lib\tlib-20080314002211-5qqxrkuk0wqqoyvi-2\nlookery/lib/apachelog.py\tapachelog.py-200803140022 | 22:12 |
yacc | 11-5qqxrkuk0wqqoyvi-4\nlookery/lib/__init__.py\t__init__.py-20080314002211-5qqxrkuk0wqqoyvi-3\nlookery/scripts\tscripts-20080314011426-ok2xe2a2a4am6oot-1\nlookery/scripts/llfp.py\tllfp.py-20080314011426-ok2xe2a2a4am6oot-3\nlookery/scripts/__init__.py\t__init__.py-20080314011426-ok2xe2a2a4am6oot-2\n' | 22:12 |
yacc | setting revision property 'bzr:revision-info' to 'timestamp: 2008-03-14 02:15:10.638999939 +0100\ncommitter: Andreas Kostyrka <andreas@andi-lap>\nproperties: \n\tbranch-nick: lookery\n' | 22:12 |
yacc | setting revision property 'bzr:revision-id:v3-single-trunk/logs/Lookery-Base' to '1 andreas@andi-lap-20080314011510-z091afzyx1t7i3gq\n' | 22:13 |
yacc | abentley: I'm not big on pdb style debugging. Lucky for me bzr-svn is not in an egg, so adding prints is not exactly hard. | 22:13 |
=== Toksyuryel` is now known as Toksyuryel | ||
abentley | Acutally, it would be better if convert_error just did "raise" when it couldn't convert. | 22:17 |
abentley | That would give a more useful traceback. | 22:18 |
rindolf | Hi all. | 22:18 |
rindolf | I'm trying to do {{{ bzr export http://www.gnome.org/~jdub/bzr/planet/2.0/ }}} but it tells me "not a branch". | 22:19 |
rindolf | What's the equivalent of svn export URL in bzr? | 22:19 |
abentley | rindolf: I don't know svn. In bazaar, it creates a copy of the working tree files, optionally gzipped, tarred, zipped, etc. | 22:20 |
dato | abentley: but does it work over remote? | 22:20 |
dato | oh, you'd need to give it a second arg | 22:21 |
rindolf | dato: thanks. | 22:21 |
james_w | rindolf: bzr export target http://www.gnome.org/~jdub/bzr/planet/2.0/ | 22:21 |
dato | rindolf: personally I'd recommend you just clone instead of export, for easy updating | 22:21 |
rindolf | james_w: thanks. | 22:21 |
dato | rindolf: but your choice :) | 22:21 |
rindolf | OK, it's making slow progress. | 22:21 |
rindolf | dato: problem is that at the moment, my Internet connectivity sucks. | 22:22 |
yacc | Now I wonder if there is a doc on the SVN API somewhere ;) | 22:22 |
rindolf | blame my ISP. | 22:22 |
james_w | yacc: I have found API docs | 22:22 |
abentley | rindolf: Also, it's in an older, less-efficient format. | 22:23 |
james_w | I found them to be under-documented, but at least better than un-documented | 22:23 |
yacc | james_w: me too ;) | 22:23 |
rindolf | abentley: what is? | 22:23 |
abentley | http://www.gnome.org/~jdub/bzr/planet/2.0/ is in a slower format. | 22:24 |
yacc | That's cool, http://svn.collab.net/svn-doxygen/search.php?query=change_dir_prop gives me the HTML source including PHP ;) | 22:24 |
yacc | Well, at least there is google ;) | 22:25 |
abentley | http://svn.collab.net/svn-doxygen/structsvn__delta__editor__t.html#o11 | 22:26 |
awmcclain | Is 1.2 in gutsy yet? | 22:27 |
abentley | awmcclain: No idea, but packages.ubuntu.com should know. Or you can use our gutsy APT repository. | 22:29 |
awmcclain | abentley: Yeah, it's only at 0.9. Thanks! | 22:29 |
abentley | awmcclain: If you mean *our* repository is at 0.9, that is unlikely. 0.9 was released in 2006 | 22:31 |
awmcclain | No no gutsy. I'm using 1.2 from your repository now. | 22:32 |
abentley | Gutsy includes 0.90, not 0.9 | 22:33 |
abentley | gutsy-backports has 1.0 | 22:33 |
jdong | I will update backports to bzr 1.3 if Hardy is going to get it plus bzr-svn and friends. | 22:36 |
* abentley is completely disconnected from the Ubuntu release cycle. | 22:37 | |
jdong | who typically takes care of Ubuntu packaging for bzr? | 22:38 |
dato | jdong: package just migrates from debian | 22:39 |
dato | (fwiw I'll upload 1.3 to debian tomorrow; rc1 is in atm) | 22:39 |
james_w | jdong: I can't remember who did the last sync, someone just pinged me on IRC one day to confirm that they had all the necessary bits together. | 22:40 |
james_w | I wasn't going to FFe for 1.3 in Hardy. I've just submitted a patch to get bzr-svn to stop complaining about version mismatch. | 22:40 |
jdong | james_w / dato: Ok, I'll take some time later tonight to look into this; I'd like to ensure we freeze Hardy with the latest bzr release in there. | 22:40 |
dato | james_w: are the syncs manual at this point? | 22:40 |
jdong | dato: have been for a long time | 22:41 |
james_w | dato: yes, and they have been for a while. | 22:41 |
james_w | dato: thanks to your work it's just a quick test and a manual sync though. | 22:41 |
jdong | james_w: unless bzr devs have any objection/hesitation, I'd have no problem FFe'ing bzr. I don't think any of the folks will complain | 22:41 |
jdong | everyone in Ubuntu-land loves bzr anyway :) | 22:42 |
james_w | *almost* everyone :-) | 22:42 |
dato | *g* | 22:42 |
james_w | jdong: I don't think anyone will mind. I was just wary as it will be post-beta. | 22:43 |
james_w | jdong: but I haven't got a feel for the Ubuntu release cycle yet, so that may be quite common. | 22:43 |
jdong | james_w: normally I would be too, but you guys have such a solid track record | 22:43 |
james_w | jdong: that's true. And there will probably be a boat load of fixes in there. | 22:44 |
jdong | james_w: indeed | 22:44 |
james_w | well the 1.3 NEWS is a little smaller than usual due to all the sprints/conferences etc. this month. | 22:44 |
jdong | james_w: I'd rather not have a LTS kick off with outdated bzr :) | 22:44 |
james_w | jdong: yeah, let's go for it. Anything you would like me to do? | 22:45 |
jdong | well I think I'll have time later tonight to research the bits; just poke me when the Debian package is uploaded :) | 22:45 |
james_w | jdong: sure. Though I will be online for limited periods this weekend. | 22:46 |
jdong | ok | 22:46 |
james_w | dato: would you mind poking jdong when you upload 1.3? | 22:46 |
dato | sure | 22:46 |
james_w | The only other thing I haven't seen an upload for is bzr-gtk, is there a new release available? | 22:46 |
james_w | dato: great, thanks. | 22:46 |
james_w | jdong: you'll need bzr-svn as well I think, and I'd like it if you took bzr-builddeb as well. | 22:47 |
dato | and bzrtools | 22:47 |
james_w | oh, of course. | 22:47 |
=== mw is now known as mw|out | ||
=== kiko is now known as kiko-afk |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!