[00:12] <maxb> What is the actual format of dump-btree --raw on a .rix /
[00:12] <maxb> ?
[00:19] <spiv> maxb: in what sense?  you mean where is there a description of how to parse that format?
[00:21] <spiv> maxb: the docstring for bzrlib.btree_index.BTreeBuilder is probably a decent reference
[00:22] <maxb> seems so
[00:22] <maxb> I'm peeking at that corrupt openobject branch
[00:22] <spiv> (Despite the embarrassing mistake in the definition of the _SIGNATURE part...)
[00:22] <maxb> There's something very dodgy in the .rix of the last pack - it contains CR bytes!
[00:25] <spiv> Ooh, wacky!
[00:25] <spiv> After decompression?
[00:26] <maxb> after dump-btree --raw
[00:26] <thumper> spiv: hi
[00:27] <thumper> ErrorFromSmartServer: Error received from smart server: ('error', 'Error -3 while decompressing: incorrect data check')
[00:27] <thumper> spiv: is there a repair thing I can use on the server side?
[00:27] <thumper> spiv: or are we talking restore from backup?
[00:27] <maxb> That sounds like the branch I was looking at :-)
[00:27] <thumper> maxb: maybe
[00:28] <thumper> maxb: more like hopefully
[00:28] <thumper> maxb: which branch are you looking at?
[00:29] <spiv> thumper: "that corrupt openobject branch"
[00:30] <thumper> spiv: yeah
[00:32] <maxb> ~openerp/openobject-addons/trunk to be precise
[00:34] <maxb> well that's disconcerting.
[00:34] <maxb> I spliced the latest pack out of pack-names, and attempted to branch a revision left in the result.
[00:34] <maxb> It still died
[00:41] <wallyworld_> quick ? - i have a lw co of launchpad branch db-devel. bzr info says submit branch is devel, i want to change it to db-devel. i tried editing the branch.conf with submit_branch = ... but no luck. any ideas?
[00:43] <spiv> maxb: hmm :(
[00:44] <maxb> Well that's bad. The busticated content is in a GC block in the oldest largest pack file in the branch
[00:45] <maxb> wallyworld_: I don't usually use lw cos, but I would tend to assume that they would not even have a branch.conf
[00:45] <spiv> wallyworld_: did you edit the .bzr/branch/branch.conf in the checkout?  That doesn't exist.  It only applies to the branch.
[00:46] <spiv> maxb: ouch
[00:52] <wallyworld_> spiv: i think i created a branch.conf file with submit_branch= in it hoping that would work
[00:54] <wallyworld_> my workflow:  bzr checkout --lightweight bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel db-devel
[00:55] <wallyworld_> this creates a local copy which i then branch from as required: bzr branch db-devel mynewbranch
[00:55] <maxb> Unless your development workstation is in the launchpad datacentre, I wouldn't recommend using a lightweight checkout
[00:56] <wallyworld_> what i do is create a "master" lw co and then have several sandboxes which i use bzr switch with
[00:56] <wallyworld_> eg devel-sandbox. this one has the working tree
[00:57] <wallyworld_> so i have separate working tree and branch directories and i reuse the working tree dir when i switch between branches
[00:58] <wallyworld_> so i reduce local disk space by only having 1 or 2 full working tree directories
[00:58] <wallyworld_> at least that's how i was recommended to do it when i started :-)
[00:59] <maxb> Oh you're doing all of this inside a shared repository aren't you
[00:59] <wallyworld_> i've been mainly working with devel not db-devel but just need to get my db-devel branch to accept that i want the submit_branch to be db-devel not devel
[00:59] <wallyworld_> yes
[01:00] <maxb> Why use --lightweight at all then?
[01:00] <wallyworld_> i think i did a bzr repo-init or somwthing in my top level lp-branches dir
[01:00] <wallyworld_> that's how i was recommended? :-)
[01:01] <wallyworld_> the idea is to only have one or two full working trees on disk and share these amongst the branches you are working on by doing a bzr switch as required
[01:01] <maxb> IIUC, you can only set things like submit_branch on a branch. And a lightweight checkout is not a branch
[01:02] <wallyworld_> oh, ok. so bzr info showing devel being the submit branch must be a default or somwthing
[01:03] <wallyworld_> i also tried hacking the .bazaar/locations.conf file
[01:03] <wallyworld_> it seems you can create config blocks for branches in there
[01:04] <wallyworld_> with things like push_location:policy = appendpath etc
[01:10] <spiv> wallyworld_: a lightweight checkout is a reasonable thing to use
[01:11] <spiv> wallyworld_: but make it a checkout of a (treeless) branch you create in your local shared repo
[01:11] <spiv> wallyworld_: rather than of a ~launchpad-pqm branch that you can't possible 'bzr commit' directly too
[01:12] <spiv> wallyworld_: and then you can use the local branch's branch.conf (or create a locations.conf entry that covers that *branch*)
[01:12] <wallyworld_> spiv: i have --no-trees or something set globally. so i was just pulling from the wrong place initially?
[01:12] <spiv> wallyworld_: the key thing here being that "submit branch", like most things, is a setting on a *branch*
[01:13] <spiv> wallyworld_: so a checkout doesn't have a submit branch itself, it just asks its branch for that setting, just as it asks it for the revision contents, etc.
[01:13] <wallyworld_> spiv: yes. that's why i have a "master" db-devel branch locally which i then branch from as i need to
[01:14] <spiv> wallyworld_: that's not the workflow you described
[01:14] <spiv> wallyworld_: your workflow description starts with you making a local *checkout* of db-devel
[01:14] <wallyworld_> seems like i messed up getting the initial local copy of db-devel then?
[01:14] <spiv> (A lightweight one at that!)
[01:15] <spiv> You want a local branch of db-devel
[01:15] <wallyworld_> yeah, i've had the devel one for so long i forgot how to "seed" a new one
[01:16] <spiv> You can probably just go to your 'db-devel' checkout and do "bzr reconfigure --branch"
[01:16] <spiv> I'm not certainly this is the cause of your immediate problem, but it's likely to be related.
[01:16] <wallyworld_> cool. thanks. i'll give it a go. and the branch i've already peeled off that db-devel will be ok still?
[01:17] <spiv> Yes.
[01:17] <spiv> Well,
[01:18] <spiv> It'll probably think it's parent branch is the one on launchpad rather than your local mirror.
[01:18] <spiv> Check the 'bzr info' output.
[01:18] <wallyworld_> will do
[01:19] <wallyworld_> it would be great to have a way for point bzr to a top level projects directory and have it tell you things like what shared repos there were, what types of branches etc
[01:19] <wallyworld_> a global overview if you like
[01:21] <spiv> Yes, that would be nice.
[01:21] <spiv> A bit tricky because there's not really any concept of a "top level projects directory" or anything like that in bzr except by convention.
[01:21] <wallyworld_> spiv: the reconfigure fixed the "master" db-devel but the one i am using shows parent_branch=~projects/lp-branches/db-devel (correct) but submit_branch=~projects/lp-branches/devel (incorrect)
[01:22] <spiv> Well, you should be able to fix that from the branch.conf or via locations.conf
[01:22] <wallyworld_> with the overview thing, you would just give it a top level directory and it would decend to all the subdirs and see what i would find
[01:23] <spiv> (vila is working on a config system improvement that will be able to tell to exactly where a given setting is coming from)
[01:23] <wallyworld_> :-)
[01:26] <wallyworld_> spiv: i edited the branch.conf for my working branch (it already had parent_location=../db-devel) and added submit_location=../db_devel but bzr info still has submit_branch wrong
[01:27] <wallyworld_> thanks for the help and your patience btw :-)
[01:29] <spiv> wallyworld_: the setting is "submit_branch"
[01:29] <spiv> not "submit_location"
[01:30] <wallyworld_> tried that too, but found something
[01:31] <wallyworld_> in ~/.bazaar/locations.conf, there is a [/home/ian/projects/lp-branches] section as well as [/home/ian/projects/lp-branches/db-devel]
[01:31] <wallyworld_> it seems the stuff in [/home/ian/projects/lp-branches] overrides the other settings
[01:31] <wallyworld_> i would have though it was the other way around
[01:32] <wallyworld_> and both of these seem to override what's in the local branches.conf file ??
[01:32] <wallyworld_> everything seems upside down
[01:36] <spiv> Yes, locations.conf overrides branch.conf: the idea is that branch.conf might not be under your control (e.g. for a remote branch) but locations.conf always is
[01:36] <wallyworld_> ah, ok. makes sense now. thanks.
[01:37] <spiv> So it allows a branch owner to specify what they consider reasonable defaults for some things, but users can still set their own policy.
[01:37] <wallyworld_> so i guess i don't really need a locations.conf if i am working locally
[01:37] <spiv> Well, I actually go the other way:
[01:37] <spiv> I just do everything in locations.conf
[01:37] <spiv> Because for me it's simplest to just have one place with all the settings,
[01:38] <spiv> but more importantly because locations.conf allows you to set something once for many branches
[01:39] <wallyworld_> ok. but then i would need new config sections for each new local branch i create eg  [/home/ian/projects/lp-branches/xxxx] ??
[01:40] <wallyworld_> i have a section for db-devel but stuff i branch from my local db-devel doesn't seem to reflect that when a do a bzr info
[01:41] <spiv> wallyworld_: that's what the foo:policy = appendpath is about
[01:42] <wallyworld_> ah. makes sense. i need to go off and rtfm. sorry
[01:42] <wallyworld_> i just copied those settings from an existing file and never really knew what they were for
[01:42] <spiv> e.g. I have push_location = lp:~spiv/bzr  and  push_location:policy = appendpath  for the directory I keep my bzr branches in
[01:43] <wallyworld_> light bulb goes on. thanks again for your help. really appreciated.
[01:44] <spiv> Not a problem.
[01:44] <spiv> It's a bit too fiddly :/
[01:44] <spiv> It works well once you know how to use it, though.
[01:45] <wallyworld_> the reason it's important is that i improved the bzr intellij plugin to allow change tracking against the submit branch and if the submit branch is wrong it sort of defeats the purpose
[01:45] <wallyworld_> yeah, as a new user to bzr, there's a lot to learn
[01:46] <wallyworld_> but i do really like bzr more than others i've used
[01:55] <thumper> maxb: ping
 Well that's bad. The busticated content is in a GC block in the oldest largest pack file in the branch
