| elmo | lifeless: did you see my whining earlier about the bzrtools edgy+ packaging being broken? | 00:06 |
|---|---|---|
| elmo | dato: (and thanks for the suggestion of sid, I can fix it easily enough myself, I just want the bazaar-vcs.org repos to be installable :) | 00:07 |
| elmo | lifeless: and/or is launchpad bugs an appropriate place for that kind of problem? | 00:07 |
| === mw is now known as mw|out | ||
| === Winterstream is now known as WinterstreamAway | ||
| poolie | spiv, does this error about "remote server did not return a token" mean anything to you? | 01:16 |
| spiv | Sounds like a locking issue? Where did this occur? | 01:17 |
| poolie | new mail to the list | 01:18 |
| poolie | if it's not familiar off hand i'll check launchpad and file a bug | 01:18 |
| spiv | Not familiar off-hand, no. | 01:19 |
| spiv | I'd be interested in the -Dhpss log for that. | 01:20 |
| ubotu | New bug: #176020 in bzr ""remote server did not return a token" assertion error" [Undecided,New] https://launchpad.net/bugs/176020 | 01:26 |
| igc | poolie: re "Branch 6 options" in the User Guide, the intro text looks wrong | 02:28 |
| igc | I assume these options all apply to new formats and perhaps to dirstate as well, not just dirstate-tags | 02:29 |
| igc | how should I word that and can anyone suggest a better heading? I don't think "Banch 6" will mean much to most users | 02:30 |
| abentley | igc: the branch 6 options do not apply to dirstate. Branch 6 introduced tags. | 02:35 |
| igc | abentley: but doesn't dirstate support the 5 settings listed: | 02:37 |
| igc | append_revisions_only | 02:37 |
| igc | parent_location | 02:37 |
| igc | bound_location | 02:37 |
| igc | bound | 02:37 |
| abentley | No. | 02:37 |
| igc | push_location? | 02:37 |
| igc | wow | 02:37 |
| abentley | Those were not part of the config file for branch format 5. | 02:37 |
| abentley | They were in separate files. | 02:38 |
| igc | ah | 02:38 |
| abentley | And there was no strict equivalent for "bound" or "append_revisions_only". | 02:38 |
| igc | abentley: so should I just say "dirstate-tags or later" formats? | 02:39 |
| abentley | Sure. | 02:40 |
| igc | thanks | 02:40 |
| abentley | Actually, I guess push location was in use for format 5, but it was typically stored in locations.conf instead of branch.conf | 02:43 |
| * igc lunch | 03:55 | |
| lifeless | spiv: poolie_: that token bug - bet you its a knit local branch, pack remote branch, or some such. | 04:54 |
| spiv | lifeless: hmm, interesting thought. | 04:59 |
| lifeless | note - I haven't read the bt or anything | 05:04 |
| lifeless | just a guess | 05:04 |
| * spiv nods | 05:05 | |
| luislavena | hello guys, anyone awake? | 06:11 |
| Peng | I am, but I'm not very useful. | 06:20 |
| pattern | what's the proper way to go about deleting a branch from a repository? | 06:20 |
| lifeless | pattern: rm -rf the branch | 06:24 |
| pattern | nice | 06:25 |
| pattern | thanks, lifeless | 06:25 |
| Peng | pattern: The revisions unique to that branch won't be removed, but it shouldn't be wasting enough space to be worried about. | 06:27 |
| luislavena | Peng: me neither, just wanted to get some "best practices" recommendations of using bzr... being very annoyed by all the git mambo... | 06:27 |
| poolie_ | reading the user guide patch | 06:28 |
| Peng | luislavena: Git mambo? | 06:28 |
| luislavena | Peng: yeah, all the "fuzz" around the -powerful- git, but couldn't get the picture of the unique checkout/mirror and their use of branch/feature and switch... | 06:29 |
| luislavena | still don't get it, and reading the user guide have a question :P | 06:29 |
| Peng | I didn't understand any of the terms in that sentence, but I'm kind of overloaded right now. | 06:32 |
| luislavena | Peng: no problem, I'm kind of tired too... | 06:32 |
| Peng | I'm not tired, I'm overloaded. | 06:32 |
| Peng | Argh, I'm about to explode. | 06:33 |
| luislavena | what the hell, I'll re-read the user guide for nth time and try to compare some of the functionality... | 06:33 |
| luislavena | Peng: oh, sorry :| | 06:33 |
| fullermd | luislavena: If you have a question, just ask it :) | 06:34 |
| * fullermd wraps some duct tape around Peng for safety. | 06:35 | |
| luislavena | will be a best practice use a checkout to mirror a dev trunk? | 06:35 |
| luislavena | I mean, I don't plan to work directly on it, but create my branch of it (feature-NN) | 06:35 |
| * luislavena think bzr have so many options that is overwhelming | 06:36 | |
| fullermd | Yes, a checkout would work. So would a branch that you just never commit in; the major difference would be whether you "update" or "pull" to keep it caught up. | 06:36 |
| fullermd | (at least, the checkout _should_ work. There've been occasional hiccups in the past where checkout wanted to be able to write to the upstream for locking) | 06:36 |
| luislavena | fullermd: ok, then a branch on a treeless repo will do the trick. | 06:37 |
| * fullermd nods. | 06:38 | |
| Peng | FWIW, I don't use checkouts. I don't see the point, and since they aren't bzr's main functionality, I don't expect them to work as well. | 06:38 |
| Peng | (I do occasionally use a lightweight checkout to save downloading the history, though.) | 06:38 |
| luislavena | I see, thank you Peng | 06:39 |
| luislavena | I'll try to get used to the workflow, being a svn guy for quite long :P | 06:40 |
| fullermd | I use checkouts with some regularity, especially for work (as opposed to personal) projects. For all the uber-distributed disdain for it, the shared-branch workflow does very well if it fits what you're doing. | 06:40 |
| luislavena | fullermd: that's the problem, found something that 'fit' whatever I'm trying to do. | 06:40 |
| luislavena | couldn't get a clear picture of the workflow that will fit better with my development. | 06:40 |
| fullermd | Yeah, it can be tricky. Once you digest it, though, the choice is great, since there's so many different problems that need different solutions. | 06:41 |
| fullermd | And even the same problem at different times. bzr's been great for me at allowing that adaptability. | 06:41 |
| === poolie_ is now known as poolie | ||
| luislavena | Peng: thank you. | 06:42 |
| luislavena | fullermd: thank you too for your comments | 06:43 |
| fullermd | luislavena: Any time :) | 06:44 |
| luislavena | a last (for now) question: | 06:47 |
| luislavena | lets say I have one share repo and my "dev" branch on it, all locally. | 06:47 |
| luislavena | I can push it remotely, but I need it to be inside another shared repo? or can stand by itself? | 06:48 |
| spiv | luislavena: it can stand by itself. | 06:49 |
| spiv | luislavena: if you have a shared repo on the remote side, pushing a new branch to that repo will automatically use that shared repo, but if there isn't it'll just make a standalone branhc. | 06:49 |
| Peng | It's a good idea to use a shared repo, though. | 06:49 |
| fullermd | If you use 'push' to send it around, it will go into another repo, or by itself, whichever fits at the other end. | 06:49 |
| fullermd | You can't, e.g., just tar it up and move it around though, unless it's standalone (or you tar and move the whole repo) | 06:50 |
| luislavena | I didn't tried the remote stuff, being using bazaar quite some time (but not full due work) but didn't make pushing yet :-$ | 06:51 |
| spiv | luislavena: basically, push will work either way. Just like locally, bzr can copy less data if there's a shared repo that already has some of the revisions you're pushing, though. | 06:52 |
| luislavena | thank you guys again, I'll try to find what fits best my workflow (trunk, production and staging with local features that will be merged on these 'stages') | 06:53 |
| luislavena | spiv: if there is already data, push should only require to add the missing data, not remove and start all over, right? :| | 06:53 |
| spiv | luislavena: right. | 06:56 |
| Peng | luislavena: But if you aren't using a shared repo, it will send all of the data again. | 06:57 |
| spiv | Peng: well, if you push a new branch it will | 06:57 |
| spiv | Peng: If you're just pushing new revisions to a branch you've already pushed, it won't. | 06:57 |
| Peng | Oh, right. | 06:58 |
| === doko_ is now known as doko | ||
| luislavena | what if I "diverge" the branch and try to push it to the original branch location? | 07:06 |
| luislavena | nevermind, will try wtih some dummy data :D | 07:06 |
| encompass | hey guys, think I made a mistake... I canceled a push... and now I am getting this... | 07:36 |
| encompass | No handlers could be found for logger "bzr" | 07:36 |
| encompass | when ever I try to push. How can I fix this issue? | 07:36 |
| encompass | just found the work around... it is a bug in both launchpad and bzr | 07:46 |
| igc | poolie: can I merge the bug tracking doc changes? jml said they were ok with him | 07:57 |
| AfC | I just created a branch called 'hope', where I was hoping that a massive merge bringing in some changes from a different upstream project would work. | 08:03 |
| AfC | It didn't | 08:03 |
| AfC | rm -r hope/ | 08:03 |
| AfC | Clearly, I have no hope. | 08:04 |
| * igc dinner | 08:23 | |
| Riddell | at 16:30 we have a half hour tutorial on bzr in #kubuntu-devel for https://wiki.kubuntu.org/KubuntuTutorialsDay, if there's a knowledgeable bzr person who could hang around and answer the questions I don't know that would be good | 09:09 |
| spiv | Riddell: That's UTC? | 09:10 |
| Riddell | spiv: yes | 09:11 |
| Riddell | possibly not ideal for .au | 09:11 |
| Riddell | or that side of the world | 09:12 |
| spiv | Yeah. There's likely to someone around at that time, though. | 09:13 |
| mwhudson | i'll be around if you can't get somone more qualified | 09:23 |
| mwhudson | jelmer or vila maybe? | 09:23 |
| mrevell | Good morning Bazaaros! | 09:26 |
| jelmer | Riddell,mwhudson: I just joined there as well | 09:43 |
| jelmer | hi Matt | 09:43 |
| Riddell | thanks | 09:54 |
| gsuveg | re | 11:04 |
| gsuveg | smart server run good ? | 11:13 |
| Peng | Good? | 11:15 |
| gsuveg | can i use as production? | 11:16 |
| Peng | Sure. | 11:17 |
| gsuveg | now use this via simple ssh | 11:17 |
| Peng | bzr+ssh? | 11:17 |
| gsuveg | yes | 11:17 |
| Peng | What do you mean? | 11:17 |
| gsuveg | now bzr run not as smart-server | 11:19 |
| Peng | What do you mean? | 11:19 |
| gsuveg | nevermind, sry, i need run | 11:19 |
| gsuveg | i read the website, thanks Peng | 11:27 |
| Peng | Ok. | 11:28 |
| === mwhudson_ is now known as mwhudson | ||
| zerok | hi :) | 11:47 |
| === mrevell is now known as mrevell-lunch | ||
| jelmer | Riddell: just curious, what is the biggest issue with the KDE repository when using it with bzr-svn? | 12:25 |
| jelmer | Riddell: The memory usage when it's caching all revision metadata? | 12:25 |
| luks | jelmer, the memory usage makes is almost unusable | 12:37 |
| luks | jelmer, you have to restart it about every 1000 revisions, which gets boring for 700k revisions | 12:38 |
| luks | (and people who are not aware of the bug will be very surprised) | 12:38 |
| === cprov is now known as cprov-out | ||
| Riddell | jelmer: yes, caching the metadata is just unworkable unfortunately | 13:04 |
| === kiko is now known as kiko-fud | ||
| === mrevell-lunch is now known as mrevell | ||
| === cprov-out is now known as cprov | ||
| * quicksilver cries | 13:41 | |
| quicksilver | why do so many blog postings about VCSes not even mention bzr? | 13:42 |
| quicksilver | http://blog.moertel.com/articles/2007/12/10/how-i-stopped-missing-darcs-and-started-loving-git | 13:42 |
| LeoNerd | Because people don't know it exists? | 13:42 |
| LeoNerd | SVN has all the limelight. And Git. | 13:42 |
| LeoNerd | Git was in news lots because of the bitkeeper/kernel stuff | 13:42 |
| zerok | and mercurial currently has some little hype thanks to opensolaris and openjdk. perhaps canonical should also do some little advertising ;) | 13:47 |
| Peng | I wonder how I found bzr? | 13:49 |
| Peng | There were those Mozilla comparisons, but I think I knew about it before them. | 13:50 |
| zerok | i think i found it through some darcs-to-* comparison ... | 13:52 |
| ricardokirkner | hi there.. I am trying to migrate some svn project to bzr. I am working on a fedora core 7 machine, and I cannot get the bzr-svn plugin to work, due to the subversion bindings version mismatch... has anyone managed to get this working on a fedora core machine ? | 13:55 |
| mwhudson | ricardokirkner: my tongue-in-cheek answer for getting this working is installing ubuntu in a chroot/vmware/xen :) | 13:57 |
| mwhudson | but once upon a time i did manage to build the right version of the bindings on os x | 13:57 |
| === kiko-fud is now known as kiko | ||
| jelmer | luks, Riddell: Thanks for the feedback. | 14:12 |
| jelmer | I'll see if I can spend some time fixing that memory leak in the next couple of days. | 14:12 |
| === mrevell_ is now known as mrevell | ||
| jelmer | ricardokirkner: I'm not aware of anybody providing pre-built rpms of a patched subversion, but there is a link on the bzr-svn wiki page to a howto that explains how to patch subversion on fedora | 14:26 |
| === kiko is now known as kiko-phone | ||
| === cprov is now known as cprov-lunch | ||
| === kiko-phone is now known as kiko | ||
| Daviey | Hey, I'm having a problem with bzr-email. i have a branch that i want a linux user group to be able to commit to (locally) - that works fine, but the bzr-email only seems to work if it's the owner | 15:19 |
| jam | Daviey: do you have a specific traceback we can see? | 15:20 |
| jam | !paste | 15:20 |
| ubotu | pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) | 15:20 |
| jam | ubotu: paste | 15:20 |
| Daviey | jam: eek, i'm not sure where logs for bzr-email are kept | 15:20 |
| jam | Daviey: well, mostly I'm interested in seeing what you saw on the terminal | 15:21 |
| jam | Either that | 15:21 |
| jam | or you can give me the tail of ~/.bzr.log | 15:21 |
| Daviey | $ bzr commit | 15:21 |
| Daviey | added test | 15:21 |
| Daviey | Committed revision 1. | 15:21 |
| Daviey | thats all on a working one | 15:21 |
| jam | Daviey: you may want to use paste.ubuntu-nl.org since it won't throttle you for a big message | 15:21 |
| Daviey | i will | 15:21 |
| jam | I'm also not sure what you mean by "only works if it is the owner". | 15:22 |
| jam | I'm not sure if you realize that each user needs to have bzr-email installed | 15:22 |
| jam | and configured | 15:22 |
| Daviey | yeah, i do | 15:22 |
| Daviey | just my own user testing atm | 15:22 |
| jam | It doesn't seem like the branch permissions should effect it, but I'm happy to help you debug what is going on | 15:22 |
| Daviey | http://pastebin.com/m1f1da47f | 15:24 |
| Daviey | thats if i commit to a folder where i'm in the same group, and have rw perms | 15:25 |
| Daviey | http://pastebin.com/m7a54f32a and thats if i commit from a branch in ~ (hence i'm the owner) | 15:27 |
| Daviey | jam: ^ | 15:27 |
| jam | Daviey: I don't see much of a difference there | 15:29 |
| jam | (only the revision_id and timestamps seem to change) | 15:29 |
| Daviey | jam: there isn't! :( .. but the second works and the first doesn't | 15:29 |
| jam | Daviey: define "works" :) | 15:29 |
| jam | Sends an email versus not sending an email? | 15:29 |
| Daviey | ie, sends an email | 15:29 |
| Daviey | yes | 15:29 |
| Daviey | I'm guessing it still looks for $HOME/.bzr/ of current user, and not the group user? | 15:31 |
| jam | Daviey: Do you mean $HOME/.bazaar/bazaar.conf ? | 15:32 |
| Daviey | yes | 15:32 |
| Daviey | (sorry) | 15:32 |
| jam | I'm sure we don't ever look in a group .bazaar | 15:32 |
| jam | Config file is always per-user | 15:32 |
| jam | I don't think we have a "group config" | 15:32 |
| jam | You could probably set things in the branch itself | 15:32 |
| jam | via $BRANCH/.bzr/branch/branch.conf (for --dirstate-tags or newer branches) | 15:32 |
| Daviey | oww, i'll try that | 15:33 |
| jam | Daviey: is there even a normal way to say "give me the home directory for this group" ? | 15:36 |
| jam | You could have all users override BZR_HOME | 15:36 |
| jam | to have it look in a different place for ~/.bazaar/bazaar.conf (and locations.conf) | 15:36 |
| jam | But then it wouldn't really be per-branch | 15:36 |
| Daviey | (only want one branch atm) | 15:37 |
| Daviey | Can post_commit_to & post_commit be in bazaar under default? Or should the wildcard [*] be used in locations.conf? | 15:38 |
| Daviey | hmmf, doesn't work with $BRANCH/.bzr/branch/ either | 15:41 |
| jam | Daviey: I think you can put it in [DEFAULT], but only do that if you want all commits to send email | 15:49 |
| jam | I know I have some branches I consider "private" | 15:49 |
| jam | Daviey: what does "bzr info" give in the group branch? | 15:49 |
| === mw|out is now known as mw | ||
| jam | I'm wondering if it is an older format that only uses ~/.bazaar/locations.conf | 15:50 |
| jam | Branch format 6 (and above) uses .bzr/branch/branch.conf | 15:51 |
| jam | also ~/.bazaar/locations.conf takes precedence over .bzr/branch.conf just in case | 15:53 |
| glyph | How does one install bzr plugins? | 16:00 |
| glyph | I have grabbed the push-and-update plugin's source, but there aren't any docs associated with it. | 16:00 |
| Peng | glyph: Drop it in bzrlib/plugins or ~/.bazaar/plugins. | 16:00 |
| === cprov-lunch is now known as cprov | ||
| Daviey | jam: i'm using Bazaar (bzr) 0.15.0, but Gutsy package of bzr-email | 16:07 |
| jam | ouch... that's an old Bazaar. | 16:07 |
| jam | I would recommend upgrading if possible | 16:07 |
| glyph | bleh. | 16:07 |
| jam | Some known minor bugs with how it handles renames | 16:07 |
| glyph | and does anyone have a suggested replacement for transport.split_url? | 16:08 |
| glyph | I see it is a "@deprecated_function(zero_ninety)" but no suggestion of a replacement | 16:08 |
| jam | glyph: for what we need, I believe you can just grab items off of the transport itself | 16:09 |
| jam | transport._user | 16:09 |
| jam | transport._scheme | 16:10 |
| jam | transport._password | 16:10 |
| jam | etc | 16:10 |
| jam | glyph: if you are interested in updating push-and-update, I'm happy to merge any patches | 16:10 |
| jam | By the way, it would be nice to change it to work as a post-push hook | 16:10 |
| jam | rather than a separate command | 16:10 |
| glyph | jam: Yeah, I was thinking the same thing | 16:10 |
| jam | So it could install a branch hook | 16:10 |
| jam | and then if it sees that the URL is ssh/sft | 16:10 |
| jam | sftp | 16:10 |
| jam | it could check if there is a remote working directory | 16:11 |
| glyph | jam: I don't think I understand the workings of bzr well enough to actually patch this though :) | 16:11 |
| jam | and then trigger the rest of the code | 16:11 |
| jam | glyph: ok, I'll take a few minutes and put something together | 16:11 |
| glyph | jam: <3 | 16:11 |
| jam | I wrote it originally, but just haven't really needed it since | 16:11 |
| glyph | jam: I don't really "need" it, but it makes an awesome demo | 16:12 |
| glyph | jam: I was just showing bzr to a guy I know who maintains a stereotypically absurd apache configuration | 16:12 |
| Peng | Why does diff need a working tree? | 16:12 |
| glyph | "bzr init" in /var/www kind of blew him away ;) | 16:12 |
| jam | Peng: it theoretically doesn't | 16:12 |
| jam | Peng: igc has a patch on the ML which gets rid of that | 16:12 |
| glyph | but it would have been nice for "push" to just update the working tree on the server (since that's really his main use-case anyway) | 16:12 |
| dato | that reminds me my discussion with lifeless the other day about a possible `push -u`, and that I still have to mail the list | 16:14 |
| Peng | jam: Oh, cool. | 16:15 |
| Peng | Just out of curiosity, why does it currently need one? | 16:15 |
| jam | I think it changes the basic flow of the command, but it means you don't need WT | 16:15 |
| jam | Peng: because it is a DWIM command, and it is complicated to get all of the edge cases working | 16:16 |
| jam | For example, you can diff a working tree file that doesn't exist in the branch | 16:16 |
| Peng | jam: Oh, that makes sense. | 16:19 |
| hexmode | Can anyone help with pqm? Here's where I am currently: http://rafb.net/p/lSPpmX40.html | 16:21 |
| ricardokirkner | hi. I managed to branch from my svn repository to a bzr repository, but in order to do that, I had to create a repository with the dirstate-with-subtree format. My problem now is that I cannot make a branch from this last branch into a repository with another format, or even convert the repository format | 16:35 |
| ricardokirkner | any ideas on what I should try? | 16:35 |
| dato | ricardokirkner: they are incompatible repository formats | 16:40 |
| dato | ricardokirkner: my recommendation is that you keep your bzr-svn branches in a separate shared repository. why do you want to use an existing one, since they are separate projects, anyway? | 16:41 |
| ricardokirkner | dato: maybe what I am doing makes no sense.. what I want to do is to migrate a project completely to bzr. | 16:41 |
| ricardokirkner | for that I branched from the svn repo | 16:42 |
| dato | ok, very well | 16:42 |
| dato | (what version of bzr do you have?) | 16:42 |
| ricardokirkner | but then, since the repository format is not the default one (it requires dirstate-with-subtree format), I wanted to branch to another repository, in the new format | 16:42 |
| ricardokirkner | I am using bzr 0.92 | 16:42 |
| ricardokirkner | is there a better way to do that? | 16:43 |
| dato | you cannot go back from dirstate-with-subtree to dirstate | 16:43 |
| dato | that is, branches originally created with bzr-svn are not compatible with the default format | 16:43 |
| dato | but that should not be a very big problem, I think | 16:43 |
| ricardokirkner | but if I want to stay in bzr from now on... that means I will have to stay frozen on that repository format forever? | 16:45 |
| dato | bzr 1.0-rc1 introduces a couple new, non-experimental repository formats, rich-root and rich-root-pack, to which you can upgrade from dirstate-with-subtree | 16:46 |
| dato | any of those two is very safe to use | 16:46 |
| dato | (the upgrade maybe slow, though) | 16:46 |
| xif | do centralized version control systems offer particular advantages to commercial companies? | 16:47 |
| ricardokirkner | so, what you are saying is.. I should stay with the current format -- dirstate with subtrees -- until bzr 1.0 is out, and then I will be able to upgrade the repository format.. correct? | 16:47 |
| xif | is it harder to keep your code closed / secret with a distributed VCS? | 16:47 |
| Peng | xif: Yes, but not inherently. | 16:48 |
| xif | Peng: what do you mean? | 16:48 |
| dato | ricardokirkner: yeah. but if you don't upgrade, you'll make people with older bzrs able to branch. why do you seem so anxious to upgrade, though? :) | 16:48 |
| Peng | xif: Well, with a centralized VCS, it's still possible to extract the entire history and wind up with just as much information as with a DVCS. | 16:49 |
| Peng | xif: The DVCSes currently aren't really focused on commercial environment so they don't have as good access-control features. | 16:49 |
| ricardokirkner | because I think... (here I might be wrong) that new repository formats should be more efficiente (performance wise) and eventually, I will want to switch | 16:49 |
| Peng | ricardokirkner: Well, the developers aren't trying to make new repo formats that are slower! | 16:49 |
| * Peng notices the backlog and scratches that last line. | 16:50 | |
| xif | Peng: so you claim CVCSes are more oriented for commercial / closed environments, so - incidentally to them being centralized - they're also a bit easier to protect than the DVCSes? | 16:50 |
| Peng | Haven't packs been pushed much more rapidly than previous backwards-incompatible changes were? | 16:50 |
| Peng | xif: Well, I'm just talking about Subversion here. | 16:51 |
| dato | ricardokirkner: there is always a way to upgrade to newer repository formats, for example in 0.92 you already have pack-0.92-subtree | 16:51 |
| xif | Peng: so SVN specifically has more evolved access-controls than most DVCSes? | 16:52 |
| dato | ricardokirkner: and that upgrade is pretty straightforward. the full details of this story is that -subtree is an experimental format, and a new format was created a bit for bzr-svn use case, the rich-root one. | 16:52 |
| ricardokirkner | dato: ok... but currently there is no way to move the repository to the currently default format. actually that is no issue as long as the dirstate with trees format is efficiente enough | 16:53 |
| Peng | xif: I'm saying that svn has better access-control than the DVCSes I have experience with (bzr and hg), and that, while that is one thing that's being worked on, I've never seen commercial environments discussed. | 16:53 |
| ricardokirkner | dato: what would you recommend me to do? | 16:53 |
| Peng | I crafted that sentence too carefully. | 16:53 |
| dato | ricardokirkner: oh. maybe it would help for you to think that, given that 0.92's default format is "dirstate", dirstate-with-subtree is actually an addition to it :) | 16:54 |
| xif | Peng: I see | 16:54 |
| === cpro1 is now known as cprov | ||
| xif | Peng: I'm asking because I'm wondering why a certain company is using Subversion instead of bazaar / git / hg | 16:54 |
| ricardokirkner | oh... ok. :-$ I hadn't though of it that way | 16:55 |
| xif | they have some very smart people there, many of the Python knowledgeable - people likely to prefer bazaar or hg | 16:55 |
| dato | ricardokirkner: what to do, depends on how much concerned are you about having the latest and the greatest, and about maintaining compatibility with older bzrs for other people for branch from you. | 16:55 |
| xif | so I guess that the codebase being top-secret has something to do with it... | 16:55 |
| Peng | xif: Well, even if companies have some smart people, they're generally insane. :) | 16:55 |
| xif | Peng: nah, this company's ok, I think :-) | 16:56 |
| Peng | xif: When you have gigabytes of history, it sucks that DVCSes copy the whole thing to every developer's computer. | 16:56 |
| xif | their CEO / CTO is a former hacker. | 16:56 |
| xif | ah, that might make sense as well | 16:56 |
| xif | Peng: what's the common solution for such a problem? | 16:56 |
| jam | xif: http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html | 16:57 |
| xif | I believe the Linux codebase has it, right | 16:57 |
| Peng | xif: Solution? | 16:57 |
| xif | Peng: certainly there are some projects - e.g. the Linux kernel project - requiring said "gigabytes of history" while using a DVCS | 16:58 |
| Peng | xif: Meh. | 16:58 |
| jam | xif: Linus doesn't care if it hurts you, as long as it works for him | 16:58 |
| Peng | xif: 10+ GB seems to be common in corporate environments, but not so much with FOSS. | 16:59 |
| xif | oic | 16:59 |
| Peng | xif: I don't know of any FOSS stuff over 2 GB. | 16:59 |
| jam | xif: Bazaar has "lightweight checkouts" and we are working on "shallow/stacked branches" to avoid some of it | 16:59 |
| jam | Peng: Moz was >3 GB in CVS | 16:59 |
| jam | Peng: OOo is about 20GB in CVS | 16:59 |
| jam | but not all of that is code | 16:59 |
| jam | they have stuff like mp3's of people's interviews in their CVS repo | 17:00 |
| Peng | jam: Moz may be 3 GB in CVS, but one can assume it would be a lot smaller in git. | 17:00 |
| Peng | jam: But OOo, oh. | 17:00 |
| jam | Peng: sure, it dropped to ~1GB in Bazaar | 17:00 |
| Peng | s/git/anything else/, then. :P | 17:00 |
| jam | Still, 1GB is non-trivial for most download | 17:01 |
| xif | jam: "to avoid some of it" -> what's "it"? | 17:01 |
| jam | xif: downloading the full set of history | 17:01 |
| jam | Lightweight Checkouts store 0 history locally | 17:01 |
| Peng | (They don't even store copies of the files like in svn, do they?) | 17:01 |
| jam | Stacked/Shallow branches would store a few commits | 17:01 |
| xif | jam: I see, thanks. I'm reading your blog now | 17:01 |
| jam | Peng: correct | 17:01 |
| Peng | :X | 17:02 |
| jam | Peng: but we do keep the inventory locally, so "bzr status" works | 17:02 |
| xif | why should I use bazaar over git or mercurial? | 17:02 |
| jam | but "bzr diff" has to hit the remote | 17:02 |
| jam | xif: http://bazaar-vcs.org/BzrVsGit | 17:03 |
| jam | xif: http://bazaar-vcs.org/BzrVsHg | 17:03 |
| xif | thanks :-) | 17:03 |
| jam | and http://bazaar-vcs.org/BzrVsSvn, but mostly it just points to my blog | 17:03 |
| xif | yeah, and I don't think many people who actually know either (or even understand CVCS vs. DVCS) would need help deciding between SVN and BZR | 17:04 |
| Riddell | ropiku: you're trying to push to launchpad? | 17:05 |
| ropiku | Riddell, yes and it says that I don't have a registered SSH key | 17:05 |
| ropiku | Riddell, and I pasted my .ssh/id_rsa.pub onto launchpad | 17:05 |
| Riddell | ropiku: what's your LP id? | 17:07 |
| ropiku | Riddell, I think the weird stuff is that I push to sftp://bazaar.launchpad.net/~ropiku/kubuntu-tutorial/ropiku-branch | 17:07 |
| ropiku | Riddell, ~ropiku (and name Mihai) | 17:08 |
| Riddell | that all looka fine | 17:08 |
| ropiku | Riddell, and it says "Launchpad user 'mihai' doesn't have a registered SSH key." that's my local username | 17:08 |
| Riddell | oh, different user name | 17:08 |
| Riddell | sftp://<lp-user>@bazaar... | 17:09 |
| Riddell | so bzr push sftp://ropiku@bazaar.launchpad.net/~ropiku/kubuntu-tutorial/ropiku-branch | 17:09 |
| ropiku | pushing... | 17:09 |
| ropiku | Created new branch. ;) | 17:09 |
| Peng | Blehh, BzrVsHg was written by a marketer, wasn't it? | 17:09 |
| ropiku | Riddell, ssh was connecting to my local username, that was it ? | 17:10 |
| Riddell | ropiku: yes, which is the wrong username for launchpad | 17:10 |
| Peng | At first glance when it was first created, I thought that article was garbage, but now it looks kinda-OK, except that it sounds like marketing trash. | 17:11 |
| ropiku | what's the difference in using sftp:// instead of bzr+ssh, isn't bzr more efficient ? | 17:12 |
| dato | yes | 17:12 |
| dato | for bzr+ssh, bzr has to be installed in the remote end | 17:13 |
| xif | I'm leaning towards bazaar because: | 17:13 |
| xif | 1) it's pure Python. I like pure Python | 17:13 |
| xif | 2) I like Ubuntu and Canonical. | 17:13 |
| Peng | xif: Psst, bzr has some Pyrex (combines Python and C) and C bits. :P | 17:14 |
| xif | Peng: oh shoot | 17:14 |
| dato | Peng: errr | 17:14 |
| dato | xif: those are optimizations and the same functionality is provided by pure bzr | 17:14 |
| dato | pure python, I mean | 17:14 |
| Peng | Right. I was trying to think of how to say that. | 17:15 |
| Peng | Anyway, bubble-bursting over. | 17:15 |
| jam | xif: you don't *have* to compile them, we have pure-python fallbacks | 17:15 |
| xif | Wikipedia says bazaar is Python: | 17:15 |
| xif | http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Technical_information | 17:15 |
| jam | But they are a bit faster if you do | 17:15 |
| xif | Mercurial OTOH is listed as "Python, C" | 17:15 |
| xif | jam: yeah, it's still cool though | 17:15 |
| xif | also, Pyrex is better than plain C. | 17:15 |
| Peng | Yeah, Mercurial has four C modules. | 17:16 |
| Peng | Bzr has parts of modules written in Pyrex or C with alternate Python versions. | 17:16 |
| Peng | What about Cython? | 17:16 |
| xif | what about it? :-) | 17:16 |
| jam | vila: ping | 17:16 |
| xif | it's a nicer Pyrex afaik, but less people use it | 17:16 |
| xif | jam: btw, how do create "Python fallbacks" for C code? | 17:16 |
| xif | just rewrite the whole thing in Python, then make sure it passes the same tests? | 17:17 |
| Peng | Cython is pretty new. | 17:17 |
| jam | xif: correct | 17:17 |
| jam | Except the other way | 17:17 |
| xif | jam: cool, good to know | 17:17 |
| jam | we had it written in Python | 17:17 |
| jam | and then we implemented it in C/Pyrex | 17:17 |
| xif | yeah, I assume so: Python is better for prototyping | 17:17 |
| jam | and made sure that all the tests pass with both ways | 17:17 |
| Peng | A couple months ago Cython's website said it was only experimental, but I can't find that now. | 17:17 |
| jam | So when we run "make check" it tests both implementations | 17:17 |
| jam | vila: I'm getting a "500 Too many spams from your IP" when trying to send email to you, but the page it sends me to is in french | 17:18 |
| xif | jam: what's the deciding factor between using C or Pyrex for the optimized rewrite? | 17:18 |
| jam | vila: http://postmaster.free.fr/ | 17:18 |
| jam | xif: Generally we prefer Pyrex | 17:18 |
| jam | we had 1 person rewrite something in C | 17:18 |
| jam | and it was good enough we weren't going to rewrite it again in Pyrex | 17:18 |
| jam | I personally always use pyrex | 17:19 |
| jam | for things I've rewritten | 17:19 |
| vila | jam: WTF ? | 17:19 |
| jam | I really like how it handles exception handling without me needing to worry about it all the time | 17:19 |
| jam | vila: I *think* my ISP somehow got blacklisted | 17:19 |
| jam | I stopped sending directly from my home machine | 17:19 |
| jam | because of blacklist sites that block whole ranges | 17:20 |
| xif | jam: OK, so there's no technical reason to ever prefer C over Pyrex, but some people (at least one person) had a personal taste preference for C extensions, which is the only reason there are pure C extensions in Bazaar's codebase | 17:20 |
| jam | xif: correct | 17:20 |
| jam | There is only 1 pure C extension | 17:20 |
| xif | jam: thanks, I'm a Python developer myself, so it's quite interesting. | 17:20 |
| xif | Peng: afaik Cython was blessed as "production ready" only very recently. | 17:21 |
| Peng | xif: Pure C is faster than Pyrex. | 17:21 |
| xif | Peng: as fast or faster :P | 17:21 |
| vila | jam: *your* actual IP is not blacklisted | 17:21 |
| xif | I'm not an expert, but in many situations Pyrex should perform just as well as native C. | 17:22 |
| Peng | xif: The number I've seen touted is that Pyrex is 75% as fast as C. Of course that will vary, but it'll always be faster. Pyrex will have extra ugly glue code, and pure C can be more carefully optimized. | 17:22 |
| vila | they say the maximum block time is 24h. but you will get blacklisted again if you spam again ;-/ | 17:22 |
| Peng | So *that's* how bzr is funded! | 17:22 |
| xif | Peng: yeah, basically Pyrex is a compromise between "down to the metal" C and "very high level" Python. | 17:23 |
| Peng | xif: Right. | 17:23 |
| xif | it's more high level than C, and sacrifices some performance for that. | 17:23 |
| Peng | It's not just that it's more high level, but that it's a translator. | 17:23 |
| xif | anyways, eventually PyPy would implement some cutting-edge JIT, and we'd all get pure-C performance with pure Python ;-) | 17:23 |
| Peng | Well, I guess it is that it's high-level. | 17:23 |
| Peng | xif: Will that be after PyPy stops being way more complex than CPython? | 17:24 |
| jam | xif, Peng : well I hand-optimized my Pyrex work by looking at the generated C code | 17:24 |
| xif | no, that would never happen :-) | 17:24 |
| jam | so you can see places where you are being silly | 17:24 |
| jam | and making it go through getattr() when it doesn't need to | 17:25 |
| vila | jam: they say they don't use any public RBL, only internal data, does your provider give you dynamic IPs ? | 17:25 |
| xif | jam: interesting. btw have you considered taking advantage of Pysco? | 17:25 |
| vila | jam: hey, lazy guy try that: http://postmaster.free.fr/index_en.html | 17:25 |
| jam | vila: my IP is static, but I send through my ISP, because apparently there are blacklists that block the whole range of MediaCom client IPs | 17:28 |
| jam | xif: One issue with Psyco is that it doesn't save any state | 17:28 |
| jam | so it has to JIT every time you run 'bzr' | 17:28 |
| jam | rather than doing it in advance | 17:28 |
| jam | so JIT in general isn't great for short-lived programs | 17:28 |
| * xif nods | 17:29 | |
| xif | which is sort of what something like bzr is about. | 17:29 |
| xif | frequent, short runs. | 17:29 |
| jam | vila: so probably someone else behind my ISP is spamming, and it makes us all look bad | 17:30 |
| vila | jam: sounds like your neighbours are either spammers or zombies :-/ | 17:30 |
| jam | vila: the relay host seems to be: 207.115.20.71 | 17:31 |
| jam | But that isn't listed in the RBL either | 17:31 |
| jam | vila: I just forwarded the message through smtp.google.com hopefully that gets through | 17:32 |
| vila | jam: still nothing, what I did get was through the mailing list though | 17:39 |
| vila | jam: err, no, I did get your mail about #175866 directly, not though the ML | 17:40 |
| vila | so the one you sent Date: Thu, 13 Dec 2007 10:07:21 -0600 didn't get blocked | 17:41 |
| jam | vila: did you get the BB:approve one? | 17:46 |
| vila | jam: no | 17:46 |
| jam | that must have been the blocked one | 17:46 |
| jam | I guess free.fr doesn't want your patch merged | 17:47 |
| vila | lol, I can see the vote on BB anyway ;-) | 17:48 |
| jam | Maybe they don't support range requests | 17:48 |
| jam | and they don't want Bazaar to reveal that | 17:48 |
| vila | I replied to your email, if you think pycurl should emit the warning too, I'll file another bug, there is a fix that is 1.0 worth IMHO, let's bikeshed on the warning without blocking it ;-) | 17:49 |
| vila | jam: the one via google just arrived | 17:56 |
| jam | vila: well, you have to get approval from poolie to get it into 1.0 | 18:01 |
| jam | But I'm happy with it for bzr.dev | 18:01 |
| vila | jam: that's how I understood it, thanks for confirming | 18:01 |
| vila | jam: did you notice you have a bunch a branches in error: https://code.edge.launchpad.net/~jameinel | 18:03 |
| Peng | vila: His net connection was too slow for a while, or something. | 18:04 |
| jam | vila: no I didn't I blame mwhudson | 18:04 |
| jam | On the plus side, I think 1.0rc3 has been merged into LP now | 18:05 |
| jam | so it should have vila's readv fixes | 18:05 |
| vila | Peng: mwhudson ate his bandwidth but I think it was only once ;-) | 18:05 |
| vila | jam: I pushing a new pack branch with bzr+ssh and my network perfmeter is quite flat, may be a similar fix should be applied there too :-/ | 18:06 |
| vila | LP still doesn't use shared repos isn't it ? | 18:07 |
| jam | vila: it is for any newly registered branches | 18:07 |
| vila | bzr push trigger the registration ? | 18:07 |
| jam | inventory.knit is too big for my bandwidth | 18:07 |
| jam | versus the LP timeout | 18:08 |
| jam | vila: I use my "bzr-register" plugin, which is a wrapper around bzr register-branch | 18:09 |
| vila | argh, they lied to us, gollum, I'm pushing at ~100KO/s damn perfmeter | 18:09 |
| jam | So doing a bugfix branch is | 18:09 |
| jam | bzr cbranch ../bzr.dev foo_XXXXX | 18:09 |
| jam | cd foo_XXXXX | 18:09 |
| jam | bzr reg --bug XXXXX | 18:09 |
| jam | vila: 100 Knock Outs per second? Damn you're good | 18:10 |
| jam | It means Launchpad periodically destroys my upstream bandwidth | 18:10 |
| jam | but usually it doesn't have a horrible amount to upload after the first time | 18:10 |
| jam | vila: LP does *not* use shared repositories yet, I believe that and/or shallow branches are marked as to-be-done by the March/April timeframe | 18:11 |
| vila | ho, so LP pull from you ? What not using just bound branches then ? | 18:11 |
| vila | hehe, you scared him ;-) | 18:12 |
| jam | vila: LP pulls from me because I don't want to pay the cost of uploading every time I "bzr commit" | 18:12 |
| jam | And I certainly don't want to have to wait for "bzr branch" to finish before I start working on a bug | 18:12 |
| jam | So I use a bound branch to my local server | 18:13 |
| jam | and let LP know about it | 18:13 |
| jam | While it may be slower than some other possibilites | 18:13 |
| jam | it takes less of *my* time | 18:13 |
| jam | (The fastest being ssh foo.canonical.com, bzr push bazaar.lp.net/~jameinel/, and then doing a checkout or something from there) | 18:13 |
| jam | The other problem is that you can't turn a hosted branch into a mirror | 18:14 |
| jam | So I can't go pre-seed the branch I'm about to have mirrored. | 18:14 |
| vila | jam: stop, you scare them all ! | 18:16 |
| vila | jam: joking, interesting setup | 18:16 |
| * jam => tries to get real work done :) | 18:16 | |
| jam | It is funny, I pretty much never use "bzr push" | 18:18 |
| jam | I keep forgetting I have a "dummy" post-push plugin that I was using to debug writing one | 18:18 |
| jam | So when I finally do use "bzr push" it chatters on my terminal | 18:18 |
| vila | hehe | 18:18 |
| vila | I use push to create branches on launchpad, for my other uses I use bound branches and just commit/update | 18:19 |
| jam | vila: weird... it seems that if I use smtp.google.com as my SMTP server, it rewrites the From address | 18:23 |
| jam | so that it comes from my gmail account | 18:23 |
| jam | rather than the account I'm claiming to send it from | 18:23 |
| jam | So my post gets blocked to the ML | 18:23 |
| jam | and you replied to my gmail account. | 18:23 |
| jam | I suppose that is their anti-spam measure | 18:23 |
| jam | mwhudson: I understand why LP was failing to mirror my newly registered branches, but do you know why it is failing to update branches I already had? | 18:24 |
| jam | I suppose I upgraded from Branch5 to Branch6 for a lot of them | 18:25 |
| jam | Maybe that triggers them to be newly copied from scratch.... :( | 18:25 |
| jam | maybe that is why my pings have become so bad lately | 18:25 |
| mwhudson | jam: that might do it | 18:27 |
| mwhudson | jam: it should be better now | 18:27 |
| jam | mwhudson: https://code.launchpad.net/~jameinel/ shows an awful lot of failed branches | 18:27 |
| jam | But I did try to refresh them all | 18:27 |
| mwhudson | yes, that would probably trigger complete re-mirroring | 18:27 |
| mwhudson | 'refresh' ? | 18:28 |
| jam | Well the "Try Again" button | 18:29 |
| mwhudson | oh right | 18:29 |
| mwhudson | when did you try that? | 18:29 |
| jam | about 2 minutes ago | 18:29 |
| jam | maybe 30 | 18:29 |
| mwhudson | probably still running then :) | 18:29 |
| mwhudson | excuse slow responses, i'm on a damp-string internet connection here | 18:29 |
| mwhudson | (in a pub :) | 18:29 |
| jam | mwhudson: it won't try to re-mirror all of them at the same time, right? Just more of a sequential pwnage of my upstream bandwidth? | 18:31 |
| jam | My ISP is probably going to ban me... :) | 18:31 |
| mwhudson | jam: it can try up to 4 at once | 18:31 |
| jam | hmm... | 18:31 |
| mwhudson | jam: and indeed, seems to be trying 3 right now | 18:31 |
| jam | I wonder if that will trigger the failures | 18:31 |
| jam | Just thinking that my bandwidth is barely enough for 1-at-a-time | 18:31 |
| mwhudson | would be surprised if it helped :) | 18:31 |
| jam | But I guess if it has the progress updates | 18:31 |
| mwhudson | it's still running 0.92 i think | 18:32 |
| jam | mwhudson: well if it was smart enough to know it was requesting the *exact same* data 3 times | 18:32 |
| mwhudson | jam: yeah, yeah, we know about that one | 18:32 |
| jam | mwhudson: can you put a squid proxy in front of my URLs :) | 18:32 |
| jam | *and* tell it to ignore the Pragma:no-cache | 18:33 |
| mwhudson | jam: do all your work in checkouts bound to branches on rookery? :) | 18:33 |
| jam | a) I sort of like knowing that all of my work is on my server | 18:33 |
| jam | b) 100ms ping to rookery is still a little bit more painful than I want to pay for 'bzr commit' | 18:34 |
| jam | I do direct checkouts for plugins to bazaar.lp.net | 18:36 |
| jam | just not for bzr branches | 18:36 |
| jam | glyph: it has been done | 18:44 |
| jam | glyph: if you update your 'push-and-update' it should just trigger for any "bzr push" | 18:44 |
| jam | Well, as long as the remote has a WorkingTree, and the remote is bzr+ssh or sftp | 18:45 |
| === BasicMac is now known as BasicOSX | ||
| Peng | Without doing any research myself, how consistent are revnos? When one, say, merges some-branch into bzr.dev, it'll get a new, dotted revno, but what happens when someone merges bzr.dev into some-other-branch? Does it change again? Sometimes, but not always? | 18:49 |
| mwhudson_ | jam: so sorry, didn't see anything after "(a)" | 18:50 |
| jam | a) I sort of like knowing that all of my work is on my server | 18:50 |
| jam | b) 100ms ping to rookery is still a little bit more painful than I want to pay for 'bzr commit' | 18:50 |
| jam | Peng: merging won't change your local revnos | 18:50 |
| jam | Peng: pull will | 18:50 |
| jam | revno's are stable from the viewpoint of a branch | 18:51 |
| Peng | jam: Err? | 18:53 |
| Peng | (I am talking about over three different branches, not just 1) | 18:53 |
| luks | well, revnos are relative to one branch, so it doesn't make much sense for 3 different branches | 18:54 |
| jam | Peng: within 1 branch, revnos will stay fixed as long as you "merge" and not "pull" | 18:54 |
| jam | The revnos you merge will change | 18:54 |
| jam | so if it is 10 in branch A, merging that into B will give it a different number | 18:54 |
| jam | (like 9.1.1) | 18:55 |
| luks | speaking of revnos, is it intentional that some revisions ("tails") in e.g. bzr.dev don't have revnos? | 18:56 |
| jam | luks: I'm not sure what you mean by tails | 18:56 |
| glyph | jam: Awesome! | 18:56 |
| jam | But the way the algorithm works, only revisions in the ancestry of a branch get numbers | 18:56 |
| jam | It would probably be possible to pretend, but you have issues when multiple 'tails' descend from the same node | 18:57 |
| jam | which one gets the '.1.' and which one gets '.2.' | 18:57 |
| jam | We resolve that by which one is merged first | 18:57 |
| jam | and if they have never been merged .... | 18:57 |
| luks | jam, for graph like http://pastebin.org/11479 | 18:57 |
| luks | B won't be even mentioned in either bzr log or viz (not sure which one) | 18:57 |
| glyph | jam: How do I enable it? | 18:57 |
| luks | but it doesn't have a revno at all | 18:57 |
| jam | glyph: You should just need to update it. If it is installed it will check on every push | 18:58 |
| glyph | jam: Hmm. | 18:58 |
| luks | because merge_sort won't include it in the resulting list | 18:58 |
| jam | It does a quick check to see if the target is valid | 18:58 |
| jam | luks: it won't be listed in log or viz | 18:58 |
| jam | because it isn't in the ancestry of the branch | 18:58 |
| glyph | jam: Aah, the UI is a tad confusing. | 18:59 |
| jam | so it isn't "log" worthy | 18:59 |
| jam | glyph: how so? | 18:59 |
| luks | it's a parent of C, isn't it? | 18:59 |
| jam | (you don't need to use push-and-update) | 18:59 |
| jam | luks: it is a *child* of C | 18:59 |
| glyph | http://pastebin.org/11481 | 18:59 |
| jam | well, depending on how you are graphing time | 18:59 |
| glyph | "This transport does not update the working tree...", and then a message telling me it just updated the working tree :) | 18:59 |
| jam | glyph: yeah, suppressing the "This transport" is hard | 18:59 |
| jam | because that is being done inside "bzr push" | 18:59 |
| jam | And I'm hooking after that | 18:59 |
| luks | jam, in python tuple speak [(C, (A, B))] | 18:59 |
| glyph | jam: OK, understood | 19:00 |
| jam | luks: In that case B should get "0.1.1" | 19:00 |
| glyph | jam: is there a way to turn this *off*? There are definitely a lot of places I might want to push that would not take kindly to having a working copy created / updated | 19:00 |
| luks | jam, but it doesn't | 19:00 |
| jam | glyph: it won't create a WT | 19:00 |
| glyph | jam: oh, okay. It just updates it if it happens to be there? | 19:00 |
| luks | jam, because merge_sort won't generate more than one revno for 0.something | 19:00 |
| jam | glyph: right, you need to do your own "bzr checkout" if you want to enable it somewhere | 19:00 |
| jam | luks: when Robert implemented it, you could have multiple from null:, and they would each get | 19:01 |
| jam | 0.1.1 and then 0.1.2 | 19:01 |
| jam | or something like that | 19:01 |
| jam | wait | 19:01 |
| jam | 0.1.1 for the second branch, 0.2.1 for the third, etc | 19:01 |
| luks | I think it's even mentioned in the docstring of merge_sort | 19:01 |
| luks | that it won't be included | 19:01 |
| jam | (the primary branch gets 1) | 19:01 |
| jam | I'll check | 19:01 |
| jam | luks: "Revisions not reachable from the tip" are not included | 19:02 |
| jam | correct | 19:02 |
| jam | You were saying "B" was a parent | 19:02 |
| jam | not a child | 19:02 |
| jam | luks: http://pastebin.org/11482 | 19:03 |
| jam | (When I draw graphs the first commit is at the top) | 19:03 |
| luks | jam, one moment, I'll give you a real-world example from bzr.dev | 19:03 |
| luks | it's actually your commit, if I remember correctly :) | 19:03 |
| luks | jam, as an example - john@arbash-meinel.com-20051228204947-2fd81543e866350a | 19:10 |
| luks | it's in the revision graph, but not in log | 19:10 |
| luks | most of these http://pastebin.org/11483 | 19:11 |
| luks | well, except one | 19:11 |
| Daviey | jam: I've just come back to it, upgraded bzr - same result! | 19:12 |
| jam | luks: I think that is actually because they are ghosts | 19:12 |
| jam | aka, revisions which are mentioned but not actually present | 19:12 |
| Peng | How do you get ghosts? | 19:13 |
| luks | no, they are present | 19:13 |
| luks | and it's also in the ancestry of the tip | 19:14 |
| luks | but not mentioned in the log, because merge sort won't generate 0.2.x | 19:14 |
| === mwhudson_ is now known as mwhudson | ||
| luks | Peng, I don't think you can with the current version of bzr | 19:15 |
| jam | glyph: I went ahead and created a monkey-patch, try updating again and testing it | 19:15 |
| jam | Now it should suppress that ugly warning message | 19:16 |
| jam | and just give you an update | 19:16 |
| jam | glyph: http://pastebin.org/11485 | 19:16 |
| jam | luks: it works here | 19:18 |
| jam | http://pastebin.org/11486 | 19:18 |
| jam | That actually isn't a ghost | 19:18 |
| glyph | jam: ... | 19:19 |
| jam | it is a plugin that got merged into bzr core | 19:19 |
| jam | glyph: ??? | 19:19 |
| glyph | jam: I am in awe. | 19:19 |
| jam | glyph: the power of python monkey patching | 19:19 |
| glyph | jam: OK now that you ruined the trick I'm a tiny bit less in awe. | 19:20 |
| glyph | jam: but your responsiveness is still legendary :) | 19:20 |
| jam | luks: so is it a problem with "bzr viz" ? | 19:20 |
| jam | Because "bzr log" seems to display it without any problems | 19:20 |
| jam | Peng: it is really hard to get ghosts in current bzr | 19:21 |
| luks | jam, umm, sorry, I was probably the old viz | 19:21 |
| jam | The converter from Arch => bzr can generate them | 19:21 |
| luks | I was just playing with a new graph view for qlog, and some revisions were missing | 19:21 |
| jam | because Arch could reference nodes that it didn't actually copy locally | 19:21 |
| luks | but I can't seem to reproduce it now | 19:21 |
| jam | The nodes in Bazaar which are actual ghosts | 19:22 |
| jam | are because our original merge code | 19:22 |
| jam | would reference them | 19:22 |
| jam | but not fetch them into the local repository | 19:22 |
| jam | I think there are about 2 of them | 19:22 |
| jam | both with my name on them | 19:22 |
| jam | because I nuked my copy once Martin had merged it | 19:22 |
| jam | (i haven't done that since :) | 19:22 |
| ricardokirkner | hi again. I have created two bzr branches from a svn repository, 1 for the trunk and 1 for a branch. now I want to merge my bzr trunk (corresponding to the svn trunk) with my bzr branch (corresponding to the svn branch) , but I get an error that 'branches have no common aancestor'. Even if I specify a revision with the -r flag, it doesnt work. is there anything I can do to work around this? | 19:26 |
| luks | are these created using bzr-svn? | 19:27 |
| ricardokirkner | yes | 19:27 |
| jam | ricardokirkner: you *can* use "bzr merge -r 0..-1", but I have the feeling it might be sub-optimal for what you want | 19:27 |
| jam | The '0' is the secret way of telling Bazaar that you really do want to merge 2 projects together | 19:27 |
| luks | hm, it's weird that bzr-svn created them without a common ancestor | 19:28 |
| ricardokirkner | although, I think I just found out how... it apparently merged with -r 0..n (last revision) | 19:28 |
| jam | But it sounds it is going to do things you don't like | 19:28 |
| luks | maybe you had your svn branching scheme wrong? | 19:28 |
| luks | (I mean the branching scheme set in bzr-svn) | 19:28 |
| ricardokirkner | no idea... what do you mean? | 19:29 |
| === Winterstream_ is now known as Winterstream | ||
| dato | luks: are you positive that bzr-svn is able to detect merges when importing? | 19:30 |
| jam | dato: it should be able to detect *branches* | 19:30 |
| jam | which gives you a common ancestor | 19:30 |
| dato | er, right | 19:31 |
| dato | I got confused | 19:31 |
| luks | ricardokirkner, see bzr help svn-branching-scheme | 19:31 |
| dato | jam: btw, I think a NEWS file in push-and-update could be helpful for people to notice this important change (cheers for it, too) | 19:32 |
| jam | I've never been big on that sort of thing | 19:32 |
| jam | "bzr log" if you want to know what has happened :) | 19:32 |
| jam | I suppose next you'll be asking me to create a setup.py so it can be bilt | 19:33 |
| jam | built | 19:33 |
| jam | and installed | 19:33 |
| LarstiQ | why, what an excellent idea :) | 19:33 |
| jam | As always.... Patches welcome | 19:33 |
| jam | And if you are going to do it, I suppose a README is in order, too | 19:33 |
| dato | heh. well, it was just a suggestion :) | 19:34 |
| ubotu | New bug: #176184 in bzr-eclipse "check in the whole branch and not just the current selected file" [Medium,Confirmed] https://launchpad.net/bugs/176184 | 19:35 |
| Daviey | jam: regarding the earlier problem - if i rm a "-" from the path it works fine, but with it there no mail? any ideas | 19:37 |
| jam | "with it there no mail" ? | 19:38 |
| jam | Why is there a '-' in the path? | 19:38 |
| jam | Anyway, something sounds fishy.. Daviey, can you send me your .conf files? | 19:38 |
| Daviey | jam: v. basic conf files | 19:39 |
| jam | well, I can say that *I* haven't had any problems with bzr-email not sending in directories I have configured it to send from | 19:40 |
| Daviey | pm them? | 19:40 |
| jam | So I'm trying to see what the difference would be | 19:40 |
| jam | Daviey: pm or email | 19:40 |
| Qhestion | hi. i can import bazaar classes via for example: "from bzrlib import workingtree". there is a file named workingtree.py. but how does Bazaar do this? i mean, i thought workingtree.py means i have to write "from bzrlib.workingtree impor workingtree" ?? | 19:41 |
| Qhestion | i am trying to do the same in my program, but i just dont get it to work. how does bazaar do this? | 19:42 |
| jam | Qhestion: "from bzrlib import workingtree" imports the "workingtree" module | 19:42 |
| jam | to get the class you need either | 19:42 |
| jam | "from bzrlib import workingtree; workingtree.WorkingTree" | 19:43 |
| jam | or | 19:43 |
| jam | "from bzrlib.workingtree import WorkingTree" | 19:43 |
| Qhestion | the thing is, "from bzrlib import workingtree" works. | 19:43 |
| jam | (note that we capitalize classes, but tend to use lowercase for modules) | 19:43 |
| Qhestion | dont know how, it just works | 19:43 |
| jam | Qhestion: you have a valid module | 19:43 |
| Qhestion | ? | 19:43 |
| jam | python -c "from bzrlib import workingtree; print workingtree" | 19:43 |
| jam | <module 'bzrlib.workingtree' from 'bzrlib/workingtree.py'> | 19:43 |
| jam | python -c "from bzrlib import workingtree; print workingtree.WorkingTree" | 19:44 |
| jam | <class 'bzrlib.workingtree.WorkingTree'> | 19:44 |
| Qhestion | <module 'bzrlib.workingtree' from 'C:\Python25\lib\site-packages\bzrlib\workingt | 19:44 |
| Qhestion | ree.pyc'> | 19:44 |
| jam | Qhestion: right, that is a *module* not a class | 19:44 |
| Qhestion | (output for first command) | 19:44 |
| Qhestion | oh wait | 19:44 |
| Qhestion | i am stupid | 19:44 |
| radix | Qhestion: there is a class named WorkingTree inside the bzrlib.workingtree module | 19:45 |
| Qhestion | i should have read the next line more carefully | 19:45 |
| Qhestion | all my fault | 19:45 |
| Qhestion | 1 from bzrlib import workingtree 2 wt = workingtree.WorkingTree.open('/home/jebw/bzrtest') | 19:45 |
| Qhestion | http://bazaar-vcs.org/Integrating_with_Bazaar | 19:45 |
| radix | hooray documentation :) | 19:45 |
| Qhestion | i think i overlooked the "workingtree." part... | 19:45 |
| Qhestion | i think i just saw what i WANTED to see | 19:45 |
| Qhestion | hmm.. anyway, i think pythons module system is crap. i think it would be better if all the modules in a package would get accumulated and... one big module | 19:47 |
| jam | Qhestion: when you get used to it... the namespaces are *wonderful* | 19:47 |
| Qhestion | nothing against namespaces | 19:47 |
| jam | Something I actually miss a lot with C/C++ | 19:47 |
| Qhestion | but i dont like 5kLine source files... | 19:47 |
| Qhestion | anyway. hmm i remember reading your name somewhere... | 19:48 |
| Qhestion | radix, jam, any chance you are also active in the storm channels? | 19:49 |
| Qhestion | i think i read some chatlog on that website... | 19:49 |
| jam | Qhestion: radix might be, I'm not | 19:49 |
| jam | Qhestion: you might be thinking jamesh | 19:50 |
| radix | Qhestion: yeah, that's me :) | 19:50 |
| jam | radix: you work on Landscape, and thus storm, right? | 19:51 |
| radix | jam: yep. | 19:51 |
| jam | twisted little man | 19:51 |
| jam | :) | 19:51 |
| jam | Well, you aren't *that* little | 19:51 |
| jam | but shorter than I | 19:51 |
| jam | I think | 19:52 |
| radix | Qhestion: You can put a bunch of names in one place if you want to, even without having 5klines of source file. Python's module system isn't crap for the reason you think it is, anyway :) | 19:52 |
| radix | jam: Yeah, and Twisted ;-) | 19:52 |
| radix | jam: probably :-) | 19:52 |
| Qhestion | radix: well, this is just what you think after using python for half a year. i think i still have to learn a lot... | 19:52 |
| Qhestion | anyway, it is MUCH better than java | 19:52 |
| Qhestion | although until yesterday i said otherwise | 19:53 |
| radix | heh :) | 19:53 |
| Qhestion | i used java in a contest | 19:53 |
| Qhestion | yesterday. | 19:53 |
| Qhestion | crap. | 19:53 |
| radix | sorry. :) | 19:53 |
| Qhestion | ? | 19:54 |
| Daviey | jam: hmmpf, i've upgraded, same problem! :( | 19:57 |
| jam | Daviey: care to do some manual debugging? | 20:00 |
| jam | You can look at bzrlib/config.py | 20:00 |
| jam | Around line 506 | 20:00 |
| Daviey | will do | 20:00 |
| jam | there is "_get_matching_sections" | 20:00 |
| jam | which is the part that should match the path for the branch | 20:00 |
| jam | with the config entry | 20:00 |
| Daviey | I guess: /usr/share/pycentral/bzr/site-packages/bzrlib/config.py | 20:01 |
| jam | Daviey: sounds correct to me | 20:01 |
| Daviey | def _get_matching_sections(self): -- nothing looks bad | 20:06 |
| dennda | hey there | 20:08 |
| dennda | I have a branch 'experimental' from 'trunk'. I did bzr merge $trunkurl and it says my experimental branch is up to revision 63. trunk, however, is 70. what's the problem there? how can I fix it? | 20:09 |
| Peng | dennda: Look at bzr log. Is everything there? | 20:10 |
| dennda | https://code.launchpad.net/memaker/ <-- the projects branches | 20:10 |
| jam | dennda: 'bzr merge' will create a new revision at the tip. | 20:10 |
| jam | Which is likely to be '64' | 20:10 |
| Peng | dennda: Did you commit after the merge? | 20:10 |
| jam | "bzr pull" will pull over and change your history | 20:10 |
| jam | to look like the source branch | 20:11 |
| lifeless | moin | 20:11 |
| jam | which will make it "70" | 20:11 |
| jam | morning lifeless, I thought you were on vacation | 20:11 |
| jam | just can't stay away, can you? | 20:11 |
| Peng | Will it merge when it's not necessary? | 20:11 |
| lifeless | jam: I am :) | 20:11 |
| dennda | Peng: bzr log shows me 63 as latest revno | 20:11 |
| Peng | dennda: Did you commit after the merge? | 20:11 |
| lifeless | jam: I'm grabbing a drink an dlogging into WoW :). Level 64 now. | 20:11 |
| Peng | dennda: What is revision 63? | 20:11 |
| jam | lifeless: congrats | 20:11 |
| Peng | dennda: Not a merge? | 20:11 |
| dennda | yes | 20:12 |
| jam | lifeless: enjoying outland? | 20:12 |
| dennda | yes, i committed | 20:12 |
| dennda | to 64 | 20:12 |
| dennda | just now | 20:12 |
| Peng | dennda: You committed the merge? | 20:12 |
| Peng | dennda: Then everything's there. | 20:12 |
| Peng | dennda: It's all listed under revision 64. | 20:12 |
| dennda | ok | 20:13 |
| Peng | (That is, the merged revisions are all listed under revision 64.) | 20:13 |
| dennda | so rev numbers don't have to be identical? | 20:13 |
| Peng | They do not. | 20:13 |
| dennda | ok | 20:13 |
| dennda | thank you | 20:13 |
| Peng | (FWIW, bzr internally uses much longer, less readable IDs. The simple numbers are just for user convenience.) | 20:14 |
| lifeless | jam: yah, starting zangarmarsh today, finished hfp last night. I'm about 70% to 65 :). | 20:15 |
| lifeless | ANd with that, ciao :) | 20:15 |
| Peng | Me too. | 20:15 |
| * Peng wanders off. | 20:15 | |
| dennda | bye | 20:15 |
| jam | everyone is leaving me | 20:23 |
| jam | lifeless: I forgot to ask, what class is your main? (obviously it can wait :) | 20:30 |
| ubotu | New bug: #176191 in bzr-eclipse "Change "Username" field to "Email"." [Undecided,New] https://launchpad.net/bugs/176191 | 20:36 |
| === asak__ is now known as asak | ||
| newz2000 | I have a web application I work on with someone else. What's the best way for me to publish my application to the webserver from my development workstation? | 21:02 |
| newz2000 | My first attempt was to bzr push it, but that just copied the trunk/.bzr stuff. | 21:04 |
| newz2000 | Is rsync the right tool, or is there a way to do it with bzr? | 21:04 |
| jam | newz2000: install my plugin | 21:05 |
| Odd_Bloke | newz2000: Check out the push-and-update plugin. | 21:05 |
| jam | https://launchpad.net/bzr-push-and-update | 21:05 |
| jam | after you do "bzr checkout" on the server | 21:05 |
| jam | from then on when you do | 21:05 |
| jam | bzr push | 21:05 |
| jam | it should make sure the target is updated | 21:05 |
| jam | Odd to have you mention this about 2 hours after I finally got around to cleaning up that plugin. | 21:05 |
| newz2000 | ok. Now, the one problem is that the server can't do a bzr checkout, because it can't see the place where I normally push to. | 21:05 |
| newz2000 | well, I could push twice I guess | 21:06 |
| jam | newz2000: once you have done a "bzr push" | 21:06 |
| jam | then you do | 21:06 |
| jam | ssh server | 21:06 |
| jam | cd path | 21:06 |
| jam | bzr checkout . | 21:06 |
| newz2000 | oh, interesting | 21:06 |
| jam | newz2000: from then on, 'bzr push' should do the "ssh server bzr update path" for you | 21:06 |
| jam | (with the plugin installed) | 21:06 |
| newz2000 | so where do I install the plugin, on my local pc? | 21:06 |
| jam | newz2000: correct | 21:07 |
| jam | newz2000: are you on linux? | 21:07 |
| jam | cd ~/.bazaar/plugins | 21:07 |
| jam | bzr checkout lp://bzr-push-and-update push_and_update | 21:07 |
| jam | bzr checkout lp:bzr-push-and-update push_and_update | 21:07 |
| jam | sorry, I get used to typing 2 // | 21:07 |
| jam | you either need 0 or 3 | 21:07 |
| newz2000 | fascinating. So I'm working on a tmp checkout... if I kill this and later push to the same location from another checkout, does it remember to update the server? | 21:09 |
| jam | newz2000: it just hooks into the "bzr push" code. And if the target has a working tree | 21:09 |
| jam | it will update it | 21:09 |
| jam | So by doing "bzr checkout" you tell my plugin that you want to keep it updated | 21:10 |
| newz2000 | cool. Giving it a shot now. | 21:10 |
| newz2000 | ok. Everything seems to have worked, but I won't know until I have some code to change. :-) | 21:15 |
| newz2000 | thanks jam. Your my hero. If you're in IA between xmas and nye you can come to my hackfest. | 21:15 |
| jam | newz2000: it should say: running command "ssh ..." | 21:16 |
| jam | If it says that, then I think it is working | 21:16 |
| jam | newz2000: what hackfest? | 21:16 |
| jam | I will be in IA, though I may not be close to Des Moines | 21:16 |
| newz2000 | I'm going to be nostalgic and try to have a programming party at my house | 21:16 |
| newz2000 | like the good ol' days. Coding for sheer pleasure | 21:17 |
| newz2000 | your plugin worked. It ran ssh. | 21:19 |
| igc | morning all | 21:21 |
| devinus | how do i set up ignore options for bzr? | 21:24 |
| jam | devinus: "bzr ignore PATTERN" ? | 21:24 |
| jam | or what do you mean by "options" ? | 21:24 |
| devinus | it takes globs? | 21:24 |
| devinus | i want to ignore all *.pyc | 21:24 |
| Odd_Bloke | devinus: bzr ignore "*.pyc" | 21:24 |
| Odd_Bloke | Note the quotes. :) | 21:25 |
| devinus | oh wow | 21:25 |
| devinus | i see i could of just done | 21:25 |
| devinus | bzr help ignore too | 21:25 |
| devinus | thanks! | 21:25 |
| jam | devinus: I thought .pyc was in our default global ignores... | 21:25 |
| jam | Anyway you may want | 21:25 |
| jam | bzr ignore "*.py[co]" | 21:25 |
| jam | Since you really want both to be ignored | 21:25 |
| jam | Though you may not run "python -O" very often | 21:26 |
| SmileyChris | i'm always getting the error "bzr: warning: unsupported locale setting (...)" | 21:26 |
| Odd_Bloke | SmileyChris: Are you on Windows or GNU/Linux? | 21:27 |
| SmileyChris | Odd_Bloke: sorry, clarification - always getting when using sftp/bzr+ssh | 21:27 |
| SmileyChris | Odd_Bloke: linux | 21:27 |
| jam | SmileyChris: sounds like LANG on your other side is set in a funny way | 21:27 |
| jam | LANG=C | 21:27 |
| jam | or LANG=en.UTF-8 should be decent | 21:28 |
| jam | I don't know why you would get it when using sftp | 21:28 |
| jam | bzr+ssh is spawning a remote process | 21:28 |
| jam | which could certainly be having troubles with the LANG on the remote side | 21:28 |
| SmileyChris | jam: seems like it can't pick up en_NZ.UTF-8 | 21:28 |
| jam | SmileyChris: well, that should be valid, but you may need to have the right locale files installed | 21:28 |
| SmileyChris | jam: on the remote side? | 21:29 |
| jam | SmileyChris: if it is only happening when you use bzr+ssh then I think it is the remote side which has the problem | 21:29 |
| jam | can you just do | 21:29 |
| jam | ssh host locale | 21:29 |
| jam | ? | 21:29 |
| SmileyChris | from local or remote? | 21:29 |
| jam | ssh remote locale | 21:30 |
| SmileyChris | ah :) | 21:30 |
| jam | If running "bzr rocks" doesn't give you a locale warning | 21:30 |
| jam | then it is the bazaar on the remote machine which is giving the warning | 21:30 |
| SmileyChris | it's the remote giving the warning | 21:30 |
| SmileyChris | just tested | 21:30 |
| SmileyChris | jam: you want the output of locale? | 21:31 |
| igc | poolie: can I please tweak 1.0 with abentley's changes to 'avanced merging'? | 21:31 |
| jam | SmileyChris: I don't specifically need it, but I'm just trying to help you track down the problem | 21:31 |
| jam | it sounds like the *remote* machine doesn't have the lang set | 21:31 |
| jam | properly | 21:31 |
| jam | interesting | 21:31 |
| jam | if I do "ssh host locale" | 21:31 |
| jam | I get a different result than | 21:31 |
| jam | ssh host <enter> locale | 21:32 |
| jam | is "ssh host COMMAND" passing through the local LANG? | 21:32 |
| SmileyChris | jam: it seems to be using my local $LANG setting | 21:32 |
| SmileyChris | running locale.getpreferredencoding() on remote python raises error | 21:33 |
| SmileyChris | (local is fine) | 21:33 |
| SmileyChris | this is really only a minor annoyance - it's only a warning (and falling back to use ascii instead of unicode), but still ;) | 21:34 |
| jam | SmileyChris: you might try doing something with SendEnv in ~/.ssh/config | 21:35 |
| jam | but I haven't figured out why it would be triggering yet | 21:35 |
| SmileyChris | jam: is there just some way to make my en_NZ locale work on remote? :P | 21:36 |
| jam | SmileyChris: well, you could just install the same package | 21:36 |
| jam | I see a "language-pack-en-base" | 21:37 |
| jam | But I don't know if that installs en_NZ | 21:37 |
| jam | I'm guessing it does, since it seems to exist here | 21:38 |
| jam | and I don't have much extra installed | 21:38 |
| SmileyChris | jam: holy moly that's a lot of dependencies though | 21:39 |
| SmileyChris | bah | 21:39 |
| SmileyChris | maybe i'll just live with the warning | 21:39 |
| SmileyChris | wants to install firefox and open office on the server | 21:39 |
| jam | A lot of dependencies for "language-pack-en-base" ? | 21:40 |
| jam | weird | 21:40 |
| jam | Let me check something | 21:40 |
| jam | dang | 21:41 |
| jam | % dpkg -S /var/lib/locales/supported.d/en | 21:41 |
| jam | language-pack-en-base: /var/lib/locales/supported.d/en | 21:41 |
| jam | I'm guessing it provides the language translations for things like openoffice and firefox | 21:42 |
| jam | but it seems like it should be more of: | 21:42 |
| jam | If program X is installed, provide the language pack for it | 21:42 |
| jam | Not "when providing *any* language support, install all programs which might use it." | 21:43 |
| Odd_Bloke | SmileyChris: Are you using 'apt-get' or 'aptitude'? If the latter, it may be trying to install things on which it does not depend... | 21:43 |
| Odd_Bloke | Assuming you're using a Debian-based system at all. :p | 21:43 |
| radix | I thought you just had to build the en_NZ locale, not install the language-pack. | 21:43 |
| jam | recommends versus depends? | 21:44 |
| jam | radix: well my /var/lib/locales/supported.d/en has en_NZ | 21:44 |
| jam | and I don't see a separate package for it | 21:44 |
| SmileyChris | Odd_Bloke: i was using latter... (ubuntu) | 21:44 |
| radix | lthough, yeah, language-pack-en-base does not depend on firefox or openoffice or anything like that, on my system. | 21:44 |
| jam | anyone better at parsing the output of "apt-cache showpkg" ? | 21:45 |
| Odd_Bloke | SmileyChris: http://packages.ubuntu.com/gutsy/translations/language-pack-en-base suggests that it _recommends_ language-support-en, which then depends on the Firefox and OO stuff. | 21:46 |
| radix | jam: uh, yeah, if you're using showpkg you're probably looking at *Reverse* Depends. | 21:46 |
| Odd_Bloke | So I suggest trying again with 'apt-get'. :) | 21:46 |
| jam | http://rafb.net/p/cAOXar16.html | 21:46 |
| SmileyChris | Odd_Bloke: ah... | 21:46 |
| jam | Reverse Depens | 21:47 |
| jam | Depends, seems to list -pack-kde-en and -pack-gnome-en | 21:47 |
| SmileyChris | Odd_Bloke: it's a depends on mine | 21:47 |
| radix | jam: yeah, I guess that's what it looks like here, but nowhere do I see dependencies on actual software like firefox or openoffice or any gnome apps | 21:48 |
| bccomm | is en_NZ checked if you do dpkg-reconfigure locales ? | 21:50 |
| SmileyChris | Odd_Bloke: I was wrong. It was the language-support-en *recommends* causing the bloat :P | 22:02 |
| SmileyChris | all working now, thanks for your help guys | 22:02 |
| SmileyChris | (specially since it wasn't really a bzr problem) | 22:02 |
| igc | poolie: those doc tweaks sent to pqm now | 22:12 |
| igc | (for 1.0, not bzr.dev) | 22:12 |
| * igc breakfast | 22:27 | |
| igc | poolie: 3105 needs to be cherrypicked from bzr.dev into 1.0 | 23:31 |
| igc | it's definitely not there yet | 23:31 |
| igc | just confirming you're going to do that | 23:32 |
| poolie_ | igc, thanks, doing that now | 23:48 |
| igc | great. thanks | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!