[08:23] <jam> morning all
[08:25] <jelmer> hi jam
[08:25] <jam> hi jelmer, feeling better?
[08:26] <jelmer> yeah, much better
[08:26] <jam> I still mean to have you come out and visit us in Eindhoven sometime. Maybe after we settle from the sprint?
[08:26] <vila> hi jam, jelmer
[08:26] <jam> hi vila
[08:26] <vila> jelmer: glad you're feeling better !
[08:27] <fullermd> Well, I guess if .eu is here, it must be time for me to go...
[08:28] <jam> fullermd: I didn't think you ever left
[08:28] <fullermd> Well, I'm almost always right, but I'm occasionally left.
[08:28] <vila> fullermd: careful, you may end up falling asleep
[08:29] <jelmer> jam: Yeah, me too
[08:29] <fullermd> Sleep?  I just did that _last_ week...
[08:29] <jelmer> 'morning vila, fullermd
[08:33] <vila> maxb: wrong revid used in bug #795703 (but the tags have been deleted nevertheless)
[08:35] <vila> maxb: I won't apply the other ones until you give feedback
[08:55] <maxb> vila: Oh dear, do I fail at copy paste?
[08:56] <maxb> gnome-mousetrap, right?
[08:56] <vila> maxb: That's my fear :-/ (I know I often fail there because of my unusual setup where the clipboard content can randomly (really ? :-/) be wrong so some copies are lost and I end up pasting an old value...
[08:56] <vila> well, often is exaggerated but that's not rare enough to be really annoying
[08:57] <maxb> Oh,yes. The revid I put for gnome-mousetrap is the same as the one from git-buildpackage above
[08:58] <maxb> I think the I and K commands should all be safe, since I was wise to the problem by then - but apparently I missed one instance near the beginning
[08:59] <vila> maxb: yes, I saw the duplicate but had of course no idea what the right one could be
[09:00] <maxb> I've updated the bug now
[09:00] <vila> cool
[09:00] <maxb> For some reason, qbzr seems particularly prone to copy / paste weirdness
[09:00] <maxb> Maybe that's what I get for using one Qt app in a Gnome desktop
[09:05] <maxb> oh. I failed, with the same revid, for gphoto2 and gst-plugins-base-0.10 too
[09:05]  * maxb sorts
[09:06] <maxb> and apparently I fixed gnumeric on breezy, but now it's failing on hoary-security
[09:12] <maxb> Whilst you're on jubany, could you also requeue --full ubuntu-defaults-builder ?
[09:12] <vila> maxb: done
[09:13] <vila> maxb: +1 for requeue in fixit.sh, it even allow c/p from IRC... :-p
[09:14] <vila> maxb: almost a natural language UI (for some geek value of natural ;)
[09:14] <maxb> I was just thinking something like that :-)
[09:17] <maxb> vila: You saw my updated commands for gst-plugins-base0.10 gphoto2 gnome-mousetrap?
[09:18] <maxb> (Just wanting to be sure since they partially interleaved with your comments on the bug)
[09:20] <vila> maxb: gphoto2 and gst-plugins-base done
[09:21] <vila> maxb: that's an interesting experiment, let's keep posting there if only to capture what happened (errors included)
[09:21] <vila> and *of course* no offense intended, I hope that's clear
[09:22] <vila> I *expect* errors
[09:22] <vila> that's why I wanted to capture recipes in fixit.sh
[09:23] <vila> I know no better way to design UI...
[09:23] <vila> maxb: also, any error should end up in some trace at http://package-import.ubuntu.com/status/ right ?
[09:24] <vila> or can there be some fallouts for users with local branches ?
[09:27] <maxb> Thanks, that's looking better - but, did you miss my comment #16 for gnome-mousetrap?
[09:27] <vila> ha crap, yeah, it seems
[09:27] <maxb> oh,
[09:27] <maxb> maybe not
[09:27] <vila> err
[09:28]  * vila blinks
[09:28] <maxb> ah, you did the tags, but not the requeue
[09:28] <vila> my comment appears *after* yours ?
[09:29] <maxb> Right - sorry.
[09:29] <maxb> I was attempting to match up the failures page and the bug
[09:29]  * vila notes to use two pages: one to copy/ one to paste
[09:29] <maxb> So, you did in fact do my second fixup to gnome-mousetrap's tags, but did you requeue it again?
[09:30] <vila> yeah, a real UI involving a single user would probably address these cases
[09:30] <vila> maxb: yup, I just requeued it
[09:30] <maxb> great!
[09:30] <maxb> so
[09:30] <maxb> :-)
[09:31] <vila> nice number, let's stop there ! :D
[09:31] <maxb> hmm
[09:34] <vila> magcius: ha, just found your comment on #714622
[09:34] <vila> gha
[09:34] <vila> magcius: sorry
[09:34] <vila> maxb: ha, just found your comment on #714622
[09:34]  * magcius looks up bug #714622
[09:34] <vila> double gha
[09:35] <vila> magcius: wrong nick completion, sorry for the noise
[09:42] <vila> rhaa, what's the bug # for selftest not using python provided definition for number of available processors/threads ?
[09:49] <jelmer> vila: are you sure we have one? IIRC we only use the python provided one in some cases
[09:50] <vila> oh, may be a fix has landed, let me check the annotations
[09:51] <jelmer> I landed a fix for the number of processors on *BSD earlier
[09:51] <vila> ha right, no bug, but that's revno 5683 by... you :)
[09:51] <vila> yup, I thought that was still pending
[09:51] <vila> could be cleanup up now that we require py26
[09:55] <vila> hmm, the python impl slightly diverge from our fallback... (sunos5 and even darwin)
[09:55] <vila> ok, forget about it
[11:43] <lifeless> poolie: bzr: failed to report crash using apport:
[11:43] <lifeless>      OSError(17, 'File exists')
[11:43] <lifeless> poolie: have you seen that before?
[11:47] <jelmer> lifeless: I've seen it before on occasion, but I'm not sure what causes it
[12:00] <jdobrien> lifeless, he's here in orlando AFAIK
[12:03] <lifeless> jdobrien: yes, he is
[13:40] <briandealwis> git users: is there a git equivalent of bzr's append_revisions_only?
[13:48] <jelmer> briandealwis, I'm not sure how it works exactly, but I think the term you're looking for is "fast forward only"
[13:49] <briandealwis> jelmer: thx for the pointer
[15:33] <RobOakes> Good morning. Is anyone aware of a tutorial that describes how to keep packaging information and the source code of a project in separate branches?
[15:34] <RobOakes> I am trying to set up a launchpad recipe similar to the one shown here: http://www.youtube.com/watch?v=_bG-SXNX9Ww
[15:36] <RobOakes> My biggest problem is that my packaging branch and my code branch don't share a common ancestor. Is there any way around this? (I don't want all of my source history as part of the packaging branch, just the debian folder.)
[15:39] <jelmer> RobOakes: you can use the nest command if you don't want them to have shared history
[15:41] <RobOakes> What would be the best way to do this? Do I need to create a new branch with the nesting command?
[15:41] <RobOakes> Sorry, my knowledge of bzr is pretty basic. I basically use it like SVN, and you can't do fancy stuff in SVN.
[15:44] <jelmer> RobOakes, the nest command would be in the recipe
[15:44] <jelmer> RobOakes: I usually just merge the source history into the packaging branch, is there any reason you don't want to do that?
[15:45] <RobOakes> Yes, it's due to size.  The program I'm packaging, LyX, has 20 years of development history and some 300,000 commits.
[15:46] <RobOakes> I'm actually curious if I can do a lightweight checkout with the source so I don't have to wait for the entire source history to download. (On my local machine.)
[15:49] <RobOakes> Would the nest line look something like this: merge packaging nest lp:~...
[15:51] <jelmer> no, it would be nest rather than merge
[15:52] <RobOakes> Okay. Is there a difference between nest-part and nest?
[15:53] <RobOakes> (bzr help is being less than helpful and Bug report which discusses them doesn't delve into the differences.)
[16:03] <maxb> You'd use nest if the debian/ directory *was* the packaging branch, nest-part if the debian/ directory was contained within the packaging branch
[16:03] <maxb> i.e. whether you need to nest a whole branch or just a subtree of one
[16:09] <RobOakes> Okay, so something like this: nest packaging lp:~lyx-outline-devel/+junk/lyx-debian debian?
[16:10] <RobOakes> If I wanted to place the entire contents of lyx-debian into a folder called debian?
[16:36] <poolie> lifeless: hi, it's vaguely familiar, the thing would be to work out which file or line is raising it
[16:45] <jelmer> 'morning poolie
[16:54] <poolie> hi there jelmer
[17:19] <jamdahl> Hi everyone, I'm having some difficulty with bazaar allowing out of date checkouts to make commits
[17:21] <maxb> Can you elaborate on what you mean?
[17:30] <jamdahl> Ok, so I have a project initialized to a central location
[17:30] <jamdahl> and 2 separate checkouts of that
[17:30] <jamdahl> Checkout 1 makes an edit and commits
[17:31] <jamdahl> Checkout 2 makes a conflicting edit and commits
[17:32] <jamdahl> My problem is that checkout 2 got no warning and was allowed to commit
[17:44] <jamdahl> any ideas?
[17:52] <jelmer> jamdahl, how were the checkouts created?
[17:54] <jamdahl> bzr checkout remotedirectory localdirectory
[17:55] <LarstiQ> evening
[17:57] <lamalex> hi, does bzr grep search history? is there a plugin that will grep a projects history for some pattern/lines of code?
[18:04] <jelmer> jamdahl: that's odd - what happened to the contents of the remote branch?
[18:05] <maxb> jamdahl: Are you sure no one used "bzr branch", "bzr unbind" or "bzr commit --local" anywhere in this?
[18:07] <jamdahl> I'm testing this so I did it all myself.  None of those commands were used
[18:07] <jamdahl> bzr checkout was used for checkout, bzr qcommit was used for commit
[18:09] <LarstiQ> lamalex: afaik that is exactly what bzr-grep does
[18:09] <lamalex> LarstiQ, i guess i just need to give it revs to search
[18:10] <lamalex> expected it to just automatically search backwards through history
[18:10] <LarstiQ> lamalex: doesn't `bzr help grep` say?
[18:10]  * LarstiQ installs it
[18:11] <LarstiQ> lamalex: if you don't specify a revision, and also not a filename, it seems to grep through history
[18:12] <LarstiQ> or maybe the help can use some rewording
[18:12] <jamdahl> I think I have narrowed down the problem actually
[18:12] <jamdahl> or at least part of it
[18:12] <jamdahl> apparently when I am calling commit, diff, and some of the other commands it isn't doing it on the entire checkout
[18:13] <jamdahl> The project I'm version controlling is a spreadsheet with the VBA code exported.  The spreadsheet is in the main directory  and the vba code is in subfolders
[18:13] <lamalex> LarstiQ, hm.. I mean it just outputs (for me) what's in the current rev without any rev numbers or anything
[18:14] <lamalex> unclear if it goes through branches that were merged and so on
[18:14] <jamdahl> It seems like much of the time when I call for a commit or try to check diff, it doesn't notice the change to the spreadsheet
[18:14] <LarstiQ> lamalex: ok, needs some rewording then. -r to the rescue!
[18:14]  * LarstiQ heads for dinner
[18:14] <lamalex> thanks
[20:42] <poolie> hullo all
[20:43] <lifeless> hi
[20:45] <poolie> hi there
[20:58] <LarstiQ> hi poolie, lifeless
[21:00] <lifeless> hi LarstiQ
[21:05] <jelmer> nåvond
[21:06] <LarstiQ> hey jelmer :)
[21:46] <maxb> jelmer: FYI bzr-builddeb r571 "Merge cleanup of DistributionBranch upstream attributes." causes problems for the udd importer - I guess that needs a related update. What were your intentions re compatibility there?
[21:47] <jelmer> maxb, I hadn't realized I had broken the udd importer - will have a look now.
[21:48] <milleja46> hi
[21:48] <maxb> jelmer: If you look in the importer's make_db_set, there's a construction of DistributionBranch with a None second argument - I think the blame is there
[21:49] <maxb> milleja46: hello
[21:49] <milleja46> i need to pull some updates for a project but i don't know how to set the bzr_ssh variable...what would the bzr_ssh variable be?
[21:49]  * milleja46 remembers he has to have pagent loaded XD
[21:49] <maxb> jelmer: "./import_package.py --no-existing --no-push python-oauth" is a relatively quick reproducer
[21:49] <maxb> milleja46: Oh. Windows. I don't know about that stuff :-)
[21:53] <LarstiQ> milleja46: iirc it doesn't always need to be set
[21:53] <LarstiQ> milleja46: but one option is "plink"
[21:56] <milleja46> LarstiQ: i know but i think i'd forgotten that i needed to have pagent running XD
[21:56] <LarstiQ> milleja46: ah right
[21:58] <milleja46> LarstiQ: is there a way to add plink to environment variables so that i don't have to set it again?
[22:01] <LarstiQ> milleja46: iirc there is an "Environment Variables" setting somewhere in System
[22:01] <LarstiQ> milleja46: you can add BZR_SSH=plink there
[22:02] <milleja46> so in the value part put bzr_ssh=plink?
[22:02] <milleja46> or just plink?
[22:49] <jelmer> maxb, fixed
[22:50] <jelmer> maxb, thanks for the reminder
[22:50] <maxb> awesome, thanks
[22:51] <maxb> bleh
[22:51] <maxb> I've found the bug which results in all these misplaced tags w.r.t the importer's meta
[22:52] <james_w> oooh
[22:52] <james_w> tell me
[22:52] <maxb> The importer is quite capable of moving tags.... but it only sends them back to launchpad using merge_tags_if_possible, mostly
[22:52] <james_w> ah
[22:53] <james_w> not sure it should be moving tags normally though should it?
[22:53] <maxb> an example is the iscsitarget import I'm trying to repair
[22:53] <maxb> It collided in maverick, so it push --overwrote that.
[22:54] <james_w> ah
[22:54] <james_w> collisions, of course
[22:54] <maxb> But, natty and oneiric were just straight pulls from what went before, so they kept the old tag
[23:06] <zyga> I'm trying to implement something equivalent to `bzr pull` using bzrlib
[23:06] <zyga> my simple code seems to work but it prints "unknown command commit"
[23:07] <systemclient> how can I tell bzr that I want to run astyle *.java before every commit?
[23:07] <zyga> am I missing something obvious?
[23:08] <zyga> here is my code: http://paste.ubuntu.com/631467/
[23:09] <lifeless> systemclient: a start_commit hook
[23:12] <zyga> lifeless, could you please have a look at my code and tell me if I'm missing something obvious (or there is an easier method of doing that apart from shelling out to bzr)
[23:12] <systemclient> lifeless: so I basically write a little python script that calls a shell command?
[23:12] <lifeless> zyga: I don't see where you are committing to trigger that error
[23:12] <lifeless> zyga: unknown command will be because you haven't loaded the bzr built in command classes (see bzrlib/command.py)
[23:13] <zyga> lifeless, I have no idea either, I'm running on daily bzr
[23:13] <lifeless> systemclient: yes, - can be very tiny
[23:13] <zyga> lifeless, let me reinstall bzr just in case
[23:13] <lifeless> systemclient: there are folk that have written generic call-shell-command implementations of the core hooks
[23:13] <lifeless> systemclient: I don't recall where they are offhand
[23:14] <zyga> lifeless, could I be initializing bzrlib incorrectly somehow?
[23:14] <poolie> we should really merge that
[23:15] <lifeless> well, you're definitely doing it a bit oddly
[23:15] <lifeless> poolie: it had security issues
[23:15] <zyga> lifeless, ah, it must have been coming from one of my plugins, sorry for the noise
[23:16] <zyga> lifeless, I wish I could do it easier but there is a bug in the way normal initialization works (I posted about this to the mailing list recently)
[23:16] <lifeless> zyga: you probably want to use bzrlib.initialize
[23:16] <lifeless> ah yes
[23:16] <zyga> lifeless, then fix it :>
[23:16] <lifeless> that surprised me
[23:17] <lifeless> zyga: you are as capable of that as me :>
[23:17] <zyga> lifeless, would you accept a simple fix without unit tests? I don't feel skilled in bzr internals enough to test this
[23:17] <poolie> zyga: if you want it to do what 'bzr pull' does' it would be easiest to just run run_bzr(['pull', ...])
[23:18] <zyga> poolie, run_bzr, I never saw that before, let me have a look
[23:18] <lifeless> zyga: you probably want to call bzrlib.commands.install_bzr_command_hooksI()
[23:18] <lifeless> zyga: that will register commit etc
[23:18] <lifeless> zyga: do that before you call load_plugins
[23:20] <zyga> lifeless, thanks, applied
[23:20] <zyga> lifeless, is there a way to initialize just the launchpad plugin?
[23:20] <zyga> lifeless, I would like to shield the system from random plugins users may have (and speed up oprations)
[23:20] <lifeless> bzrlib.plugin.set_plugin_path(); import bzrlib.plugins.launchpad
[23:20] <zyga> lifeless, awesome!
[23:20] <lifeless> (something like that)