| somerville32 | Hey. I've made Bzr quotes! :] | 00:01 |
|---|---|---|
| === BasicMac is now known as BasicOSX | ||
| lifeless | night all | 03:21 |
| Peng | Good night. | 03:22 |
| beuno | lifeless, you wouldn't happen to be around, would you? I'm working with Verterok on some changes to bzrlib we would like included before 1.0, and I can't commit to the bzr's branches anymore. Is there a chance I can get activated again? | 04:25 |
| jelmer | beuno: which bzr branch would you like to commit to ? | 04:39 |
| jelmer | bzr.dev isn't accessible directly - please send merge requests to the list | 04:40 |
| beuno | jelmer, no, we want to uplaod a branch to the group so both of us can commit | 04:40 |
| beuno | and it really doesn't make sense to create a new group just for this purpose | 04:41 |
| beuno | so we want to upload it to the bzr group, and work on it there | 04:41 |
| jelmer | ah, ok | 04:41 |
| beuno | (seemed to me like the logical workflow) | 04:42 |
| Kamping_Kaiser | would i be able to install bzr on a sparc running debian Etch? | 07:04 |
| Peng | If Python runs on it, bzr should have no problem. | 07:07 |
| Kamping_Kaiser | thanks | 07:08 |
| Peng | Bazaar has some C components for performance, but even if they didn't compile for some reason, it doesn't need them (it'll just be slower). | 07:08 |
| Kamping_Kaiser | bzr intalled from backports fine. thanks. | 07:11 |
| Peaker | If I decide to reject/destroy a branch in a shared repo, I'll get ghost revisions left, right? Is there a way to clean up such ghosts? | 11:27 |
| LarstiQ | Peaker: ghost revisions are the opposite, they are referred to by a branch but don't actually exist in the repository. | 11:29 |
| Peaker | LarstiQ: oh, how can that happen? | 11:29 |
| LarstiQ | Peaker: after removing a branch you have revisions in your repo that are not referenced instead, and yes you can remove those (although 'bzr gc' still isn't written) | 11:29 |
| gsuveg | re | 11:29 |
| LarstiQ | Peaker: one very good source for that is branches converted from arch, where it was almost trivial to get to that state. | 11:30 |
| gsuveg | bzr-gtk is broken? | 11:30 |
| LarstiQ | gsuveg: nafaik | 11:30 |
| gsuveg | gutsy and from bzr site | 11:30 |
| Peaker | LarstiQ: How can I remove them? | 11:30 |
| LarstiQ | Peaker: the remove-revisions plugin | 11:30 |
| Peaker | LarstiQ: ah, thanks | 11:31 |
| LarstiQ | Peaker: but be careful, that can also create ghosts | 11:31 |
| Peaker | LarstiQ: if it can't see all the branches? | 11:31 |
| Peaker | LarstiQ: or, how would it cause that? | 11:31 |
| LarstiQ | Peaker: if you tell it to remove revisions that are still used | 11:31 |
| Peaker | LarstiQ: Oh, I was hoping its more like "gc" :) | 11:31 |
| LarstiQ | Peaker: the step of figuring out which ones to use is not automated afaik | 11:31 |
| gsuveg | bzr-gtk: Depends: bzr (< 0.91~) but 0.92~rc1-1bazaar1 is to be installed | 11:31 |
| LarstiQ | Peaker: right :) | 11:32 |
| gsuveg | LarstiQ, sry. me sound like its a bit broken | 11:32 |
| gsuveg | apt sources deb http://bazaar-vcs.org/releases/debs/gutsy ./ | 11:32 |
| LarstiQ | gsuveg: you're talking about specific situations wrt a distribution, your original statement was way broader | 11:33 |
| LarstiQ | gsuveg: so that probably means newer bzr-gtk debs have to be uploaded | 11:33 |
| LarstiQ | but bzr-gtk itself works just fine | 11:33 |
| dato | gsuveg: we're waiting that bzr-gtk 0.92 gets releseased, otherwise it can't be packged :) | 11:33 |
| LarstiQ | jelmer: ^^ | 11:33 |
| LarstiQ | dato: oh well, that might also block a bit ;) | 11:33 |
| gsuveg | dato, ah. | 11:33 |
| gsuveg | but .91 would work with .92 not? | 11:36 |
| Peaker | why is ubuntu bleeding-edge not up-to-date with newest released bzr's? | 11:39 |
| gsuveg | dato, and on repo bzr-gtk is only the 0.90 | 12:02 |
| gsuveg | you can edit the dependecy not ? | 12:02 |
| dato | gsuveg: well, it's better not to | 12:06 |
| jelmer | LarstiQ, Szilveszter does the releases these days | 12:16 |
| gsuveg | i've back to 0.90 what in gutsy is | 12:16 |
| LarstiQ | jelmer: k | 12:18 |
| lifeless | moin | 13:57 |
| ryanakca | Since codebrowse appears to be down, how could I get a file from revision 4 if that file is no longer versioned? I've tried bzr revert -r4 file ... but it complains about not being versioned... | 13:58 |
| dato | ryanakca: try bzr cat -r 4 path/to/file >file.v4 | 14:00 |
| ryanakca | dato: thanks :) | 14:02 |
| lifeless | ryanakca: bzr revert -r4 file should indeed have worked; | 14:12 |
| lifeless | desperately seeking reviewers | 15:08 |
| vila | lifeless: hi :) You have two patches pending revisions, I already expressed my concerns about transport.list_dir, I didn't dig enough reconcile nor packs so far to comment on the second (stage 1 of pack reconcile) | 15:27 |
| vila | AIUI you plan to rework the first to avoid list_dir, if that's the case, I'd be happy to give you a +1 if that makes it happen quicker :) | 15:28 |
| vila | ghaa, s/revisions/reviews/ | 15:29 |
| lifeless | vila: well, you know I disagree on the list_dir usage | 15:52 |
| lifeless | there is no technical reason I know of yet to avoid list_dir for writable transports | 15:52 |
| vila | lifeless: ha, thanks for the precision, I was wrong then :) | 15:53 |
| lifeless | I plan in a future packs format to see if we can remove list_dir | 15:54 |
| lifeless | but for the current format there is no alternative | 15:54 |
| lifeless | that isn't worse. | 15:54 |
| vila | hmmm, so putting the webdav plugin on the back burner still depends on that then | 15:55 |
| vila | I'll to monitor that point more closely | 15:55 |
| lifeless | still, I'm seeking a reviewer for the stage1 reconcile packs patch | 16:44 |
| lifeless | jelmer: ping | 16:55 |
| jelmer | lifeless, pong | 17:02 |
| lifeless | jelmer: I've looked at the setup.py patch; and it seems less clean to me than th autotools it's replacing | 17:19 |
| lifeless | jelmer: I wanted to chat interactivvely about this, because I may be missing something | 17:19 |
| jelmer | lifeless: at the moment, the python package doesn't get installed at all | 17:31 |
| jelmer | so you're forced to run out of the source tarball | 17:32 |
| lifeless | right, so I want to fix that | 17:32 |
| lifeless | and I ocmcmented in the bug that I had no objection per se t o moving everything to setup.py if it was a net win; but thats clearly more than just fixing the bug | 17:32 |
| jelmer | Also, the dependency on automake just to install a few files is a bit heavy | 17:33 |
| jelmer | make check doesn't work currently (for me at least) | 17:33 |
| lifeless | what goes wrong ? | 17:34 |
| jelmer | let me check | 17:35 |
| jelmer | lifeless: never mind, looks like config-manager got deinstalled for some reason | 17:40 |
| * jelmer wonders if it'd be a better idea to start from scratch | 17:41 | |
| lifeless | jelmer: with pqm ? | 17:42 |
| jelmer | not with pqm specifically, but the sort of thing I'm looking for myself | 17:43 |
| lifeless | a little more detail might help me here :) | 17:45 |
| jelmer | I don't need support for baz, config-manager or creating repositories and things like the current testsuite in shell, automake make it hard to add the features I am looking for (bundle support, python gpgv, loading bzr plugins, better status page) | 17:45 |
| ubotu | New bug: #160012 in bzr "http urllib hides programming errors related exceptions" [Low,In progress] https://launchpad.net/bugs/160012 | 17:45 |
| jelmer | perhaps git support | 17:46 |
| lifeless | jelmer: so, pqm is getting cleaned up slowly; | 17:46 |
| lifeless | pqm does load bzr plugins - the plan is to drop all other VCS upport; support git etc via bzrlib plugins | 17:47 |
| === phanatic_ is now known as phanatic | ||
| jelmer | pqm doesn't load bzr plugins at the right time yet, that's what my other patch fixed | 17:48 |
| lifeless | bug #? I'll commit it now | 17:48 |
| jelmer | I don't think there's a bug #.. was a merge request I sent to you on may 23 | 17:52 |
| jelmer | should I resend it? | 17:54 |
| lifeless | I've found it I think. one sec, playing with it. | 17:54 |
| jelmer | lifeless: We could still ditch autoconf and automake, use a simple Makefile for building the docbook stuff and setup.py for the python-specific things? | 17:56 |
| lifeless | PEP8 issues but otherwise fine I think | 18:06 |
| lifeless | (VWS after class is needed) | 18:06 |
| lifeless | also ou create a heavweight checkout not a lightweight one | 18:07 |
| jelmer | lifeless, what about using Makefile for docbook for bug 117197 ? | 18:10 |
| ubotu | Launchpad bug 117197 in pqm "Doesn't install required Python package" [High,Fix committed] https://launchpad.net/bugs/117197 | 18:10 |
| jelmer | lifeless: still alive? | 18:17 |
| mc_ | how can i tell bzr which editor to use? | 18:19 |
| dato | mc_: there are several ways, all explained in the tutorial. basically some environment variables (EDITOR, BZR_EDITOR) | 18:20 |
| dato | mc_: and the "editor" option in ~/.bazaar/bazaar.conf | 18:21 |
| mc_ | ty | 18:23 |
| === mc_ is now known as mc__ | ||
| === BasicMac is now known as BasicOSX | ||
| schierbeck | jelmer: pingz0r! | 19:06 |
| jelmer | schierbeck, pong! | 19:11 |
| schierbeck | what do you think about using commit messages to identify revisions to the user? | 19:15 |
| schierbeck | when they have to choose from a revision's parent | 19:15 |
| lifeless | that might be nice | 19:17 |
| schierbeck | i've sent a branch url to the ml | 19:17 |
| schierbeck | have a look and tell me what you think :) | 19:18 |
| schierbeck | currently only the toolbar buttons use it | 19:18 |
| jelmer | lifeless: see my comments from about an hour ago | 19:18 |
| schierbeck | ? | 19:20 |
| schierbeck | i only just sent it in | 19:20 |
| schierbeck | damn you're fast! | 19:20 |
| dato | heh | 19:20 |
| jelmer | schierbeck, that was about some pqm stuff | 19:20 |
| schierbeck | oh | 19:20 |
| schierbeck | :) | 19:20 |
| lifeless | jelmer: Sorry, eating etc | 19:21 |
| lifeless | I've merged your patch, it's off to people now | 19:21 |
| === me_too is now known as turbo0O | ||
| === turbo0O is now known as me_too | ||
| jelmer | lifeless: any thoughts wrt using make+setup.py rather than automake? | 19:21 |
| jelmer | lifeless, thanks for merging it | 19:22 |
| lifeless | done, revno 172 | 19:22 |
| lifeless | network here sucks worse than well most things | 19:24 |
| lifeless | I don't entirely get the objection to automake; automake isnot huge, it's well understood | 19:28 |
| jelmer | It's not really aimed at installing python packages | 19:32 |
| jelmer | you'd have to add some magic to find the right directory to install it in, the right python executable to use, etc | 19:33 |
| jelmer | also, automake sucks in general imo | 19:36 |
| schierbeck | jelmer: don't you think we call the navigation buttons in the viz something other than "back" and "forward" | 19:46 |
| schierbeck | it doesn't fit with the visual representation of the history | 19:47 |
| schierbeck | i'd rather have "up" and "down" | 19:47 |
| jelmer | yeah, up and down sounds fine to me | 19:47 |
| dato | but history is *time* independently of how you repreesnt it | 19:47 |
| jelmer | I'm not so sure about using commit message to identify revisions | 19:47 |
| dato | and time goes forwards and backwards, not up and down | 19:47 |
| dato | IMHO :) | 19:47 |
| jelmer | there are a lot of people that don't use clear enough commit messages | 19:48 |
| schierbeck | jelmer: i still think it's MUCH better than, say, revision id | 19:50 |
| schierbeck | and i think it's good enough for now | 19:50 |
| schierbeck | until we find something better | 19:50 |
| schierbeck | dato: but normal people don't think that way | 19:51 |
| schierbeck | they say "i want to go down on this list" | 19:51 |
| dato | well. you won't convince me but, alas, I'm not the bzr-gtk maintainer. :) | 19:51 |
| schierbeck | user interfaces aren't about what's right, they're about what's right for the users | 19:51 |
| schierbeck | :) | 19:52 |
| jelmer | schierbeck: I'd rather not experiment like this in the branch that's used for releases | 19:53 |
| phanatic | schierbeck: i'm about to release 0.92 and jelmer and i were talking about broken lines (ui option to disable it would be nice to have) | 19:54 |
| jelmer | schierbeck: I think revno's would be a better temporary solution | 19:55 |
| schierbeck | jelmer: compromise -- revno's *and* messages | 19:57 |
| schierbeck | phanatic: i'm working on options ui right now | 19:57 |
| schierbeck | jelmer: you have to agree, revids are completely useless for this purpose | 19:58 |
| jelmer | yeah, revids aren't useful for this sort of stuff, indeed | 19:59 |
| jelmer | schierbeck, I think a combination is a good compromise | 19:59 |
| schierbeck | okay | 20:02 |
| schierbeck | i'm currently looking at including the branch nick as well | 20:02 |
| schierbeck | it works pretty good | 20:02 |
| Peaker | is there a way to retroactively delete large files to save space in the repo? | 20:15 |
| jelmer | you can remove revisions from history using the remove-revisions plugin | 20:16 |
| jelmer | but it's very very slow (rewrites the whole repository) | 20:16 |
| Peaker | so if I remove revisions that added large files, the continuations of those will be rebuilt without those large files? | 20:18 |
| Peaker | or will the continuations/children just be broken? | 20:18 |
| jelmer | In theory, yes | 20:20 |
| jelmer | Haven't ever done that yet | 20:20 |
| Peaker | yes broken or yes deleted? :) | 20:21 |
| jelmer | the continuations will be ok | 20:22 |
| Peaker | ah cool, I hope he didnt add more stuff with the big files | 20:24 |
| schierbeck | phanatic and jelmer: how should i turn off brokenlines? | 20:27 |
| schierbeck | if you could add a gproperty to viz.treeview.TreeView it would be pretty easy | 20:28 |
| phanatic | schierbeck: we were pondering about a button on the toolbar which would toggle broken lines (and also remember its state) | 20:29 |
| schierbeck | phanatic: i'd rather have it in the menu bar | 20:30 |
| schierbeck | people probably won't toggle it every few minutes | 20:30 |
| jelmer | schierbeck: that means the menu bar would have to be merged before 0.92 | 20:31 |
| Peaker | do you think it would be a good idea to create a plugin that removes a file retroactively by recreating the entire history in the repo excluding the addition and any changes to that file? | 20:31 |
| phanatic | agreed. but merging the menubar branch just before release wouldn't be a good qa prectice :) | 20:31 |
| phanatic | practice | 20:31 |
| jelmer | schierbeck: which should really be released asap before bazaar 0.92 is released | 20:31 |
| schierbeck | jelmer: okay, we can move it to the menubar after the release | 20:32 |
| schierbeck | what persistence backend should we use? | 20:33 |
| schierbeck | the conf files? | 20:33 |
| jelmer | either the conf files or gconf, not sure what would make the most sense | 20:33 |
| jelmer | using the conf files is consistent with bazaar, using gconf is consistent with GNOME | 20:34 |
| phanatic | jelmer: gconf is not available on win32 | 20:34 |
| phanatic | afaik | 20:34 |
| jelmer | ok, so we would at least have to support the conf files | 20:34 |
| jelmer | guess we can always add gconf support later, if there's a good reason for it | 20:34 |
| schierbeck | do we have to reload the treeview when toggling? | 20:35 |
| schierbeck | or can it redraw dynamically | 20:36 |
| jelmer | reloading would be acceptable for now I think | 20:36 |
| schierbeck | okay | 20:37 |
| schierbeck | by the way, what do you think about the menubar approach? is it something i should pursue? | 20:38 |
| phanatic | schierbeck: from the olive point of view, a menubar on a child window looks quite interesting :) | 20:39 |
| schierbeck | phanatic: i know, but i hate olive | 20:39 |
| schierbeck | i never use it :) | 20:39 |
| phanatic | many people do, love it or hate it :P | 20:39 |
| schierbeck | i think it's important that we can set options directly from viz | 20:40 |
| schierbeck | such as show/hide columns | 20:40 |
| schierbeck | and a go menu really makes sense | 20:40 |
| schierbeck | i'm only asking because i'm making some other major improvements on that branch | 20:41 |
| jelmer | yeah, we have to keep olive in mind | 20:41 |
| phanatic | that sounds reasonable. i don't have any other complaints about the menubar on viz | 20:41 |
| jelmer | another option would be to add a LogWindow that is specific to olive and is somewhat simpler | 20:42 |
| phanatic | but maybe you could allow it to be disabled | 20:42 |
| jelmer | now that we have all the different components available as separate widgets, that should be quite easy | 20:42 |
| schierbeck | yup, that sounds good | 20:44 |
| schierbeck | i'll continue with my efforts then | 20:44 |
| schierbeck | i'd like to switch to using signals and properties only | 20:45 |
| schierbeck | the revision-/logview especially is bad | 20:45 |
| schierbeck | with a custom callback mechanism | 20:45 |
| schierbeck | when's the next release due? | 20:46 |
| jelmer | all synchronised with bazaars' releases | 20:46 |
| jelmer | s/bazaars'/bazaars main/ | 20:46 |
| Peaker | it could be nice to pop up kompare as the differ in the "bzr vis" dialog | 20:47 |
| phanatic | we agreed to do synchronised releases till bzr 1.0 | 20:48 |
| dato | and then? | 20:49 |
| phanatic | bzrlib should be api stable by then, so we can walk on our own path | 20:50 |
| phanatic | jelmer, schierbeck: i'll do a release tomorrow, if you don't mind... | 20:53 |
| schierbeck | it's fine | 20:53 |
| jelmer | sounds good to me, provided that the broken lines feature can be turned off somehow | 20:53 |
| schierbeck | is there a setting one can give to the cell renderer that disables the newish stuff? | 20:54 |
| schierbeck | i'm not too comfortable with the cairo stuff | 20:54 |
| jelmer | schierbeck: you can specify the behaviour of the broken lines code using a parameter to TreeView's constructor | 20:55 |
| schierbeck | okay | 20:55 |
| schierbeck | should it be None when turned off? | 20:57 |
| jelmer | yes | 20:57 |
| schierbeck | okay | 20:57 |
| schierbeck | and just hardcoded to 32 otherwise? | 20:57 |
| schierbeck | (short-term) | 20:57 |
| jelmer | I'm not sure what the best value for it would be, it would depend on the branch I think | 21:06 |
| jelmer | I just kept 32 as default since that's what gary used | 21:06 |
| schierbeck | okay | 21:10 |
| schierbeck | jelmer: what should the toggle button be labeled? | 21:10 |
| jelmer | "Compact View" or something? | 21:12 |
| schierbeck | okay | 21:15 |
| schierbeck | jelmer, phanatic: pushing to lp right now | 21:22 |
| schierbeck | i still need to implement persistence | 21:22 |
| phanatic | schierbeck: cool | 21:22 |
| schierbeck | phanatic: i'd like to have a meeting some time in the not-too-distant future | 21:24 |
| schierbeck | about coding guidelines | 21:24 |
| phanatic | :) | 21:24 |
| schierbeck | things like the naming of callbacks | 21:24 |
| schierbeck | there are like 3 different ways being used right now :) | 21:24 |
| phanatic | yeah, it would be useful | 21:25 |
| schierbeck | i'll send a message to the ml tomorrow | 21:25 |
| phanatic | right | 21:25 |
| schierbeck | http://bazaar.launchpad.net/~dasch/bzr-gtk/brokenlines | 21:26 |
| schierbeck | check it out | 21:26 |
| schierbeck | i'll go eat something :) | 21:26 |
| schierbeck | jelmer: do you know how to implement the persistence layer? | 21:55 |
| schierbeck | i haven't looked at the api | 21:55 |
| jelmer | phanatic was looking at that | 21:57 |
| schierbeck | okay | 21:58 |
| schierbeck | i'll just take a look myself, it seems that phanatic has left | 21:59 |
| schierbeck | well, that was pretty easy | 22:07 |
| jelmer | you may both be working on the same thing | 22:07 |
| schierbeck | well, i'm already done :) | 22:12 |
| schierbeck | i've pushed it to the branch | 22:12 |
| schierbeck | http://bazaar.launchpad.net/~dasch/bzr-gtk/brokenlines | 22:12 |
| lifeless | ola | 22:13 |
| Verterok | lifeless, hola | 22:24 |
| lifeless | jamesh: hi, how did pending reviews go on further changes ? | 22:32 |
| jamesh | not sure | 22:35 |
| lifeless | jelmer: we need a better name for olive | 22:36 |
| lifeless | jelmer: it's still showing as 'olive' rather than e.g. 'bzr GUI' or something | 22:36 |
| jelmer | lifeless: please discuss that with Szilveszter, I don't use/develop Olive | 22:36 |
| lifeless | ahha, ok | 22:37 |
| jelmer | personally, I would rather see the integration in nautilus improved than having a standalone app | 22:37 |
| jelmer | but I think Olive is nice to have too - it's certainly more mature than nautilus-bzr | 22:38 |
| schierbeck | jelmer: i agree completely | 22:39 |
| lifeless | I agree that iing the nautlius integration is important | 22:39 |
| lifeless | s/ii/fixi/ | 22:39 |
| schierbeck | we need more work on nautilus-bzr | 22:39 |
| schierbeck | i should eventually replace olive completely, if possible | 22:39 |
| schierbeck | *it | 22:39 |
| jelmer | not sure about that - olive also works on Windows and XFCE | 22:40 |
| schierbeck | we need better integration with the Windows file browser, too | 22:40 |
| jelmer | so there is certainly a place for it, until we get thunar and windows shell integration done | 22:40 |
| lifeless | we have a bzr tortoise for inwdows now | 22:40 |
| jelmer | lifeless: tortoise isn't anywhere near olive wrt functionality though | 22:40 |
| lifeless | till; native UI++ | 22:41 |
| schierbeck | +1 | 22:41 |
| * jamesh wonders why all Windows VCS plugins are called tortoise | 22:41 | |
| jelmer | yeah, I agree | 22:41 |
| schierbeck | btw, i got a tango guy working on some icons for us | 22:41 |
| jelmer | jamesh: they're all slow | 22:41 |
| lifeless | ouch | 22:42 |
| jelmer | schierbeck: ah, nice :-) | 22:42 |
| schierbeck | thought so :) | 22:42 |
| fullermd | I wish one of them were easier to get going, though. Every time I look at the installation instructions, it makes ME twitch, and I'm the *nix guy. The idea of trying to point some of the graphicist Windows people I'd want to use it at that installation isn't confidence-inspiring. | 22:42 |
| jelmer | we need more people developing on Windows | 22:42 |
| fullermd | Or less people running Windows ;) | 22:43 |
| jamesh | by that I take it you mean other people? | 22:43 |
| schierbeck | i'm with fullermd... | 22:43 |
| schierbeck | hehe | 22:43 |
| fullermd | I mean, there can't be more than a billion or so of them, right? All it takes is a little rounding error to turn 1 into 0... | 22:43 |
| schierbeck | how are we doing on OS X | 22:43 |
| jelmer | jamesh: Afraid so, yep | 22:44 |
| schierbeck | jelmer: should we review and merge the brokenlines-option branch tonight? | 22:45 |
| jelmer | schierbeck: as long as it happens before 0.92 :-) Not sure what Szilveszters plans wrt the relaese date are | 22:47 |
| schierbeck | i think he wants a release tomorrow | 22:48 |
| lifeless | later all, meeting time | 22:54 |
| schierbeck | bb | 22:54 |
| schierbeck | well, i'm off as well | 22:55 |
| schierbeck | see y'all! | 22:55 |
| ubotu | New bug: #159997 in bzr "`bzr push` fails with error 530 (login incorrect)" [Undecided,New] https://launchpad.net/bugs/159997 | 23:00 |
| ubotu | New bug: #160081 in bzr "KnitCorrupt: incorrect number of lines" [Undecided,New] https://launchpad.net/bugs/160081 | 23:00 |
| siretart | jelmer: is bzr-svn supposed to support push over svn+ssh:// urls? | 23:08 |
| jelmer | siretart: yes. | 23:09 |
| siretart | jelmer: http://paste.debian.net/41505 | 23:09 |
| siretart | not sure what's going wrong here | 23:09 |
| siretart | svn ls svn+ssh://svn.debian.org/svn/pkg-wpa/wpasupplicant/trunk works at least | 23:10 |
| jelmer | siretart: please file a bug | 23:10 |
| siretart | ok. what information do you need? | 23:10 |
| siretart | (apart from the traceback) | 23:10 |
| jelmer | the backtrace should be sufficient | 23:10 |
| siretart | ok | 23:10 |
| siretart | thanks! | 23:10 |
| siretart | filed as bug #160085 | 23:13 |
| ubotu | Launchpad bug 160085 in bzr-svn "push over bzr+ssh:// crashes" [Undecided,New] https://launchpad.net/bugs/160085 | 23:13 |
| jelmer | thanks | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!