[00:01] <lifeless> jam: do you want to talk about parth's patch ?
[00:06] <lifeless> jelmer: feed-pqm will take the lp commit message and Just Work
[00:06] <lifeless> poolie: I'm going to mail the bzr list about savannah now, unless you want to?
[00:08] <poolie> go for it
[00:18] <GaryvdM> lifeless: does it make sense that we should not have to import xml when doing bzr status on a 2a branch, or am I missing something.
[00:19] <jelmer> lifeless: I haven't had feed-pqm working yet
[00:19]  * jelmer tries to remember what was wrong last time
[00:19] <GaryvdM> lifeless: I cant work out if the inventories are stored in xml or bencode
[00:20] <lifeless> jelmer: please give it a shot and file a bug
[00:20] <lifeless> jelmer: I want to stabify to death pqm-submit.
[00:20] <lifeless> GaryvdM: in 2a? neither.
[00:20] <lifeless> GaryvdM: commit objects are stored in bencode I think.
[00:20] <lifeless> early CHK formats used xml commit objects
[00:21] <GaryvdM> lifeless: Cool
[00:30] <jelmer> lifeless: :-)
[00:30] <jelmer> lifeless: will do
[00:59] <igc> morning
[01:02] <GaryvdM> Morning igc
[01:02] <igc> hi GaryvdM
[01:06] <poolie> +1 re pqm
[01:06] <poolie> hi igc
[01:06] <igc> hi poolie
[01:06] <poolie> igc, can you catch up with jam sometime to hand over windows build stuff?
[01:06] <igc> poolie: sure
[01:19] <lifeless> \o/ I'm down to inbox 72
[02:05] <lifeless> bbs, grabbing lunch
[04:13] <eric_f> is there a way to "undo" a rename?
[04:13] <eric_f> I did bzr mv --auto and it's pretty far off
[04:14] <poolie> eric_f, mv --after to put it back the way you want
[04:28] <poolie> lifeless, does anything else need to happen on 2.1.2 and 2.2b3?
[04:29] <poolie> could you try to push the former into SRUs and backports?
[04:29] <lifeless> poolie: I've put 2.1.2 forward for lucid already
[04:30] <lifeless> I haven't done anything for backports, as you say its probably finding the right person to tickle
[04:30] <lifeless> poolie: I put the 2.1.2 lucid SRU forward on friday
[04:30] <poolie> great
[04:31] <poolie> there is a bug asking for a backport...
[04:33] <lifeless> I believe so
[04:33] <lifeless> you've commented on it before.
[04:36] <Jaearess> What does an asterisk by a file mean in the 'bzr status' command?
[04:37] <Jaearess> My Google search only turned up a bug report that it wasn't documented, but not what it actually means.
[04:37] <mwhudson> it means it's either gained or lost the execute bit since the last commit
[04:37] <Jaearess> Ah, thank you.
[04:38] <Jaearess> Someone wielding chmod -R 777 wildly would probably cause that to show up on a lot of files, correct?
[04:47] <lifeless> yes
[04:47] <spiv> Jaearess: yes
[04:50] <lifeless> spiv: sigwinch is done, yes?
[04:52] <spiv> lifeless: gosh I hope so!
[04:52] <lifeless> just updating kanban
[05:17] <spiv> Hmm.
[05:17] <spiv> That was odd.
[05:17] <spiv> My internet connection mostly dropped out... except I could still reach Google.
[05:17] <lifeless> spiv: !
[05:17] <spiv> Then Mary came home and the rest returned!
[05:17] <lifeless> spiv: anyhow, while I'm looking at Kanban
[05:18] <spiv> So, you were asking about sigwinch: yes that should be done -- we no longer register a sigwinch handler :)
[05:18] <lifeless> do you want to confirm that you're (removing relocking, doing merge-subdirs)
[05:18] <lifeless> which are the two things in kanban with your name on them
[05:18] <spiv> Yes, confirmed.
[05:18] <lifeless> if you're not doing either, we should put it back in the backlog
[05:19] <spiv> I'm not actively doing removing relocking.
[05:19] <spiv> But it is a background task I nibble at from time to time.
[05:19] <lifeless> right
[05:19] <lifeless> I don't think we've got a good way to really show 'not significant time' tasks
[05:19] <lifeless> which I think that that falls under, no ?
[05:20] <lifeless> 16:18 < bob2> yay, exetel plugged their international link back in
[05:20] <lifeless> spiv: ^
[05:21] <spiv> lifeless: ah, although it affected some .au stuff for me as well!
[05:23] <lifeless> probably peered stuff
[05:31] <lifeless> sign MS
[05:31] <lifeless> please, if you're going to make a free virus scanner, don't make it broken.
[05:31] <lifeless> you've got the dang OS source code in front of you.
[05:40] <fullermd> Sure, but who can read it?
[05:43] <lifeless> fullermd: their staff can, one hopes
[05:45] <fullermd> Aw.  You're so coot when you're optimistic   :)
[05:47] <lifeless> ha!
[05:47] <lifeless> fullermd: http://preachsecurity.blogspot.com/2009/06/microsoft-security-essentials-road-test.html
[05:47] <lifeless> fullermd: "Overall some things that I noticed is that the engine's real time protection is a little lacking, as it rarely (only once) caught the piece of malware as it was being unzipped, and typically only when I attempted to actually run the file."
[05:56] <lifeless> oh and https://support.mozilla.com/en-US/forum/1/542294
[05:57] <lifeless> for added value 'ms virus scanner breaks firefox. Yay.'
[06:00] <mneptok> lifeless: most clergy have their holy books right in front of them, and really can't decipher them in any meaningful way, either. ;)
[06:00] <lifeless> mneptok: I'm not sure fiction counts as source code ;P
[06:01] <mneptok> lifeless: tell that to HURD developers.
[06:01] <lifeless> LOL
[07:23] <vila> hi all
[07:23] <vila> poolie: ping, quick chat ?
[07:24] <lifeless> poolie just popped out for a bit
[07:24] <lifeless> try him again in 20
[07:24] <lifeless> gnight
[07:25] <vila> lifeless: thks, g'night
[08:25] <poolie> hi vila
[10:16] <NET||abuse> hey guys,, had a weird thing just happpen
[10:18] <NET||abuse> i was changing permissions for access to a bzr repo/working copy to run on a server, the two users in question were in the same group, so i rann chmod -R 775 bzrrep/  where the working copy and standalone repo is on the server,
[10:18] <NET||abuse> then as the second user i tried bzr up(i'd just pushed up a change from my local machine) but i'd failed to update permisisons .bzr.log, it ran the update and also gave an error saying permissino denied on that log file,,, problem is nwo when i run bzr st as either user in the working copy, everything is marked as modified.
[10:19] <NET||abuse> i don't think it was doing that before now, though i didn't happen to check
[10:19] <fullermd> Well, you set the +x flag on every file in the WT; presumably most of them didn't have it before, so that WOULD be a modification...
[10:19] <NET||abuse> ohh, format: pack-0.92   is that out of date.
[10:19] <NET||abuse> ahhhh
[10:19] <NET||abuse> fullermd, of course, duh
[10:20] <NET||abuse> so ye, it's got that change marked,, any wya to get it to disregard that change?
[10:20] <fullermd> Disregard?  No.  You could use revert (or another chmod) to undo it.
[10:20] <NET||abuse> or would i be better checking it out to a parallel directory location as the new user i want to switch over to using?
[10:51] <flam> is there a command to update bazaar to a newer version? i'm using windows
[10:52] <flam> bzr help commands didn't show it, neither did few minutes of googling:p
[14:17] <mgz> flam: no, windows doesn't work like that. download and run the new msi. or a debiant install cd.
[14:18] <mgz> -t
[14:42] <starenka__> hi, sorry for silly question, but i have problems w/ group permissions while using bzr+ssh
[14:43] <starenka__> i set umask in /etc/profile to 002 and it works in shell, but while pushing repo to server the repo is rw-r--r--  any clue?
[15:10] <TresEquis> starenka__: google points to this: https://lists.canonical.com/archives/bazaar/2007q3/027560.html
[15:11] <starenka__> thanks. i made a "wrapper" script in /usr/bin/local/bzr which sets umask and runs bzr
[15:11] <starenka__> it works like a charm
[17:12] <parthm> jam: ping
[17:17] <jam> hi parthm
[17:17] <parthm> jam: hi, i was thinking some more about the `bzr st` bad ignore pattern
[17:18] <parthm> i am somewhat divided between warning / error but am leaning towards error. if we have a bad pattern other commands like `add` and `ignored` would fail anyway.
[17:19] <parthm> i am not sure if there are others. so it may be better to fail quickly and have the user fix it sooner than later.
[17:21] <parthm> there could also be a case that a user ends up pushing a bad pattern to their server/lp. as .bzrignore is already added. its just a `bzr ci` and `bzr push`.
[17:21] <parthm> so failing on `st` may be a good idea.
[17:22] <jam> parthm: why would add and ignore have to fail?
[17:22] <jam> the point is that, especially right now, people may have a bad config
[17:23] <jam> having it fall over when it used to work is bad
[17:23] <jam> having it fall over *in general* is bad
[17:23] <jam> I don't feel super strongly
[17:23] <jam> but we've done the 'error early' in the past
[17:23] <jam> and generally it has provided worse user experience
[17:24] <jam> as a minor misconfiguration in X
[17:24] <jam> suddenly blocks Y and Z from working at all
[17:25] <parthm> jam: `ignore` works, it issues a warning and discards the bad pattern.
[17:26] <jam> even if the pattern was already in the file?
[17:26] <parthm> `ignored` fails as we compile all ignored patterns (99 at a time) into one pattern. so we cant selectively ignore.
[17:27] <jam> you certainly *could*
[17:27] <parthm> jam: yes. if  a file has a bad pattern, `ignore` would still work. so it issues a warning about the pattern on the command line. if the tree is processed, then a followup error is shown about the existing bad pattern.
[17:28] <jam> parthm: the problem is that if we filter out the bad pattern from the disk content we make it harder to get the right pattern
[17:28] <jam> since the old one is gone
[17:28] <jam> it may be a fair trade
[17:28] <jam> but something to be thought about
[17:28] <parthm> jam: we don't filter out the bad pattern from the file. filtering is only for the command like. we display an error message for the pattern in file.
[17:30] <parthm> jam: http://pastebin.com/fMWtEUjc
[17:30] <jam> so for compiling, we could certainly attempt the 100-way compile and if it fails rollback
[17:31] <parthm> jam: i am not sure i understand. are you talking about `ignored`?
[17:31] <jam> yes
[17:31] <jam> but also statu
[17:31] <jam> status
[17:31] <jam> add, etc
[17:32] <parthm> jam: what do you mean by try the compile and rollback?
[17:40] <jam> parthm: try to compile all 100, if it fails, compile them individually to find the one that failed
[17:41] <parthm> jam: thats whats done in the current patch. the current patch allow the operation to happen, if there is an exception, it processes the file to find the bad pattern and displays it along with the error message.
[17:41] <jam> so why does ignored *have* to fail?
[17:42] <parthm> jam: so are you suggesting we retry after filtering out the bad pattern at runtime?
[17:42] <jam> That is what I've been suggesting, yes
[17:44] <parthm> jam: IMO once the user has a bad pattern in the file he would sooner or later end up with a problem so it may be better to just error out pointing to the pattern.
[17:44] <parthm> i don't think existing installation would have a bad pattern as it would make bzr crash.
[17:44] <jam> parthm: the difference is whether someone can still finish what they were trying to do
[17:44] <jam> *before* they have to fix everything
[17:44] <jam> or if they have to drop their train of thought
[17:45] <jam> and go handle this thing
[17:46] <parthm> jam: i agree with your point on 'train of thought' but the results of a command e.g. `ignored` may not be what the user expects due to the skipped pattern.
[17:47] <jam> parthm: that is why we give a big warning
[17:49] <parthm> jam: i suppose being a ui thing there is no obviously right answer :)
[17:50] <parthm> jam: i will paste this chat on the merge proposal and probably others can chime in with their views.
[17:58] <C-S> How can I add stuff to the bzr wiki?
[17:59] <parthm> C-S: You should be able to create a login and edit it.
[17:59] <parthm> C-S: What do you have in mind?
[18:00] <C-S> parthm: I just added qbzr and bzr-explorer to the FreeBSD port system. That needs to be reflected in the downloads sections of qbzr and bzr-explorer.
[18:00] <parthm> C-S: cool :)
[18:01] <C-S> parthm: indeed. bzr-git and bzr-svn are under way :-)
[18:01] <parthm> C-S: yay!
[18:01] <C-S> parthm: which means we will have all necessary tools easily installable on FreeBSD!
[18:02] <C-S> parthm: here is an example: http://www.freshports.org/devel/bzr-explorer/
[18:02] <parthm> C-S: thats pretty neat. it should make things very convenient for a lot of users. the plugins you mention have dependencies and not the most convenient to install.
[18:03] <C-S> parthm: right, that makes it much easier. bzr-svn requires subvertpy for example and bzr-git dulwich. The FreeBSD ports system installs them automatically as needed
[18:03] <C-S> parthm: I had to port subvertpy too, of course.
[18:04] <parthm> C-S: you can probably mention this on the bzr mailing list. there may be interested parties there too.
[18:04] <C-S> parthm: You can have a look at the respective Makefile where all the dependencies are mentioned: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/bzr-explorer/Makefile?rev=1.1;content-type=text%2Fplain
[18:05] <C-S> parthm: good idea. I am not on these lists though. Do you have a link?
[18:05] <parthm> C-S: i was a FreeBSD user for quite some time. been on ubuntu for about 2 years now.
[18:05] <C-S> parthm: FreeBSD is a beauty. You should consider a switch :-)
[18:06] <mgz> parthm: I'm massacring bzr-grep for fun, please review when I'm done
[18:06] <C-S> parthm: cool. I am already working on a port for bzr-grep. Are you the maintainer?
[18:06] <parthm> mgz: sounds good :)
[18:06] <parthm> C-S: yes. i am the maintainer for bzr-grep
[18:07] <C-S> parthm: if yes. please post your releases on launchpad. that makes it much easier for me to grab the latest copy.
[18:07] <C-S> parthm: otherwise, I have to download via bzr and release 0.3.0 myself.
[18:07] <C-S> parthm: that is annoying.
[18:07] <C-S> parthm: second, that way, I'll have a second backup download site
[18:08] <parthm> C-S: do you mean a tarball?
[18:08] <C-S> parthm: right
[18:08] <C-S> parthm: by the way. bzr-grep is absolutely great
[18:08] <parthm> C-S: will do.
[18:08] <parthm> C-S: good to know :)
[18:08] <C-S> parthm: cool. Many many thanks. You make my life easier.
[18:09] <C-S> parthm: as you know, people of FreeBSD don't want to release updates via bzr or some VCS. It just doesn't make sense for the average user
[18:09] <C-S> parthm: so, tarball would be great :-)
[18:09] <parthm> C-S: i agree.
[18:10] <C-S> parthm: Great. So, I wait for your tarball and will then continue on the port.
[18:10] <mgz> while I have you right here:
[18:10] <mgz>     line = line.decode(_te, 'replace')
[18:10] <mgz> why?
[18:10] <mgz> and... wha?
[18:10] <mgz> this is a raw line from a file we're greping through,
[18:10] <parthm> C-S: when i was a casual bzr user i myself preferred installing it via apt-get on ubuntu. have been thinking of creating a ppa.
[18:10] <mgz> that we want to print *to* the terminal
[18:10] <mgz> why are we *de*coding it in the terminal encoding?
[18:10] <C-S> parthm: sorry, but what is a ppa?
[18:11] <C-S> parthm: something like a package?
[18:11] <parthm> C-S: ppa is the package system for ubuntu.
[18:11] <C-S> parthm: Ok. Sure, I agree, packages/ports are so much easier for most people.
[18:12] <parthm> mgz: thats probably a bug then. my unicode-fu is not the best :( ... could you file a bug?
[18:12] <C-S> parthm: and you usually have bugs in development, so it makes sense to stay with the official release as long as posible.
[18:12] <C-S> parthm: anyway. many thanks.
[18:12] <mgz> I'll just fix it when I'm done with this consolidation
[18:12] <parthm> C-S: thanks for the freebsd ports :)
[18:13] <C-S> parthm: sure. Its a pleasure.
[18:13] <mgz> I might break some things, am touching a lot of code branches, but if I do, it's your tests fault :P
[18:13] <parthm> mgz: great :)
[18:13] <parthm> mgz: yes ... i think the tests should be sufficient. if not will add some more :)
[18:18] <parthm> mgz: what are you looking into regarding bzr-grep?
[18:19] <mgz> well, what I *started* looking at and what I'm doing are... nothing like each other
[18:19] <mgz> I'm currently deleting code.
[18:19] <mgz> I wanted to do some unicode things.
[18:19] <mgz> hmmm:
[18:19] <mgz> a = '\x1b[35m\x1b[35mfile0.txt\x1b[0m\x1b[1;36m:\x1b[0m\x1b[1;31mfoo\x1b[0m is \
[18:19] <mgz> x1b[1;31mfoo\x1b[0mbar1\n'
[18:19] <mgz> b = '\x1b[35mfile0.txt\x1b[0m\x1b[1;36m:\x1b[0m\x1b[1;31mfoo\x1b[0m is \x1b[1;31
[18:19] <mgz> mfoo\x1b[0mbar1\n'
[18:20] <mgz> I think I better go back to longer ansi sequences for the moment, to avoid confusing the tests
[18:20] <LeoNerd> Can't you use an  \e  to help those
[18:20] <LeoNerd> ?
[18:20] <mgz> oo, but I've duped the lead in.
[18:20]  * mgz fixes that
[18:21] <parthm> mgz: the unicode support is probably not the best in bzr-grep. this was before i really actually understood unicode :P .. not that i get it fully yet.
[18:21] <mgz> well, it's largely not your fault anyway, you're kinda stuffed on knowing what the file contents are
[18:22] <mgz> anyway, so what I'm doing currently is making bzr-grep a bit slower so I can delete some code, and make it faster
[18:22] <mgz> what it comes out the other end like, I have no idea
[18:22] <parthm> mgz: i am glad to have another pair of eyeballs on bzr-grep. thanks.
[18:23] <mgz> okay, I'm just gonna change the test on that bit, saves an ansi switch
[18:23] <mgz> bom ta dom ta dom
[18:24] <parthm> well, its getting late here. goodnight.
[18:25] <mgz> night!
[19:25] <vila> mgz: ping
[19:25] <mgz> boingy.
[19:27] <mgz> vila: any fun progress on leaks?
[19:27] <vila> yeah, a robust socket server in a thread, with fresh tests
[19:28] <vila> Oh, and clear road ahead to turn my experiments into production
[19:28] <vila> mgz: see my pm ?
[19:46] <ompaul> can anyone tell me how to dig around in a bzr .pack file
[20:21] <jam> ompaul: in general, the contents aren't going to be very friendly to generic digging, is there something specific you are trying to do?
[20:25] <ompaul> just curious to see what happened historically
[20:25] <jam> ompaul: trying to see the history of individual files?
[20:25] <ompaul> jam, I have a 30 meg pack file
[20:26] <ompaul> out of 42megs
[20:26] <ompaul> kind of like s2n :)
[20:26] <jam> ompaul: you might be interested in https://edge.launchpad.net/bzr-repodetails
[20:26] <jam> ompaul: we collapse pack files over time
[20:27] <ompaul> ok
[20:27] <ompaul> thanks
[20:27] <jam> so that 30M is probably the bulk of your history
[20:27] <ompaul> it is since day one
[20:27] <ompaul> jam, thank you for that
[20:28]  * ompaul wanders off to share this new clue file 
[20:53] <lifeless> vila: hi
[20:54] <lifeless> vila: what did you find to be the cause of the leaks?
[20:54]  * vila waves
[20:54] <vila> the cause was known for a long time: http server threads,
[20:54] <vila> I've found some server in the sftp area
[20:55] <vila> The main source of problems was uncaught exceptions in these threads especially when I started closing their socket from *another* socket
[20:56] <jam> hi vila, go to bed :)
[20:57] <vila> jam: hey ! Yeah, yeah, bed, good
[20:57] <lifeless> vila: ok cool
[20:57] <lifeless> vila: uhm, the paste web server has code to kill threads
[20:57] <lifeless> hi jam
[20:57] <jam> lifeless: ouch, somebody creamed you in bym
[20:57] <lifeless> yeah
[20:57] <vila> lifeless: *kill* threads ? Via a C extension ?
[20:57] <lifeless> took them 6 waves of 48 ichis
[20:58] <lifeless> and then 2 more waves to get resources
[20:58] <lifeless> vila: ctypes; have a look at it
[20:58] <jam> lifeless: yeah, I find that putting ProjectX in there actually helps a lot
[20:58] <jam> 2 X's is as much dps as the other 41 Ichis, and if you stagger them correctly, they usually help to take out a tower or two
[20:58] <vila> lifeless: that would complement what I just did quite nicely.. I'll check
[20:58] <jam> (if a snipe focuses them they go down in 2 hits, though)
[20:59] <lifeless> jam: i think she was pissed that in 4 waves I made a pretty deep dent in her yard
[20:59] <jam> lifeless: who?
[20:59] <lifeless> april
[20:59] <lifeless> the person who attacked me [just a random neighbour]
[20:59] <jam> sorry, can't help, not in my neighbor list :)
[21:00] <lifeless> :)
[21:00] <lifeless> jam: I was looking at kanban
[21:00] <lifeless> yesterday; I'm wondering if its a little stale
[21:01] <lifeless> are you stil working on win32 installer scripts, historydb, fetch perf and annotation caches ?
[21:02] <jam> lifeless: the historydb stuff is pretty much done, so I moved it over
[21:02] <jam> the rest, yes
[21:07] <james_w> abentley: do you know how to deal with "bzr: ERROR: Format Checkout reference format 1 cannot be initialised by this version of bzr." and a broken branch when using reconfigure-pipeline?
[21:08] <james_w> well, I've got my branch back, but I have no idea what the error was telling me to start with
[21:13] <james_w> ah, API issues due to colo change
[21:14] <james_w> fixed by pulling bzr-pipeline, thanks abentley
[21:20] <abentley> james_w, happy to help :-)
[21:34] <bendj> I logged into a client's box to try to un-fubar some of their recent work.  @ a 'bzr pull' I get "bzr: ERROR: exceptions.ImportError: cannot import name LogicalLockResult" ( more -> http://pastebin.com/EbC5jCf5)
[21:34] <bendj> New one on me ... though I notice they've bzr 2.2b3.  Sound familiar to anyone?
[21:42] <jam> bendj: sounds like api skew, where some of there modules are up to date, and some are not.
[21:42] <jam> Since 2.2b3 isn't packaged yet (I believe) you might try deleting the existing install, and installing from scratch again.
[21:43] <bendj> jam: k. brb ...
[21:55] <lifeless> ok
[21:55] <lifeless> some to overhaul branch cloning a it
[21:55] <lifeless> *bit*
[21:55] <bendj> jam: cleaned house, dropped back to a 2.1.0 tarball, up'd to 2.2b3 trunk, reinstalled modules.  back in business ... except for one plugin: dulwich
[21:56] <bendj> getting,
[21:56] <bendj> Pulling /usr/local/lib/python2.6/site-packages/bzrlib/plugins/dulwich from bzr+ssh://bazaar.launchpad.net/~vcs-imports/dulwich/trunk/
[21:56] <bendj> Not a branch: "bzr+ssh://bazaar.launchpad.net/~vcs-imports/dulwich/trunk/".
[21:56] <jam> bendj: "bzr pull --remember lp:dulwich"
[21:57] <jam> I'm guessing the trunk location moved
[21:58] <bendj> jam bingo.  thanks!  now back to our regularly schedule un-fubaring ...
[22:15] <jelmer> lifeless: hi
[22:15] <lifeless> hi
[22:16] <jelmer> lifeless: are you aware of a good way to store version info in a single file?
[22:16] <lifeless> you mean like bzr version-info ?
[22:16] <jelmer> lifeless: I'd like it to be available from both __init__.py and setup.py
[22:17] <jelmer> but there doesn't seem to be a good way to do that that doesn't break BZR_PLUGINS_AT and 'bzr plugin-info'
[22:17] <exarkun> jelmer: The least terrible option I've heard is to keep it in package/version.txt and read it from setup.py and __init__.py.  But clearly there are plenty of pitfalls there.
[22:18] <jelmer> exarkun: yuck :-(
[22:18] <lifeless> jelmer: how does it break things?
[22:18] <jelmer> lifeless: they don't support relative imports
[22:18] <jelmer> so 'import info' from __init__.py doesn't work
[22:18] <lifeless> what!
[22:18] <lifeless> it sure should
[22:19] <jelmer> it doesn't work when using BZR_PLUGINS_AT
[22:19] <lifeless> sounds like a bug in BZR_PLUGINS_AT
[22:19] <lifeless> theres no reason it shouldn't work
[22:19] <jelmer> ok, that's easy then
[22:19] <vila> lifeless: there is one: it's a bug :-(
[22:20] <lifeless> I fixed a bug in plugin-info a short while back to permit doing this
[22:20] <lifeless> so it *was* working
[22:20] <lifeless> vila: sounds like BZR_PLUGINS_AT isn't finished then.
[22:20] <jelmer> it works when not using BZR_PLUGINS_AT
[22:21] <vila> the problem is that during the import of the plugin's __init__.py the module path is not set, so plugins that are fully lazy work (the module path *is* set *after* the __init__.py file load :-/
[22:21] <jelmer> I've been using it for quite some time and I remembered 'bzr plugin-info' was broken
[22:21] <jelmer> but it works now :)
[22:22] <vila> lifeless: it escaped the tests... I have some idea about a possible workaround but no time to investigate
[22:22] <vila> namely: force a dummy module with the right path into sys.modules
[22:22] <vila> but I don't know if python will like that...
[22:22] <jelmer> vila: should I file a bug?
[22:22] <vila> jelmer: sure
[22:22] <lifeless> vila: I have no idea what BZR_PLUGINS_AT is doing, but I suspect its about 1000 time more complex than needed
[22:23] <lifeless> :)
[22:23] <vila> lifeless: if you can cut the number of lines by 1000, I'll give you a bottle of champagne :)
[22:23] <lifeless> vila: :P
[22:24] <vila> lifeless: I went with the lightest way I could think of relying on... some python provided load_module which obviously doesn't address this "detail" :-)
[22:26] <lifeless> vila: load_module in plugin.py ?
[22:27] <vila> lifeless: yeah, it uses imp.locad_module and then set the mod._path__, this 'mod' is then inserted into sys.modules by python I think
[22:28] <vila> s/locad/load/
[22:50] <lifeless> vila: do you need help with it
[22:50] <vila> lifeless: to try that ? No, I need time :-/
[22:51] <vila> I thought I was the only one blocked by it and went with creating a symlink in bzrlib/plugins instead (temporary :-/)
[22:51] <vila> yeah, I know, I should have filed a bug, bad vila
[22:52] <lifeless> go sleep