=== 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 | ||
jam | morning all | 08:23 |
---|---|---|
jelmer | hi jam | 08:25 |
jam | hi jelmer, feeling better? | 08:25 |
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:26 |
fullermd | Well, I guess if .eu is here, it must be time for me to go... | 08:27 |
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:28 |
jelmer | jam: Yeah, me too | 08:29 |
fullermd | Sleep? I just did that _last_ week... | 08:29 |
jelmer | 'morning vila, fullermd | 08:29 |
vila | maxb: wrong revid used in bug #795703 (but the tags have been deleted nevertheless) | 08:33 |
ubot5 | Launchpad bug 795703 in Ubuntu Distributed Development "jubany fixups relating to misplaced tags (AssertionError:<module>:main:find_unimported_versions:check)" [Undecided,In progress] https://launchpad.net/bugs/795703 | 08:33 |
vila | maxb: I won't apply the other ones until you give feedback | 08:35 |
maxb | vila: Oh dear, do I fail at copy paste? | 08:55 |
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:56 |
maxb | Oh,yes. The revid I put for gnome-mousetrap is the same as the one from git-buildpackage above | 08:57 |
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:58 |
vila | maxb: yes, I saw the duplicate but had of course no idea what the right one could be | 08:59 |
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:00 |
maxb | oh. I failed, with the same revid, for gphoto2 and gst-plugins-base-0.10 too | 09:05 |
* maxb sorts | 09:05 | |
maxb | and apparently I fixed gnumeric on breezy, but now it's failing on hoary-security | 09:06 |
maxb | Whilst you're on jubany, could you also requeue --full ubuntu-defaults-builder ? | 09:12 |
vila | maxb: done | 09:12 |
vila | maxb: +1 for requeue in fixit.sh, it even allow c/p from IRC... :-p | 09:13 |
vila | maxb: almost a natural language UI (for some geek value of natural ;) | 09:14 |
maxb | I was just thinking something like that :-) | 09:14 |
=== hunger_ is now known as hunger | ||
maxb | vila: You saw my updated commands for gst-plugins-base0.10 gphoto2 gnome-mousetrap? | 09:17 |
maxb | (Just wanting to be sure since they partially interleaved with your comments on the bug) | 09:18 |
vila | maxb: gphoto2 and gst-plugins-base done | 09:20 |
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:21 |
vila | I *expect* errors | 09:22 |
vila | that's why I wanted to capture recipes in fixit.sh | 09:22 |
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:23 |
vila | or can there be some fallouts for users with local branches ? | 09:24 |
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:27 |
* vila blinks | 09:28 | |
maxb | ah, you did the tags, but not the requeue | 09:28 |
vila | my comment appears *after* yours ? | 09:28 |
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:29 |
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 changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | UDD failures: 444 | ||
maxb | :-) | 09:30 |
vila | nice number, let's stop there ! :D | 09:31 |
maxb | hmm | 09:31 |
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 | |
ubot5 | 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 |
vila | double gha | 09:34 |
vila | magcius: wrong nick completion, sorry for the noise | 09:35 |
vila | rhaa, what's the bug # for selftest not using python provided definition for number of available processors/threads ? | 09:42 |
jelmer | vila: are you sure we have one? IIRC we only use the python provided one in some cases | 09:49 |
vila | oh, may be a fix has landed, let me check the annotations | 09:50 |
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:51 |
vila | hmm, the python impl slightly diverge from our fallback... (sunos5 and even darwin) | 09:55 |
vila | ok, forget about it | 09:55 |
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:43 |
jelmer | lifeless: I've seen it before on occasion, but I'm not sure what causes it | 11:47 |
jdobrien | lifeless, he's here in orlando AFAIK | 12:00 |
lifeless | jdobrien: yes, he is | 12:03 |
briandealwis | git users: is there a git equivalent of bzr's append_revisions_only? | 13:40 |
jelmer | briandealwis, I'm not sure how it works exactly, but I think the term you're looking for is "fast forward only" | 13:48 |
briandealwis | jelmer: thx for the pointer | 13:49 |
=== mbarnett` is now known as mbarnett | ||
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:33 |
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:34 |
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:36 |
jelmer | RobOakes: you can use the nest command if you don't want them to have shared history | 15:39 |
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:41 |
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:44 |
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:45 |
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:46 |
RobOakes | Would the nest line look something like this: merge packaging nest lp:~... | 15:49 |
jelmer | no, it would be nest rather than merge | 15:51 |
RobOakes | Okay. Is there a difference between nest-part and nest? | 15:52 |
RobOakes | (bzr help is being less than helpful and Bug report which discusses them doesn't delve into the differences.) | 15:53 |
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:03 |
=== med_out is now known as med | ||
=== med is now known as medberry | ||
RobOakes | Okay, so something like this: nest packaging lp:~lyx-outline-devel/+junk/lyx-debian debian? | 16:09 |
RobOakes | If I wanted to place the entire contents of lyx-debian into a folder called debian? | 16:10 |
poolie | lifeless: hi, it's vaguely familiar, the thing would be to work out which file or line is raising it | 16:36 |
jelmer | 'morning poolie | 16:45 |
poolie | hi there jelmer | 16:54 |
jamdahl | Hi everyone, I'm having some difficulty with bazaar allowing out of date checkouts to make commits | 17:19 |
maxb | Can you elaborate on what you mean? | 17:21 |
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:30 |
jamdahl | Checkout 2 makes a conflicting edit and commits | 17:31 |
jamdahl | My problem is that checkout 2 got no warning and was allowed to commit | 17:32 |
jamdahl | any ideas? | 17:44 |
jelmer | jamdahl, how were the checkouts created? | 17:52 |
jamdahl | bzr checkout remotedirectory localdirectory | 17:54 |
LarstiQ | evening | 17:55 |
lamalex | hi, does bzr grep search history? is there a plugin that will grep a projects history for some pattern/lines of code? | 17:57 |
jelmer | jamdahl: that's odd - what happened to the contents of the remote branch? | 18:04 |
maxb | jamdahl: Are you sure no one used "bzr branch", "bzr unbind" or "bzr commit --local" anywhere in this? | 18:05 |
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:07 |
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:09 |
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:10 | |
LarstiQ | lamalex: if you don't specify a revision, and also not a filename, it seems to grep through history | 18:11 |
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:12 |
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:13 |
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 | 18:14 |
=== yofel_ is now known as yofel | ||
poolie | hullo all | 20:42 |
lifeless | hi | 20:43 |
poolie | hi there | 20:45 |
LarstiQ | hi poolie, lifeless | 20:58 |
lifeless | hi LarstiQ | 21:00 |
jelmer | nåvond | 21:05 |
LarstiQ | hey jelmer :) | 21:06 |
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:46 |
jelmer | maxb, I hadn't realized I had broken the udd importer - will have a look now. | 21:47 |
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:48 |
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:49 |
LarstiQ | milleja46: iirc it doesn't always need to be set | 21:53 |
LarstiQ | milleja46: but one option is "plink" | 21:53 |
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:56 |
milleja46 | LarstiQ: is there a way to add plink to environment variables so that i don't have to set it again? | 21:58 |
LarstiQ | milleja46: iirc there is an "Environment Variables" setting somewhere in System | 22:01 |
LarstiQ | milleja46: you can add BZR_SSH=plink there | 22:01 |
milleja46 | so in the value part put bzr_ssh=plink? | 22:02 |
milleja46 | or just plink? | 22:02 |
=== milleja464 is now known as milleja46 | ||
jelmer | maxb, fixed | 22:49 |
jelmer | maxb, thanks for the reminder | 22:50 |
maxb | awesome, thanks | 22:50 |
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:51 |
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:52 |
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:53 |
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 | 22:54 |
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:06 |
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:07 |
zyga | here is my code: http://paste.ubuntu.com/631467/ | 23:08 |
lifeless | systemclient: a start_commit hook | 23:09 |
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:12 |
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:13 |
zyga | lifeless, could I be initializing bzrlib incorrectly somehow? | 23:14 |
poolie | we should really merge that | 23:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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) | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!