[01:56] <thumper> maxb: was that the openobject-addons?
[02:21] <maxb> thumper: hi, and yes. I have noted on the bug 666642
[02:21] <thumper> maxb: yep, ta, just commenting now
[02:23] <dOxxx> howdy
[02:24] <dOxxx> got a question about blackbox testing in bzr... how would I validate that a bzr command is changing the bzr config correctly, without affecting the user's bzr config?
[02:44] <spm> *** FYI. codehost will be done shortly for an update. actual downtime should be < 30 seconds ***
[02:45] <spm> taking it down now
[02:47] <spm> and should be fine again
[03:04] <jam> spiv: are you sure the email you replied to isn't just a troll?
[03:05] <spiv> jam: hmm
[03:06] <fullermd> Eh, he's always seemed honest to me.  Quirky nutcase, but an honest quirky nutcase.
[03:06] <spiv> jam: grumpy certainly, but googling does indeed suggest they have their own SSH implementation.
[03:06] <jam>  you mean lsh, or something else?
[03:06] <spiv> Something else.
[03:06] <spiv> Possibly something private.
[03:07] <spiv> A quick google didn't find it (although it did find a reference to it)
[03:07] <spiv> Given their attitude to the GPL I doubt they'd use GNU's ssh :)
[03:08] <spiv> dOxxx_away: the bzr TestCaseInTempDir class should insulate you from the user's config
[03:08] <spiv> dOxxx_away: grep for 'config' in the existing tests, perhaps
[03:09]  * spiv -> lunch
[04:44] <dOxxx> thanks spiv
[05:41] <dOxxx> night all
[09:31] <Glenjamin> hi guys, has anyone experienced a "too many open files" error hosting the smart server over http using mod_wsgi?
[09:32] <Glenjamin> After much googling the theory is that there are some leaking file handles, and the long-running wsgi process ends up hitting the limit
[09:32] <Glenjamin> but i have no idea how to test that theory
[09:32] <maxb> You should be able to prove/disprove that easily with lsof -p PID#
[09:34] <Glenjamin> i did lsof and counted the number of files for root, www-data and the user wsgi runs bzr as - all three were within the limit
[09:34] <Glenjamin> but the requests still got the error
[09:37] <Glenjamin> oh, progress
[09:38] <Glenjamin> it apepars after each request the number of handles to bzr.log increases
[09:38] <Glenjamin> which means it's not bzr, it's my wsgi wrapper
[09:40] <Glenjamin> oh balls, i'm opening the bzr log on every request - due to not understanding how wsgi works at all
[14:56] <ssandberg_> hi! is there a way to cherry-pick a changeset (bzr merge -r from..to) and include the changeset comments?
[14:56] <poolie> sorry, no
[14:56] <poolie> only as text
[14:58] <ssandberg_> poolie, ok, that's a pity. do you know if there are any plans to add this? is there a bug report?
[14:59] <poolie> yes there is
[15:12] <abentley> james_w: What's the difference between NestPartInstruction.target_subdir and ChildBranch.nest_path ?
[15:13] <poolie> meeting now about launchpad for upstreams in #ubuntu-uds-bonaire1
[15:15] <james_w> abentley, where it is coming from and where it is going
[15:17] <abentley> james_w: Remember, ChildBranch.nest_path is unset for NestPartInstructions.  What is the equivalent of ChildBranch.nest_path for NestPartInstruction?
[15:19] <abentley> james_w: Is NestPart.subpath the equivalent of ChildBranch.nest_path ?
[15:29] <abentley> james_w: FWICT, target_subdir is the TARGET-DIR in "nest-part NAME BRANCH SUBDIR [TARGET-DIR [REVISION]]" and nest_path is the TARGET-DIR in "nest NAME BRANCH TARGET-DIR [REVISION]", so why aren't they the same variable?
[15:32] <ovnicraft> hi folks, i get myaddons/ in branch but i want to create a branch for each dir inside myaddons/ as a multibranch and keeps sync, there is any support in core of bzr?
[15:34] <poolie> not in core, i suggest you use scmproj
[15:36] <ovnicraft> poolie, its supported in lp?
[15:36] <poolie> what would you want lp to do with it?
[15:43] <Tak> is the cleanup_now() method no longer used in the bzrlib command api?
[16:01] <james_w> abentley, I don't know offhand
[16:02] <abentley> james_w: I see that TARGET-DIR is optional for nest-part.  What do you do if you want to specify a REVISION, but not a TARGET-DIR?
[16:04] <james_w> abentley, you specify a target dir
[16:05] <abentley> james_w: what target dir would you specify?
[16:59] <roryy> hrm
[16:59] <roryy> does anyone use wine on linux to run bzr selftest?
[17:00] <poolie> roryy, yes, i do
[17:00] <poolie> not automatically, but from time to time
[17:00] <poolie> it's good
[17:00] <roryy> cool
[17:00] <roryy> do you use wineconsole ?
[17:01] <poolie> i mostly use just 'wine python ./bzr ....'
[17:01] <poolie> there are some list posts about it
[17:02] <poolie> may also be something in the testing gudie
[17:03] <roryy> cool, ta
[17:11] <lvh> Hello
[17:11] <lvh> Is there a way to push a bzr branch to svn?
[17:11] <lvh> Ideally, I'd like to create a bzr repo from svn, branch (with bzr), and then put that branch on the svn repo.
[17:11] <dash> yes.
[17:12] <dash> it pretty much Just Works.
[17:12] <Glenjamin> if you install bzr-svn (a plugin), it just works :)
[17:12] <poolie> roryy, some tests probably fail but bugs or patches are very welcome
[17:13] <roryy> poolie: cool.  mgz got a funny result on win with a merge i proposed, but i can't reproduce it under wine
[17:14] <poolie> meeting now about bzr and ubuntu in #ubuntu-uds-curacao12
[17:17] <mgedmin> suppose I have a checkout, not updated lately
[17:17] <mgedmin> how can I find how what would be changed if I run 'bzr up'?
[17:17] <mgedmin> I don't see a --dry-run in bzr help up
[17:17] <vila> mgedmin: bzr missing
[17:17] <mgedmin> bzr: ERROR: No peer location known or specified.
[17:18] <Glenjamin> bzr missing :bound
[17:18] <mgedmin> is there a short name for "the branch I'm a checkout of", or do I need to copy and paste--- thanks for preempting my question with an answer!
[17:18] <mgedmin> awesome
[17:18] <poolie> bzr st -r :bound ?
[17:19] <poolie> mgedmin, you could file a bug asking for 'update --dry-run'
[17:19] <mgedmin> I'm surprised you don't already have a bug "every command should have --dry-run"
[17:19]  * Tak bzr info --dry-run
[17:20] <poolie> we may?
[17:20] <Tak> is UDS the reason that nobody at canonical is responding to email?
[17:20] <mgedmin> https://bugs.launchpad.net/bzr/+bug/37829
[17:20] <vila> merge has --preview
[17:21] <poolie> Tak, probably :)
[17:21] <poolie> any mail in particular?
[17:21] <Tak> ok - at least there's a reason ;-)
[17:21] <poolie> i've been dealing with some
[17:21] <Tak> myself and a coworker have sent some commercial-launchpad-question -related emails this week
[17:23] <Tak> tsk, it's even in orlando - a year ago I would have dropped by
[17:23]  * mgedmin wishes 'bzr unbind' wouldn't just forget the url
[17:23] <jelmer> mgedmin: I think it's a feature, that way you can easily unbind and rebind
[17:25] <mgedmin> oh, it remembers!  I assumed it forgot because 'bzr info' didn't show any related branches
[17:25] <mgedmin> I could've done bzr pull :bound --remember
[17:25] <mgedmin> instead of copying and pasting the url from my scrollback
[17:26] <Remaille> hi, I have some code in a folder, I did a bzr init
[17:27] <Remaille> and now I want to upload all of it into LP
[17:27] <Remaille> I did a : bzr push lp:name
[17:27] <Remaille> and i have : "No new revisions to push."
[17:27] <vila> Remaille: may be you should create a revision now before pushing: bzr add ; bzr commit -m 'import blah' ; bzr push
[17:28] <Remaille> This branch is empty.
[17:28] <Remaille> hum ok
[17:28] <vila> Remaille: then there is nothing to push
[17:28] <poolie> Tak, i'll ping people
[17:29] <Tak> well - I don't want to make trouble
[17:29] <Tak> but otoh, I /do/ want everyone here to be blown away by launchpad's awesomeness
[17:29] <Remaille> vila, ok thanks a lot
[17:30] <Remaille> I use bzr once every two years :-)
[17:32] <vila> Remaille: start by using it once a year then :)
[17:32] <Remaille> :-)
[17:33] <Remaille> and write down on a txt file what you told me :-) maybe you answered the same question from me two years ago ? ;-)
[17:34] <vila> Remaille: I can't remember that far, that's why I use a DVCS ;)
[17:35] <mgedmin> bug 1
[17:35] <mgedmin> oops, wrong channel
[18:52] <james_w> abentley, any target dir you want. You probably want the same as the source dir, as that is what you get if you specify nothing
[18:59] <abentley> james_w: So generating a manifest for "nest-part packaging lp:~foo-dev/foo/packaging debian" would produce "nest-part packaging lp:~foo-dev/foo/packaging debian debian $REVISION"
[19:00] <james_w> abentley, hmm, not sure, might be a bug
[19:01] <abentley> james_w: I think that is what it has to produce.  Based on the code, I think it actually produces "nest-part packaging lp:~foo-dev/foo/packaging debian $REVISION", but that would cause $REVISION to be interpreted as TARGET-DIR.
[19:01] <james_w> I think it would produce "nest-part packaging lp:~foo-dev/foo/packaging debian None $REVISION"
[19:03] <abentley> james_w: There is a conditional on whether target_subdir is None.  If it is None, I believe it is completely excluded.
[19:03] <james_w> right
[19:04] <abentley> james_w: Which makes me think it would not produce "None" in "nest-part packaging lp:~foo-dev/foo/packaging debian None $REVISION"
[19:05] <james_w> right, you are correct
[19:07] <abentley> james_w: I can patch it.  Do you think the "debian debian" version is the correct manifest output?
[19:07] <james_w> abentley, https://code.edge.launchpad.net/~james-w/bzr-builder/fix-nest-part-manifest/+merge/39466
[19:09] <abentley> james_w: that will not roundtrip perfectly.  Is that acceptable to you?
[19:10] <james_w> why won't it?
[19:11] <abentley> james_w: get_recipe_text will convert "nest-part packaging lp:~foo-dev/foo/packaging debian" into "nest-part packaging lp:~foo-dev/foo/packaging debian debian"
[19:13] <abentley> james_w: if you wanted to make the roundtripping perfect, you would need to do "if target_subdir is None and revid_part is not None"
[19:13] <james_w> abentley, I agree, but my test is saying different
[19:15] <abentley> james_w: branching...
[19:15] <james_w> abentley, I mean the second test I just wrote to fix that issue
[19:16] <james_w> damn, my fault
[19:22] <james_w> abentley, just pushed a new revision
[19:26] <abentley> james_w: r=me
[19:26] <abentley> james_w: thanks.
[19:26] <james_w> thank you
[19:26] <james_w> need a release?
[19:27] <abentley> james_w: no, at this point we're not using manifests in anger.
[19:28] <mtaylor> GAH
[19:28] <mtaylor> bzr: ERROR: Tree transform is malformed [('unversioned executability', 'new-737'), ('unversioned executability', 'new-738')]
[19:28] <mtaylor> I thought that was fixed like a million years ago
[19:29] <mtaylor> http://paste.drizzle.org/show/103/
[19:29] <abentley> mtaylor: sorry.
[19:30] <mtaylor> abentley: do I just suck?
[19:30] <abentley> mtaylor: This would be a case where one side deleted a file and the other side changed its executability.
[19:30] <mtaylor> abentley: oh, lovely
[19:30] <mtaylor> abentley: is there anyway for me to find out which file?
[19:31] <mtaylor> abentley: because I can gladly fix it in one of the trees
[19:32] <abentley> mtaylor: I think this requires setting a breakpoint where the exception was raised and then calling TreeTransform methods.
[19:37] <james_w> mtaylor, we probably didn't squash all the cases
[19:37] <james_w> mtaylor, can you tell me how to reproduce?
[19:37] <mwhudson> BZR_PDB=1 should get you to an appropriate pdb prompt?
[19:38] <abentley> mtaylor: tt._new_name.get('new-737') or tt.tree_id_paths.get('new-737') should give you the name or path.
[19:38] <lvh> What are things like "lp:" called? Can I add my own?
[19:39] <mwhudson> lvh: its a directory service, and yes
[19:39] <lvh> mwhudson: Aha, thanks
[19:39] <abentley> lvh: mostly, you need to write a plugin to do so.
[19:39] <mwhudson> yeah, you need a plugin
[19:40] <lvh> right, but I can just use the bookmark plugin and cover most use cases, right?
[19:40] <mwhudson> yeah, the bookmark plugin handles many cases
[19:41] <abentley> lvh: that will work great for static assignments.  For dynamic ones, like expanding prefix:* => http://example.com/*, I have bzr+ssh://bazaar.launchpad.net/~abentley/%2Bjunk/openlookup/, but it's not documented.
[19:42] <lvh> abentley: Aha, thank you. I will take a look at that
[19:42] <mtaylor> james_w: grab lp:~mordred/drizzle/test-elliott-release and then http://wc220.com/drizzlefiles/drizzle7-2010.10.02.tar.gz and then do bzr merge-upstream --version=2010.10.02 drizzle7-2010.10.02.tar.gz
[19:43] <abentley> lvh: basically, you need to add a section to bazaar.conf like so: http://pastebin.ubuntu.com/520925/
[19:43] <mwhudson> i have a plugin that lets me say things like bzr pull -d plugin:svn
[19:43] <mwhudson> but sadly, not on this machine
[19:44] <mtaylor> abentley:
[19:44] <mtaylor> (Pdb) print tt._new_name.get('new-737')
[19:44] <mtaylor> None
[19:45] <abentley> mtaylor: okay, try  tt.tree_id_paths.get('new-737')
[19:45] <mtaylor> *** AttributeError: 'TreeTransform' object has no attribute 'tree_id_paths'
[19:45]  * mtaylor pokes around...
[19:45] <abentley> mtaylor: sorry, leading underscore.
[19:45] <mtaylor> yup. see it
[19:45] <mtaylor> hrm
[19:45] <mtaylor> u'drizzled/set_var.cc'
[19:46] <mtaylor> so, in trunk, set_var.cc got renamed to sys_var.cc and then a new set_var.cc was added
[19:46] <james_w> mtaylor, what's your version of bzr-builddeb?
[19:46] <mtaylor> (repeat for set_Var.h
[19:46] <james_w> I'm pretty sure that's one of the cases that I fixed
[19:46] <mtaylor> james_w: builddeb 2.2.0
[19:46] <lvh> abentley: Aha! Despite the fact that that *does* look sexy, unfortunately I can't use things that are undocumented or unsupported (yay policy)
[19:47] <james_w> mtaylor, you need 2.6 or maybe 2.5
[19:47] <mtaylor> james_w: should I just pull lp:bzr-builddeb
[19:47] <james_w> mtaylor, what's your platform?
[19:47] <james_w> that would work
[19:47] <lifeless> ubuflu
[19:47] <mtaylor> just branched - trying
[19:47] <mtaylor> lifeless: hah
[19:47] <lifeless> mtaylor: available now
[19:47] <mtaylor> (actually, this is on a squeze box)
[19:47] <mtaylor> lifeless: where r u?
[19:47] <abentley> lvh: Well, undocumented I could fix, but unsupported is tricker... :-)
[19:48] <lifeless> hallway?
[19:48] <mtaylor> lifeless: will find - honestly not _important_ - more an idea - coming
[19:48] <mtaylor> james_w: nope. still exception
[19:48] <james_w> mtaylor, ok, I'll take a look
[19:55] <mtaylor> james_w, abentley : also, the set_var.cc was modified in the same rev it was renamed in - so it may not be obvious to merge-upstream that renamed-set_var.cc is the same file
[19:56] <mtaylor> is there anything you can think of I can do to my local tree to un-confuse merge-upstream? (like re-commit something or something?)
[19:58] <abentley> james_w: are you using RenameMap to guess renames?  That should be able to detect a rename if the file hasn't changed excessively.
[19:59] <james_w> abentley, we are not
[19:59] <james_w> mtaylor, not without understanding the error better, sorry
[20:00] <mtaylor> james_w: ok. cool
[20:00] <abentley> james_w: ah.  Well, you might find it useful, and if not, I'd be interested to hear why.
[20:01] <mtaylor> abentley: well... the file _did_ change excessively ...
[20:01] <mtaylor> abentley: perhaps I should have done the rename as a commit and then the change as a commit... ?
[20:02] <abentley> mtaylor: I don't know enough about bzr-builddeb to be able to answer that, sorry.  james_w?
[20:02]  * mtaylor is now probably being annoying... will just try things
[20:06] <mtaylor> just for the record, splitting rename and new content into different commits no helpie
[20:23] <ovnicraft> h folks, maybe its OT but i want to know how add a user to push in my branch in lp?
[20:42] <mtaylor> ovnicraft: it's more a question for #launchpad - but you want to create a user in launchpad and then that user can push branches to launchpad quite easily
[20:42] <ovnicraft> mtaylor, yes but add a user i fixed thi teams
[20:42] <ovnicraft> mtaylor, thx
[20:44] <mtaylor> abentley, james_w: fwiw, I reverted the four files to a version before the rename, did the merge-upstream, then reverted the files to the version _after_ the rename - and all seems ok
[20:44] <james_w> mtaylor, I'm getting somewhere with the debugging as well
[20:45] <mtaylor> james_w: excellent :)
[20:45] <james_w> it's actually a duplicate id problem, not unversioned executability
[20:45]  * mtaylor likes causing complex problems...
[20:45] <james_w> I'm not sure how to tell where the trans ids that I have came from though
[20:53] <james_w> mtaylor, plugin/haildb/tests/r/insert_null.result plugin/haildb/tests/t/type_float.test
[20:54] <james_w> any idea why they would be getting involved?
[20:54] <mtaylor> james_w: gosh no
[20:55] <mtaylor> james_w: they shouldn't be involved with this at all
[20:55] <mtaylor> james_w: unless both changes hit trunk as part of the same merge
[22:07] <lvh> Does svn-push no longer exist? Is it just push-with-an-svn-url now?
[22:07] <dash> correct
[22:09] <lvh> bzr push svn://host/repo/branches/new-branch-1234 will just work?
[22:09]  * lvh is extremely skeptical, having played with hg-svn today
[22:09] <dash> lvh: yes but it might make some svn users unhappy
[22:09] <lvh> dash: Why is that
[22:09] <lvh> dash: I'm trying to merge changes into twisted trunk without using svn (if possible)
[22:09] <dash> lvh: if they use tools (like combinator) that expect branching to occur in a different revision from branch content adding
[22:10] <dash> lvh: if you use svn cp to create the branch _then_ push to it, all will be right with the world
[22:10] <lvh> oh okay
[22:10] <dash> the only other twist is that there's 'dpush' which pushes without bzr metadata on the revision
[22:10] <lvh> dash: Which for twisted is good?
[22:11] <dash> lvh: glyph will probably complain if you don't use it
[22:11] <dash> but i've ignored him and you can too ;)
[22:14] <glyph> use dpush
[22:14] <glyph> otherwise you will put corrupt revision metadata in the twisted repository
[22:14] <glyph> you might have been able to get away with it last week, but we are facebook friends now, so I know where you live.
[22:14] <dash> oh, hi.
[22:15] <lvh> glyph: my lp thing used to have my address quite accurately
[22:16] <glyph> lvh: More generally, dpush is the stealth way to go.  it does some rebasing and loses a bunch of information, but if you use it, it is basically indistinguishable from using the stock svn client, from the perspective of everyone else on the project.
[22:16] <glyph> this is what it looks like if you use a regular push: https://trac.calendarserver.org/changeset/4434
[22:17] <lvh> glyph: Okay so the way to not piss you off, working from scratch: bzr branch thesvnrepo; bzr branch to feature-1234; hack hack hack; create remote svn branch; bzr dpush svn://host/repo/branches/feature-1234?
[22:17] <glyph> lvh: except +ssh, basically, yes.
[22:17] <glyph> and that is the way I work these days, because of the aforementioned trac ugliness.
[22:17] <dash> well
[22:17] <glyph> Frankly if trac could hide those, and bzr never choked to death on its own metadata, I'd be fine with a normal push.
[22:18] <dash> better to do svn cp then 'bzr branch' or 'bzr co' from the branch url
[22:18] <dash> so that when you push you don't get "omg these branches have diverged"
[22:19] <glyph> pull first!
[22:19] <glyph> although man
[22:19] <glyph> there really needs to be a 'bzr sync' or something, so I can just run that in a hurry, get on a plane and then do the merge later
[22:19] <lvh> dash: Wait what pull where
[22:20] <lvh> dash: Also does that work if I start from lp:twisted
[22:20] <glyph> I hate the workflow where it's wait-wait-wait-okay connected to remote server wait-wait-wait-okay oops diverged, TIME TO WAIT AGAIN
[22:20] <dash> lvh: instead of creating a local bzr branch from trunk, create a local bzr branch from the svn branch you're targeting
[22:20] <lvh> glyph: works well IRL: "hey can you look at this piece of code" "um okay, what's wrong" "nothing I just wanted to make sure I merged first."
[22:21] <lvh> dash: Right okay. And bzr-svn is smart enough to make that work if everything else is a bzr repo? I already have a shared repo with a "trunk" directory which is lp:twisted
[22:22] <glyph> oh man
[22:22] <glyph> lp:twisted is not a good scene
[22:22] <glyph> don't use that
[22:22] <lvh> Okay
[22:22] <glyph> or... wait maybe I'm wrong, I haven't used it in a while.
[22:22] <dash> i think it uses bzr-svn now
[22:22] <glyph> Do the revision numbers match up with our branch-hosting bzr mirror?
[22:23] <dash> lvh: the main thing is that if you branch from lp:twisted it won't prime bzr-svn's svn rev cache
[22:23] <dash> glyph: AFAIR yes
[22:23]  * dash checks.
[22:24] <lvh> So, starting from scratch: bzr init-repo Twisted; cd Twisted; bzr branch svn://svn.twistedmatrix.com/svn/Twisted/trunk trunk; svn cp create-a-branch; bzr brach that-branch awesome-feature-1234; hack hack hack; bzr dpush?
[22:24] <dash> yeah, looks like it.
[22:24] <dash> lvh: yes.
[22:24] <lvh> Okie, thanks
[22:24] <glyph> we also have a bzr mirror
[22:25] <lvh> glyph: Is it okay to use that or is that too a source of bad things
[22:25] <dash> it's created using bzr-svn
[22:25] <dash> as is lp:twisted
[22:25] <dash> they should have the same history as anything you branch from svn yourself
[22:28] <glyph> they match exactly
[22:28] <glyph> basically they're an optimized way of bootstrapping
[22:28] <glyph> although eventually you end up needing to prime your svn revision cache anyway
[22:28] <glyph> because they lag
[22:29] <lvh> Hm.
[22:29] <lvh> dash: Sorry, I disconnected. If lp:twisted and the twisted bzr mirror are both made with bzr-svn, why is one a bad idea and the other not such a bad idea? SVN metadata?
[22:31] <dash> lvh: glyph was remembering the old version of lp:twisted from before bzr-svn worked real good
[22:31] <dash> it's fine now
[22:32] <lvh> dash: So, I can still use my shared repo with trunk I stole from lp:twisted?
[22:32] <dash> yep
[22:45] <lvh> revno: 15682
[22:45] <lvh> svn revno: 30182 (on /trunk)
[22:46] <lvh> dash: So, to actually merge the change, I can just do it on bzr and push to svn trunk, since everyone knows trunk exists, and that won't piss glyph off?
[22:47] <dash> lvh: i forget whether dpush sets svn:mergeinfo or not
[22:48] <dash> glyph: re trac: "hide_properties = svk:merge, bzr:file-ids, bzr:merge, bzr:revision-info"
[22:49] <peitschie> mornin everyone :)
[22:52] <glyph> dash: okay, I just told a guy that
[22:52] <glyph> dash: do you want to tell exarkun?
[22:54] <dash> glyph: in the 'browser' section, specifically
[23:04] <glyph> dash: now you've done it.  #calendarserver


