| jelmer | maxb: welcome to ~bzr :-) | 00:23 |
|---|---|---|
| maxb | Thanks :-) | 00:24 |
| maxb | I vaguely recall some "how to package for the PPA" documentation somewhere? | 00:24 |
| lifeless | oh hai there | 00:26 |
| maxb | ah, Martin has sent me the link | 00:44 |
| poolie | hi maxb | 01:05 |
| maxb | hi | 01:05 |
| poolie | i might have had the wrong name about /staging | 01:05 |
| poolie | or perhaps we only talked of it and didn't actually create it yet | 01:05 |
| maxb | I guess that gary was intending to use the beta ppa as a staging area just because it already exists, and isn't currently occupied by later versions | 01:06 |
| poolie | it was 2.1-proposed i was thinking of | 01:06 |
| poolie | so how about if we create a 2.2-proposed in ~bzr? | 01:06 |
| maxb | well, I'd be in favour of a non-versioned name, either proposed or staging | 01:06 |
| poolie | ok, so ~bzr/proposed? | 01:06 |
| maxb | sounds good to me | 01:06 |
| poolie | that's roughly consistent with the meaning of proposed in ubuntu, aiui | 01:07 |
| poolie | (it may already be checked for consistency but it's close) | 01:07 |
| maxb | close enough, yes | 01:07 |
| poolie | ok i'll create that | 01:09 |
| maxb | Do you know if there is any standard regarding packaging branches for the plugins? | 01:10 |
| poolie | i don't think it's entirely standardized, but it would be good to make it so | 01:11 |
| poolie | and/or document what is done now, into that document | 01:11 |
| poolie | also we should look at moving the packaging branch names on lp into the package branch namespace, ie | 01:11 |
| poolie | lp:ubuntu/hardy/bzr/bzr-ppa | 01:11 |
| maxb | That would make them more obvious, yes | 01:12 |
| poolie | biab | 01:15 |
| * maxb sets a dependency of bzr/proposed -> bzr/ppa | 01:16 | |
| lifeless | maxb: are you aware of add-apt-archive (IIRC) - adds dependent ppas automatically | 01:43 |
| poolie | i didn't know it did that | 01:51 |
| lifeless | it should, if it doesn't I have a version I wrote that does | 01:51 |
| poolie | maxb in some ways we shouldn't have that dependency | 01:51 |
| poolie | we'll get better testing without it | 01:52 |
| poolie | if we first copy everything into the proposed ppa | 01:52 |
| lifeless | anyhow, for clrity, I'm neither for or against | 01:52 |
| lifeless | just adding data to the mix | 01:52 |
| maxb | lifeless: Interesting data point, but we can't rely on everyone adding the PPA doing so via add-apt-archive | 02:09 |
| poolie | i agree, but what conclusion do you draw from that? | 02:10 |
| maxb | option 1 is to build our own subvertpy and dulwich. option 2 is to have jelmer or people he adds to ~subvertpy and ~dulwich build the packages in those PPAs, and copy them into the ~bzr ppas | 02:12 |
| maxb | based on jelmer's response, we pick option 1 | 02:13 |
| maxb | Oh! | 02:18 |
| maxb | I've just realized the conversation was about * maxb sets a dependency of bzr/proposed -> bzr/ppa | 02:18 |
| maxb | Whereas I was interpreting it as being a response to my email | 02:19 |
| maxb | It seems that the lucid version of add-apt-repository does *not* chase PPA build-dependency links | 02:21 |
| poolie | no, it doesn't | 02:21 |
| maxb | the changelog of the maverick version doesn't mention anything like that either | 02:23 |
| poolie | i don't think it should | 02:25 |
| poolie | and there's probably no easy way for it to do this | 02:25 |
| poolie | on the whole i think we should copy those packages into our ppa | 02:25 |
| poolie | i don't think add-apt-archive exists on old ubuntus | 02:25 |
| poolie | and people are likely to have the habit of just configuring things manually | 02:26 |
| poolie | which will give them dependency errors | 02:26 |
| poolie | it may also make it a little easier to check consistency when we promote things from proposed to released | 02:26 |
| poolie | we might want a dependency on testtools and subunit too | 02:26 |
| poolie | i wonder if you can script the copying through an api? | 02:26 |
| poolie | would be nice | 02:27 |
| maxb | poolie: Yes, you can. I have a script which I use to promote completed builds from mercurial-ppa/staging-foo to mercurial-ppa/foo | 02:31 |
| * maxb removes dependency of bzr/proposed -> bzr/ppa again, since I think I'm convinced that's reasonable | 02:47 | |
| poolie | ok updating the backport branches now | 02:49 |
| poolie | hm so our packaging-dapper, at least, is not related to the current maverick packaging branch... | 02:50 |
| * maxb has copied python-testtools into bzr/proposed | 02:52 | |
| maxb | (for hardy - karmic) | 02:53 |
| maxb | Is dapper still worth the effort? | 02:53 |
| poolie | maybe not | 03:20 |
| poolie | it uses a different python packaging system so it's going to be a bit annoying | 03:20 |
| poolie | i'm confused anyhow, because dapper is already EOL | 03:22 |
| maxb | poolie: dapper is EOL on the desktop, but not on the server until the release of Nefarious Nundu or whatever | 03:24 |
| poolie | natty narwhal fwiw | 03:25 |
| poolie | ok, so it may still be supported for server security releases, but perhaps it's not worth doing further non-security updates | 03:27 |
| mkanat | All righty, I do believe that it is loggerhead time. | 03:29 |
| poolie | spm, meet mkanat | 03:29 |
| spm | heh | 03:30 |
| spm | heya max! how goes? | 03:30 |
| mkanat | spm: Heya! :-) | 03:30 |
| mkanat | spm: I seem to have consistently had difficulty getting things simply by requesting them in bugs. | 03:30 |
| poolie | getting things? | 03:30 |
| poolie | oh asking for debug info | 03:30 |
| mkanat | poolie: Data, logs, information. | 03:30 |
| mkanat | Yeah. | 03:31 |
| poolie | spm may feel he has difficulty getting fixes by requesting them in bugs :) | 03:31 |
| mkanat | It seems to me that asking in the bug system ought to be the Right Way.... | 03:31 |
| spm | mkanat: the logs you were after in the most recent? that'd be a pure timing problem. we've all been in Madrid for the past week - I'm only back at work today myself | 03:31 |
| mkanat | spm: Yeah. Okay. | 03:31 |
| mkanat | spm: I just want to make sure that the LOSAs are actually seeing my requests when I make them. | 03:31 |
| mkanat | spm: In the past I had to ask mwhudson for stuff. | 03:31 |
| poolie | i'd like to know that you're unblocked, that you're working on something pretty useful, and that the improvements are actually getting landed into production and data on their success or failure loops back | 03:32 |
| spm | but also, bugs aren't wonderful *for us* as a "pls do X" thing. Mainly as we're automatically subscribed to so many across multiple projects; that the sheer volume overwhelms. tehre's no way we can easily filter the noise from real stuff. | 03:32 |
| mkanat | poolie: Well, I have other things to work on, on loggerhead, while I wait for that data. | 03:32 |
| mkanat | spm: Perhaps Launchpad needs a Requests system. | 03:33 |
| poolie | right, i don't mean to to imply you're blocked altogether | 03:33 |
| poolie | use Answers | 03:33 |
| poolie | assigned to canonical-losas | 03:33 |
| mkanat | poolie: Okay, if that works, I can do that. | 03:33 |
| spm | that works | 03:33 |
| poolie | maxb, since jaunty EOLs in October perhaps we shouldn't update it | 03:33 |
| * poolie sees maxb's mail | 03:34 | |
| maxb | poolie: I suggest we not put particular effort into it if it would be specially difficult, but if it's just one more time around a loop in a script, let's do it | 03:34 |
| poolie | agree | 03:35 |
| spm | mkanat: part is you're (personally) in a kinda funky space being an external party. So yeah, answers will work per poolie's suggestion; or 'ping losa' in here to get stuff more urgently; or email losas@c.c as an alt/headsup that you've asked for something. | 03:36 |
| mkanat | spm: Okay. | 03:37 |
| spm | poolie: tho I believe you may have access to the logs on devpad as well? certainly they should be synced there. | 03:38 |
| poolie | the loggerhead logs | 03:38 |
| poolie | oh ok | 03:38 |
| * poolie looks | 03:39 | |
| === mordred_ is now known as mtaylor | ||
| SpookyET | Hello. I'm looking for the command that generates a graph like git log --graph. | 03:51 |
| rubbs | SpookyET: IIRC there is no command line grapher, you could look at qlog but you'd need qbzr installed. | 03:56 |
| rubbs | I could be wrong though | 03:56 |
| SpookyET | rubbs: qbzr is a pain to compile on mac. | 03:57 |
| rubbs | oh, yes I could see that | 03:57 |
| rubbs | is there no installer for bzr explorer for the mac? (sorry i have only tried windows and linux) | 03:57 |
| SpookyET | rubbs: To clarify, the dependencies are a pain. I remember trying the HG version, but I don't think it's called qHG. There is, but it looks alien on Mac and not that stable. | 03:58 |
| SpookyET | CuteHG. Compiling pyqt, qt4.... it's a pain to get right. | 04:00 |
| poolie | rubbs: i thought it was included in the bzr installer? imbw | 04:03 |
| poolie | maxb, hardy package sent to the ppa | 04:04 |
| poolie | i can never decide if it's less trouble to build locally and faff about with chroots, or to send it straight to the ppa and wonder what will eventually happen | 04:04 |
| mkanat | jam: There's no 0.3 branch of meliae...do I just pull from trunk to get 0.3 from bzr? | 04:04 |
| poolie | in this case i tried the second, and it was rejected :/ | 04:05 |
| poolie | due to being in quilt format | 04:05 |
| SpookyET | I would like to see one more workflow added to bzr, branching inside the same directory like git/hg. Yeah, I know you can checkout and switch like SVN, but that's not the same thing. | 04:29 |
| mkanat | SpookyET: I think that's a design decision difference. | 04:48 |
| mkanat | SpookyET: bzr has repos, instead. | 04:48 |
| SpookyET | mkanat: The unit of measure is the repo in git/hg. The unit of measure is the branch in bzr. Shared-repos is for space saving, the branches are still separated by physical folders. | 04:49 |
| mkanat | SpookyET: Right, but the effect is the same, it's just a different layout. | 04:49 |
| mkanat | SpookyET: Perhaps what you want is shelves, which exist. | 04:49 |
| SpookyET | mkanat: No quite if have to take paths into account. | 04:50 |
| lifeless | so | 04:51 |
| mkanat | Sigh. Fedora still ships a debug python. I'm going to have to run Ubuntu in a VM to debug this loggerhead memory problem. | 04:51 |
| lifeless | lets shortcut this | 04:51 |
| lifeless | we're adding in-workspace branches as an optional core feature eventually | 04:51 |
| lifeless | there are already plugins that offer this | 04:51 |
| mkanat | Oh, okay. | 04:51 |
| lifeless | and that said, you shouldn't need to take paths into account | 04:51 |
| SpookyET | mkanat: Why not compile a python in your home dir? | 04:52 |
| lifeless | things like 'switch' look in .. appropriately anyway | 04:52 |
| mkanat | SpookyET: It will take me just as much time to install Ubuntu as it will for me to compile my own python in a custom location and install every module I need to run both loggerhead and meliae. | 04:52 |
| poolie | mkanat: do you know of vm-builder? | 04:54 |
| poolie | it's quite nice | 04:54 |
| mkanat | poolie: I don't, but the KVM tools in Fedora work really well. | 04:54 |
| * mkanat reads up on vm-builder, though. | 04:55 | |
| SpookyET | lifeless: Think configuration files, virtual hosts.... It's much easier to change the contents of the same folder to test a feature than to configuration files for apps and servers. | 04:59 |
| mkanat | SpookyET: I think that shelves will do what you want now. | 05:00 |
| mkanat | SpookyET: But I've never used them, so I could be wrong. | 05:00 |
| SpookyET | mkanat Shelving is for other things. Let's say you did some changes. But, now you need to fix a bug. You shelve your changes. Fix the bug, commit. Unshelve your changes. It's for a small things. Using shelves as branches is not advisable. | 05:02 |
| lifeless | SpookyET: sure. I know some folk find switch just fine for that with branches elsewhere | 05:05 |
| lifeless | SpookyET: like I say a) we're going to do it and b) what we have is the basis for it anyhow | 05:05 |
| SpookyET | lifeless: I believe you. I understood. | 05:05 |
| lifeless | jelmer is a key person doing this stuff | 05:06 |
| lifeless | if you want to help out | 05:06 |
| SpookyET | Cool | 05:06 |
| === mwhudson_ is now known as mwhudson | ||
| === oubiwann-away is now known as oubiwann | ||
| poolie | maxb: can you tell me where that ppa-copy script lives | 05:35 |
| SpookyET | Good night. | 05:46 |
| poolie | jelmer (if any) is bzr-git actually in a ppa atm? | 05:51 |
| poolie | nm, it's in ~bzr of course, i just misread it | 05:53 |
| mkanat | spm: Also, can you tell me whether or not the system was swapping at the time of the hang? | 05:56 |
| spm | mkanat: no it wasn't. it was purty much bsns as usual; ~ 1Gb RSS in the process; everything *looked* fine; just wasn't working. :-/ | 05:57 |
| mkanat | spm: Okay, good to know that we have multiple bugs. | 05:58 |
| mkanat | Before, I kept getting various different descriptions of the same bug. :-) | 05:58 |
| spm | :-) | 05:58 |
| mkanat | Hahaha, I can't debug this memory leak in my VM, because Firefox gets too big. | 05:59 |
| lifeless | \o/ | 05:59 |
| poolie | biab | 06:18 |
| poolie | hi spiv, what's new with you? | 06:55 |
| spiv | Catching up on old TODOs, mainly. I started looking at https://bugs.edge.launchpad.net/bzr/+bug/593560, because its tagged UDD, but found the immediate thing to do (disable accel trees by default) had actually already been done for another bug. | 06:58 |
| ubot5 | Launchpad bug 593560 in Bazaar "Slow performance for many operations on the gcc code import branches (affected: 1, heat: 3)" [High,Confirmed] | 06:58 |
| poolie | mm, one of those bugs where it's likely to stay kinda-open | 06:59 |
| poolie | perhaps we should either reprofile and identify the next biggest thing, or say that fixing hardlinking fixed it | 06:59 |
| poolie | i've been updating ppas | 07:00 |
| poolie | it's a bit annoying | 07:00 |
| poolie | many possible snags | 07:00 |
| spiv | I merged up 2.0->2.1->2.2->trunk, was a bit surprised at how many fixes hadn't made it into trunk yet. | 07:01 |
| poolie | thanks for that | 07:01 |
| spiv | I kinda wish we could instruct PQM "merge this to 2.x, then merge up to 2.x+1, etc, then trunk" | 07:01 |
| spiv | Because as a human I have to wait for PQM to commit the merge to 2.x before I can start the next step. | 07:02 |
| poolie | mm | 07:03 |
| spiv | But NEWS conflicts and the difficulty in improving PQM would make that annoying to do. | 07:03 |
| spiv | (And the news_merge plugin often fails to help with cross-release merges) | 07:04 |
| poolie | well, it's not written anywhere that we absolutely have to use pqm | 07:05 |
| poolie | but perhaps the pragmatic thing is to just make a bot that merges up every day, or every week, and complains if they fail? | 07:05 |
| poolie | lp uses that | 07:05 |
| poolie | s/merges/asks pqm to merge | 07:05 |
| spiv | I understood :) | 07:05 |
| spiv | That would probably be a good start. Hopefully it would show my concerns about NEWS to be too pessimistic. I guess the main trouble is when there's a new release on one of the series. | 07:07 |
| poolie | we could split out separate news per series | 07:08 |
| poolie | then it'll just be an update into NEWS-2.2 | 07:08 |
| * poolie wonders if it would be too crazy to have a bzr builddeb option that directly uploads into a ppa | 07:08 | |
| poolie | or maybe there is one | 07:08 |
| spiv | Yes, a more machine friendly structure would help a lot. (And ease implementing policies like "when merging from earlier series, copy new NEWS entries from that series into the latest release of this series") | 07:09 |
| vila | hi all ! | 07:10 |
| spiv | vila: hey! | 07:11 |
| poolie | spiv i think i'd rather just have the release say "this includes all changes from bzr 2.0.8, 2.1.x, 2.2.y, etc" | 07:11 |
| poolie | but, either way | 07:11 |
| poolie | hi vila, | 07:11 |
| vila | spiv: hey ! Nice patch for parallel=fork ! I haven't replied yet but while my earlier attempt was different, I think your patch is simpler even if it doesn't address corner cases unlikely to be encountered, | 07:12 |
| spiv | vila: I was about to ask if you'd seen it | 07:12 |
| poolie | how was your holiday? | 07:12 |
| vila | As long as the CPU is/are pegged, I think simplicity beats purity :) | 07:12 |
| vila | poolie: just... great | 07:12 |
| spiv | vila: there's an interesting side effect too — I don't seem to get "can't start new thread" problems with the new partitioning | 07:13 |
| vila | spiv: luck | 07:13 |
| vila | spiv: it also depends on how many processes you use | 07:13 |
| spiv | vila: possibly because the more even sharing of threads across processes helps stay under the limit we were hitting | 07:13 |
| vila | spiv: yes, and spreading the leaking tests | 07:14 |
| spiv | (well, "more even" assuming thread-leaking tests occur in clumps, as is the case atm) | 07:14 |
| vila | spiv: yup, but I still like to resubmit my fixes on the subject :-D | 07:15 |
| spiv | Please do :) | 07:16 |
| spiv | This is just avoiding the symptoms a little better, not fixing the problems that cause them :) | 07:16 |
| vila | spiv: indeed ! And certainly avoiding them more robustly than just using --parallel=fork | 07:17 |
| vila | meh, I meant, just slicing the whole test suite | 07:18 |
| spiv | vila: implement --isolate=fork? ;) | 07:18 |
| lifeless | spiv: from subunit import donealready | 07:18 |
| spiv | lifeless: I know, but there's no CLI glue in the bzr test runner for it :P | 07:19 |
| vila | spiv: how many cores do you use ? (More precisely what does python -c 'from bzrlib import osutils ; print osutils.local_concurrency()' says for your PC ?) | 07:23 |
| spiv | vila: 4 | 07:23 |
| vila | spiv: ok, so any bad balancing is impacting you more than me (8). Quick tests shows that your patch is more effective than the previous version but still leaves a single (or two) process running in the end (instead of 8) | 07:25 |
| vila | spiv: my patch was avoiding that to the cost of forking more processes, so on the overall, I'm not sure it can beat yours for the total elapsed time | 07:26 |
| spiv | I think it's hard to beat my patch if we determine the partitions ahead of time and without any idea of how long each test takes. | 07:27 |
| vila | spiv: anyway, as said above, simplicity wins so I'm very happy you addressed the problem :D | 07:27 |
| spiv | A more dynamic allocation of tests to the subprocesses could do better. | 07:27 |
| vila | spiv: yup, my patch tried to address that by partitioning only some of the tests and as soon as one process ends, started a new one with part of the remaining tests | 07:28 |
| vila | spiv: so, more forks with their associated costs | 07:29 |
| vila | spiv: your patch is not in 2.2 right ? | 07:30 |
| spiv | I don't think so... but see http://pastebin.com/MEbk2TAy ;) | 07:33 |
| spiv | In theory you could dynamically allocate tests without more forks if the subprocesses didn't need to know their list of tests in advance. | 07:34 |
| spiv | But whatever you do to improve it will be more complex than my patch ;) | 07:35 |
| GaryvdM | Hi james_w. | 07:36 |
| GaryvdM | james_w: You said I must speak to you to change the qbzr ubuntu branches to pull from the debian branch and/or the upstream branch. | 07:36 |
| GaryvdM | I would really like to do that. | 07:37 |
| vila | spiv: yup, it wasn't itching enough before your patch, I don't think it will now :) | 07:37 |
| spiv | :) | 07:40 |
| poolie | spiv/lifeless, what do we normally do to upgrade trunk import branches? | 07:41 |
| poolie | create a new import and make that the focus? | 07:41 |
| lifeless | hmm? | 07:41 |
| lifeless | I like to upgrade in place | 07:41 |
| poolie | http://code.edge.launchpad.net/postgresql is all still in 1.19 format | 07:41 |
| lifeless | wheee | 07:41 |
| poolie | doesn't that disrupt other branches stacked on it? | 07:41 |
| lifeless | yes | 07:42 |
| lifeless | but recoverably - they can be upgraded independently (unless they are woefully damaged as per bugs spiv has worked on recently) | 07:42 |
| poolie | they can be upgraded too separately, or we need to ask people to do them separately? | 07:42 |
| lifeless | there's no automatic around those upgrades that I'm aware of | 07:43 |
| lifeless | some folk just make a new import | 07:43 |
| lifeless | largely its been the consumers of the branches choices, so far. | 07:43 |
| * mneptok consumes lifeless and belches erotically | 07:59 | |
| lifeless | mneptok: I don't think that means what you think it means | 08:03 |
| Crovax-31 | Hi, I'm trying to create a bzr repository from a git one | 09:19 |
| Crovax-31 | but I don't find a good way to use git-bzr | 09:20 |
| Crovax-31 | or bzr-git | 09:20 |
| lifeless | jelmer: this ones yours I think :) | 09:20 |
| jelmer | heh | 09:20 |
| jelmer | Crovax-31, what doesn't work exactly when you try bzr-git? | 09:20 |
| Crovax-31 | hum, I used easy_install to get it, and "bzr: ERROR: unknown command "git-import"" | 09:21 |
| jelmer | Crovax-31, easy_install doesn't work for bzr plugins as far as I know | 09:22 |
| Crovax-31 | I tryed to copy the egge in ~/.bazaar/plugins/git | 09:22 |
| jelmer | Crovax-31: can you try putting the branch/directory in ~/.bazaar/plugins/git ? | 09:22 |
| jelmer | eggs don't work for bzr plugins (that's the reason easy_install doesn't work, too) | 09:22 |
| * Crovax-31 is french what do you mean by putting the branch/directory in ~/.bazaar/plugins/git, unzip the last tar.gz? | 09:24 | |
| jelmer | yep | 09:24 |
| Crovax-31 | bzr: ERROR: exceptions.AttributeError: 'InterLocalGitNonGitRepository' object has no attribute 'fetch_refs' | 09:28 |
| Crovax-31 | the plugin seems to be installed ^^ | 09:28 |
| Crovax-31 | thanx | 09:28 |
| jelmer | Crovax-31: Yeah, unfortunately that's a known issue - "bzr branch" should work though, or a more recent revision of bzr-git | 09:29 |
| Crovax-31 | I'm using the lastest release | 09:30 |
| Crovax-31 | ee, how to use bzr branch specifying git for a local repo/folder | 09:30 |
| jelmer | Crovax-31: Just specify the URLs as you usually would | 09:32 |
| Crovax-31 | so if my repo is ./docs I'll put? | 09:33 |
| jelmer | Crovax-31: if your bzr repository is at ./docs, e.g. use "bzr branch git://foo/host ./docs/trunk" | 09:34 |
| Crovax-31 | great, thanx a lot it works | 09:35 |
| === jelmer_ is now known as jelmer | ||
| GaryvdM | poolie: Are you still up? Got some questions about the ppa. | 11:37 |
| metaperl | I am trying to get bazaar 2.1 or greater for unbuntu, but dont see a link here - https://launchpad.net/~bzr/+archive/ppa | 14:18 |
| jelmer | metaperl, that PPA has bzr 2.1 | 14:19 |
| metaperl | jelmer I dont see a link though.... | 14:19 |
| jelmer | metaperl: what sort of link are you looking for? | 14:19 |
| metaperl | I want to download a .deb and install via dpkg | 14:19 |
| maxb | jelmer: I don't suppose you remember why dulwich Build-depends: python-support (>= 0.90) ? | 14:20 |
| metaperl | how would adding something to /etc/sources.list lead to this bzr overriding the one in standard ubuntu? | 14:20 |
| metaperl | oh now i've clikcedon the tech details link | 14:21 |
| maxb | metaperl: The file is /etc/apt/sources.list. apt will use the highest version of a package available across all configured sources | 14:21 |
| jelmer | maxb: Mainly because that's a version of python-support I knew worked. | 14:21 |
| maxb | k | 14:21 |
| metaperl | maxb thanks I didnt know that | 14:21 |
| aj-dneg | i'm using bzr to hack on an svn repository (no branch layout). after some upstream changes have been made i merge them into my local branch with bzr merge and obviously can't push. rebase seems to do nothing even though i have a branch/merge in my history but not on the server. the other option is to merge back in (and lose the individual commits) but i don't want to have to make a separate trunk checkout just to do that. can i do it directly? bzr merge only w | 14:22 |
| aj-dneg | orks on the current folder... | 14:22 |
| aj-dneg | did that all get through ^^? | 14:22 |
| jelmer | aj-dneg: rebase will only rebase your local branch onto new revisions on the server side | 14:22 |
| jelmer | aj-dneg: merge and rebase don't mix very well. perhaps try uncommitting the merge and then rebase ? | 14:23 |
| aj-dneg | i'd rather not undo several revisions | 14:24 |
| aj-dneg | i would be ok to just do a merge, at least my repo keeps the individual commits then | 14:24 |
| aj-dneg | is there some way i can do bzr merge --branch svn://whatever/ . | 14:24 |
| aj-dneg | or do i really have to make my own local branch of svn://whatever/ first | 14:24 |
| jelmer | aj-dneg: You would have to make your own local branch of svn:// first. | 14:25 |
| aj-dneg | so i have two branches, upstream and local? :S | 14:26 |
| maxb | gah. git on hardy lacks the --bare option to init, scuppering the dulwich testsuite | 14:27 |
| jelmer | maxb: I'd ignore the testsuite for hardy in that case | 14:27 |
| jelmer | newer revisions of dulwich no longer depend on git-core | 14:28 |
| maxb | hrm. actually the suite is broken even on karmic | 14:35 |
| maxb | prior to lucid, git init did not take a directory positional argument | 14:36 |
| * maxb shelves temporarily to ponder | 14:37 | |
| === mordred_ is now known as mtaylor | ||
| aj-dneg | is there some way to generate a list of patches, one per-revision in bzr? | 15:38 |
| LeoNerd | I'm not sure I get the question... | 15:49 |
| LeoNerd | You mean like bzr log ? | 15:49 |
| jelmer | aj-dneg: bzr log -p ? | 15:49 |
| aj-dneg | jelmer: that's pretty much it -- thanks :) | 15:53 |
| aj-dneg | jelmer: actually i just found bzr send, even better! | 15:55 |
| thrope | hello - whats the situation with keyword expansion? I would like to have the current revision automatically included in a document like with svn keywords | 16:29 |
| jelmer | thrope, see http://launchpad.net/bzr-keywords | 16:33 |
| fullermd | Unchanged from some time ago; PoC. | 16:33 |
| jelmer | PoC? | 16:33 |
| fullermd | Proof of Concept | 16:33 |
| fullermd | It's not really usable in any practical sense. | 16:33 |
| === deryck is now known as deryck[lunch] | ||
| === Ursinha is now known as Ursinha-lunch | ||
| mars | Hi everyone, I have a question about removing a symlink from a source tree | 17:28 |
| jelmer | hi Maris | 17:28 |
| mars | Hi jelmer | 17:29 |
| mars | the symlink points to ../thefile | 17:29 |
| mars | which is obviously not versioned (it is branch parent directory) | 17:29 |
| mars | whenever I try to run 'bzr rm thesymlink', bzr says "No WorkingTree exists for "file:///home/mars/launchpad/qa-tagger/.bzr/checkout/" | 17:30 |
| mars | file:///home/mars/launchpad/qa-tagger/.bzr/checkout/ is the shared repository full path | 17:30 |
| jelmer | and "bzr root" works as expected, printing the root of your working tree? | 17:31 |
| mars | yes it does | 17:31 |
| jelmer | I think this might be an open bug | 17:32 |
| mars | ok | 17:32 |
| mars | I may try overwriting the symlink, committing, then removing | 17:32 |
| jelmer | is thefile a branch by any chance? | 17:34 |
| mars | no, it is not. It is a regular file. | 17:35 |
| jelmer | mars: you might try removing the file before running "bzr rm" | 17:35 |
| mars | jelmer, I tried that as well, and it did not work. I may have had to use 'rm thelink; bzr rm ../thefile' instead of 'rm thelink; bzr rm thelink' | 17:37 |
| mars | jelmer, I just overwrote the symlink with a plain old file, committed that, then removed it. Works. Thank you for the help. | 17:37 |
| === deryck[lunch] is now known as deryck | ||
| === r0bby is now known as robbyoconnor | ||
| metaperl | excuse the amateur question, but when I want to update a bazaar repo that I downloaded via bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk ... what do I type? | 19:00 |
| dash | 'bzr pull' | 19:00 |
| metaperl | oh ok thanks | 19:00 |
| === Ursinha-lunch is now known as Ursinha | ||
| mkanat | Can a commit have multiple parents? | 20:07 |
| dash | mkanat: sure, in the case of merges. | 20:08 |
| mkanat | Okay. | 20:11 |
| kyan | Hello! I'm a bit of a noob to bzr, but now I'm on a linux box and have it installed. When I type bzr push lp:~info-futuramerlin/futuramerlin.com-calculator/main0.93, I get bzr: ERROR: Invalid url supplied to transport: "lp:~/info-futuramerlin/futuramerlin.com-calculator/main0.93": No such person or team: . What should I do about that? Thanks! | 21:22 |
| dash | hm | 21:22 |
| dash | kyan: are you sure what you typed starts with "~info" and not "~/info"? | 21:23 |
| marienz | my first guess is actually that your shell did odd things to that ~ | 21:23 |
| marienz | I'd try quoting the entire url | 21:23 |
| dash | oh true. | 21:23 |
| kyan | Same error. | 21:23 |
| kyan | At https://code.launchpad.net/~info-futuramerlin/futuramerlin.com-calculator/main0.93, it gave what I typed. | 21:24 |
| kyan | @dash: Oh, now I get what you're saying. | 21:25 |
| kyan | I typoed.... | 21:25 |
| kyan | Still not working. This exchange was rather wordy, so: http://pastebin.com/rU5sVuv2 | 21:26 |
| dash | ah. | 21:27 |
| dash | launchpad doesn't know about your ssh key. | 21:27 |
| kyan | Ok... I added one the other day. | 21:27 |
| kyan | https://launchpad.net/~info-futuramerlin/+sshkeys | 21:28 |
| kyan | Did I do something incorrectly in adding it? | 21:28 |
| kyan | I generated it with a different computer. Should I make another one? | 21:32 |
| rubbs | do you have the cooresponding key on this computer? | 21:33 |
| kyan | No. | 21:33 |
| kyan | (I assume you mean the files in ~/ssh | 21:33 |
| kyan | I mean ~/.ssh | 21:34 |
| rubbs | correct. | 21:34 |
| rubbs | you need the private key in your .ssh dir | 21:34 |
| kyan | Ok I guess I'll make a new one. | 21:34 |
| rubbs | yeah, probably a good idea. you can have multiple ones on the site | 21:34 |
| lifeless | or you can copy it from the other machine | 21:34 |
| rubbs | this too ^ | 21:35 |
| kyan | Done. | 21:36 |
| kyan | https://launchpad.net/~info-futuramerlin/+sshkeys | 21:36 |
| kyan | I'm 'push'ing that again. | 21:37 |
| kyan | elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.93$ bzr push "lp:~info-futuramerlin/futuramerlin.com-calculator/main0.93" Enter passphrase for key '/home/elwa/.ssh/id_rsa': bzr: ERROR: Target directory lp:~info-futuramerlin/futuramerlin.com-calculator/main0.93 already exists, but does not have a .bzr directory. Supply --use-existing-dir to push there anyway. | 21:37 |
| kyan | Should I use --use-exsisting-dir? | 21:38 |
| rubbs | if you are just pushing and updated version of the same branch then yes you can do that. keep in mind that if history is different, it will be overwriten IIRC | 21:38 |
| lifeless | did you make the branch via the web UI ? | 21:38 |
| kyan | Yes. | 21:39 |
| lifeless | then yes, use --use-existing-dir | 21:39 |
| lifeless | making branch via the web UI causes that | 21:39 |
| lifeless | thumper: ^ :) | 21:39 |
| kyan | ok | 21:39 |
| * thumper sighs | 21:39 | |
| lifeless | I know you know | 21:40 |
| thumper | yes, redoing the register branch page has been on a TODO list for ages | 21:40 |
| lifeless | but I'd really love to just remove that field from the form | 21:40 |
| thumper | lifeless: that is the plan | 21:40 |
| thumper | lifeless: and to have general push instructions isntead | 21:40 |
| lifeless | is there anything particularly hard about it ? I mean, could *I* do it ? | 21:40 |
| thumper | we should do some proper UI design | 21:41 |
| lifeless | that too | 21:41 |
| thumper | I'd like to have the same form do foreign mirrors too | 21:41 |
| kyan_ | It's gotten stuck with Fetching revisions:Inserting stream | 21:44 |
| kyan_ | What does that mean? | 21:45 |
| lifeless | its pushing | 21:45 |
| kyan_ | Ok ... must be pretty slow since it says '0KB/s'. | 21:46 |
| kyan_ | Is there a way to see its status? | 21:47 |
| kyan_ | BTW, in case you're curious, what I'm doing is releasing my calculator program as floss, and uploading old revisions. | 21:49 |
| kyan_ | http://www.futuramerlin.com/data/2186.html | 21:50 |
| lifeless | well, it looks like you're having some internet connection trouble | 21:50 |
| lifeless | the push does need to send a fair amount of data the first time | 21:50 |
| kyan_ | Ah! It says 'created new branch'. I guess that's good. | 21:51 |
| kyan_ | Seems to have worked! | 21:51 |
| kyan_ | http://bazaar.launchpad.net/~info-futuramerlin/futuramerlin.com-calculator/main0.93/files | 21:51 |
| lifeless | congrats | 21:52 |
| kyan_ | I'm uploading my oldest version now. Thanks for your help! | 21:55 |
| kyan_ | Ok... still problems. | 21:58 |
| kyan_ | When I pushed the previous version 0.91 it seemed to succeed but when I looked at it via the web interface there were no revisions. | 21:58 |
| kyan_ | http://bazaar.launchpad.net/~info-futuramerlin/futuramerlin.com-calculator/main0.91/files | 21:58 |
| kyan_ | elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ bzr push "lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91" --overwrite bzr: ERROR: Working tree "/home/elwa/dev/futuramerlin.com-calculator/main0.91/" has uncommitted changes (See bzr status). Use --no-strict to force the push. elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ bzr status added: Calculator_ALL0_91.zip Calculator_exe0_91.zip elwa@gozog | 22:00 |
| kyan_ | fo-futuramerlin/futuramerlin.com-calculator/main0.91" --no-strict Enter passphrase for key '/home/elwa/.ssh/id_rsa': No new revisions to push. elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ | 22:00 |
| kyan_ | Still, there's nothing there. Any ideas? | 22:01 |
| lifeless | bzr st | 22:02 |
| kyan_ | elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ bzr st "lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91" nonexistent: lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91 bzr: ERROR: Path(s) do not exist: lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91 elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ | 22:03 |
| kyan_ | elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ bzr st added: Calculator_ALL0_91.zip Calculator_exe0_91.zip elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ | 22:04 |
| kyan_ | Hmmm, doesn't seem to be doing much | 22:04 |
| lifeless | that says you have added a file | 22:04 |
| lifeless | but you haven't committed it | 22:04 |
| kyan_ | How should I commit it? | 22:04 |
| lifeless | bzr commit | 22:04 |
| kyan_ | 'push' didn't work. | 22:04 |
| kyan_ | ok. | 22:04 |
| lifeless | I note that you're adding zip files | 22:05 |
| lifeless | this is a bit unusual | 22:05 |
| lifeless | what are you trying to accomplish here? | 22:05 |
| rubbs | kyan_: if you are uploading source, best to keep it uncompressed, bzr will compress the history for you. | 22:05 |
| kyan_ | @rubbs: ok. I was just uploading the old files. Sorry. I'll upload those again. | 22:06 |
| rubbs | Just to clarify commit will place the changes you made to the local history, push will then push your history updates to the remote branch. This is why you much commit before pushing ;) | 22:06 |
| kyan_ | After unzipping them. | 22:06 |
| kyan_ | Ohhhhh. Thanks. As I said, I'm quite a noob to this :-) | 22:07 |
| rubbs | kyan_: that's probabaly better. Bzr will know how to compress that better, most VCSs don't do well with binaries. | 22:07 |
| lifeless | if you want to upload old releases | 22:07 |
| rubbs | kyan_: np, we all were there at one point. | 22:07 |
| lifeless | you can use the releases facility, which works with zip files/tarballs that sort of thing | 22:07 |
| rubbs | oh I didn't know about the releases facility. | 22:08 |
| * rubbs looks that up | 22:08 | |
| kyan_ | Lifeless: what is the releases facility? | 22:08 |
| kyan_ | http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=launchpad+releases+facility | 22:08 |
| lifeless | in launchpad | 22:08 |
| lifeless | you have 'series' | 22:08 |
| lifeless | each series has milestones | 22:09 |
| lifeless | and milestones can be 'released' | 22:09 |
| lifeless | after they are released you can attach changelogs, release notes and downloads to them | 22:09 |
| kyan_ | what is a series? | 22:09 |
| kyan_ | what are milestones? | 22:09 |
| kyan_ | (sorry I'm not more familiar with the terminology) | 22:10 |
| lifeless | https://help.launchpad.net/Projects/SeriesMilestonesReleases | 22:11 |
| kyan_ | Thanks. | 22:15 |
| kyan_ | Still more problems: elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ bzr commit "lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91" Committing to: /home/elwa/dev/futuramerlin.com-calculator/main0.91/ aborting commit write group: PathsNotVersionedError(Path(s) are not versioned: lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91) bzr: ERROR: Path(s) are not versioned: lp:~inf | 22:15 |
| kyan_ | just running 'bzr' says that 'bzr add' will make them versioned. | 22:16 |
| kyan_ | I ran bzr add | 22:16 |
| kyan_ | and then it gave me the same error when I tried to commit it. | 22:16 |
| jelmer | kyan_: you can't commit to a remote location | 22:18 |
| jelmer | kyan_: You'll have to commit locally and then push your changes. | 22:18 |
| kyan_ | Um, ok... so just run bzr commit? | 22:18 |
| rubbs | right | 22:18 |
| kyan_ | Thanks... | 22:18 |
| rubbs | you do all your changes locally first, the only thing you do to remote branches (usually) is push and pull | 22:19 |
| rubbs | there are exceptions of course, but for our purposes now, always do stuff locally, and make the remote a "mirror" of your local branch by pushing to it. | 22:19 |
| kyan_ | While committing it it opened nano and should I type sthg now? | 22:19 |
| === kbrown_ is now known as kbrown | ||
| kyan_ | rubbs: thanks. That makes sense. | 22:19 |
| rubbs | np | 22:20 |
| rubbs | yes, I believe when it opens nano it's asking for a commit message | 22:20 |
| rubbs | I usually commit like this when it's just a short message $ bzr commit -m "My short commit message" | 22:20 |
| kyan_ | Ok. Thanks. | 22:21 |
| rubbs | np | 22:22 |
| kyan_ | Did that and pushing it. | 22:22 |
| rubbs | good, initial pushes take a while, but subsequent ones should be quicker | 22:22 |
| kyan_ | Is that because subsequent ones just send a diff? | 22:23 |
| rubbs | more or less | 22:24 |
| rubbs | little more, but it won't send info the remote system already has | 22:24 |
| kyan_ | BTW, my reason for using zips has something to do with the 22mb vs 3mb filesize difference... :-P | 22:32 |
| lifeless | bzr will pack tighter than zips | 22:33 |
| lifeless | if you do 10 zips you'll have 30 mb | 22:33 |
| lifeless | if you put the original source in bzr without zips, and did 10 commits, you'll have 3mb | 22:33 |
| rubbs | exactly bzr will require a larger amount up front but down the road the savings will be quite worth it. | 22:33 |
| lifeless | rubbs: it shouldn't require more up front either | 22:34 |
| kyan_ | Also, is it possible to do this pseudonymously or anonymously? | 22:35 |
| rubbs | oh right, I was thinking with a working tree | 22:35 |
| rubbs | kyan_: well pushing would require an account on lp, but anyone with bzr could branch from it IIRC | 22:35 |
| kyan_ | I was just wondering b/c launchpad seems to have used the wrong pseudonym. | 22:36 |
| kyan_ | (my personal pseudonym rather than my development pseudonym{ | 22:37 |
| rubbs | of that I'm not sure what happened. I'd help out, but I have to go now sorry. | 22:43 |
| rubbs | good luck with everything, and continue to ask questions if you have them. Someone will answer | 22:43 |
| === Ursinha is now known as Ursinha-bbl | ||
| === wilx_ is now known as wilx | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!