[00:00] heya! [00:00] * Verterok waves greetings [00:00] jfroy: it looks like a bug un setuptools :( [00:01] jfroy: or an old version [00:02] Verterok: not part of setuptools, that's part of bdist_mpkg [00:02] How do you get "bzr: ERROR: No module named tests" when running from source?! :( [00:02] Ahh! Plugin! Heh [00:02] jfroy: right, it seems to be fixed in trunk [00:03] That's what I get for not reading hte traceback first. [00:03] Verterok: Ah, I see [00:04] jfroy: the trac instance seems to be down, but you can get it from the svn: "< impl> I didn't realize Aerdan had prioritized the animals he wants to have sex with"] [00:04] 19:48 < mxpxpod> jelmer: ok, thanks [00:04] worng paste :p [00:04] jfroy: http://svn.pythonmac.org/bdist_mpkg/bdist_mpkg/trunk/ [00:04] yeah I got it :) [00:04] ok [00:05] Verterok: seems to work great [00:06] nice [00:07] poolie: can you call back? [00:07] sure [00:09] hi poolie [00:09] Verterok: yup, works :) [00:09] jfroy: yay! [00:11] It is Very Good™ not to have to type my svn passwords 3 times or more for operations on svn repositories (with my experimental bzr+keychain branch) [00:11] :) [00:12] Need to get that out of experimental now :p [00:13] poolie: sorry, missed it [00:13] poolie: pls ring again [00:13] Verterok: It's kind of sucky that you have to maintain two builds to target 1.4 and 1.5 [00:14] jfroy: yeap, don't have an idea of how much I agree on that [00:14] Tiger is so long ago for me, was svn even bundled with it? [00:14] jfroy: but I know there are a lot of people still on 1.4.x [00:14] jfroy: nope, you must install it from "somewhere" (macports, collabnet, etc) [00:18] Verterok: that's incredibly crappy :/ [00:19] jfroy: yeap, that's the reason I only build it against collebnet binaries :) [00:19] Honestly, I'd just make 2 packages, one for svn 1.4 and one for svn 1.5, installed in /usr/local/ (e.g. the collabnet binary packages). If they have it elsewhere, I'd just tell them to build bzr-svn from source... [00:19] Eek, there's a test that builds everything? [00:20] jfroy: imagine building it for macports, fink, collabnet (all x2 (1.4 amd 1.5)) :p [00:20] Verterok: no thanks ;p [00:20] me neigther :) [00:21] If you wanted to be *reaallly* clever, you could build against 1.4 only in /usr/local, then use an installer script to find the actual install, then muck around the Mach-O headers to change the import paths, and hoping the 1.5 libraries are binary compatible with the 1.4 libraries :p [00:21] Sounds like a lot of unpleasant installer script work :p [00:22] indeed :p [00:23] Verterok: oh, you'd also have to weak import all symbols and modify the bzr-svn source to check for NULL function symbols, in case someone decides to build from source and omit support for https, or keychain, or what have you :p [00:25] jfroy: that sounds way too complicated :), I'll stick with the script that build both version against collabnet binaries. as far I know, is the more complete dmg for 10.4 [00:26] if someone builds svn from source, I'm pretty sure the 'll be able to build bzr-svn ;) [00:26] Verterok: I wasn't being serious :p [00:26] jfroy: I supposed that, but just in case :) === jamesh_ is now known as jamesh [03:08] markh, could you try to build 1.7.1 exes sometime? [03:08] i did not set up that server yet [03:08] i'd like to [03:09] poolie: sure - I'll try and do that this afternoon [03:09] thanks [03:11] I've been working on porting pywin32 to py3k recently - that is an interestng experience :) [03:12] well - more like watching/helping some other person do it :) [03:12] I figured I should get a little hands-on experience before the first official release - even if only by a few days [04:00] spiv: is there a config option I can use so that -dHPSS is always on? [04:16] jml: "alias bzr='bzr -Dhpss'" in your bashrc ;) [04:21] incidentally, MemoryTransport.rename's behaviour varies based on dict ordering. [04:26] jml: that doesn't sound good. [04:26] spiv: it doesn't feel good eiter. [04:27] in other sucky news [04:27] mwh@grond:init-stack-pull$ bzr push [04:27] Using saved push location: bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/init-stack-pull [04:27] bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('bzr+ssh://bazaar.launchpad.net/%7Emwhudson/launchpad/init-stack-pull/.bzr/repository/') [04:28] mwhudson: pastebin the traceback? [04:28] spiv: there is no traceback [04:29] mwhudson: ~/.bzr.log is your traceback-recording friend! :) [04:29] hey guess what guys!!! [04:29] it was autopacking [04:29] It might be caused by the same sort of situation that has caused TooManyConcurrentRequestErrors in the past. [04:29] Heh. [04:29] number one bzr bug [04:30] at least it's fixed now [04:30] mwhudson: I'd still like to see the traceback :) [04:31] spiv: https://pastebin.canonical.com/9805/ [04:32] spiv: happens with bzr.dev 3731 too fwiw [04:32] Yeah, I think it does have the same root cause. [04:32] mwhudson: thanks [04:32] my bzr.dev may be a little out of date tho [04:33] spiv: bug 276972 if you are interested. [04:33] Launchpad bug 276972 in bzr "MemoryTransport.rename behaviour varies with dict ordering" [Undecided,New] https://launchpad.net/bugs/276972 [04:39] jml: ta [04:44] spiv: happens with bzr.dev too, but maybe upgrading the bzr on the server would fix it? not sure [04:44] (as would maybe pushing over sftp i guess) [04:46] mwhudson: depends on what the underlying error that is being masked by the bug in BzrBranch.push is [04:46] mwhudson: I can give you a patch to allow the original exception to propagate [04:47] spiv: i am driving several hundred km away in about 20 mins :) [04:47] mwhudson: http://rafb.net/p/4pgIvJ66.html [04:48] mwhudson: but if you go enjoy your road trip instead I'll understand :) [04:55] mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/230902 [04:55] Launchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed] [05:28] spiv: ping; remind me - subclasses of classes with slots; need the total list of attributes? [05:28] lifeless: IIRC, they just need the list of attributes added by the subclass. [05:29] Hmm, apparently my memory is faulty. [05:31] spiv: :P [05:32] Ah, no, just my quick 10-second attempt to verify it in the python interpreter was wrong :) [05:32] My memory turns out to be fine :) [05:35] (And the docs in fact say the meaning of defining the same slot twice, i.e. in a class and in a subclass, is "undefined") [05:43] * mwhudson off [05:52] spiv: interesting; see, I want to delete a slot the base class has :P [05:56] lifeless: ah, well... tough :P [05:58] :-> [06:05] when did I last mention hating doctest? [06:07] abentley: are you up? [06:07] Yeah [06:08] serializers are puzzling me [06:08] I'm hacking on a demand-loading inventory [06:08] serializer foo currently assumes you *can* serialize an inventory to a single string [06:08] e.g. bzrlib/tests/per_repository/test_repository.py [06:08] line 671, [06:08] test_add_revision_inventory_sha1 [06:09] which checks that the serializer is used and its sha output recorded [06:10] I *think* I need to make the interface tests not be defined in terms of the serializer object, but I was wondering if you had any thoughts? [06:10] lifeless: by demand-loading, what do you mean? Segmented so that only some items are loaded at a time? [06:10] abentley: yes [06:10] abentley: fragemented into lots of little pieces [06:11] So I would say the serializer abstraction doesn't make sense for these. [06:11] I figure I can have a serializer object that represents the particular style of splitting [06:11] and we still have revisions as single objects [06:12] Okay, our *current* serializer abstraction doesn't make sense. [06:12] :> [06:12] thanks, I think I have what I need [06:12] I've posted about this work btw, and its pushed [06:13] the most recent stuff isn't passing tests yet and I'm closing the gap there hoping to push more to play with tonight [06:13] You'll probably want moral equivalents of most of the single-string serializer tests. [06:13] And I'd imagine the existing tests should be used for existing serializers. [06:14] lifeless: Yeah, I sort of read it. [06:14] lifeless: i don't have a strong opinion that you should do a cache in a CHKInventory now [06:14] it is not very clear from your mail why you'd want to [06:16] I'm not really clear on what CHK stands for, so I can't comment intelligently. [06:16] abentley: its an abbreviation for content hash key; e.g. "md5:1234123421342" or "sha1:1234135143514645acdef" [06:18] (this predates git's terminology and is more general, I think its a more useful way to talk about using hashes as keys) [06:18] lifeless: So CHK is a superset of content-addressible filesystem. [06:19] poolie: there may be code that does lots of repeated lookups of the same fileid [06:19] poolie: a cache would ameliorate those codepaths (remove repeated-parsing overhead) [06:19] right [06:20] i thought that's what you meant [06:20] abentley: roughly yeah; not really a file system as packs are transactional etc etc [06:20] lifeless: I mean the CHK terminology, not your work specifically. [06:21] abentley: the yes, though I think perhaps 'intersecting with' rather than 'superset', but perhaps I'm being overly pedantic [06:22] abentley, i agree, i think HashKeyedInventory or something would be clearer [06:22] or even just HashedInventory [06:22] SmokingInventory [06:22] mm [06:23] at least it's not scatalogical [06:23] Yeah, HashedInventory is more evocative. [06:24] its building on CHKMap not on hashing itself; its quite generic code; uhm, I'm sure thenaming can be improved, but perhaps its making the layers clearer that is needed [06:25] This is also a split inventory concept. Is it splitting on directories or a radix tree? [06:25] abentley: either [06:25] abentley: I intend to put together CHKMap subclasses to let use experiment with both both those concepts and the other variations [06:26] abentley: (which are the parameters I mentioned in my mail from tuesday) [06:26] s/use/us/ [06:28] presumably both of them should be renamed if we think 'CHK' is cryptic [06:29] lifeless: I didn't see that mentioned in the email. [06:29] poolie: presumably; one more note on naming though - it should be quite specific; 'Hashed' is IMO hopelessly generic, I mean, current Inventory objects are Hashed internally. (self._byid). [06:30] I didn't find "CHK" too cryptic, but perhaps I'm just odd :) [06:31] abentley: this list: [06:31] The undecided aspects, which experimentation/modeling is needed on: [06:31] ... [06:31] includes the item for how we break up nodes in the tree [06:34] lifeless: It doesn't actually say that, though. I had to re-read it 3 times to guess that "should we canonicalise nodes by size rules, or (only applies to a name map that doesn't hash keys) by directory membership" was addressingthat. [06:35] abentley: sorry :) [06:35] abentley: I'm quite deeply embedded in this now, after some months of lead up; I'll try to be more clear in future [06:36] abentley: though there is a tradeoff in repeating content from the design work (which is in doc/developers/inventory.txt in bzr.dev) [06:42] lifeless: Yes, there is a balance to be struck. [06:44] abentley: I just an image of a set of scales being hit repeatedly [06:44] abentley: :) === cody-somerville_ is now known as cody-somerville [06:53] poolie: uploaded [06:56] thanks! [06:57] markh, could you send me a brief roadmap of what you'd like to do next on tortoise? [06:57] sure [07:03] hi all [07:17] spiv: any reason you didn't re-vote on 'regression on OSX in TestReadMergeableFromUrl.test_smart_server_connection_reset' ? [07:25] spiv: ping [07:25] spiv: I have a wtf moment in check [07:25] spiv: in repository.py, line 3259 for me is: [07:26] knit_parents = parent_map[key] [07:26] this is in a try:except RevisionNotPresent: guard [07:26] but parent_map is a plain dict ? [07:26] * spiv opens it up [07:27] lifeless: sure looks like a wtf [07:27] spiv: clearly, I'm doing heart surgery here, so I'm seeking option numero duo [07:27] spiv: ok, so its broken code, and the question is 'why do normal repos not hit it' [07:27] spiv: thanks [07:27] lifeless: I assume there's a gap in the test coverage :( [07:28] spiv: possibly not [07:28] lifeless: hmm, actually [07:28] spiv: possibly its a redundant check that cannot trigger unless something else is broken [07:28] (as in some other code is broken) [07:28] lifeless: yeah, that's what I'm suspecting [07:28] lifeless: anyway, no need for us both to do the same digging at the same time :) [07:29] spiv: I'm not digging at that :) [07:29] spiv: with consensus on the wtf, I'm ignoring it [07:29] Ah. Well, I still intend not to get side-tracked then :P [07:29] spiv: good choice :) [07:30] vila: oh, I didn't re-read the new patch carefully, I thought it was just updating == to is. I see now it also moved it to the right layer. [07:30] lifeless: did you call? [07:30] poolie: no [07:31] vila: it'd be nice to have a test that reliably fails (on all platforms) without this fix. [07:33] vila: I *think* that's probably feasible using the _DisconnectingTCPServer in test_bundle (i.e. the same way that is triggering test failures for you atm) [07:33] spiv: I'll look into that, do you also want it to apply to all SmartMedium classes ? [07:34] well, may be not all, the pipe one may not be relevant [07:34] vila: e.g., start a _DisconnectingTCPServer, create a SmartTCPClientMedium pointing at it, and then try client_medium.read_bytes(1) [07:35] Well, it'd be good to have equivalent tests for all SmartMedium classes, but it can't be the exact same test. [07:35] Pipes don't talk to sockets and get socket.errors, after all :) [07:36] bzr is *sweet* [07:36] sure, and socket.error may not be relevant either for http [07:36] Right. [07:37] I certainly wouldn't object to doing that :) [07:38] spiv: Ok, I read that as BB:resubmit then :) Thanks [07:38] But I wouldn't hold up landing the fix to this medium while working on unique tests for all medium implementations. [07:38] So, bb:tweak :) [07:38] I can actually remember how to use some of the commands, unlike cvs [07:38] jdrake: that's because we don't use "update" to do three different operations ;) [07:39] haha [07:39] I might actually be able to use bzr to do more than just code with school coming up. [07:40] vila: bb:tweak formally given [07:42] spiv: ok, thanks [07:43] abentley: if you're around, do you remember the precise in-memory difference between a rich-root inv and a non-rich-root ? [07:43] abentley: actually, nvm, asking that question clued me in to the answer [07:43] hi lifeless [07:44] lifeless: jelmer hinted you might know a workaround for phantom references messing up "diff" [07:44] (bug#275861) [07:45] oh "ghost revisions" it's called [07:46] robsta: hi; uhm, I don't think I do [07:46] robsta: did he hint with any more detail ? [07:46] jelmer: ^ EWHYME? [07:46] lifeless: no; is this specific to svn server-side? [07:47] robsta: yes, bzr-svn exercises the ghost capabilities most strongly of anything bar 'baz-import' which I think has actually been deleted from bzrtools now [07:48] robsta: last I heard jelmer was working on changing a bunch of stuff to fit what bzr's core looks for more; I don't know if he has [07:49] robsta: BTW, orthogonal thing, you might like to try the 'development2' format in bzr.dev; it uses the btree stuff I was doing back @ guadec; the new compressor isn't finalised yet, but the index stuff helps quite a bit [07:49] lifeless: define "quite a bit" [07:50] lifeless: i tried going back to bzr-playground.gnome.org, but when i merge my svn into the bzr branch there's an error about rich-root [07:50] robsta: depending on specific workload, up to 10 times faster, or more. [07:50] robsta: pastebin the rich root error please [07:51] speed is not the problem, the problem is that diff bails on me [07:51] robsta: right, did I mention orthogonal? [07:54] lifeless: http://pastebin.com/m36aec880 [07:55] * robsta prefers to stay one-dimensional [07:55] that would be the whiskey dimension? [07:55] run bzr info -v locally please [07:55] specifically on gtk-css-engine-bzr [07:56] http://pastebin.com/m6f95d2bf [07:57] no idea *how* you got that setup; but its not a bzr-svn compatible local repository [07:57] back it up, then bzr upgrade --rich-root-pack [07:57] then try again [07:58] lifeless: yay [07:58] lifeless: so does this still have ghost references, or can i push --overwrite this to the upstream svn? [07:59] robsta: give it a shot; I disclaim all knowledge of code internals [07:59] svn is atomic yeah? whats the worst could happen :P [08:00] vila, yeah, let's talk here [08:00] Discussing with John, it appears that log.py miss an API with revids (that's the main blocking part for missing) [08:01] either that or some variation where you give the list of revisions you want to show [08:01] roughly speaking, log is designed around revnos with shortcuts to avoid O(history) when only mainline revisions are needed [08:01] vila: ^ oh yeah, re ghosts, bzr-svn, major user. [08:01] lifeless: thanks, sorry, I still need to send that mail :-/ [08:01] lifeless: but it's not forgotten ! [08:03] lifeless: "No new revisions to push." can i force this somehow? [08:04] lifeless: for some reason svn is like 30 revs ahead [08:04] I (well jam too :) think log.py should evolve in a direction where we can calculate revnos on-demand [08:04] vila, i think that idea of jam's that we should show why some revisions are included is interestning [08:04] > the true solution is to be able to get revnos without being O(history) [08:05] right, that would be highly useful [08:05] sure, the two are related, but getting revnos without being O(history) is the root [08:05] so as i understand there are two threads towards that - either caching them, or looking for algorithms that let us skip larger parts of the graph [08:06] another one being changing the revno definition, but for compatibility I don't want to *start* with that [08:06] an intermediate solution is also to use gdfo [08:07] gdfo == Greatest Distance From Origin [08:07] which could also help spiv case in Batch get_parent_map HPSS calls made from InterRepo._walk_to_common_revisions [08:08] I know that but I'm not able to explain it clearly just yet :-/ [08:08] roughly, we indirectly batches requests when bisecting today, using gdfo can help batching requests in a more controlled way [08:09] robsta: svn has new content? [08:09] robsta: or just a higher 'revno' ? [08:09] lifeless: just revno, just pulled everything into the bzr tree [08:10] robsta: revno is per-branch, so it sounds like no-problem to me, or am I missing something? [08:10] vila, so as far as scheduling it, i'd be looking at: is it likely you'll make progress on it, does it matter to guilhem and other users, and should we be concentrating on something else instead [08:10] i would say the startup overhead for log does matter to people [08:11] robsta: I have to go now; sorry [08:11] robsta: uhm, I'd hope jelmer is up soon [08:11] I'm surely making progress on it but I need some more time to show results [08:11] bye poolie [08:11] and vila etc [08:11] lifeless: will use it, should work, thanks! [08:11] the scale being days [08:11] night lifeless [08:11] lifeless: cu [08:11] the scale being days, several days, but not more than two weeks I'd say [08:11] Well, on the downside, getting log running IS awfully slow sometimes... [08:12] But on the sorta-upside, any time I feel like log is too slow, I can just run log -v to jolt myself. [08:12] another aspect, thanks fullermd, is to make log really streamed [08:13] We're storing the revno of HEAD in the branch. I can't help but feel we're not USING it, though... [08:13] another option being to *not* show revnos for people who want really fast log :) [08:13] * spiv goes to the shops [08:13] fullermd: we use it ! [08:13] all shortcuts are based on that [08:13] vila, or we could default to log --line, and make sure that it does not compute non-mainline revisions [08:13] i think that may be the easiest in some ways? [08:13] poolie: I think we do already [08:14] do you know what's the main thing in the profile of --line? [08:15] hm [08:15] That's even sadder, then. [08:15] well, perhaps that's beside the point [08:15] fullermd: what is? [08:16] log --forward --short -r-10.. of bzr.dev (with bzr dev), with all the caches heated up and all, takes like 3 seconds. [08:16] I concentrate on higher level stuff so far but plan to measure progress on how things go [08:16] I assumed at least some of that was eaten up walking back to origin to figure out the revnos. [08:16] hm, it's about 800ms for me... [08:17] 2.608u 0.223s 0:02.84 99.2% [08:17] fullermd: come on, --forward is just asking for slowness :) [08:17] at least for now [08:18] Doesn't make any distinguishable difference :p [08:18] hm [08:18] roughly, actually, log is based on the idea that we built the history we need (the long part) then we issue the formatted text we want for each revision [08:18] Now, granted, my system isn't the speediest on the planet. But still, it's fast enough that Firefox is almost usable a good half of the time. [08:18] anyhow [08:19] What I'd want to do is make it more streamed: walk the needed graph, filter revisions, display formatted text [09:09] jelmer: are you around? [09:21] hi luks [09:22] hi [09:41] ok, now I'm really confused [09:41] I thought `bzr dpush` from bzr-svn was supposed to rebase my branch [09:42] but it kept my bzr revision untouched, so I deleted the bzr-svn cache, tried to branch again and I still get the original revision [10:00] hm, so long since I modified a chatscript [10:00] oops [10:07] hi bazaarians [10:15] luks, somewhat [10:15] luks, it will rebase your *local* branch [10:15] if necessary [10:16] jelmer: yeah, the thing is that it did not [10:16] jelmer: at least from what I can see [10:16] jelmer: and I don't understand where is the info (revid, etc.) stored, because it's not in SVN [10:16] luks, it will also not rebase if it didn't have to push anything [10:17] jelmer: it pushed one revision, I'll try to branch on a completely clean machine [10:17] jelmer: robsta has some issues [10:20] lifeless: should i attach the repo tarball to the bug (1.7M bz2) = [10:20] robsta: sure [10:21] jelmer: I am not here right now, but all I had robsta do was upgrade to rich root (they weren't, for some ??? reason - don't know how anything had worked before then) [10:21] jelmer: but now it has a missing text error, I'm suspecting some bzr-svn interaction bug; perhaps you can chat in detail with robsta to figure out exactly what's happened [10:23] #277043, fyi [10:26] Hi guys. I do have a small project versioned with bzr (personal version control in the guide), myproj/subprojA. so in subprojA there is a .bzr repo with the full history. However, I am now adding other sub-projects: myproj/subprojB, myproj/subprojC and I would like to have a new bzr repo with everything in myproj. So I cd myproj; bzr init. How can I pull all the versioning history of subprojA into it ? with merge? in myproj if I do bzr merge subproj [10:27] lifeless, robsta: I don't have time to look into it at the moment, but have a look when I do. Thanks for filing a bug. [10:30] n/p [10:54] is there a revisionspec for branch parent? [11:03] I want to checkout django-1.0 with bzr [11:03] bzr get http://code.djangoproject.com/svn/django/trunk django-bzr [11:03] works [11:03] while [11:04] bzr get http://code.djangoproject.com/svn/django/tags/releases/1.0 django [11:04] doesn't [11:04] the 2 path works with the svn command [11:22] jml: :parent ? [11:22] lifeless: nope. maybe my bzr is too old. [11:23] oh thats a location alias [11:23] meh [12:14] if I convert my branch to rich-root-pack format, how likely will I make other people suffer? (the main person I collaborate with has that format and that makes it hard for me to currently accept his bundles) === bac_afk is now known as bac === kiko_ is now known as kiko [15:43] hi there! [15:43] I'm trying to use bzr-svn [15:43] I installed it using "sudo easy_install bzr-svn" [15:43] but it doesn't seem to be working :( [15:46] http://dpaste.com/81931/ [15:58] g0nzal0: what is the name of the directory were easy_install "installed"? [15:59] /usr/lib/python2.5/site-packages/bzr_svn-0.4.13-py2.5-linux-i686.egg [15:59] ohh eggs [16:00] g0nzal0: I'm not sure that bzr plugins work as eggs at all [16:00] I see, I'll try something else, thanks for the info :) [16:00] g0nzal0: try installing it using plain old setup.py and avoid egg [16:00] yes, I'm onto it [16:01] g0nzal0: np === alperkanat is now known as alperkanat|away [16:05] Verterok: :( [16:05] http://dpaste.com/81935/ === alperkanat|away is now known as alperkanat [16:12] let's see [16:12] g0nzal0: run it with -Derror [16:13] g0nzal0: i.e: bzr -Derror plugins [16:18] Verterok: I had bzr installed with easy_install too [16:19] Verterok: took that away [16:19] Verterok: and reinstalled it from ppa [16:19] Verterok: (I use Ubuntu) [16:19] $ bzr -Derror plugins [16:19] gtk 0.94.0 [16:19] Graphical support for Bazaar using GTK. [16:19] launchpad [16:19] Launchpad.net integration plugin for Bazaar. [16:19] svn 0.4.13 [16:19] Support for Subversion branches [16:19] :-D [16:19] g0nzal0: goooood, ppa is goood :) [16:20] didn't know about it, it rocks! :) === alperkanat is now known as alperkanat|away [16:23] la la la, Russian roulette, pqm blocked [16:23] I'm branching django-survey with bzr-branch!!! === BasicPRO is now known as BasicOSX [16:27] vila: *why* does it always happen from *your* submissions? [16:28] I'm really quite surprised [16:28] I wonder if it is merging from lp: that is causing problems [16:28] I had one submission passing without problem from lp earlier [16:29] maybe it doesn't like "osx" in names [16:29] what surprised me the most is that the submissions are successful while someone is *killing* a process (knowing what process may help though) [16:30] vila: I just pinged mthaddon, and he said he got it going again [16:30] thanks to him and you, again... [16:31] Most probably, bugs are a big family and some vendetta is going on each time I fix a nasty one :) === alperkanat|away is now known as alperkanat === alperkanat is now known as alperkanat|away === alperkanat|away is now known as alperkanat === kiko is now known as kiko-fud [18:05] <_MMA_> Command to upload *all* unknown files in a existing branch? [18:05] <_MMA_> bzr add ? [18:06] yeap [18:06] well [18:06] depends on your definition of *all* [18:06] add won't add ignored files [18:06] <_MMA_> Anything shown as "unknown". [18:07]