[10:53] <Luciph3r> reboot
[04:28] <morgs> Time passes...
[04:29] <Kinnison> It is dark
[04:32] <mdke> carlos, ping
[04:32] <carlos> mdke, pong
[04:32] <mdke> carlos, one of the portugese guys has just asked me a question about translation
[04:32] <carlos> which one?
[04:32] <mdke> carlos, he says the translations of the gnome menus are inaccurate, would you know where he can correct these?
[04:33] <mdke> joao
[04:34] <mdke> carlos, meet joao
[04:35] <jalrnc> carlos: hi
[04:35] <carlos> jalrnc, hi
[04:35] <jalrnc> we are translating the quickguide as you know, and it makes references to application names that show up in the gnome menus
[04:35] <jalrnc> those application names in gnome already exist when we install portuguese support with ubuntu
[04:35] <jalrnc> 1. some of those names are not properly translated 2. we would like to have them corrected and so be consistent with quickguide
[04:35] <carlos> usually, the translation is stored inside the application
[04:36] <carlos> so for instance, if the Evolution translation is broken
[04:36] <carlos> you should fix it at:...
[04:36] <carlos> koke, !
[04:36] <koke> hi!
[04:37] <mdke> carlos, he was wondering whether it is best to translate in rosetta and then push upstream, or coordinate directly with upstream (gnome?)
[04:37] <jalrnc> carlos: so we should fix those names at each individual application, ok
[04:37] <koke> I'm planning to work on the FindingPackages goal, and I'll need some help from launchpad team
[04:37] <jalrnc> carlos: right
[04:38] <koke> can someone tell me what is this about https://wiki.launchpad.canonical.com/DoapSchemaNG ?
[04:38] <koke> I can't see it :)
[04:38] <carlos> hmmm, evolution is really slow in Rosetta.... we should improve its performance...
[04:39] <carlos> mdke, jalrnc: Well, you can use Rosetta and then send the updates to upstream
[04:39] <carlos> mdke, jalrnc usually is a good thing to coordinate with upstream that way the fix is shared
[04:39] <carlos> koke, morgs is your man
[04:39] <jalrnc> carlos: what's the best way to coordinate with upstream?
[04:40] <morgs> koke: I'm responsible for DoapSchemaNG... it's about extending the Launchpad product registry to allow multiple wikis, mailinglists, screenshot URLs, download URLs etc per product / productrelease etc.
[04:40] <jalrnc> carlos: lets say we fix it first in rosetta, what should we do next? or should we coordinate with upstream before start changing in rosetta?
[04:41] <morgs> koke: Not really major rocket science, just extending the launchpad database schema a bit.
[04:41] <koke> morgs: great, that's what I needed
[04:41] <carlos> jalrnc, the best solution is talk first with upstream
[04:41] <koke> I was wondering if you were working on it
[04:41] <morgs> koke: yes
[04:41] <carlos> jalrnc, and you can use Rosetta so Ubuntu gets the fix and then send the fixed .po file to upstream
[04:42] <koke> http://koke.amedias.org/img/g-a-i-mockup-2.png <-- I need to extract that metadata from somewhere
[04:42] <jalrnc> carlos: and by upstream you mean each application individually or gnome upstream?
[04:42] <carlos> jalrnc, if you want the fix in Ubuntu, you need to use Rosetta, but you don't need to use Rosetta to coordinate with upstream if you don't want to
[04:42] <jalrnc> carlos: ok
[04:42] <carlos> jalrnc, in GNOME case, the GNOME Portuguese team
[04:43] <koke> morgs: but some I'll need also information about available versions in diferent releases of ubuntu. Is this possible from DOAP-ng ?
[04:43] <carlos> evolution was not a good choice as example...
[04:44] <jalrnc> carlos: ok, should those menu names be fixed in each indivual application individually or in gnome?
[04:44] <carlos> jalrnc, those menu names come from the application
[04:44] <jalrnc> carlos: ok
[04:44] <carlos> so you need to fix them individually
[04:44] <morgs> koke: Hmm. All the data is in the database, but it is "part" of different systems - so the versions in Ubuntu are part of the "soyuz" part of launchpad.
[04:45] <jalrnc> got it
[04:45] <Kinnison> I'm not convinced you want to know the different versions available
[04:45] <Kinnison> unless they're in your apt sources
[04:45] <Kinnison> in which case the info is available by interrogating apt
[04:45] <koke> morgs: I know. What I need is a rdf file for all that data, it will be processed at the client
[04:45] <jalrnc> I'll discuss with my team weather we want to fix it in rosetta, but I think we do, and we'll definitely coordinate with upstream
[04:46] <morgs> koke: Another project w.r.t. DOAP is to publish project/product/productseries/productrelease information in RDF/XML format - like the real DOAP upstream project.
[04:46] <jalrnc> carlos, mdke: thanks!
[04:46] <morgs> koke: the RDF publishing is targeted at being implemented by July 6.
[04:46] <morgs> "Launchpad 1.0"
[04:46] <mdke> cheers carlos
[04:46] <koke> morgs: I can manage the files in another place for development and integrate with launchpad then
[04:47] <morgs> It will include the basic Freshmeat-type details in RDF - basically representing the "upstream" versions of the products, not the ubuntu versions.
[04:47] <carlos> jalrnc, no, thank you!
[04:47] <carlos> mdke, cheers
[04:47] <koke> morgs: maybe the final solution will imply to have those files in another place but taking the data from launchpad
[04:49] <morgs> koke: I'm not sure what you mean by "in another place", but the basic idea is that a product in launchpad is at https://launchpad.ubuntu.com/products/foo, and you will find the RDF at https://launchpad.ubuntu.com/products/foo/+rdf
[04:49] <morgs> It will have a list of product releases (I'm oversimplifying but basically...) and each release will have the URL where you can download the RDF for that release.
[04:50] <koke> morgs: I have to spec what I need in that file and I'll tell you to see if it fits on launchpad plans
[04:50] <morgs> like https://launchpad.ubuntu.com/products/foo/+series/stable/1.0.1/+rdf
[04:51] <morgs> koke: I can mail you a preliminary example of the RDF files - still subject to change at this stage but will give you an idea...
[04:51] <koke> and any way to match which version is on a specific ubuntu release?
[04:51] <koke> morgs: great :)
[04:52] <Kinnison> koke: Soyuz RDF hasn't even been specced at all yet
[04:52] <morgs> koke: Hmm. It just gives "upstream" releases.
[04:52] <koke> Kinnison: that would be done by soyuz rdf??
[04:52] <Kinnison> koke: Well, if you care about what is in a distro yes
[04:52] <Kinnison> soyuz is all the distro-related stuff
[04:52] <koke> ok
[04:53] <koke> that's what I meant with "in another place"
[04:53] <Kinnison> So you'd be looking for something like: /distros/ubuntu/hoary/foosourcepackage/+rdf
[04:53] <Kinnison> but that's way off
[04:53] <morgs|afk> back in a bit...
[04:54] <koke> Kinnison: maybe, just some way to be able to discover from a doap rdf which version of that product is availble in each ubuntu release
[04:55] <Kinnison> it'd be not-right to look via doap for that I don't think
[04:55] <Kinnison> but we've not got completely tight distro<->upstream linkage in the db yet
[06:15] <koke> bradb: is there any way to list all the bugs for a package?
[06:15] <koke> or is planned to be?
[06:16] <bradb> koke: there have been a few requests for it (i've wanted to use it too :). how about if we made "All Bugs" one of the search "quick links"?
[06:17] <bradb> if you had a different expectation of how it would be done, please feel free to tell me about it
[06:18] <koke> bradb: just like https://launchpad.ubuntu.com/malone/distros/ubuntu, but https://launchpad.ubuntu.com/malone/products/foo
[06:18] <koke> an url for a "show bugs of package foo"
[06:18] <bradb>  /malone/products/foo already works
[06:19] <bradb> do you mean /distros/ubuntu/+packages/somepackage and /distros/ubuntu/hoary/+packages/somepackage or something like that?
[06:23] <koke> bradb: yep, something like that
[06:24] <bradb> koke: i feel it would be useful too. you can likely expect that kind of thing to land a little bit after 1.0.
[06:25] <koke> ok
[06:26] <carlos> bradb, isn't it what /distros/ubuntu/+packages/somepackage/+bugs is for?
[06:26] <carlos> I suppose it's not implemented yet :-)
[06:27] <bradb> correct ;)
[06:27] <carlos> but I think we talked about it at UDU
[06:27] <carlos> bradb, isn't it a 1.0 goal?
[06:27] <bradb> we talked about it as early as cape town, just didn't prioritize it for 1.0.
[06:27] <carlos> bradb, it's part of launchpadmenus, isn't it?
[06:27] <bradb> carlos: no.
[06:27] <bradb> not that i'm aware of.
[06:27] <carlos> oh, ok
[06:28] <bradb> which isn't saying that it for sure isn't, but just that if it /is/, i didn't know that was a required part of making LP menus work