jelmer | hey poolie | 00:07 |
---|---|---|
jelmer | hi maxb | 00:07 |
maxb | hello | 00:07 |
poolie | hi jelmer, maxb | 00:11 |
poolie | thanks for the reviews jelmer | 00:49 |
lifeless | jelmer: if you're still aroud | 00:52 |
lifeless | jelmer: can we talk about geoffs patch ? | 00:52 |
jelmer | lifeless: sure | 00:54 |
lifeless | so, he put that patch together based on a description of what I wanted in loggerhead | 00:55 |
lifeless | I'm worried that its being parleyed into a bigger, different change. | 00:55 |
lifeless | I don't think loggerhead should need to know about doing iter_tree_entries etc for the export. | 00:55 |
jelmer | lifeless: I'd prefer to change this to be more flexible for other callers as well if we're going to change it, and both options seem to be roughly equally trivial | 00:56 |
lifeless | jelmer: the implementation you suggested doesn't meet loggerheads needs | 00:57 |
jelmer | lifeless: what's the context? | 00:57 |
lifeless | jelmer: we need a generator | 00:57 |
lifeless | to let us return control to the wsgi framework | 00:58 |
jelmer | lifeless: but you're not actually going to stream the data, just send it all in a bulk at the end? | 00:59 |
lifeless | we are streaming | 00:59 |
jelmer | lifeless: the generator still takes a tarball argument, and adds the data there as well | 00:59 |
lifeless | I would like it if geoffs patch were evaluated directly on its impact on bzrlib: is it sufficiently tested, will it decrease performance, or make things be structured badly. | 00:59 |
lifeless | jelmer: that doesn't matter. | 01:00 |
lifeless | jelmer: loggerheads tarball object is mapped to a file object that accumulates the bytes in a buffer; when each yield occurs the accumulated bytes are handed off to the wsgi stack | 01:00 |
spiv | Good morning. | 01:05 |
mgz | special mailing list post of the day: <http://lists.ironpython.com/pipermail/users-ironpython.com/2011-June/014868.html> | 01:07 |
jelmer | lifeless: that seems more complicated than just iterating over the items and files and writing out item.tobuf() + file.read() | 01:10 |
lifeless | jelmer: that would a) not work with zip files, b) not stream. | 01:10 |
jelmer | lifeless: this function doesn't work with zip files anyway | 01:11 |
lifeless | but the structure will | 01:11 |
jelmer | lifeless: both ways stream per file | 01:11 |
lifeless | shrug | 01:11 |
lifeless | I don't really want to overdesign this | 01:11 |
lifeless | I don't want geoff blocked on something that makes it harder for him or loggerhead | 01:11 |
lifeless | and he is right now | 01:11 |
lifeless | if the design is poor, we should ask him to fix it | 01:12 |
jelmer | anyway, I haven't voted on this, and I don't feel strongly about it. I was just saying it seemed simpler to factor out the body of the loop, rather than creating a generator which makes things more complex imho | 01:12 |
lifeless | but you seem to want to solve different problems | 01:12 |
lifeless | jelmer: it requires a generator | 01:12 |
lifeless | _requires_ | 01:12 |
jelmer | that generator can be in loggerhead | 01:13 |
jelmer | and just be a three line loop | 01:13 |
lifeless | jelmer: Well, that won't work for .zip files (which folk will want), because they don't have the same output model | 01:14 |
lifeless | I don't think it makes sense to make the loggerhead code simpler for tarballs at the cost of needing two codepaths in loggerhead for zip/tarballs | 01:14 |
jelmer | IIRC zipfiles in Python don't stream anyway | 01:15 |
lifeless | zipf.writestr(zinfo, content) | 01:16 |
lifeless | is the per-file stuff | 01:16 |
lifeless | so, it needs a similar tweak to permit this in loggerhead for zip files | 01:16 |
lifeless | I think writing to the file is simple and clear | 01:16 |
lifeless | we can have the same contract for both generators, both live in bzrlib.export.*, and one driver for adapting them to wsgi streaming | 01:17 |
lifeless | if we have /any/ tar specific code in loggerhead that won't work. | 01:17 |
lifeless | which is what I don't like about your proposal | 01:17 |
lifeless | mgz: win | 01:17 |
lifeless | mgz: I presume you know about the great regex mistake ? | 01:18 |
mgz | I thought you'd appreciate that lifeless :) | 01:20 |
jelmer | lifeless: I don't see how that helps; ZipFile's constructor requires a filename or seekable file object | 01:21 |
lifeless | jelmer: we manage to export to stdout | 01:22 |
* jelmer gets some sleep | 01:22 | |
lifeless | jelmer: which is nonrewindable | 01:22 |
jelmer | lifeless: charis:~/src/bzr/bzr.dev% bzr export --format=zip - | 01:22 |
jelmer | bzr: ERROR: [Errno 29] Illegal seek | 01:22 |
lifeless | ah! ok, so bugs to fix there. | 01:23 |
lifeless | still, i think making the contract be tied to tar would be a mistake | 01:23 |
lifeless | sleep well | 01:23 |
mgz | the zipfile module is pretty useless unfortunately | 01:23 |
mgz | it's been multiply threatened with a rewrite that's never arrived | 01:23 |
lifeless | we have/had a fixed copy | 01:24 |
lifeless | bbiab, grocery shopping needs doing | 01:24 |
jelmer | I think one of the problems is that the zip file format requires the compressed/uncompressed sizes to be known up front | 01:25 |
jelmer | anyway, really gone now.. :) | 01:25 |
mgz | hm, really? I thought the header was minimal and everything that mattered was in the tail. | 01:26 |
mgz | hence the gif/zip hacks. | 01:27 |
jelmer | yeah, you're right | 01:27 |
jelmer | wikipedia confused me because it still calls them headers | 01:27 |
mgz | beheaded headers | 01:28 |
mgz | they're severed and placed in a basket at the end | 01:28 |
=== smoser` is now known as smoser | ||
=== tchan1 is now known as tchan | ||
gour | i'm converting all my old repos to bzr and while doing it i just wanted to put one old project under bzr (no conversion from some other DVCS), but bzr failed with: http://pastebin.com/Jtt4HtAP | 06:32 |
gour | i've found it as https://bugs.launchpad.net/bzr-diffstat/+bug/56680 | 06:52 |
ubot5 | Ubuntu bug 56680 in Bazaar Diffstat Plugin "uncaught exception: bzr: ERROR: exceptions.UnicodeDecodeError:" [High,Confirmed] | 06:52 |
gour | and it's more than 4yrs ago since it's reported...it would be cool to fix it before 2.4 | 06:53 |
gour | another one is https://bugs.launchpad.net/bzr-submit/+bug/67973 | 06:55 |
ubot5 | Ubuntu bug 67973 in Bazaar Submit By Mail Plugin "exceptions.UnicodeDecodeError" [Medium,Fix committed] | 06:55 |
gour | the most recent activity in regard to this problem seems to be https://bugs.launchpad.net/bzr-explorer/+bug/735349 | 07:02 |
ubot5 | Ubuntu bug 735349 in Bazaar Explorer "UnicodeError while converting BzrError to unicode" [High,Confirmed] | 07:02 |
AuroraBorealis | does anyone know if launchpad will be getting a wiki? | 07:32 |
AuroraBorealis | cause ive been contributing to a project on github and its a much nicer site :< | 07:32 |
gour | AuroraBorealis: there is discussiion about it atm | 07:34 |
AuroraBorealis | hmm | 07:35 |
gour | AuroraBorealis: check https://bugs.launchpad.net/launchpad/+bug/240067 | 07:35 |
ubot5 | Ubuntu bug 240067 in Launchpad itself "Launchpad projects need wikis" [Low,In progress] | 07:35 |
AuroraBorealis | i think its a bit more then low priority =/ | 07:37 |
spiv | AuroraBorealis: note that that the 'launchpad' project only really uses Critical, High, and Low. https://dev.launchpad.net/BugTriage#Importance | 07:38 |
gour | this is certainly one of the features i really miss in LP, but i prefer bzr much more than git | 07:38 |
gour | ..which i simply cannot stand | 07:39 |
gour | i even use bzr-git for fetching github projects | 07:39 |
thumper | AuroraBorealis: low means it isn't being worked on by lp devs | 07:39 |
AuroraBorealis | i see | 07:40 |
thumper | AuroraBorealis: I'd like to see LP get a wiki... | 07:40 |
thumper | but I keep spending time writing other stuff | 07:40 |
thumper | perhaps I'll instigate my own 20% time | 07:40 |
AuroraBorealis | cause my projects on launchpad just seem confusing compared to github | 07:40 |
spiv | I'm not sure adding a large complex feature to Launchpad will automatically reduce that confusion :) | 07:41 |
spiv | I agree a wiki for projects would be nice. | 07:42 |
AuroraBorealis | i feel the entire website needs to be revamped hehe | 07:43 |
AuroraBorealis | but a wiki just seems like another tab | 07:43 |
AuroraBorealis | also i'm confused on the little history graph things launchpad branches have | 07:48 |
AuroraBorealis | https://launchpad.net/inkscape for example, does it go up then right? | 07:48 |
spiv | AuroraBorealis: does the larger view at https://launchpad.net/inkscape/+series make it clearer? | 07:50 |
AuroraBorealis | so it seems like 'trunk' is the vertical line | 07:51 |
AuroraBorealis | and they keep branching off | 07:51 |
spiv | Or for comparison, https://launchpad.net/bzr/+series | 07:51 |
AuroraBorealis | but am i right that it seems the main trunk branch is on the left? | 07:52 |
spiv | The bzr example is a bit more interesting perhaps because you can see the dates of releases from different series overlapping. | 07:52 |
spiv | It's not a graph of branches or revision history. | 07:52 |
AuroraBorealis | so its just a graph of versions? | 07:53 |
AuroraBorealis | or 'series' | 07:53 |
spiv | It's a visualisation of release series and their milestones. | 07:53 |
AuroraBorealis | ah. k | 07:53 |
AuroraBorealis | so i take it launchpad doesn't have a graph of revisions | 07:53 |
spiv | Someone really ought to integrate one into loggerhead. You can browse the revision history by following the “Browse the code” link on e.g. https://launchpad.net/inkscape | 07:55 |
spiv | It doesn't yet do the sorts of pretty graphs you get with bzr GUIs like 'bzr qlog', but I'm sure someone will do one for it eventually. | 07:56 |
AuroraBorealis | which take like 5 clicks to get to | 07:56 |
spiv | Which do? | 07:56 |
AuroraBorealis | to get to the link to 'view all revisions' hehe | 07:56 |
AuroraBorealis | and yeah i was just using github to contribute to some project and i liked their revision graph | 07:56 |
spiv | I count 2 clicks. | 07:56 |
spiv | From https://launchpad.net/inkscape click “Browse the code”, from there click “view branch changes” | 07:57 |
AuroraBorealis | ah that. i clicked code at the top | 07:57 |
spiv | Yes, it's a nice graph. Fortunately you can get the same thing in a local GUI via 'bzr qlog' (qbzr plugin) or 'bzr viz' (bzr-gtk plugin). | 07:58 |
AuroraBorealis | yeah i use bzr explorer which i think has qlog in there | 07:58 |
AuroraBorealis | https://github.com/sr/git-wiki/network is sweet :> | 07:58 |
spiv | Which isn't quite as convenient as having it in a web page, but it's good enough for me at least. | 07:58 |
AuroraBorealis | yeah | 08:01 |
AuroraBorealis | geez branching the bzr source is taking forever xD | 08:07 |
spiv | Have you done "bzr lp-login"? | 08:12 |
AuroraBorealis | i have not | 08:12 |
AuroraBorealis | is that why its taking forever? | 08:12 |
thumper | AuroraBorealis: yes | 08:14 |
thumper | AuroraBorealis: it'll be going over http | 08:14 |
thumper | AuroraBorealis: instead of the bzr+ssh protocol | 08:14 |
AuroraBorealis | doh | 08:14 |
AuroraBorealis | well i'll do that after it finishes | 08:14 |
AuroraBorealis | does it not need my password? | 08:16 |
thumper | AuroraBorealis: it needs an ssh key on LP | 08:16 |
AuroraBorealis | yeah i have that | 08:16 |
thumper | then you're good | 08:16 |
AuroraBorealis | but i just typed launchpad-login <username> and it didnt output anything | 08:16 |
=== AuroraBorealis is now known as aurora|game | ||
aurora|game | it seems to be working. thanks =) | 08:19 |
gour | aurora|game: have you tried github's bug tracker? | 08:22 |
* gour grins :-) | 08:22 | |
AuroraBorealis_ | sorry gour , no i have not, is it crappy? | 08:47 |
gour | AuroraBorealis_: i'd say, yes | 08:49 |
gour | it cannot compare with LP's features | 08:49 |
AuroraBorealis_ | haha | 08:50 |
AuroraBorealis_ | cool. | 08:50 |
AuroraBorealis_ | im just experimenting with a lot of stuff. I like bzr cuase i can host my private code (stuff for school) on my own server and stuff | 08:51 |
gour | AuroraBorealis_: i used darcs for many years, tried hg, touched git, played with monotone and recently used fossil, but now i'm moving to bzr which is simply the most intuitive & complete dvcs ("..for human being.") | 09:00 |
AuroraBorealis_ | hehe | 09:04 |
AuroraBorealis_ | yeah, i like it | 09:04 |
AuroraBorealis_ | plus its python, git seems to be very linux centric. | 09:05 |
gour | darcs was(is) great tool, but it does not have LP or any similar, even less featured, public hosting solution | 09:05 |
AuroraBorealis_ | never heard of darcs | 09:05 |
gour | git looks to me as a big hack, without real design behind it...monotone is nicely designed, but it's niche | 09:06 |
AuroraBorealis_ | i installed git | 09:06 |
AuroraBorealis_ | and it installed a shitty ssh.exe to my path which screwed up bazaar | 09:06 |
gour | AuroraBorealis_: http://darcs.net/ it has patch theory and it's quite different and very intuitive | 09:06 |
gour | bzr is 'sweet spot' | 09:06 |
AuroraBorealis_ | yeah =) | 09:07 |
=== AuroraBorealis_ is now known as AuroraBorealis | ||
jelmer | gour: still there? | 09:45 |
jelmer | gour: those two bugs you mentioned are unrelated to the issue you're seeing | 09:45 |
gour | jelmer: yeah, i'm here | 09:46 |
gour | hmm | 09:47 |
gour | last one is relevant? | 09:47 |
jelmer | gour: they're indeed UnicodeDecodeError tracebacks too, but raised from a different location | 09:47 |
jelmer | gour: the bzr-explorer one? | 09:47 |
gour | yes | 09:48 |
gour | so, it looks all are from different locations, but same symptoms | 09:50 |
* gour was pointed at the right one - https://bugs.launchpad.net/bzr-explorer/+bug/735349 | 09:54 | |
ubot5 | Ubuntu bug 735349 in Bazaar Explorer "UnicodeError while converting BzrError to unicode" [High,Confirmed] | 09:54 |
gour | ahh...wrong one | 09:55 |
gour | this one is correct: https://bugs.launchpad.net/bzr/+bug/715547 | 09:55 |
ubot5 | Ubuntu bug 715547 in Bazaar ""bzr add" crashed ERROR: exceptions.UnicodeDecodeError" [Medium,Confirmed] | 09:55 |
=== zyga-afk is now known as zyga | ||
spiv | maxb: around? | 10:31 |
jelmer | 'morning spiv | 10:31 |
spiv | Good evening jelmer :) | 10:34 |
gour | seeing that SF has support for web pages and wiki, i wonder what do you think about LP vs SF for hosting projects under bzr? | 10:53 |
spiv | Depends on what your project needs. You can always use both of course! | 10:54 |
spiv | I find the SF bug tracker to be much, much worse than LP's. | 10:54 |
gour | problem is that LP does not have neither space for web page nor wiki | 10:56 |
fullermd | Not only that, it doesn't even provide CVS. | 10:56 |
spiv | Sure. | 10:57 |
gour | i do not worry for lack of CVS :-) | 10:58 |
spiv | It is an issue for many projects. Some are small enough that a link in the project description to the contents of the README file in bzr is plenty, and some are large enough that they have their own website anyway. But there's a big set of stuff in between those that want that sort of feature, and LP doesn't yet cater well to that. | 10:58 |
gour | but LP is the only one from {github,bitbucket, google,sf,lp} missing wikis | 10:58 |
spiv | Sure. We know. | 10:59 |
spiv | Pretty much everyone thinks LP should have them too, including the LP dev team I think :) | 11:00 |
gour | and the 'bug' is quite old already | 11:00 |
spiv | Right. The paid LP devs are already pretty busy with other work: <https://dev.launchpad.net/RoadMap> | 11:01 |
spiv | But if someone were to help write the necessary bits I'm sure it'd be welcomed! | 11:01 |
gour | lack of wiki is turning many people to 'competition' which is sad | 11:02 |
spiv | It would be nice to have, but getting free or cheap webhosting elsewhere for those bits isn't too hard, so I understand why it isn't an urgent priority for the LP team. | 11:02 |
spiv | Is it? | 11:03 |
gour | i believe it is...having code on one site, tracker on another, wiki on the 3rd...not pretty | 11:04 |
gour | considering that other hostings have all-in-one | 11:04 |
gour | {github,bitbucket, google,sf} probably support wiki with a good reason ;) | 11:04 |
lifeless | wiki != webhosting fwiw | 11:08 |
gour | lifeless: i'd be satisfied with just having wiki on LP | 11:08 |
lifeless | well, its getting specced at the moment | 11:09 |
lifeless | its still ill defined what that actually means | 11:09 |
gour | even just to render sphinx-generated pages | 11:09 |
gour | lifeless: why don't you inspect what's offered at {github,bitbucket, google,sf} instead of reinventing the wheel | 11:10 |
lifeless | gour: uhm, we have and are? | 11:10 |
spiv | gour: what makes you think that's not happening? | 11:10 |
lifeless | gour: they all have quite different offerings | 11:10 |
lifeless | gour: and none of those commercial, proprietary services have been kind enough to share their user and market needs analysis with us. | 11:11 |
gour | the point is the many people/projects would like to have wiki, that's why {github,bitbucket, google,sf} have it...it's only question to adjust to the LP | 11:12 |
gour | here i'd say that "even blind uncle" applies | 11:12 |
spiv | gour: if it's that easy, then please go ahead and do it! | 11:12 |
spiv | gour: it's open source, and patches are certainly welcome. | 11:12 |
gour | it's not that the rest of LP is perfect in the 1.0 release | 11:13 |
gour | spiv: i do not have neither required skills nor time to work on it...wikkid is a project launched for that purpose, afaik | 11:13 |
spiv | gour: Ok. Apparently no-one else has had the skills and time yet either, though. | 11:14 |
* gour is thankful to have free LP, but lack of wiki might move me to SF | 11:14 | |
spiv | Which, as one of those people who also lacks the time, I completely understand! | 11:15 |
gour | spiv: pls. don't think i am criticizing LP...just want to improve it...because, let's face it - less LP customers also means less bzr ones | 11:15 |
lifeless | gour: we want it, but we want it done well. Getting a free wiki with links to it from LP is -dead- easy - heck we even model links to the wiki in LP today. | 11:15 |
fullermd | I note that when I put a project on SF, I don't think it had any wiki support. And I think it's had 3 different wiki generations since then. | 11:16 |
gour | i strongly believe github is not popular just because of git | 11:16 |
spiv | gour: I agree, github does many things quite well | 11:17 |
gour | fullermd: how are you satisfied with SF & bzr? | 11:17 |
fullermd | Well, I've never yet used bzr on SF. My project there is in CVS :p | 11:17 |
lifeless | we're not short on desire, we're short on elbow grease; doing a system that will run 20K wikis with no page renders over 5 seconds and 99% under 1 second, no single points of failure and embeddable in the same domain [so entirely xss free] is -nontrivial- | 11:18 |
maxb | spiv: Now I am | 11:18 |
fullermd | Their docs on bzr aren't seemingly maintained at all. Last I looked, they still said they support bzr 1.10, when it was easy to tell they were running 2.1 or 2.2. | 11:18 |
spiv | maxb: oh hey, I was just having a temporary thinko with the kde-l10n-* command | 11:18 |
spiv | maxb: it's requeued now, although I see kde-l10n-th has developed a new and interesting failure | 11:19 |
spiv | Perhaps an empty bzrdir on LP or something as a remnant of the previous failures? | 11:19 |
* maxb looks at kde-l10n-th and thinks "WTF!?" | 11:20 | |
gour | according to wikipedia, github was launched in feb 2008, and wiki 'bug' at LP is from june same year | 11:21 |
spiv | maxb: previous line in log is about opening the working tree for kde-l10n-th/karmic-backports | 11:21 |
lifeless | gour: yes, the desire has been around a while | 11:22 |
spiv | gour: I'm really not sure what your point is? LP does many things github doesn't, like PPAs | 11:22 |
spiv | gour: because while they may have overlapping goals, they also have differing ones too, and accordingly differing priorities. | 11:23 |
gour | spiv: aren't PPAs rlevant only for Ubuntu? | 11:23 |
spiv | gour: they're pretty relevant to where the LP dev spend their time as well :) | 11:23 |
gour | spiv: maybe only to change priority from Low :-) | 11:23 |
spiv | gour: see https://dev.launchpad.net/BugTriage#Importance | 11:24 |
lifeless | gour: low is accurate: we're not going to try and make this happen using paid developers in the next 6 months. And as priorities change, we don't try and assess priorities more than 6 months out. | 11:25 |
gour | spiv: Low - We mark as Low any bug that we recognise as legitimate but that we have no plans to fix. | 11:25 |
spiv | gour: right — and the paid LP team doesn't plan more than 6 months in advance. | 11:25 |
spiv | (Not in this sense, at least) | 11:26 |
lifeless | hmm, I think thats confusing | 11:26 |
lifeless | so I will edit | 11:26 |
gour | and it's already 3years...the whole point, and here i can stop from my side, is that lack of wiki at LP causes harm to the LP & bzr since people/projects needing one go to {bb,github.sf, google}... | 11:27 |
* gour is researching about SF now... | 11:28 | |
spiv | gour: sure, but so do all the other bugs and missing features of LP | 11:28 |
spiv | gour: and so far it's been the opinion that those are even more important to address using the finite resources available | 11:28 |
spiv | Your opinion is obviously different, but stating it here isn't going to change matters. | 11:29 |
gour | one of the first hits - http://amanica.blogspot.com/2011/05/bazaar-on-sourceforgenet.html | 11:29 |
gour | spiv: i'm aware of it and won't discuss it any longer | 11:30 |
spiv | You could try to advocate for it on the launchpad-dev list perhaps. If you present evidence that it really is a huge factor in driving potential users away that would be useful I think. | 11:30 |
spiv | maxb: those kde-l10n-* are failing due to branches on LP that are just empty directories, not even a .bzr dir. I guess we try deleting them from LP and requeuing. | 11:42 |
EM03 | why bzr over git? | 11:42 |
EM03 | git is faster? I mean whats a killer feature? | 11:43 |
spiv | Many people find it nicer to use. | 11:43 |
EM03 | an example? | 11:43 |
Riddell | poolie: I still can't access jubany, what's the rt URL to complain on? | 11:49 |
gour | EM03: git help log vs. bzr help log ;) | 11:49 |
EM03 | hehehe | 11:49 |
EM03 | i know git very well and its quick just curious why one would choose bzr | 11:50 |
gour | "it's for human being" | 11:50 |
EM03 | can i have an example were thats true? | 11:50 |
EM03 | (not saying it isn't) | 11:50 |
gour | i'm spoild by darcs ui, and bzr is quite pleasant to use...with git one has to think too much about the tool | 11:51 |
gour | git's ui, model... | 11:51 |
gour | EM03: have you tried monotone? | 11:51 |
gour | e.g. i tried to become power user of orgmode, but it required too much time...otoh, taskwarrior was so intuitive...same with git vs. bzr | 11:53 |
gour | EM03: otoh, if you like git, be free to continue with it ;) | 11:53 |
maxb | spiv: Right - if only all the failures were that easy :-) | 11:53 |
EM03 | gour: not that I'm in love with it just want to see se bzr is better :P | 11:54 |
gour | EM03: just try to use it for some time and don't think that some extra ms are worth the effort to think how to avoid shooting one's own feet ;) | 11:56 |
EM03 | oh gour , you make it sound so easy | 11:56 |
gour | EM03: on which platform you are? | 11:56 |
gour | EM03: http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html | 11:57 |
gour | and http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/tutorial.html | 11:58 |
* gour was playing with bzr when changing the format was the rule :_) | 11:58 | |
spiv | maxb: still failing; but updated | 11:58 |
spiv | s/but/bug/ | 11:58 |
maxb | "There is already a branch merge proposal registered for branch lp:~ubuntu-branches/ubuntu/hardy/kde-l10n-th/hardy-201106020937 to land on lp:ubuntu/hardy/kde-l10n-th that is still active." | 11:59 |
jelmer | gour: we still seem to have that image, while in fact the last change of the default format was quite some time ago (2 years?) | 12:00 |
gour | jelmer: yeah, labelling is hard..just ask lightttpd guy about memory leaks | 12:02 |
gour | *guys | 12:02 |
fullermd | Funnily enough, every time I use monotone, I get another round of "sorry, I can't do anything until you 'mtn db migrate' to update the database structure". | 12:03 |
gour | i'm also tired about git's tspeed-talk as it's the only relevant feature of dvcs | 12:03 |
maxb | tspeed-talk? | 12:03 |
gour | speed-talk | 12:03 |
gour | fullermd: heh, foosil borrowed some stuff from mtn | 12:04 |
gour | *fossil | 12:04 |
maxb | Well, in fairness to git, there are some applications where I'd rather use bzr, but am compelled to use git for the performance | 12:04 |
* gour cannot type properly... :-/ | 12:04 | |
lifeless | maxb: you know jam will fix those :) | 12:04 |
* gour does not work on kernel-sized projects ==> no need for git | 12:04 | |
* maxb is keeping the revprops tree of a Subversion repository with >1 million revisions in Git | 12:05 | |
maxb | bzr doesn't really like a tree with >1 million files and 1.9GB in size | 12:05 |
lifeless | maxb: hmmm, it should handle it | 12:06 |
lifeless | maxb: the dirstate would be sizable | 12:06 |
maxb | It probably can handle it, but not quickly enough to be palatable for a human user | 12:06 |
maxb | Even git is far from instantaneous on a tree that size | 12:07 |
lifeless | sure | 12:07 |
lifeless | file a bug ? | 12:07 |
lifeless | gnight all | 12:07 |
maxb | A bug on "Performance on big trees does not compare favourably to Git" feels a bit like bug | 12:09 |
maxb | A bug on "Performance on big trees does not compare favourably to Git" feels a bit like bug 1 | 12:09 |
ubot5 | Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 | 12:09 |
maxb | jelmer: You seem to have push --overwritten me in pkg-bazaar/bzr/2.4 :-/ | 12:12 |
lifeless | maxb: 'bzr takes 60 seconds to st a 1M file tree with hot cache' | 12:12 |
lifeless | maxb: you don't need to say git in there at all | 12:12 |
maxb | fair enough | 12:12 |
jelmer | maxb: Yeah, sorry about that - I'd already done the merge locally too, with some additional changes and there weren't any other changes than the merge | 12:19 |
jelmer | I tried merging your branch, but I got conflicts on the generated files so I opted to --overwrite instead | 12:20 |
maxb | Unfortunately those revisions are already merged into the beta-ppa branches | 12:33 |
maxb | I guess I'll sort out a merge | 12:34 |
jelmer | maxb: sorry, I hadn't realized it was there as well | 12:38 |
=== mrevell is now known as mrevell-lunch | ||
=== mrevell-lunch is now known as mrevell | ||
deni | hi guys | 15:47 |
deni | can anyone tell me how to start the freaking olive gui? i installed bzr-gtk which should be the package for olive | 15:47 |
maxb | Not any more. Olive has been split from bzr-gtk and is now a wholly separate project | 15:53 |
deni | maxb: can i find it debain repos? | 15:54 |
maxb | I am uncertain whether it has been packaged | 15:56 |
maxb | I'd search on the BTS, but bugs.debian.org seems to be down right now | 15:56 |
jelmer | I'm pretty sure it's not packaged | 15:56 |
maxb | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598703 | 15:57 |
ubot5 | Debian bug 598703 in wnpp "RFP: olive-gtk -- Graphical frontend for Bazaar" [Wishlist,Open] | 15:57 |
deni | on the main page it says i can install it via leeny-backports | 15:57 |
deni | i tried to install bzr via squeeze backport and i don't think it installed any gui frontends | 15:58 |
jelmer | deni: it should install a olive-gtk executable in /usr/bin | 15:59 |
deni | jelmer: nope | 16:00 |
deni | also it can't find it in the repos | 16:00 |
jelmer | deni: it's there, see http://packages.debian.org/lenny/all/bzr-gtk/filelist | 16:01 |
deni | i hva the bzr-gtk package | 16:02 |
deni | ]don't know how to start that though | 16:02 |
deni | autocomplete says there is no olive or bzr-gtk app | 16:02 |
jelmer | deni: it's not in squeeze, you need the lenny package | 16:03 |
deni | jelmer: still not luck | 16:06 |
deni | meh | 16:06 |
deni | will try tomorrow | 16:06 |
deni | thank for your help | 16:06 |
jelmer | deni: see that page, it's definitely there in the lenny package | 16:06 |
deni | jelmer: ok, tnx | 16:07 |
jelmer | deni: that said, I'm not sure if it will work with newer versions of bzr, for example | 16:08 |
jelmer | you might have more luck just pulling down the source from lp:olive | 16:08 |
Riddell | jam: able to take another (hopefully final) look at https://code.launchpad.net/~jr/bzr/598572-zlib-error/+merge/62966 and https://code.launchpad.net/~jr/bzr/707274-commit-message-hook/+merge/62334 ? | 16:11 |
jelmer | hi Riddell | 16:34 |
jelmer | Riddell: It's ascension day here in .nl, IIRC John is away for the next couple of days | 16:34 |
Riddell | ah, religion leaving us without a patch pilot | 16:35 |
ovnicraft | hello i am testing a bzr oodifff plugin i get this error: http://pastie.org/2009130 | 16:40 |
ovnicraft | i cant fixed so i see is based in bzr api | 16:40 |
ovnicraft | any hits to fixed ? | 16:40 |
ovnicraft | fix it ? | 16:40 |
ovnicraft | its in your doc http://doc.bazaar.canonical.com/plugins/en/oodiff.html | 16:43 |
jelmer | Riddell: reviewed the zlib error MP | 16:45 |
jelmer | ovnicraft: hi | 16:45 |
ovnicraft | jelmer, hi | 16:45 |
ovnicraft | i see in that plugin is trying to use get_default_plugin_path() | 16:46 |
ovnicraft | jelmer, can you help me ? | 16:47 |
Riddell | jelmer_: what does it mean if you approve it in your review but the status is still Needs review? | 16:59 |
maxb | Usually means the reviewer forgot that LP's review model has that distinction :-) | 17:06 |
jelmer_ | Riddell: what Max says, it means I'm stupid :) | 17:10 |
Riddell | groovy, I'll self approve | 17:10 |
=== jelmer_ is now known as jelmer | ||
ovnicraft | hello i have this error with my oodiff plugin http://pastie.org/2009303 | 17:16 |
ovnicraft | bzr needs any explicit configuration with ASCII ? | 17:17 |
jelmer | ovnicraft: that looks like a bug in the plugin | 17:17 |
jelmer | ovnicraft: please file a bug against the bzr-oodiff project | 17:17 |
jelmer | hmm, it doesn't appear to have been touched since 2009 :-/ | 17:18 |
ovnicraft | jelmer, yes | 17:18 |
jelmer | Riddell: ooh, that builddeb hook is neat | 17:18 |
ovnicraft | and i want to support it | 17:18 |
ovnicraft | jelmer, method implemented is working now | 17:19 |
ovnicraft | jelmer, you can see the method http://paste.pocoo.org/show/399537/ | 17:20 |
jelmer | ovnicraft: I think you need to pass in plain strings to the diff function | 17:21 |
jelmer | the XML document probably contains unicode strings, which you'd have to encode (to utf-8, perhaps?) | 17:22 |
ovnicraft | so i need encode to utf-8 my files ? | 17:22 |
jelmer | no, in bzr-oodiff before you call text_differ(), you need to encode the strings you pass to it | 17:23 |
jelmer | from_text = [l.encode("utf-8") for l in from_text] | 17:25 |
ovnicraft | so with utf-8 files encoded is working ok | 17:26 |
jelmer | cool :) | 17:26 |
ovnicraft | now will apply your changes and see waht happen | 17:27 |
ovnicraft | what* | 17:27 |
=== deryck is now known as deryck[lunch] | ||
dcoles | Hm. Here's a bit of a worrying one. Should bzr-svn ever eat a svn revision. | 19:16 |
dcoles | As in running svn log on trunk shows the revision yet bzr log doesn't. | 19:16 |
jelmer | dcoles: there's an open bug report about that - it's fixed in zbr-svn trunk | 19:17 |
jelmer | at least, if I think it's the issue I think you mean | 19:18 |
dcoles | Basically the svn revision appears invisible to bzr-svn (I can't -rsvn:# it) | 19:18 |
dcoles | It resulted in a rather interesting "Why did you revert my change. I didn't revert anything. You never made that change" *grin* | 19:19 |
dcoles | I'll try trunk. | 19:20 |
jelmer | dcoles: it's a race condition | 19:21 |
jelmer | dcoles: upgrading to trunk won't fix the earlier revision, but it will prevent the race in the future | 19:21 |
dcoles | Was that lp:515850 | 19:33 |
dcoles | Bug #515850 | 19:33 |
ubot5 | Launchpad bug 515850 in Bazaar Subversion Plugin "Revisions added while a commit is happening are ignored" [High,Fix committed] https://launchpad.net/bugs/515850 | 19:33 |
jelmer | yep | 19:33 |
=== gour1 is now known as gour | ||
=== deryck[lunch] is now known as deryck | ||
=== yofel_ is now known as yofel | ||
jjohansen | I have been trying to setup a git clone of a bzr tree and have run into a problem. Basically the tree has some tags with ~ in the name which git doesn't like | 21:06 |
jjohansen | is there any way to work around this? | 21:07 |
rattasak | Hi, I just started using bazaar and believe i am misunderstanding something about shared repositories. i have a project with code files in ~/projectA. i create a repo on a mapped network drive by using 'bzr init-repository --trees /drive/repo' and then create an branch for the project i want to track in the repo using 'bzr init /drive/repo/projectA' | 23:12 |
maxb | jelmer: https://code.launchpad.net/~dulwich/dulwich/unstable mirroring has stopped due to the failure of alioth. Could you update the URL to include a /bzr/ path segment and restart it? | 23:13 |
rattasak | i then do 'bzr checkout /drive/projectA projectA' | 23:13 |
rattasak | add and commit the files in that working directory using bzr add and bzr commit | 23:13 |
rattasak | but when i check the repo at /drive/repo, i don't see a working tree there | 23:13 |
maxb | Ok, so a couple of things | 23:14 |
maxb | First, why would you even want a working tree on a shared drive? | 23:14 |
maxb | Second, the act of sending revisions to a remote branch does not cause its working tree to be updated. | 23:14 |
rattasak | ah, reliability of the network drive is a slight issue atm so i would like to have a working copy there in case the history files get corrupted during the push (which is something i'll fix with the network drive soon and is not ideal) | 23:15 |
rattasak | ah | 23:15 |
rattasak | doing a commit locally on something that was checkouted does a puch to the corresponding remote branch right? | 23:16 |
rattasak | push* | 23:16 |
maxb | Yes | 23:16 |
rattasak | i see | 23:16 |
rattasak | is there a set of conditions or a command to explicitly update the remote working tree? | 23:18 |
maxb | "bzr update" | 23:19 |
maxb | https://launchpad.net/bzr-push-and-update may be of interest to you | 23:19 |
lifeless | (run on the remote machine) | 23:19 |
maxb | Although I'm not sure it will work with a checkout, from its description | 23:20 |
rattasak | aaah gotcha, bzr update within the repo's working tree then (e.g. /drive/repo/projectA)? | 23:20 |
maxb | Yes | 23:21 |
rattasak | aah great! just tried it out. | 23:22 |
rattasak | thanks for both of your guys help | 23:22 |
maxb | Although, as a backup methodology, I think you would be better off setting up an automatically updated copy of the *branch* elsewhere | 23:22 |
rattasak | ah i see | 23:22 |
rattasak | maybe do a sync instead of the local working directory? | 23:23 |
rattasak | sync with an external program i mean | 23:23 |
maxb | It is usually a lot better to use "bzr push" or "bzr pull" than an external program | 23:23 |
maxb | You cannot guarantee that an external program will do the right thing if the source is being written to | 23:24 |
rattasak | push to a standalone branch stored elsewhere? (if standalone branch means something not stored within a repo...i am migrating from hg so my terminology is a little mixed up) | 23:26 |
maxb | Yes (and yes, that's what a standalone branch is) | 23:28 |
rattasak | ah ok. thanks for your help clearing that up for me. | 23:29 |
poolie | hi all | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!