| lifeless | jam: oh, also - the new ACF exception is harder for people to match on | 00:03 |
|---|---|---|
| lifeless | jam: how do you feel about: | 00:03 |
| lifeless | putting the string AbsentContentFactory in the string, | 00:03 |
| lifeless | changing the exception to BzrError (or something like that, that doesn't spew a backtrace) | 00:03 |
| lifeless | having it ask for a bug to be filed, with ~/.bzr.log's contents for that command | 00:04 |
| poolie | emmajane: hi, are you around? | 00:05 |
| lifeless | mwhudson: bug 406898 | 00:09 |
| ubottu | Launchpad bug 406898 in bzr "rocketfuel-setup (Launchpad) SHA1KnitCorrupt error" [Undecided,New] https://launchpad.net/bugs/406898 | 00:09 |
| mwhudson | lifeless: yeah, don't really know what's going on there | 00:09 |
| mwhudson | lifeless: it's probably a bzr-git bug? | 00:10 |
| mwhudson | (it's also intermittent, which is really strange) | 00:10 |
| lifeless | not sure at all | 00:10 |
| mwhudson | or maybe it's not intermittent, but only happens over http or something | 00:10 |
| lifeless | is the branch in 2a format? | 00:12 |
| spiv | poolie: good morning. | 01:04 |
| poolie | hullo spivvo | 01:04 |
| poolie | jam: i have comments on the lock-warning branch, please don't merge it yet | 01:32 |
| spiv | Ugh, the bazaar@ moderation queue has gotten huge. | 02:25 |
| poolie | spiv, oh probably, i haven't done it for a while and not many other people do | 02:37 |
| poolie | and i think the spam filteringthere is poor | 02:38 |
| spiv | Yeah. | 02:39 |
| mwhudson | lifeless: borrow your cvs knowledge very briefly? | 02:49 |
| lifeless | sure | 02:49 |
| mwhudson | lifeless: https://pastebin.canonical.com/20636/ <- a chunk of rlog | 02:49 |
| mwhudson | lifeless: the date for 1.20 seems a little bong, correct? | 02:49 |
| lifeless | yes | 02:50 |
| lifeless | client had the date wrong | 02:50 |
| lifeless | rule 1 of distributed systems, you can't trust anyones dates except your own | 02:50 |
| mwhudson | unless it's just a coincidence, i think this is confusing cscvs | 02:50 |
| mwhudson | (very hypothetical as of yet) | 02:50 |
| lifeless | cscvs has a huge chunk of code to deal with this - it generates a DAG of the versions | 02:50 |
| lifeless | then walks that DAG, in parallel for all files, for each branch | 02:51 |
| mwhudson | oh | 02:51 |
| lifeless | theres a 'fun' test case in there | 02:51 |
| lifeless | for the case of two files | 02:51 |
| lifeless | with revs 1.1 @ time A, 1.2 @ time B in file F | 02:52 |
| lifeless | and revs 1.1 @ time B, 1.2 @ time A, in file G | 02:52 |
| lifeless | with the same commit messages | 02:52 |
| mwhudson | lifeless: the CVS/Catalog thats getting generated in this case has revision 1.20 as the only 'add' for this file | 02:53 |
| lifeless | [you need to turn this into 3 commits - A 1.1; A1.2,B1.1; B1.2 | 02:53 |
| lifeless | mwhudson: I think you're pulling on the right thread | 02:53 |
| lifeless | this is one of the fundamental issues with CVS though; its not pretty | 02:54 |
| lifeless | (I have actually seen that test case in the wild. Debugging that weirdness was Not Fun) | 02:54 |
| mwhudson | the only 'mainline' add, rather | 02:55 |
| lifeless | its definitely wrong | 02:57 |
| lifeless | so the /intent/ is that date is a hint but the DAG wins | 02:58 |
| mwhudson | ok | 02:58 |
| lifeless | we start with N parallel DAGS, one per file | 02:58 |
| lifeless | we collect across the DAGS by commit message | 02:58 |
| lifeless | within that, cycles are broken - such as that vicious case above | 02:58 |
| lifeless | finally, we walk in DAG,date order | 02:59 |
| lifeless | so that if two commits on different files have no ordering to each other, date order wins | 02:59 |
| lifeless | thats the intent. the reality - I think you've found damage :) | 02:59 |
| mwhudson | i think there are probably two bugs here | 02:59 |
| * lifeless is shocked | 03:00 | |
| mwhudson | one is this case (it's from sane-backends) | 03:00 |
| mwhudson | the other, and this is rather more common, is that there seems to be a problem updating the catalog when a merge creates a file | 03:00 |
| lifeless | mwhudson: I'm lunching/prepping LCA submission before the deadline | 03:06 |
| lifeless | mwhudson: which is in 1 hour IIRC. So after that hassle me more :P | 03:07 |
| mwhudson | lifeless: cool, thanks for the thoughts so far | 03:07 |
| * mwhudson is off for a haircut soon in any case | 03:07 | |
| abentley | lifeless: (in a non-pipeline, shelve would be as it is, in a pipeline it would add pipes?) All branches are single-pipe pipelines, so that's not a way to distinguish. I think we'd start with separate commands. | 03:17 |
| abentley | lifeless: (does shelve need a supercapability over commit?) shelve is meant to be a stepping stone to a true undo feature, so it will need more capability than commit has. | 03:19 |
| lifeless | poolie: around? | 04:04 |
| poolie | hi | 04:04 |
| lifeless | a) quick call and b) still on for slug? I'm meeting horms et all @ the red oak at 5pm if you want a little pretalk social | 04:05 |
| poolie | a- sure; b- i doubt i can make it | 04:05 |
| * spiv heads out for a run and lunch. | 04:30 | |
| thumper | any bzr talks proposed for LCA2010? | 05:01 |
| lifeless | yes | 05:01 |
| lifeless | I put the groupcompress one in a minutes ago | 05:01 |
| thumper | cool | 05:02 |
| jml | thumper, I proposed a talk on Ubuntu Distributed Development. | 05:10 |
| mwhudson | jml: hooray | 05:10 |
| thumper | jml: hey, I just proposed two | 05:10 |
| thumper | more launchpaddy though | 05:11 |
| jml | thumper, | 05:11 |
| thumper | jml: yes... | 05:12 |
| jml | thumper, oh sorry, typo. | 05:13 |
| thumper | jml: ok | 05:13 |
| mwhudson | lifeless: borrow your thoughts again? | 05:23 |
| lifeless | sure | 05:28 |
| mwhudson | lifeless: so there is a problem in cscvs something like this: | 05:30 |
| mwhudson | a branch is imported from cvs, all fine | 05:30 |
| mwhudson | hm | 05:30 |
| mwhudson | terminology :) | 05:30 |
| mwhudson | a module is imported from cvs, all fine | 05:30 |
| mwhudson | a file is created on a non-MAIN branch in cvs | 05:30 |
| mwhudson | the import is updated, the catalog gets some entries, all still fine | 05:31 |
| mwhudson | the branch is merged to MAIN in cvs | 05:31 |
| mwhudson | when cscvs goes to update the import, the Revision that adds the file is a Revision.CHANGE | 05:31 |
| mwhudson | so applying it goes boom | 05:32 |
| mwhudson | if you generate the catalog from scratch, the Revision that adds the file to MAIN is a Revision.ADD, and it all works | 05:32 |
| mwhudson | lifeless: makes sense so far? | 05:32 |
| mwhudson | i've chased this as far as CacheGenerator.set_rev_type -- when you do an initial import, this is where the CHANGE gets overridden to an ADD | 05:33 |
| lifeless | so 1.0 of the file is dead | 05:34 |
| lifeless | 1.1 is alive, but datewise there are 1.0.1.1 versions alive before hand? | 05:34 |
| lifeless | it makes sense to me; the incremental analysis is incorrectly thinking the CHANGE can be applied to trunk. | 05:35 |
| mwhudson | lifeless: well, cvs has 1.1 not 1.0, but yes | 05:35 |
| lifeless | magic black holes aside | 05:36 |
| lifeless | ;) | 05:36 |
| mwhudson | lifeless: http://pastebin.ubuntu.com/238150/ <- the full log | 05:36 |
| mwhudson | lifeless: so i'm currently thinking that set_rev_type should dip into the catalog to check for this case, but i've nfi if that's at the right level | 05:38 |
| lifeless | it should be already | 05:40 |
| lifeless | but yes, I think you're in the rightish spot | 05:40 |
| lifeless | its cscvs, by definition you're in the right spot | 05:40 |
| mwhudson | holy crap, my fix works! | 05:45 |
| mwhudson | the complexity is all kinds of wrong, but nm that | 05:45 |
| lifeless | i am sorry | 05:46 |
| lifeless | its a _very_ organic codebase | 05:46 |
| * lifeless is not here anymore (\o/ starting at stupid o'clock) | 05:49 | |
| mwhudson | thanks for being a teddy bear | 05:51 |
| lifeless | anytime | 05:51 |
| lifeless | however, right now, I has talk to finish. | 05:51 |
| lifeless | so, I actually mean, anytime except now. | 05:51 |
| arjenAU | lifeless: has anyone played with inotify and bzr combo? | 05:52 |
| lifeless | arjenAU: I wrote an inotify watcher at guadec 2008 | 05:52 |
| lifeless | dunno were it went... | 05:52 |
| lifeless | arjenAU: but that was for repositories | 05:52 |
| lifeless | there is a mail sender demon that uses inotify to detect changed branches too | 05:52 |
| arjenAU | lifeless: pondering it for redundant webservers | 05:53 |
| lifeless | arjenAU: how do you mean? | 05:53 |
| arjenAU | auto-syncing them, but with revisioning and through bzr rther than rsync | 05:53 |
| arjenAU | just talking static files and php scripts, not db data ;-) | 05:54 |
| lifeless | oh hmm | 05:54 |
| lifeless | probably a little shell love could glue them together well | 05:54 |
| lifeless | a little program to watch for changes and run bzr update; bzr commit | 05:54 |
| lifeless | myself, I'd just deploy via bzr upload to both servers | 05:55 |
| arjenAU | with a push trigger. and it'd need to make sure of conflict resolution etc | 05:55 |
| lifeless | and smack, hard, anyone touching them otherwise | 05:55 |
| arjenAU | yea not disagreeing there, but there are other uses... pmwiki for instance uses plain files by default rather than a db. | 05:55 |
| lifeless | right | 05:55 |
| arjenAU | which has benefits. | 05:56 |
| lifeless | surely it has a hook to call into things on changes? | 05:56 |
| arjenAU | yep it has, but inotify would solve it more generically | 05:56 |
| lifeless | with risk though | 05:56 |
| arjenAU | regardless of which stupid app the server has. | 05:56 |
| lifeless | inotify has some latency, and you could record inconsistent state | 05:56 |
| arjenAU | yes, hence the pondering and asking you ;-) right now it's an evil thought. | 05:56 |
| lifeless | anyhow, I don't know of anyone doing this particular scenario, but bzr can coexist with inotify in python progreams - thats known for sure :) | 05:57 |
| arjenAU | yaya | 05:57 |
| arjenAU | there's a pyinotify too | 05:57 |
| lifeless | yes, using that | 05:58 |
| arjenAU | lifeless: already using etckeeper with bzr. rocks. | 05:58 |
| lifeless | nice! | 05:58 |
| arjenAU | I suggested something like that years ago except only bk was around then. happy someone actually did it and integrated with apt and such. | 05:59 |
| arjenAU | it's like essential on a box. shouldnt be without it | 05:59 |
| poolie | hi arjen | 06:20 |
| poolie | spiv - did your comment before mean that you emptied the mailman greasetrap? | 08:58 |
| spiv | poolie: no, just that I noticed the list admin mail about it. | 08:59 |
| poolie | :/ | 08:59 |
| poolie | it's such an annoying chore | 08:59 |
| poolie | i'll do it | 08:59 |
| spiv | Yeah, it sucks. | 08:59 |
| poolie | geez, look at them all | 09:00 |
| spiv | Are we still getting bazaar-ng@ mail forwarded to that? If not then decommissioning might cut down the problem a little. | 09:00 |
| poolie | i think not | 09:01 |
| poolie | i can't believe our spam system thinks all this crap about acai berries is relevant | 09:03 |
| poolie | spiv, i might call it a day | 09:14 |
| spiv | poolie: ok. Have a good weekend. | 09:16 |
| timeless_mbp | hello, is bzr supposed to fail when there's no disk space available? | 10:40 |
| timeless_mbp | http://pastebin.mozilla.org/665240 | 10:40 |
| fullermd | Well, I wouldn't expect it to _succeed_ :) | 10:42 |
| fullermd | I don't think python has built-in support for growing hard drives. | 10:42 |
| timeless_mbp | well... as an end user, i expect that 'st' is a readonly operation | 10:45 |
| * timeless_mbp gets out an end user's list of unreasonable expectations and points to this one | 10:45 | |
| fullermd | Well, it's potentially a write operation, since it may want to rewrite the dirstate file about the checkout (I don't think it does every time there are possibilities, for efficiency reasons). | 10:45 |
| fullermd | In this case, though, it blew up on writing the logfile. In that sense, _every_ bzr operation writes. | 10:46 |
| fullermd | Even 'bzr rocks', which is as near a no-op as imaginable, writes an entry into .bzr.log. | 10:46 |
| timeless_mbp | is there a --please-do-not-right | 10:46 |
| timeless_mbp | or --please-do-no-write | 10:46 |
| fullermd | There's no general such option, no. You could hack around this _particular_ case by seeing the BZR_LOG env variable to something like /dev/null (or something on a partition with space). | 10:47 |
| timeless_mbp | so, this is a design decision, and not bugworthy? | 11:02 |
| fullermd | Well, the two aren't necessarily exclusive. | 11:05 |
| fullermd | It _is_ a conscious decision. That doesn't mean it can't be changed, though I wouldn't expect this one to be. | 11:05 |
| fullermd | If it's actually a significant problem or a big surprise for you, it's worth registering in a bug or on the ML; the decision would certainly never be changed if nobody argued against it. | 11:06 |
| timeless_mbp | essentially my system has a bunch of version controlled directories | 11:07 |
| timeless_mbp | they automatically grow with changes from "upstreams" | 11:07 |
| timeless_mbp | i was looking for trees which had changes, to decide whether i could delete them (if there aren't any changes in the tree, i could get it back later, when my disk space problems were resolved) | 11:08 |
| fullermd | .bzr.log won't grow without bounds; bzr rotates it when it gest to a few megs. | 11:08 |
| fullermd | You can use $BZR_LOG to shut it off temporarily, or rm the existing one/backup manually to free up a little space. | 11:09 |
| timeless_mbp | in this case, i'm pretty sure my repositories were fairly tiny | 11:09 |
| timeless_mbp | they were network-manager and network-manager-gnome | 11:09 |
| fullermd | (stat may still try to write metafiles and fail if the partition is full, but one problem at a time) | 11:09 |
| timeless_mbp | and had only a couple of uses | 11:09 |
| timeless_mbp | sorry, i had to delete stuff, and the bzr repos were going to go, once i found the files i needed :) | 11:09 |
| fullermd | The error you got isn't from writing anything in those branches, it's from the ~/.bzr.log (though that may be the same partition) | 11:10 |
| fullermd | So `env BZR_LOG=/dev/null bzr st` would get you past that at least. | 11:10 |
| timeless_mbp | -rw-rw-r-- 1 timeless timeless 168K Jul 31 13:35 /home/timeless/.bzr.log | 11:11 |
| fullermd | File a bug with the stacktrace anyway; we should probably handle it a little more gracefully. | 11:11 |
| * timeless_mbp puts on a clueless hat | 11:11 | |
| timeless_mbp | "where's your bug tracker?" | 11:11 |
| fullermd | https://bugs.launchpad.net/bzr | 11:11 |
| timeless_mbp | thanks | 11:13 |
| * timeless_mbp goes to find the password | 11:13 | |
| timeless_mbp | heh, it seems i've filed a couple of bugs against bzr :) | 11:15 |
| timeless_mbp | oh, no | 11:15 |
| timeless_mbp | it seems i can't understand launchpad's UI.. great | 11:15 |
| fullermd | Don't think that makes you special :p | 11:19 |
| timeless_mbp | yeah, probably not | 11:21 |
| timeless_mbp | https://bugs.launchpad.net/bzr/+bug/407295 | 11:22 |
| ubottu | Launchpad bug 407295 in bzr ""bzr st" failed to handle No space left on device for ~/.bzr.log" [Undecided,New] | 11:22 |
| timeless_mbp | anyway, thanks. have a good weekend or something | 11:22 |
| vxnick | does bzr-keywords work well? | 13:06 |
| fullermd | In itself, it seems OK. But various issues in the filtering layer keep it from being really useful. | 13:13 |
| vxnick | as long as it doesn't break anything :) | 13:13 |
| === sabdfl1 is now known as sabdfl | ||
| vxnick | are there any docs about the 2a format and a description of stacked branches? | 13:47 |
| === mrevell is now known as mrevell-lunch | ||
| awilkins | Louder | 14:13 |
| awilkins | Oops | 14:13 |
| === mrevell-lunch is now known as mrevell | ||
| dolphy | Hi all, quick question. When contributing to a project generating a bundle sent by mail for a feature I added | 15:21 |
| dolphy | if I want to work on a new fix feature meanwhile it's being reviewed, should I remove my branch and start from scratch again so that all bundles I m pushing are all coming from the original current branch ? | 15:22 |
| beuno | emmajane, hi | 15:26 |
| beuno | dolphy, you just create a new branch from trunk, yes | 15:26 |
| beuno | so your diff is clean | 15:26 |
| beuno | "feature branches" | 15:27 |
| dolphy | beuno: any faster way to do that than rm -rf and a brand new bzr branch command ? | 15:28 |
| beuno | dolphy, don't rm -f! | 15:28 |
| beuno | leave it | 15:28 |
| beuno | until it gets approved | 15:29 |
| beuno | you may need to make changes :) | 15:29 |
| beuno | branch should be pretty fast if you're using a shared repository | 15:29 |
| homy | Hi! Do you usually also put compiled binaries under revision control? | 15:49 |
| LeoNerd | Generally not | 15:49 |
| LeoNerd | But as with general vauge questions you'll get general vague answers. :) can you be more specific about your use case? | 15:50 |
| luks | anything automatically generated | 15:50 |
| homy | LeoNerd: no special use case. Just this one: http://bazaar-vcs.org/Workflows#Solo. | 15:53 |
| LeoNerd | Oh.. well, generally, don't then. | 15:53 |
| LeoNerd | Half the point of a DVCS is you can do things like branch and merge. bzr won't be able to merge a compiled binary. | 15:53 |
| LeoNerd | Best just to keep the source which it can merge, and have the binary handled separately by some build system. | 15:53 |
| homy | LeoNerd: But I do put binary files like images under Revision control? | 15:54 |
| LeoNerd | Well.. again.. it's partly up to you. bzr -can- store binary files... it's up to your situation if that's a good idea. | 15:54 |
| LeoNerd | There can be valid use cases. E.g. storing GIF images as part of a webapp source. | 15:54 |
| homy | or icons for a qt programm. | 15:54 |
| LeoNerd | Indeed. | 15:55 |
| awilkins | I wonder if you could bolt on that Google x86-binary-diff algorithm | 15:55 |
| homy | ok, thanks. In what use case *would* you store compiled binaries? | 15:55 |
| awilkins | Or something that unpacked JAR files and diffed the classes before | 15:55 |
| awilkins | homy: Maven repository? | 15:55 |
| awilkins | homy: Backup archive? | 15:55 |
| awilkins | homy: I;m storing compiled binaries, but that's because I'm using Bazaar as an update mechanism for my users on a particular project - and the binaries are not in the source tree | 15:56 |
| awilkins | homy: thinking about it I could probably just install Maven on their machines and make them run a maven goal to update their software... | 15:57 |
| awilkins | .. they could have a working tree of the sources | 15:58 |
| awilkins | But the project is basically done with now | 15:58 |
| homy | sorry, what is "maven repository"? | 15:58 |
| awilkins | Maven is a build-and-dependency system, primarily for Java applications | 15:58 |
| emmajane | poolie, pong | 15:58 |
| emmajane | beuno, hey :) | 15:59 |
| homy | the same as apache maven? | 15:59 |
| awilkins | homy: Yes | 15:59 |
| awilkins | homy: We're using Apache Archiva as our repository | 15:59 |
| beuno | emmajane, how's your day today to have a call? | 16:07 |
| emmajane | beuno, pretty good. I'm just dealing with allergies right now so I'm snuffling lots. | 16:32 |
| beuno | emmajane, in 2 or 3 hours would be great for me | 16:33 |
| emmajane | beuno, that would be just after lunch which could work for me nicely as well. | 16:33 |
| beuno | emmajane, perfect. Lets ping-pong later then :) | 16:33 |
| emmajane | beuno, sounds good :) | 16:33 |
| corporate_cookie | I have a development branch; which is out of sync with a production branch. I want to merge some changes (entailed in 2 revno's) from the development into the production branch; but only the changes entailed in those two revnos. Anyone know how that can be done ? | 16:53 |
| === deryck is now known as deryck[lunch] | ||
| === beuno is now known as beuno-lunch | ||
| jam | sidnei: ping | 18:00 |
| Tak | does bzr+ssh:// require server software other than ssh? | 18:01 |
| LarstiQ | Tak: bzr installed on the remote end | 18:06 |
| LarstiQ | Tak: or well, invokable. bzr_remote_path=~/src/bzr/bzr.dev/bzr works too | 18:06 |
| Tak | ok, but there doesn't have to be any kind of server running? | 18:08 |
| Tak | not like svnserve | 18:08 |
| LarstiQ | Tak: no, bzr is just started up over the ssh session and shut down again | 18:16 |
| === deryck[lunch] is now known as deryck | ||
| Tak | cool | 18:26 |
| Tak | is it possible to preauthorize a password with bzr+ssh using the auth mechanism? | 18:26 |
| LeoNerd | Isn't that what an ssh key is for? | 18:27 |
| Tak | heh, not possible sometimes | 18:29 |
| === rockstar` is now known as rockstar | ||
| sidnei | jam: pong | 18:36 |
| jam | hey sidnei, I was hoping we could get buildbot working to build the latest installer | 18:38 |
| jam | have you done anything with it recently? | 18:38 |
| sidnei | jam: not recently no, but i haven't forgotten about it. | 18:39 |
| jam | so at this exact moment I'm a bit preoccupied with something | 18:39 |
| jam | but in about an hour it would be nice to work on it with you | 18:39 |
| sidnei | jam: ok, i should get to a stopping point in one hour too | 18:40 |
| jam | sidnei: ok, I'll try to ping you if I don't hear from you first :) | 18:42 |
| sidnei | jam: awesome, thanks! | 18:42 |
| nilg | hi, I've a problem, I've modified source files wrongly, it was after a local commit but before pushing on lauchnpad, does a revert command will do the trick, that is ignoring my last modifications? | 19:26 |
| nilg | I tried to push directly (since I did not commit the changes), but it says: bzr: ERROR: These branches have diverged. Try using "merge" and then "push".1 | 19:27 |
| nilg | but I certainly not want to merge I just want to ignore these last modifications | 19:28 |
| SamB | nilg: "bzr uncommit" | 19:28 |
| blackxored | hello everybody | 19:28 |
| SamB | or maybe "bzr pull --overwrite" | 19:28 |
| blackxored | how to export a part of my bzr branch to a svn repository without lose of history | 19:29 |
| blackxored | ? | 19:29 |
| SamB | blackxored: what part? | 19:29 |
| blackxored | a debian/ directory without the .bzr/* files at the root | 19:29 |
| SamB | blackxored: what does the repository actually consist of ? | 19:30 |
| SamB | the bzr one, I mean | 19:30 |
| nilg | SamB, no this will ignore my last commit, right? but I don't want this I want to ignore my last changes not committed | 19:30 |
| SamB | nilg: oh! | 19:30 |
| SamB | well, the diverging has nothing to do with that | 19:30 |
| SamB | run "bzr missing" to see how they diverged | 19:31 |
| nilg | and I'm scared to do bzr revert and loose my last commit | 19:31 |
| SamB | bzr revert doesn't lose you commits | 19:31 |
| SamB | only "bzr uncommit" or "bzr pull --overwrite" | 19:31 |
| SamB | (and you can still *probably* find them again even then) | 19:31 |
| blackxored | SamB, I got this branch: rootdir => .bzrignore and etc debian/ dir I need to push the debian dir only without the .bzr oens | 19:31 |
| SamB | blackxored: you can't skip .bzrignore without losing history | 19:32 |
| nilg | SamB, bzr revert has exactly what I wanted, thank you so much!!!! | 19:33 |
| blackxored | then .bzrignore has to be checkout? | 19:33 |
| blackxored | ci,I mean | 19:33 |
| SamB | the .bzr directory, though, isn't part of the bzr-managed tree -- it's where bzr keeps it's notes -- so that won't show up if you just "bzr push" to the SVN URL of your choice | 19:33 |
| SamB | hopefully, either your bzr repository originally came from the SVN repository or the SVN repository is empty? | 19:34 |
| * SamB wonders what exactly a "chk" *is* | 19:37 | |
| blackxored | SamB, the svn repo is empty | 19:37 |
| SamB | blackxored: so, why does it even need to be an SVN repository? | 19:37 |
| blackxored | SamB, because is where the team is | 19:38 |
| blackxored | anyway, my three is something like .bzr .bzr-builddeb com debian edu org .pc , and I only need to push debian/ | 19:38 |
| SamB | blackxored: and do you have bzr-svn installed, and is it a SVN 1.5 (or greater) format repository? | 19:38 |
| blackxored | yes it is | 19:38 |
| SamB | hmm, why do you only want to push the "debian" directory? | 19:39 |
| blackxored | because I'm doing debian related work and that's all I need to commit | 19:39 |
| SamB | I think it would make a lot more sense to keep using the bzr repository if Debian makes you jump through so many hoops to use SVN | 19:39 |
| blackxored | SamB, sure but I'm part of a team | 19:40 |
| blackxored | SamB, so solutions/? | 19:40 |
| jam | sidnei: ping for great justice | 19:40 |
| blackxored | SamB, I just want to keep history under debian | 19:40 |
| SamB | well, you could either commit it all, or you could lose some of the history by filtering the branch ... | 19:41 |
| blackxored | SamB, and push debian | 19:41 |
| sidnei | jam: wrapping up, 2 minutes | 19:41 |
| Tak | can you make another branch of the svn repo, merge in just the commits to debian/, then push those back up to the repo? | 19:41 |
| jam | k | 19:41 |
| blackxored | Tak, right, the question is how? | 19:41 |
| SamB | but that would probably make it very difficult to collaborate with Ubuntu ... | 19:41 |
| Tak | was your bzr branch originally branched from the svn repo? | 19:42 |
| blackxored | Tak, no It was private | 19:42 |
| SamB | blackxored: it would make things way more complicated unless the people who made the bzr repository aren't going to continue using it ... | 19:42 |
| blackxored | SamB, I hosted my branch in launchpad initially | 19:42 |
| blackxored | SamB, I could assume that won't be used anymore | 19:43 |
| Tak | I'm not sure if you can automatically merge two branches that don't have the same ancestor... | 19:43 |
| SamB | blackxored: and did you already try to talk the rest of the team into joining you in using the bzr branch? | 19:43 |
| SamB | Tak: SVN repo is empty | 19:43 |
| SamB | Tak: that's why I'm wondering what is so important about using SVN! | 19:43 |
| blackxored | SamB, because the team uses svn! | 19:44 |
| SamB | blackxored: they can't use anything but svn? | 19:45 |
| blackxored | SamB, I'd be glad if they use bzr, actually, I'll jump and jump and jump... | 19:45 |
| blackxored | SamB, I'm quite new , so won't ask them to switch | 19:45 |
| Tak | hmm, could you push the branch to the repo, then merge out non-debian/-relevant revisions? | 19:46 |
| sidnei | jam: ok, ready | 19:46 |
| * sidnei updates bzr.dev | 19:46 | |
| blackxored | the branch has no upstream code | 19:47 |
| blackxored | only debian dirs, and bzr-related ones | 19:47 |
| SamB | blackxored: com edu and org are debian-related? | 19:47 |
| Tak | must be a java project ;-) | 19:47 |
| SamB | I mean, what do they do? | 19:47 |
| blackxored | Tak, is a java project | 19:48 |
| SamB | blackxored: oh, so there *is* upstream code! | 19:48 |
| jam | sidnei: so the first (small?) issue, is that I don't think Tortoisebzr actually makes releases | 19:48 |
| * Tak winnar | 19:48 | |
| blackxored | those files are ignored | 19:48 |
| jam | so we don't really have tags to use | 19:48 |
| jam | per se | 19:48 |
| jam | is the solution to just force it? | 19:48 |
| blackxored | SamB, *are* ignored | 19:49 |
| Tak | so...everything but debian/ is ignored anyway? | 19:49 |
| blackxored | Tak, yes! | 19:49 |
| sidnei | jam: what you mean by 'force' it? | 19:49 |
| Tak | so what's the problem? | 19:49 |
| SamB | blackxored: so what bzr branch do you want in svn? | 19:49 |
| SamB | step 1: make that branch | 19:49 |
| jam | sidnei: force them to start using tags and releasing | 19:50 |
| jam | or faking it my making my own branch with tags in it | 19:50 |
| blackxored | ok, listening | 19:50 |
| jam | to date, I've just grabbed whatever the current tbzr tip revision is | 19:50 |
| SamB | step 2: bzr push svn://alioth.debian.org/path/to/repo/and/branch | 19:50 |
| sidnei | jam: tip would work, but of course it would be best to have a tag | 19:50 |
| sidnei | jam: who's upstream for tortoizebzr? | 19:51 |
| jam | random people | 19:51 |
| ronny | hmm | 19:52 |
| jam | It was originally written a while ago, then updated by Mark Hammond | 19:52 |
| jam | right now I'm not sure who is really maintaining it | 19:52 |
| jam | I've seen updates from both bialix and Naoki | 19:52 |
| ronny | reminds me, i need to get a hold of all the tortoise kinds of people (there shouldnt be one for each vcs) | 19:53 |
| SamB | blackxored: if you don't really care about anything but debian/, you could just use jelmer's filtering plugin to remove everything else from the entire history before pushing | 19:53 |
| ronny | more like one for all of the vcs's | 19:53 |
| jam | sidnei: beyond that I think I can go through and update some of the bits. | 19:54 |
| sidnei | jam: how does tagging work in bzr? can you tag a remote branch? | 19:55 |
| jam | sidnei: tags are maintained as part of the branch meta-info | 19:55 |
| jam | so if you are deleting the target, you can't just set a tag there | 19:56 |
| jam | if you were copying into your own branch, then you could have your own set of tags | 19:56 |
| jam | sidnei: what is this: | 19:56 |
| jam | rem Enable this when this branch is merged. | 19:56 |
| jam | rem make python-installer PYTHON24=${settings:python24} PYTHON25=${settings:python25} PYTHON26=${settings:python26} | 19:56 |
| jam | rem @if %ERRORLEVEL% NEQ 0 (set BUILD_ERROR=%ERRORLEVEL%) & goto End | 19:56 |
| SamB | why aren't tags part of the repository ? | 19:56 |
| jam | You seem to copy the code from "python-installer" into your own set of lines w/ bdist_wininst | 19:56 |
| jam | SamB: read the mailing list | 19:56 |
| jam | lots of discussion there | 19:57 |
| jam | stuff like, 2 projects using the same shared repo, and using "release-1.2" style tags | 19:57 |
| jam | but being different ancestries | 19:57 |
| SamB | jam: yes! I'm not exactly going to reread the whole thing | 19:57 |
| SamB | jam: oh, point | 19:57 |
| SamB | okay, that's good enough for me for the moment | 19:57 |
| jam | yeah, there was a *lot* of discussion about possible tag mechanics | 19:57 |
| jam | I'm not very satisfied with what we have, but at least we have something. | 19:58 |
| SamB | and it's not a case where there is an obvious improvement | 19:58 |
| sidnei | jam: hold on, let me finish this thought about tags, then i will look into that | 19:58 |
| jam | sidnei: so I'm wondering if I should uncomment the "rem" and then remove the next few lines. | 19:58 |
| sidnei | jam: so just tagging a specific revision (the one included in the installer) of tortoisebzr trunk in launchpad with the installer release version would be enough, if that's possible | 19:58 |
| jam | sidnei: I would guess I actually have write access to lp:tortoisebzr or if necessary, I could *get* it. | 19:58 |
| sidnei | jam: seems like you have access. in fact, i now have access to. the owner is an open team *wink* | 19:59 |
| SamB | wow, that's got pugs beat! | 20:00 |
| ronny | hmm | 20:00 |
| jam | sidnei: what is "gf.recipe.bzr" ? | 20:00 |
| ronny | now, how to persuade all the different tortoiseFoo teams to work togeth | 20:00 |
| SamB | I mean, I have joked that if you so much as *sneeze* in #perl6, they will give you pugs commit access, but ... | 20:01 |
| sidnei | jam: it's a buildout recipe that calls bzr | 20:01 |
| ronny | i managed to end up in the pugs contributors list | 20:01 |
| sidnei | jam: just so the branches to be pulled for the plugins are in the buildout.cfg | 20:02 |
| jam | sidnei: sure, but where is that recipe, and how is it maintained? | 20:02 |
| jam | as I don't see the code anywhere | 20:02 |
| SamB | (assuming your sneeze includes an email address and possibly an SSH public key ;-P) | 20:02 |
| sidnei | jam: oh, it's in launchpad, lp:gf.recipe.bzr | 20:02 |
| jam | sidnei: how is that found by the boostrap code? | 20:02 |
| SamB | sidnei: that's your girlfriend's recipes? | 20:03 |
| jam | as I don't see a reference to that sort of thing | 20:03 |
| sidnei | SamB: could be :) | 20:03 |
| ronny | what is gf ? | 20:03 |
| sidnei | jam: oh. it's downloaded from pypi with easy_install | 20:03 |
| sidnei | gf == greenfinity | 20:03 |
| sidnei | company from hungary | 20:03 |
| SamB | hmm, what's the correct Ubuntu release to list in my sources.list to get the nightly builds at the moment? | 20:04 |
| jam | sidnei: so should we be using the rc6 release, and/or #strict ? | 20:05 |
| * SamB wishes bzr would up an additional progress bar when it has to do a repack ... | 20:06 | |
| sidnei | jam: rc6 should work yes, i haven't used strict, i believe it's not needed | 20:06 |
| jam | sidnei: I'm concerned about this: | 20:07 |
| jam | On update, if "pull" is unsuccesful, the recipe will give an error with the bzr command output, but it will not cause buildout to stop with an error. The developer needs to look at this output to realize that the update has not taken place. | 20:07 |
| jam | I'd rather buildout failed if it doesn't manage to update properly. | 20:07 |
| jam | IMO | 20:07 |
| sidnei | jam: ok. i believe strict fails in that case, so we can use strict. | 20:07 |
| SamB | jam: that *is* the usual configuration, yes | 20:08 |
| jam | SamB: what is the usual configuration? | 20:08 |
| jam | At least from what I can tell, gf.recipe.bzr changed what is happening | 20:08 |
| jam | and if I read pypi correctly, it seems to say that the latest release is more relaxed then before | 20:09 |
| SamB | having buildbot fail when it can't pull / checkout from the VCS | 20:09 |
| sidnei | jam: looking at the source for strict, seems like it does what you want. | 20:11 |
| jam | now, do I need to set: | 20:12 |
| jam | gf.recipe.bzr#strict = 1.0rc6 | 20:12 |
| jam | or do I just set | 20:12 |
| jam | gf.recipe.bzr = 1.0rc6 | 20:12 |
| jam | and then later use | 20:12 |
| jam | recipe = gf.recipe.bzr#strict | 20:12 |
| sidnei | jam: the latter, though it's ':strict' not '#strict' | 20:13 |
| jam | sidnei: k, though that isn't what pypi said | 20:13 |
| jam | according to this page: http://pypi.python.org/pypi/gf.recipe.bzr | 20:13 |
| jam | perhaps the docs for gf.recipe.bzr need to be updated? | 20:14 |
| sidnei | jam: yeah, i don't remember #strict working, but i could be wrong. | 20:14 |
| * sidnei files a bug | 20:14 | |
| jam | (given that you seem to have commit rights there) | 20:14 |
| jam | sidnei: so I had #strict and it didn't fall over immediately | 20:14 |
| jam | but that could be because it treated # as a comment | 20:14 |
| jam | and just ignored it | 20:15 |
| sidnei | likely yes | 20:15 |
| sidnei | i have a couple branches to merge there, will sneak this fix in | 20:15 |
| jam | sidnei: this doesn't seem like the correct place for an official zlib dll: | 20:16 |
| jam | http://www.zlatkovic.com/pub/libxml/zlib-1.2.3.win32.zip | 20:16 |
| jam | not to mention I noticed because I got a timeout while trying to download | 20:16 |
| sidnei | jam: that's the one i've been using for building lxml for ages, where you've been getting zlib from? | 20:17 |
| jam | I'm not sure what you were doing with it, but I would think: | 20:17 |
| jam | http://www.zlib.net/zlib123-dll.zip | 20:17 |
| jam | sidnei: and the fact that the dir is "libxml" means it would be a reasonable place for *libxml* but not necessairly zlib :) | 20:18 |
| jam | argh | 20:18 |
| jam | getting a traceback inside "hexagonit.recipe.download" | 20:18 |
| sidnei | jam: if i remember correctly, the version provided at zlib.net is not statically compiled, but i could be wrong | 20:18 |
| jam | sidnei: http://paste.ubuntu.com/239887/ | 20:19 |
| jam | sidnei: the one at zlib is a dll, yes | 20:19 |
| jam | but the one *I* compile against is a dll, as well | 20:19 |
| jam | I've been packaging zlib1.dll into the installer for a while | 20:20 |
| sidnei | jam: ah, so you're shipping the dll, ok. | 20:20 |
| jam | well, py2exe is :) | 20:20 |
| sidnei | jam: for lxml, it is all statically linked, so the dll doesn't need to be shipped | 20:21 |
| jam | also, is there any chance to not have "make installer-all" pollute my working dir? | 20:21 |
| jam | sidnei: well, python itself statically compiles against it | 20:21 |
| jam | and if they *didn't* then we wouldn't need to do it ourselves | 20:21 |
| jam | we want like 1 function out of it, but python hides the zlib dependency | 20:21 |
| jam | so even though all the functionality is there... ;( | 20:22 |
| sidnei | :/ | 20:22 |
| sidnei | jam: log is not defined, ha! | 20:23 |
| SamB | sidnei: import math, duh ;-P | 20:23 |
| jam | sidnei: yeah, so bug in hexagonit... I think we can work around it somehow by unsetting: 'strip-top-level-dir' | 20:24 |
| jam | sidnei: what does that setting do? | 20:24 |
| jam | since I see you set it on almost all the recipes | 20:24 |
| sidnei | jam: it unpacks the file in the target directory, instead of creating a sub-directory with the zip file name | 20:25 |
| jam | sidnei: so the zlib.net zip file puts everything into the root dir | 20:26 |
| jam | should we be unsetting this? | 20:26 |
| sidnei | jam: give it a try, i believe so | 20:26 |
| jam | sidnei: it at least doesn't crash | 20:26 |
| jam | so a good strat | 20:26 |
| jam | start | 20:26 |
| jam | I'm all the way to "Getting release from bzr repository...." | 20:27 |
| sidnei | jam: awesome | 20:28 |
| jam | course, it breaks after that | 20:28 |
| jam | but at least a start :) | 20:28 |
| sidnei | :P | 20:28 |
| sidnei | jam: whats the failure | 20:29 |
| jam | "C:/Users/jameinel/dev/bzr/work/tools/win32/qbzr/trunk@tag:release-0.12/" | 20:29 |
| jam | (I'm pretty unhappy about all the droppings in my WD, I'll probably try to clean that up next.) | 20:30 |
| * SamB wishes you didn't need a special build of python just to get backtraces in GDB... | 20:30 | |
| jam | sidnei: As near as I can tell, it isn't trying to use "trunk -r tag:XXX" but an actual branch named "trunk@tag:..." and it never actually created it | 20:32 |
| jam | my guess is something about not handling the "@" | 20:32 |
| jam | bzr *itself* doesn't treat it like svn does | 20:32 |
| jam | it just considers it another character | 20:32 |
| jam | not an indication that it is a specific rev in that branch | 20:32 |
| sidnei | jam: yes, that seems like a bug in gf.recipe.bzr, which is odd because it worked when i tried | 20:32 |
| jam | sidnei: might be 1.0rc5 versus 1.0rc6? | 20:32 |
| jam | also: lp:///~jameinel/bzr/1.18-win32-buildbot | 20:32 |
| sidnei | jam: maybe, want to change versions.cfg and try again? | 20:33 |
| jam | is the latest of what I've been doing | 20:33 |
| * sidnei gets it | 20:33 | |
| jam | I had to back up the setuptools version | 20:33 |
| jam | do you know any reason why I would need setuptools...9 instead of 8? | 20:33 |
| sidnei | jam: no specific reason, just the latest available | 20:33 |
| jam | k | 20:33 |
| jam | I seem to have 8 installed | 20:33 |
| jam | and if I leave it at 9 | 20:34 |
| jam | it fails | 20:34 |
| jam | claiming incompatibility | 20:34 |
| sidnei | nasty | 20:34 |
| sidnei | jam: what's the parent branch for your branch? | 20:36 |
| sidnei | seems like it has a couple extra changes from bzr.dev | 20:36 |
| jam | sidnei: only things that landed in bzr.dev, but probably not mirrored to lp: yet | 20:37 |
| sidnei | jam: ah, ok. | 20:37 |
| jam | namely: 4580 Canonical.com Patch Queue Manager 2009-07-31 [merge] | 20:37 |
| jam | (jam) Support SIGBREAK on Windows dropping you into the debugger. | 20:37 |
| sidnei | xactly | 20:37 |
| sidnei | jam: whats your complaint about the WD? | 20:38 |
| jam | sidnei: building the installer creates about 10 directories in tools/win32 | 20:39 |
| jam | which means "bzr status" is no longer clean | 20:39 |
| sidnei | jam: where should they be created? under build? | 20:39 |
| jam | sidnei: something like that | 20:39 |
| sidnei | jam: makes sense | 20:40 |
| jam | sidnei: working on it now | 20:40 |
| nevans | I'm looking for the simplest command line to restore a previously deleted file/dir (assuming that I know the rev id that I want) | 20:50 |
| nevans | "bzr cp foo/bar@123 foo/bar" was my first instinct (coming from svn-land) | 20:51 |
| Raim | nevans: bzr revert foo/bar restores the file | 20:54 |
| nevans | oh yeah. | 20:54 |
| Raim | nevans: think like reverting the deletion | 20:54 |
| nevans | :) | 20:55 |
| jam | sidnei: so since i'm creating this new location, would it make sense to always nuke it as part of "make installer-all" ? | 20:55 |
| jam | and I'm getting the same failure with 1.0rc5 | 20:55 |
| sidnei | jam: im investigating the failure, seems like an actual bug | 20:56 |
| sidnei | jam: not sure about nuking, i would prefer it to be part of make clean | 20:56 |
| nevans | Raim: hmm... no luck. | 20:56 |
| jam | sidnei: so the way "build_release" works, is that it keeps branches of everything it wants | 20:56 |
| nevans | bzr revert -r 123 foo/bar just does nothing. | 20:56 |
| jam | but then nukes a new directory | 20:57 |
| jam | and stages everything into that | 20:57 |
| jam | so it doesn't necessarily do a fresh download of everything | 20:57 |
| jam | but it *does* copy everything into a clean build location | 20:57 |
| jam | sidnei: revno 4583 of my branch now stages everything into a 'build-win32' directory | 20:57 |
| nevans | it's possible that the containing dir was also deleted at some point (and then recreated). but I don't even get a conflict | 20:57 |
| sidnei | jam: yeah, i remember that. | 20:58 |
| sidnei | jam: i would say go for it then. | 20:58 |
| Raim | nevans: maybe I did not understand you correctly, but you just deleted a file and want the last version back, right? why would you need a revision number? | 20:58 |
| nevans | ahh! I just figured it out. It turns out that I never *actually* deleted the file dir. | 20:58 |
| nevans | I simply moved it from src/foo to src/shelved/foo | 20:58 |
| jam | sidnei: so the main problem is that it is going to download everything from remote *from scratch* based on what I'm seeing now | 20:59 |
| jam | (it seems to copy everything into $project) | 20:59 |
| nevans | so, when I tried to "bzr src/foo/bar", that was a no-op, because src/foo/bar actually still exists in my HEAD (albeit in a different location) | 20:59 |
| jam | which would be inside $BUILD/$project | 20:59 |
| nevans | however, when I ran "bzr revert -r 123 src/foo" it renamed src/shelved/foo back to src/foo | 21:00 |
| sidnei | jam: ok, found the bug. the 'strict' recipe is out-of-sync with the other one, i have a branch ready to merge to fix that. i will make a release with this asap | 21:00 |
| jam | k | 21:00 |
| nevans | Raim: to answer your question, it wasn't *just* deleted. I thought it was deleted a long time ago. | 21:00 |
| sidnei | jam: you can change where it's checked out, just change the 'destination' | 21:00 |
| nevans | when actually it was merely renamed a long time ago. | 21:01 |
| jam | it seems to be trying to re-use my local shared repo, which means it inherits certain flags like "by default don't create working trees" | 21:01 |
| sidnei | jam: for the [bzr] part, set the shared-repo to true | 21:01 |
| sidnei | jam: that makes it create a new shared-repo | 21:01 |
| jam | sidnei: though for testing, I don't really want to wait 10min for it to download bzr from scratch... :) | 21:01 |
| sidnei | jam: eh :) | 21:02 |
| jam | as long as it is only bzr, its probably fine | 21:02 |
| sidnei | jam: for landscape, i've made 'destination' a configurable option and i pass it a path outside the tree | 21:02 |
| sidnei | jam: so all checkouts are on a central directory | 21:03 |
| jam | sidnei: so gf.recipe.bzr has another small bug | 21:04 |
| jam | it seems to assume that "bzr branch $OTHER" will create a local working tree | 21:04 |
| jam | but you can create a local repo and set "no_working_trees" | 21:04 |
| jam | which is how mine work | 21:04 |
| jam | works | 21:04 |
| sidnei | jam: true. is there a command line option to force working tree? | 21:04 |
| jam | sidnei: so there is "bzr branch --no-tree" I don't know if the other way works | 21:06 |
| jam | checking | 21:06 |
| jam | no, it looks like the flag only disables creating a tree | 21:07 |
| jam | setting it to True, gets overridden by the repository policy | 21:07 |
| jam | you *can* do "bzr checkout ." to make it create a workingtree | 21:07 |
| sidnei | jam: so bzr checkout after bzr branch | 21:09 |
| jam | potentially | 21:09 |
| jam | I'm trying to understand gf.recipe.bzr a bit to be sure | 21:09 |
| jam | sidnei: shouldn't bzr_strict inherit from bzr ? | 21:10 |
| jam | (or something to that effect) | 21:10 |
| jam | I suppose you could do "bzr get --no-branch" and then "bzr checkout ." after that | 21:11 |
| jam | which should always succeed | 21:11 |
| jam | otherwise I'm not sure what "bzr checkout ." does when you already have a checkout | 21:11 |
| sidnei | jam: that could work | 21:13 |
| jam | sorry "get --no-tree" :) | 21:13 |
| === zirpu2 is now known as zirpu | ||
| jam | sidnei: so without :strict (since it is currently broken) if it fails to get the branch at all | 21:25 |
| jam | it then fails during "os.chdir()" | 21:25 |
| jam | rather than giving you the error at the time it happened | 21:25 |
| jam | namely, that it can't get the code... | 21:25 |
| jam | anyway, I don't quite understand why the default isn't strict | 21:26 |
| jam | but hey, I'm not the one writing it | 21:26 |
| * SamB wishes Python supported compacting collection ... | 21:27 | |
| sidnei | jam: strict wipes out the branch if it fails to pull *wink* | 21:27 |
| jam | also, it seems that gf.recipe.bzr requires that you have a valid "bzr.exe" in your path, as Ihave 'bzr.bat' and a really old version of bzr.exe | 21:27 |
| jam | hmm | 21:28 |
| jam | failing the build because you failed to pull | 21:28 |
| jam | is different than nuking a dir | 21:28 |
| sidnei | jam: i agree. it should never nuke a dir. i am not using strict because of that, so i should fix it | 21:28 |
| sidnei | jam: if you get your old version of bzr.exe out of the path, it should call bzr.exe i believe | 21:29 |
| sidnei | s/exe/bat on the latter | 21:29 |
| jam | http://paste.ubuntu.com/239952/ | 21:30 |
| jam | "no such file" | 21:30 |
| jam | http://paste.ubuntu.com/239953/ | 21:30 |
| jam | works if I explicitly state "bzr.bat" | 21:30 |
| jam | let me try it in a different shell | 21:31 |
| sidnei | jam: pass 'shell=True' | 21:31 |
| jam | ah, yeah, shell=True changes that | 21:31 |
| sidnei | jam: does it call bzr.bat then? | 21:32 |
| jam | sidnei: yes | 21:32 |
| jam | and gf does use shell=True | 21:32 |
| sidnei | jam: awesome. that's the intended behaviour | 21:32 |
| jam | sidnei: I was wondering if we could get it to run the local copy of bzr | 21:33 |
| jam | but that is probably a pain to get working | 21:33 |
| sidnei | jam: uhm, that could work. maybe an option to the gf.recipe.bzr recipe 'executable=/path/to/bzr.py' | 21:34 |
| jam | sidnei: yeah, I'm not sure that it is generally useful | 21:34 |
| jam | as only *bzr* is going to have that | 21:34 |
| sidnei | jam: or people that don't have bzr in the PATH | 21:34 |
| jam | while gf.recipe.bzr is about building everything else with bzr as just a mechanism to get the code | 21:34 |
| sidnei | (or even more than one bzr in the PATH) | 21:35 |
| jam | sidnei: also, how does all of this work if you want to try packaging $TIP for bzr + plugins? | 21:35 |
| jam | The idea being a "nightly" build | 21:35 |
| jam | is it that you would use $TIP for bzr, but explicit versions for everything else? | 21:35 |
| sidnei | jam: should work both ways. did i show you this? http://buildbot.sidneidasilva.com/ | 21:36 |
| sidnei | argv: ['make', 'installer-all', 'BZR_TARGET=release', 'PLUGIN_TARGET=plugin-dev',... | 21:36 |
| jam | So I think I have the "boostrap" stage all working | 21:41 |
| jam | I get to the point of: | 21:41 |
| jam | cd build-win32 && bin/build-installer.bat release plugin-release | 21:41 |
| jam | Removed: c:\Users\jameinel\dev\bzr\work\build-win32\release\bzr.1.17 | 21:41 |
| jam | so it seems like it makes it all the way to the end | 21:42 |
| jam | but "build-installer.bat" sort of falls over | 21:42 |
| jam | now, it could be that "foo.bat" can't find my "make" | 21:42 |
| jam | as I have make in cygwin | 21:42 |
| jam | but not a mingw32 or other more "pure windows" make | 21:43 |
| sidnei | jam: could be. is it in your PATH? | 21:43 |
| jam | well running "cmd.exe" and then typing "make" | 21:44 |
| jam | seems to find it | 21:44 |
| sidnei | should be enough | 21:45 |
| jam | so, is there a way to get the .bat file to say something about what is going wrong? | 21:45 |
| jam | or alternatively, why are we using .bat here, rather than python? | 21:46 |
| sidnei | jam: no specific reason, other than passing environment variables in python is a little more sucky | 21:50 |
| jam | sidnei: just to set PYTHONPATH? | 21:51 |
| sidnei | jam: no, there's a boatload of environment variables in build-installer.bat, check it out | 21:52 |
| sidnei | jam: is there a way to make a branch remember its pull location without doing 'bzr pull --remember'? i wanted 'bzr get --remember' | 21:52 |
| jam | ah sure | 21:52 |
| jam | sidnei: "bzr get" defaults to remember | 21:52 |
| jam | or I should say | 21:52 |
| jam | if you are creating a new branch it should remember its source automatically | 21:53 |
| jam | sidnei: Popen(env = {dict}) doesn't seem that bad to me | 21:53 |
| sidnei | so 'bzr get BRANCH' followed by 'bzr pull' with no args should work just fine? | 21:53 |
| jam | sidnei: yes | 21:53 |
| * sidnei fixes gf.recipe.bzr once more | 21:54 | |
| sidnei | jam: im fine with rewriting it as a python script, just that it sounded like too much work at the time. not sure it will gain you anything though | 21:54 |
| jam | sidnei: easier for *me* to support :) | 21:55 |
| jam | won't gain a lot today, sure | 21:55 |
| jam | more about maintenance, etc | 21:55 |
| jam | I guess what it would give me right now is a way to drop into pdb to figure out why it thinks it is building just fine, but I'm not actually getting any results | 21:57 |
| sidnei | jam: there's no output at all? | 21:58 |
| jam | sidnei: I showed you the output | 21:58 |
| jam | it seems to build everything | 21:58 |
| sidnei | jam: it should exit with an errorcode if it it fails | 21:58 |
| jam | well, dependencies | 21:58 |
| jam | and then I get: | 21:58 |
| jam | root is c:\Users\jameinel\dev\bzr\work\build-win32 | 21:58 |
| jam | Removed: c:\Users\jameinel\dev\bzr\work\build-win32\release\bzr.1.17 | 21:58 |
| jam | with exit code 0 | 21:58 |
| sidnei | doesn't sound right | 21:59 |
| * sidnei checks | 21:59 | |
| jam | (I added the "root is" line) | 21:59 |
| jam | It removes the directory, seems to checkout a new directory | 21:59 |
| jam | and then stops | 21:59 |
| sidnei | jam: that's all checked in to your branch? i will give it a try | 22:01 |
| jam | the message isn't | 22:01 |
| jam | but having everthing "work" is checked in | 22:01 |
| jam | ah, let me push | 22:01 |
| jam | sidnei: rev 4586. | 22:02 |
| jam | if I remove the @echo off | 22:03 |
| jam | line | 22:03 |
| jam | it does the checkout | 22:03 |
| jam | and then just stops | 22:03 |
| jam | oh I know why.... | 22:03 |
| jam | bzr.bat | 22:03 |
| jam | calling a .bat file *from* a .bat file | 22:03 |
| jam | transfers control | 22:03 |
| jam | and stops running locallly. | 22:03 |
| jam | thats a reason to use python | 22:03 |
| sidnei | :P | 22:03 |
| jam | using "CALL bzr" makes it return control | 22:04 |
| sidnei | jam: try adding '%COMSPEC% /c' before bzr | 22:04 |
| sidnei | or that yeah | 22:04 |
| jam | but I don't know what it does if it is a .exe | 22:04 |
| sidnei | %COMSPEC% will work with an exe | 22:04 |
| sidnei | i am mostly confident | 22:05 |
| jam | right, it is just effectively "sh -c" | 22:05 |
| sidnei | yup | 22:05 |
| jam | so it at least gets to the point of: | 22:05 |
| jam | c:\Python25\python.exe: can't open file 'setup.py': [Errno 2] No such file or directory | 22:05 |
| jam | and I think *that* is because I don't have checkouts | 22:05 |
| sidnei | seems so | 22:05 |
| jam | k, 4587 uses COMSPEC | 22:08 |
| jam | now I'm having failures related to 'msginit' | 22:08 |
| jam | seems I have a copy on my path that doesn't work | 22:08 |
| jam | man, getting the dependency stack for pygtk on windows sucks | 22:18 |
| jam | everything is a .zip download | 22:18 |
| jam | and there are all sorts of version questions | 22:18 |
| sidnei | jam: you will start bundling pygtk in the installer too? | 22:18 |
| jam | no | 22:18 |
| jam | It is just where I have "msginit" on my system | 22:19 |
| jam | k, found another small problem with "rebase" vs "rewrite" | 22:25 |
| sidnei | jam: i made a release of gf.recipe.bzr with a fix for strict and a couple others that were pending merge, want to try that? | 22:29 |
| sidnei | jam: 1.0rc7 it is | 22:30 |
| jam | sure | 22:30 |
| jam | I assume I just change the version nmu? | 22:30 |
| jam | num? | 22:30 |
| jam | (and add :strict back) | 22:30 |
| sidnei | jam: yep | 22:31 |
| jam | sidnei: so I'm getting a failure now ,because qbzr optionally supports pygments, and py2exe is failing when it tries to import pygments | 22:31 |
| jam | any suggestions? | 22:31 |
| jam | would we put that into boostrap ? | 22:31 |
| jam | or is it just use whatever people have installed | 22:31 |
| jam | like we do for PyQt etc | 22:32 |
| sidnei | jam: depends on how hard it is to get pygments in. if it's trivial, i would add it | 22:32 |
| sidnei | i guess size also matters | 22:32 |
| jam | well, it is an "easy_install" sort of thing | 22:33 |
| jam | I think we want it in the final package | 22:33 |
| jam | PyQt dominates the size of everything else | 22:33 |
| sidnei | jam: let's do it then | 22:33 |
| jam | I'm pretty sure it is installed on kerguelen | 22:34 |
| jam | sidnei: of course, we aren't staging PyQt at this time | 22:34 |
| jam | how does buildout handle the fact that you may have libs in your python install | 22:34 |
| jam | which differ from what you are building | 22:34 |
| sidnei | jam: there are some recipes that can be told to ignore all of site-packages in your python install | 22:36 |
| sidnei | jam: gary is polishing that up for launchpad usage | 22:36 |
| sidnei | jam: but that's different from what we are doing, which is to call 'python setup.py py2exe', going completely around that | 22:37 |
| jam | sidnei: so far, 1.0rc7 "just works" for me | 22:39 |
| sidnei | jam: there is a way of generating a 'custom interpreter' with buildout, which would mean we can get things installed locally without polluting the system-wide site-packages, but i wonder if that will play well with py2exe | 22:39 |
| jam | sidnei: well, you could boostrap into downloading python.msi and installing it to a local dir, etc | 22:39 |
| jam | so it seems that on kerguelen, if I use setuptools c8 (like I have here) it fails with the same "incompatible" error | 22:40 |
| jam | (just opposite) | 22:40 |
| jam | so perhaps I'll just install c9 here and live with it | 22:40 |
| sidnei | jam: that's probably a good idea | 22:42 |
| sidnei | c8 is like 2 years old by now ainnit? | 22:42 |
| jam | well not much older than that | 22:43 |
| jam | this machine isn't much more than 1.5 yrs old | 22:43 |
| jam | can you update setuptools using setuptools? | 22:45 |
| sidnei | jam: you can! easy_install -U setuptools | 22:45 |
| sidnei | on windows you might need to call it with python easy_install-script.py | 22:45 |
| sidnei | otherwise it fails to replace the .exe | 22:46 |
| sidnei | (easy_install.exe that is) | 22:46 |
| sidnei | jam: if you want to give the buildout python thing a try, see the section 'custom interpreter' on this page: http://grok.zope.org/documentation/tutorial/introduction-to-zc.buildout/recipes-to-install-eggs-scripts-and-custom | 22:46 |
| sidnei | jam: if you add eggs = Pygments there, then run setup.py with the the generated 'bin/py', it *might* work | 22:47 |
| jam | sidnei: Couldn't find index page for 'zc.recipe.eggs' (maybe misspelled?) | 22:49 |
| jam | ahh, singular | 22:49 |
| sidnei | jam: yes, mispelled, it's 'egg' | 22:49 |
| jam | well zc.recipe.egg:eggs | 22:50 |
| jam | so the plural form is in there | 22:50 |
| sidnei | eh | 22:50 |
| jam | sidnei: hmm... that gets me to the point where it thinks "build-win32/subvertpy" should be a checkout | 22:51 |
| jam | when the checkout should be "build-win32/subvertpy/release" | 22:51 |
| jam | perhaps a bug in gf? | 22:51 |
| sidnei | jam: could be, traceback? | 22:51 |
| jam | http://paste.ubuntu.com/240101/ | 22:53 |
| sidnei | jam: your branch is pushed? | 22:56 |
| jam | sidnei: everything except the 'zf.recipe.egg' stuff | 22:56 |
| jam | I get the same failure without it | 22:56 |
| jam | it seems that :strict and uninstall aren't playing well together | 22:57 |
| jam | though getting rid of :strict seems to cause the same failure | 22:57 |
| sidnei | jam: yeah, uninstall is called by both. removing the directory manually will get you going for now, while i figure out what's wrong | 22:58 |
| jam | on kerguelen it is up to "getting trunk for bzrtools" | 22:59 |
| jam | sidnei: if I delete subvertpy, then it has the same failure for bzr-rewrite | 22:59 |
| jam | I have the feeling, it is going to keep chaining until it is all deleted | 22:59 |
| sidnei | jam: yeah, all of them | 22:59 |
| jam | though maybe it is because I did a manual "bzr co" ? | 22:59 |
| jam | so it doesn't actually build at home because I don't have VC9 | 23:00 |
| jam | weird, transient error downloading svn-lib | 23:01 |
| jam | Connection Refused now | 23:01 |
| jam | of course, it doesn't do anything nice like tell me what url it couldn't download: | 23:01 |
| jam | http://paste.ubuntu.com/240118/ | 23:01 |
| sidnei | ;/ | 23:02 |
| sidnei | jam: i figured the uninstall problem | 23:02 |
| sidnei | jam: os.listdir() found the .bzr dir, because of the shared-repo | 23:03 |
| jam | ah, so it says there is something there other than just the directories it knows to remove? | 23:04 |
| sidnei | jam: well, it's a plain bug. it tries to do 'bzr st .bzr' :) | 23:06 |
| jam | oops | 23:07 |
| jam | it seems subversion.tigris.org is down right now anyway... | 23:08 |
| jam | so not much I can do to try it at this point | 23:08 |
| jam | not a big deal | 23:08 |
| jam | as I should have stopped working 10 min ago :) | 23:08 |
| sidnei | me too :) | 23:09 |
| sidnei | jam: what timezone are you on? | 23:09 |
| jam | central US | 23:10 |
| jam | chicago | 23:10 |
| jam | what about yourself? | 23:10 |
| sidnei | jam: BRT (GMT-3), freezing southern brazil | 23:10 |
| jam | interesting, as I'm GMT-5 | 23:11 |
| jam | I guess you work later than I do :) | 23:12 |
| sidnei | yes, i work from 10-8 with long break for lunch | 23:13 |
| jam | sidnei: well thanks for working on this with me | 23:15 |
| jam | I think it is close | 23:15 |
| jam | will you be available at all on Mon? | 23:15 |
| sidnei | jam: it's been a pleasure! thanks for pushing me! | 23:15 |
| sidnei | jam: i will | 23:15 |
| jam | k, I'll see you around then | 23:15 |
| jam | hopefully the subversion web host will be back up :) | 23:16 |
| sidnei | jam: except 16UTC, for an irc meeting, but that should be no trouble | 23:16 |
| sidnei | see ya! | 23:16 |
| sidnei | jam: fwiw, i made a 1.0rc8 of gf.recipe.bzr with the fix for uninstall | 23:32 |
| * sidnei disappears now | 23:32 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!