[00:04] i have several different projects in their own branches, i want to tag them all with the same tag (because they are bundled together in a release). Is there an easier way to this than individually tagging every branch? [00:04] like a 'virtual' branch that points to all the projects? [01:13] out of curiosity, does bzr have the ability to update all branches in a given tree. so if I have main repo A, have in that tree have repo's B & C, is there a bzr update --all style of command that will update all repos in the given branch/tree? [01:14] spm: your choice of terminology is a bit weird, but IIRC bzrtools includes a repo-pull or multi-pull or something command that will find branches under your cwd and pull in all of them [01:14] spm: (and maybe the new colocated branches have something along these lines?) [01:15] spiv: hola. right that's pretty much what I was chasing - sorry, was talking svn/bzr with some sysadmin mates, and hence the weirdness. [01:20] o/ spm, spiv [01:20] o/ poolie [01:22] spm: also config-manager can do that [01:23] spm: when you're dealing with N-trees (vs N-branches of one tree) [01:23] lifeless: yup. that was the one I was directly aware of; this was more of a can bzr do a more naive implementation to what cm does [01:23] the context was a (brief) discussion wrt svn externals; I was idly curious if bzr had similar - outside of cm [01:24] not that I expect to convert them, yet; but hey. :-) [01:24] cm, blast from the past! [01:38] bob2: there is an internal doc on best practice for dev& deploys [01:39] bob2: unknown to me, -ops have been using cm all this time; said doc mandates continued use [01:39] haha [01:41] ironically, LP has reinvented it with a different name, but -ops still use cm to do the deploys [01:41] by ironic, I mean hahaonlyserious [02:11] fascinating [02:11] surprised no one noticed earlier [06:43] spiv: I'm coming to sydney fri/sat/sun; any chance of catching up with you three? [06:43] lifeless: hmm, probably! [06:53] spm: there are also bzr-externals and scmproj [06:55] ahh cool, thanks! [07:40] spiv: my itinerary is poolies thing on friday, hack day with erik on sat, possibly yum cha, or possibly $whatveer sun, 4pmish to airport [07:59] morning all! [08:03] mgz: hey [08:04] * fullermd ambushes vila. [08:04] . o O (Stay still or run ?) [08:04] So, speaking of bug 964171, which we totally weren't ;p [08:04] Launchpad bug 964171 in Bazaar "date:today in log broken in 2.5+" [Undecided,Incomplete] https://launchpad.net/bugs/964171 [08:05] Last you left it in Incomplete, where it's in danger of getting auto-reaped at some point. Is there something needed from me on it? [08:05] ha damn, this one has already overflowed my list twice :-/ [08:06] so, I think I wanted feedback about whether this was specific to some branches and reproducible with all bzr versions [08:06] It failed for me with 2.5 and .dev, but worked with 2.4 (didn't try earlier, but...) [08:07] Pretty sure I tossed together a scratch branch and it acted the same. [08:07] I think jelmer could shed some light there too which is why I subscribed it [08:08] s/it/him/ damn it [08:08] * jelmer if vila is suggesting he is genderless :) [08:08] % bzr revision-info -rtoday [08:08] bzr: ERROR: Requested revision: 'today' does not exist in branch: file:///tmp/bzr/t/A/ [08:08] pfew, fixed the tyop faster ;) [08:08] % \bzr revision-info -rtoday [08:08] bzr: ERROR: Requested revision: 'today' does not exist in branch: file:///tmp/bzr/t/A/ [08:08] % ~/src/bzr/back-branches/2.4/bzr revision-info -rtoday [08:08] 1 fullermd@over-yonder.net-20120411080736-0x9pjobhkv3gryaq [08:09] (.dev, 2.5, and (obviously) 2.4, respectively) [08:10] fullermd: it's definitely a bug [08:13] 'k. Can we move it to Confirmed or something? I don't so much care about "ZOMG we need to fix this today", but if it's in Inc and gets killed off by LP's autoreaper, it'll make things so much harder for me to act smug and point at "see, I totally already reported that" down the road. [08:13] (and after all, that's the important part of the process, right?) [08:14] fullermd: :) [08:14] fullermd: done [08:15] Oh, hm, it looks like "I.e. when -rdate: is the branch tip" is a point too. [08:16] If I stuff another rev on the branch (so both 1 and 2 are today), .dev and 2.5 properly give back rev 1. [08:16] I guess this is bzr's way of subtly hinting that I should be getting more work done before asking it questions. [08:19] Hm, didn't we fix all the compile warnings at some point? I get a handful of the pointer->integer cast warnings. [08:20] fullermd: I think I've always seen them [08:21] Hm. I don't get them with clang. Little odd. [08:23] Shows up another oddity though; `gmake CC=clang` changes the compiler used in the compile steps, but it still uses 'cc' for the linking. Not quite exactly a bug maybe, but unexpected. [08:24] Anyway. Better stop looking for excuses to not be working... [10:35] Anyone fancy looking at an UDD MP for me? https://code.launchpad.net/~maxb/udd/environment-setup/+merge/101307 [10:57] maxb: seems pretty reasonable to me, might just want vila to look it over too [11:06] maxb: the scripts have been rewritten by jml/james_w because they want to reuse udd in a different context so they wanted some dependencies *out* of the scripts (adding pkgimport.conf starts addressing that), putting everything *in* again goes in the opposite direction, you should see with them to reach a consensus [11:08] maxb: have a look at udd/iconfig.py too which already defines pi.install_dir and pi.base_dir based on _root_dir that you're duplicating with udd_scripts_root [11:09] * vila bbl [11:22] jelmer: hah. Now of course I run into subvertpy missing probe_transport() is called.. [11:22] _when_ probe_transport() is called [11:25] LarstiQ: it seems reasonable enough to require subvertpy for that [11:26] vila: jml / james_w are welcome to re-use the udd.* modules, but making our bin/ scripts do the right thing when invoked without wrapper shell scripts shouldn't affect them, I would think [11:27] maxb: I haven't looked at this change in particular (kind of caught up in something else atm).... [11:27] maxb: but personally, I think the best thing we can do for this code-base is to split the "watch packages on Launchpad" bit away from the "import packages into branches" bit. [11:29] Sure, but right now I just want scripts that don't die if I don't have a PYTHONPATH set :-) [11:29] jelmer: it looked a bit funny trying to pull from a colocated branch, but I can't seem to reproduce it [13:01] maxb, what we have done on other projects is add a py.sh file by some other means (i.e. puppet) that sets the variables for the specific deployment [13:02] I don't see any reason why the python scripts can't set up at least their path sanely all by themselves [13:03] Do you use bin/* in your other use of the udd code at all? [13:04] hi. What is the most likely cause of such an error ? http://paste.pocoo.org/show/579483 [13:14] maxb, we do [13:14] maxb, the "watch packages on Launchpad" part [13:14] Hm, that's a surprise, many of them are highly specific [13:14] add-import-jobs, mass-import etc.¸ but not "import-package" [13:14] requeue-package is the odd one out [13:14] as we need it, but not the zap-revids stuff [13:15] Right. Well, even so, I don't think the changes in my MP would break anything per se, though some of them would be unnecessary [13:17] oh, the BZR_EMAIL one would be undesirable [13:18] Much of the environment setup could probably be moved into bin/import-packaet [13:21] mgz: congratulations, you've been given commit access to testtools :) [13:24] ha, thanks jml [13:25] alas I don't have any branches that need sneaking through without review to abuse my new position [13:25] mgz: heh. [13:26] mgz: I have a branch that needs review, which you're welcome to. But I might wait for lifeless to give it a shot anyway. [13:28] hm, subunit tag stuff, would be good for lifeless to look at that indeed === yofel_ is now known as yofel === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck === yofel_ is now known as yofel [22:42] hi all