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