poolie | fullermd, is it broken or just not loading? | 00:19 |
---|---|---|
fullermd | bzr: ERROR: exceptions.AttributeError: 'GlobalConfig' object has no attribute '_get_filename' | 00:23 |
mgz | looks like r5395, which appears to try and keep compat, wonder why it broke. | 00:29 |
mgz | ask vila tomorrow fullermd. | 00:30 |
fullermd | Oh, cool. I'll tell him you made me pounce him first thing ;) | 00:30 |
dOxxx1 | good evening... | 00:34 |
=== dOxxx1 is now known as dOxxx | ||
dOxxx | jelmer: Are r302-305 of bzr-fastimport compatible with bzr 2.3.0? I'm currently building r301 with the mac installers. Can I update it to r305? | 00:35 |
poolie | hi d0 | 00:35 |
poolie | dOxxx, | 00:35 |
dOxxx | hey poolie | 00:35 |
dOxxx | poolie: do you know the state of bzr-fastimport compatibility with bzr 2.3? | 00:36 |
dOxxx | there hasn't been a release since 2009 :P | 00:36 |
poolie | i don't know | 00:37 |
poolie | it was somewhat of ian's own project, though it is obviously useful to have generally | 00:37 |
poolie | jelmer expressed an interest in looking after it | 00:37 |
dOxxx | I see | 00:37 |
poolie | lifeless, what is 'pipefile in makefile' | 00:39 |
lifeless | pipefail sorry | 00:40 |
poolie | ah | 00:40 |
lifeless | *if* you make bzr selftest --subunit exit with nonzero | 00:40 |
lifeless | then you'l *also* need to set pipefail | 00:40 |
lifeless | otherwise the exit code will be ignored and swallowed by the pipeline | 00:40 |
poolie | if we make it exit nonzero, we should no longer need a pipeline afaics | 00:40 |
poolie | or do we? | 00:41 |
lifeless | thats an option too | 00:41 |
lifeless | depends on whether you want a human summary or not | 00:41 |
lifeless | pqm can interpret subunit for you these days | 00:41 |
lifeless | [which is another thing you might want to do in tarmac) | 00:41 |
poolie | so... | 00:43 |
poolie | does pqm do anything with the selftest.log file, or is that just there so we can run subunit-stats on it? | 00:43 |
poolie | or another way to ask is, what is the interface expected by pqm? | 00:43 |
poolie | just that you'll emit subunit to stdout? | 00:43 |
lifeless | pqm looks at stdout | 01:01 |
lifeless | and at the overall exit status | 01:01 |
maxb | Urgh, transition from python-central to python-support in 2.3.0-1 packaging. That'll be fun. I'll need to do something special for hardy IIRC | 01:10 |
maxb | dOxxx: bzr-fastimport 305 is in sid. I think you may safely assume that that means it's compatible with 2.3.0 | 01:11 |
maxb | but yes, a release would be nice :-) | 01:12 |
maxb | FWIW my list of things that appear to need releases based on the ppas is: | 01:12 |
maxb | bzr-fastimport bzr-gtk bzr-loom bzr-rewrite bzr-svn python-fastimport qbzr | 01:13 |
spiv | james_w: https://bugs.launchpad.net/udd/+bug/653307 just gets more and more confusing and alarming | 01:49 |
james_w | erk | 01:49 |
james_w | any idea how that could happen? | 01:50 |
spiv | james_w: in general, yes, but as I said in comment #7 I don't see any suspicious code at all | 01:58 |
james_w | hmm | 01:59 |
spiv | james_w: the way it generates commits seems completely typical and kosher | 01:59 |
james_w | spiv, you re-imported that package from nothing? | 01:59 |
spiv | I haven't, but I thought all the affected packages had all their branches deleted? | 02:00 |
spiv | Or rather, I did reimport locally, and with no trouble | 02:00 |
spiv | Although it's almost impossible to imagine seeing this problem during a signel, intial import run. | 02:00 |
spiv | Because that all happens in a single, shared inventory. | 02:01 |
spiv | s/inventory/repository/ | 02:01 |
james_w | yeah, we deleted all the branches, but didn't re-import with the newer bzr | 02:01 |
james_w | so I wonder if it's still a fixed bug? | 02:01 |
* spiv rereviews the fixed bugs in 2.1 vs now | 02:02 | |
spiv | (because it's not the non-canonical one that had seemed likely, although I'm very glad we aren't using that version of bzr anymore!) | 02:02 |
=== Ursinha is now known as Ursinha-gone | ||
spiv | james_w: is there an easy way to do a local test run of just importing squeezy and then a second run to import sid? | 02:09 |
james_w | spiv, I don't think so | 02:10 |
* spiv hmms | 02:10 | |
spiv | james_w: I'm still puzzled by the Feb 2010 timestamps on the files in the supposedly-deleted-then-recreated branches, too. | 02:12 |
james_w | spiv, why's that? | 02:13 |
spiv | james_w: well I'd expect Jan 2011, as that's when the new branches were pushed to LP? | 02:13 |
james_w | spiv, true | 02:14 |
james_w | spiv, are you talking about working tree files after a checkout, or the branch/repo files on LP? | 02:14 |
spiv | Repo files, e.g. look at http://bazaar.launchpad.net/~ubuntu-branches/debian/squeeze/dsdo/squeeze/.bzr/repository/packs/ | 02:14 |
james_w | hmm | 02:16 |
james_w | 2010, you're right, that doesn't make a lot of sense | 02:16 |
spiv | Compre e.g. http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/packs/ in case you're wondering if it's something weird in the webserver :) | 02:16 |
spiv | So if for some reason the old branches weren't deleted we're *still* at the point where we haven't ruled out "ancient bzr/udd/builddeb/launchpad bug, fresh import will fix" | 02:18 |
spiv | But I'm not sure how thaey can't be deleted, because I'm preetty sure I was watching it happen :) | 02:18 |
james_w | yeah | 02:19 |
james_w | unless deleting via the webservice doesn't nuke things like we assumed | 02:20 |
james_w | but that seems very unlikely given that branches on disk are based on db ids | 02:20 |
james_w | maybe we need to try delete + reimport again | 02:21 |
mwhudson | 00/00/c9/3e is quite an old id too fwiw | 02:21 |
mwhudson | new branches are up in the 00/01/xx/xx space | 02:21 |
james_w | so old branch seems to be the most likely candidate right now | 02:22 |
spiv | mwhudson: higher, apparently: 00/06/0f/2a is the natty branch of dsdo | 02:22 |
mwhudson | spiv: oh ok | 02:22 |
mwhudson | my point still stands :) | 02:22 |
spiv | (time to start planning for expanding that ID column? :) | 02:23 |
dOxxx | maxb: thanks :) | 02:24 |
mwhudson | spiv: nah, you guys just have to implement colocated branches soon! | 02:25 |
* mwhudson afk for a bit | 02:25 | |
maxb | hmm. bzr-gtk build failure in natty | 02:27 |
* maxb creates a cowbuilder chroot | 02:28 | |
maxb | "Xvfb failed to start" | 02:51 |
maxb | This is NOT a useful error message :-( | 02:51 |
maxb | (bzr-gtk/jaunty) | 02:52 |
dOxxx | nope :) | 02:52 |
maxb | Just for complete bizarreness, it works fine on hardy and karmic | 02:52 |
achiang | hm, i was just surprised by some debcommit behavior, which i suppose is an issue there, not bzr. but maybe someone can enlighten me anyway... | 03:05 |
achiang | make a bunch of changes to files, but only 'bzr add foo bar' | 03:05 |
achiang | dch -a ; debcommit | 03:05 |
achiang | i would have expected a new commit with just a, b, and debian/changelog | 03:06 |
achiang | instead, i got everything. :-/ | 03:06 |
mwhudson | um, you are familiar with git i guess? | 03:08 |
achiang | i suppose this expectation comes from the fact that i'm used to git's index. :( | 03:08 |
mwhudson | bzr ci commits all changes by default | 03:08 |
mwhudson | there is nothing like the index | 03:08 |
achiang | yes, it is my fault | 03:08 |
lifeless | it does what everyone else in the world expects :P | 03:08 |
mwhudson | bzr ci is like git commit -a i think? | 03:08 |
dOxxx | mwhudson: yes | 03:08 |
lifeless | no | 03:08 |
achiang | yeah | 03:08 |
lifeless | it does'nt add new files | 03:08 |
dOxxx | no? | 03:08 |
mwhudson | oh right | 03:08 |
dOxxx | ah | 03:08 |
lifeless | all versioned files are recorded, unknown files remain unknown. | 03:09 |
lifeless | gone files become unversioned and are deleted in the commit | 03:09 |
achiang | lifeless: i mean, sure, i'm not here to start a holy war. but a large portion of "everyone else" uses git. :-/ | 03:09 |
achiang | but of course, the fault is mine in this case for having wrong expectations. | 03:10 |
achiang | re-reading the debcommit man page, i see that i should just call it with the files i want to commit next time | 03:10 |
achiang | ok, now this question *is* related to bzr -- i just did a bzr uncommit to recover from the bad debcommit | 03:14 |
achiang | it actually puts my tree back in the state before i did the debcommit, with uncommitted changes in the tree | 03:15 |
lifeless | thats right | 03:15 |
achiang | that is actually quite nice, but i am confused why it behaved that way? my reading of the uncommit man page makes me think that the -r -1 commit should just completely go away | 03:15 |
lifeless | it undoes the commit | 03:15 |
achiang | as if it'd never happened at all | 03:15 |
lifeless | the act of committing doesn't change the files you have on disk. | 03:15 |
lifeless | so neither does the act of uncommitting. | 03:16 |
achiang | interesting | 03:16 |
achiang | it also makes sense, the way you describe what commit/uncommit does | 03:16 |
achiang | lifeless: thanks for the help, i appreciate it | 03:17 |
lifeless | anytime | 03:17 |
achiang | (et al) | 03:18 |
james_w | whoops: http://package-import.ubuntu.com/status/libdbusmenu.html | 03:34 |
spiv | james_w: where "whoops" == "upgrade to bzr 2.3 broke stuff"? | 03:37 |
james_w | I assume so | 03:38 |
spiv | I only asked for an upgrade to 2.1.3, FWIW :) | 03:38 |
james_w | heh :-) | 03:38 |
james_w | I don't see it in the release notes | 03:39 |
poolie | hi all | 05:38 |
poolie | spiv, are you around? | 05:54 |
poolie | is https://code.launchpad.net/~spiv/bzr/fetch-all-tags-309682/+merge/42910 ready for re-review, or still WIP? | 05:55 |
spiv | poolie: I am, sort of | 05:59 |
spiv | poolie: power is still out, but jsut for my flat | 05:59 |
poolie | huh | 05:59 |
spiv | poolie: so currently chasing that up! | 05:59 |
poolie | good luck | 05:59 |
poolie | i was just going to quickly see if there was anything i should review | 05:59 |
poolie | but, perhaps i should instead do the whoami bug | 05:59 |
spiv | poolie: Off the top of my head all my patches are ready for rereview | 06:00 |
spiv | (It's a shame that's not a cleear yes/no at a glance, I wonder if I should do something differently) | 06:01 |
poolie | maybe you should resubmit when you get all the existing stuff done? | 06:02 |
poolie | that's not just you; i think just generally it's not clear when it wants more review | 06:02 |
spiv | *nod* | 06:06 |
* spiv has just run extension cables from the stairwell to the kitchen so the fridge can have power | 06:26 | |
vila | . o O (spiv: Safety first: make sure the beers stay cold, errrr the milk ! I meant the milk !) | 07:00 |
vila | hi all ! | 07:00 |
vila | fullermd: Oh dear, so sorry, I meant to look at that and... forgot :-/ | 07:01 |
vila | fullermd: but note that `bzr config mypush` (backquotes) can ~replace 'bm:mypush' starting with 2.3 and poolie suggested 'config:mypush' | 07:04 |
poolie | hi vila | 07:04 |
vila | poolie: hey ! | 07:05 |
* fullermd goes crosseyed trying to parse that... | 07:11 | |
vila | fullermd: huh ? And I thought you had some perl background... I didn't even quote single chars there... | 07:13 |
fullermd | Well, I _lexed_ it just fine :p | 07:14 |
spm | vila: perl has more use of shift-numbers = eg !&^%#@#*(&^)( | 07:14 |
spm | if it doesn't look like line noise, it's not perl :-) | 07:15 |
vila | spm: what's wrong with 'if ($c !~ /^%.*$/)' ? Crystal clear ! | 07:19 |
spm | dear lord. I can parse that. AAAAAAAAAAAAA | 07:20 |
spm | :-) | 07:20 |
fullermd | Oh, good. Now you're talking sense. | 07:20 |
spm | haha | 07:21 |
vila | spm: see ? This perl-is-noise meme is just crap ! :D | 07:22 |
vila | xml now... | 07:23 |
* spm digs up some old line noise captures to compare vs actual perl code, and finds the comparison... similar | 07:23 | |
fullermd | XML definitely isn't line noise. | 07:23 |
fullermd | Line noise serves an actual _purpose_... | 07:23 |
spm | fullermd: 1, vila/spm: 0 | 07:24 |
vila | LOL | 07:24 |
vila | ha, found back one of my favorite: 'local $/ ;' without comment :) | 07:25 |
fullermd | Yes, I have memories of stabbing people for crap like that... | 07:26 |
fullermd | Not legally actionable memories, of course. I feel a sudden burst of amnesia... | 07:26 |
vila | for those reading from home, this set the line separator to None so the next read on the *default* file will read until the end of file | 07:26 |
vila | fullermd: very useful trick, you should remember to put it inside a block to limit its side-effect though ;) | 07:26 |
fullermd | It's so much more self-documenting to just $x = join '', <FILE> | 07:26 |
vila | my $text ; { local $/ ; $text = <FILE> ; } isn't that bad | 07:30 |
vila | with a '# Slurp it into memory' comment just above | 07:31 |
fullermd | I still prefer the join. It doesn't need a comment, or screwing with magic vars. | 07:33 |
vila | bah, no magic vars ? You spoil the fun ! | 07:36 |
fullermd | Oh, no, I enhance it. I only use my OWN magic vars. Any fool can look up the _language's_ magic to work from; I like the bar for touching my code to be higher than that :p | 07:37 |
vila | local ftw ! | 07:40 |
fullermd | Any real win has global effect :p | 07:44 |
vila | spiv: wow, bzr@jubany upgraded to 2.3b5 !!?! | 07:50 |
vila | spiv: this means I should track *that* into bzr-package-importer so we also get that after the migration... | 07:51 |
vila | spiv: I did not dare to do it, but since you did... :) | 07:51 |
maxb | *headdesk* | 08:12 |
maxb | So, properly removing bzr's internal copy of configobj shows us that.... hardy's python-configobj lacks features which causes test failures | 08:13 |
vila | . o O (Quickly throw a pillow on maxb's desk) | 08:13 |
vila | don't do that then ? | 08:13 |
maxb | ah well, I'll just back out the removal in the hardy PPA | 08:14 |
maxb | yay unit tests, I suppose | 08:16 |
vila | indeed, we may miss some about the features we really require from configobj though | 08:17 |
fullermd | I dunno. I mean, it's hardly a coincidence that unit tests are responsible for a huge percentage of test failures... | 08:18 |
poolie | maxb, how long has hardy got to run? | 08:20 |
poolie | we could probably stop building bzr 2.4 for that | 08:20 |
maxb | desktop EOL at hardy release. server EOL at S-series release | 08:25 |
maxb | erm | 08:25 |
maxb | * hardy: desktop EOL at natty release. server EOL at S-series release | 08:25 |
vila | Z-series ? :D | 08:25 |
maxb | I am tempted to propose we drop all Jaunty packages, though | 08:26 |
fullermd | Taylor series? | 08:26 |
vila | maxb: +1 | 08:26 |
maxb | Jaunty is EOL already. Just no-one has turned off PPA for support for it | 08:26 |
maxb | I'll send an email to make it official | 08:27 |
maxb | hmm | 08:30 |
maxb | Except, dropping jaunty doesn't actually result in saved effort, since pretty much any backporting effort you need, is needed to get back so far as hardy too | 08:31 |
poolie | right | 08:32 |
poolie | i wonder if building _new_ bzr series onto hardy is worth while | 08:32 |
poolie | perhaps we should separately backport configobj? | 08:33 |
poolie | but as i recall that gets complicated because of dependencies from other programs | 08:33 |
poolie | and i think it's hard to get new configobj working there | 08:33 |
maxb | bzr includes a copy of configobj - but we removed it in these packages because Debian folks picked up on the unnecessary duplication. So we just need to unremove it on hardy | 08:34 |
vila | poolie: well, we had to decide what kind of support we want to provide for hardy, main includes bzr-1.3.1 only so I'd say we'd better limit ourselves to the stable ppa as I don't think we will ever be allowed to release even 2.0 there | 08:35 |
vila | (there == hardy-updates) | 08:35 |
maxb | It's now possible to get download count info out of the LP API. We should see how many downloads bzr 2.3.0/hardy gets | 08:36 |
poolie | right | 08:37 |
poolie | maxb, i was thinking of removing it from the upstream tree too | 08:37 |
poolie | anyhow, i should go | 08:37 |
poolie | good night to you | 08:37 |
vila | right, but that won't tell us how many hardy sites may want to upgrade | 08:37 |
vila | poolie: g'night | 08:37 |
poolie | vila, i wonder how many people want to upgrade bzr and don't even want to go to lucid | 08:38 |
poolie | probably some | 08:38 |
poolie | removing a copy of configobj would be nice but it's not a big win | 08:38 |
poolie | anyhow, really goodby | 08:38 |
vila | yup, probably not that much and we can tell them to use the ppa | 08:38 |
* fullermd . o O ( bzr said I needed to upgrade my old Ubuntu, so I installed FreeBSD... ) | 08:39 | |
vila | ENOMATCH: Ubuntu or * better*, don't forget the better :-p | 08:40 |
fullermd | :P | 08:41 |
fullermd | 2.3.0 port update: http://www.freebsd.org/cgi/query-pr.cgi?pr=154496 | 08:44 |
fullermd | miwi@ is fairly consistent, so probably committed in the next few days. | 08:44 |
vila | interesting diff... | 08:47 |
fullermd | Howso? | 08:48 |
vila | fullermd: the summary it provides is due to the FreeBSD process right ? | 08:48 |
vila | I mean, it gives an overview of which files were added (none removed apparently which is a bit weird) | 08:48 |
vila | ha, sorry, yes it does | 08:49 |
* fullermd isn't sure what you mean by 'summary'... | 08:49 | |
vila | pkg-list | 08:49 |
fullermd | pkg-plist, as in 'packing list'. Yeah, list of the files, so that deleting a package knows what to delete. | 08:50 |
vila | right | 08:50 |
vila | the whole diff contains almost no noise for a human reader (considering SHA as noise is a bit extreme but you get the idea) | 08:51 |
fullermd | Well, changing the big number in the launchpadlibrarian URL every upgrade is noisy for me :p | 08:52 |
vila | fullermd: blame your packaging system for not being able to follow redirections ? :-D | 08:52 |
fullermd | But yah, it's not an overly verbose process. The pkg-descr change I've meant to do the last handful of upgrades, but kept forgetting :p | 08:53 |
fullermd | Well, it's _able_. In fact, it goes to significant lengths to _avoid_ it :p | 08:53 |
vila | why ? | 08:53 |
fullermd | (for a number of reasons, most of which are probably bad...) | 08:53 |
vila | ha | 08:53 |
vila | some good ones worth mentioning maybe ? | 08:54 |
fullermd | The only potentially good one I've ever heard has to do with those "brilliant" sites which respond with redirects instead of 404's to nonexistent files, and that sort of garbage. | 08:54 |
vila | by the way, did I already asked you about some way to get a list of plugins with their releases/revids/revnos from The Ports ? | 08:55 |
fullermd | Leads to user confusion when the downloaded tarball fails the SIZE/SHA256 check because it contains 10k of HTML instead of... y'know. A tarball... | 08:55 |
vila | hmm | 08:55 |
vila | bad sites, bad, bad, bad | 08:55 |
fullermd | Not sure you did. I can't offhand thing of a totally automated way... | 08:55 |
vila | no urgency but it would be nice | 08:56 |
fullermd | Only one I manage is bzrtools. C-S maintains a half dozen of them I think... | 08:56 |
fullermd | freshports probably has a list somewhere you can pull of "all ports that depend on X"; most of those are probably plugins. | 08:56 |
fullermd | Don't see one offhand. Well, can script it out of INDEX pretty easily, I imagine. | 08:58 |
fullermd | Ideally as a perl one-liner, with over half the characters requiring the shift key. Naturally :p | 09:00 |
vila | Shift Copy/Shift Paste :D | 09:00 |
vila | fullermd: If you can propose a mp with a script in tools/packaging, I'll gladly help refine it (long term thingie, may not find its way in 2.3, yada yada) | 09:02 |
fullermd | Hmm... well, still too readable, but... | 09:08 |
fullermd | http://pastebin.com/Ysa4khCk | 09:08 |
vila | wow | 09:09 |
vila | do you really need the progress bar there ? (/\|/) :D | 09:10 |
fullermd | Hey, INDEX is a big file :p | 09:10 |
fullermd | Feel free to add a 'local $/;' on to the beginning if it makes you happy ;) | 09:11 |
vila | lol | 09:11 |
fullermd | Alternately: `grep bazaar-ng /usr/ports/INDEX-8 | cut -f1 -d\|`. But who wants to waste all that time with a pipeline? | 09:12 |
vila | 8 is for FreeBSD8 right ? | 09:12 |
fullermd | (and that also lists bazaar-ng itself, which obviously doesn't depend on bzr, so you waste a bunch of electrons outputting that...) | 09:12 |
fullermd | Yah. Though I doubt that particular list changes across versions much... | 09:13 |
vila | copy/pasted into my freebsd8/INSTALL tip&tricks file | 09:13 |
fullermd | Very good. You'll receive my invoice shortly 8-} | 09:16 |
vila | hehe | 09:17 |
vila | . o O (fullermd.debt.beers++) | 09:17 |
jelmer | hehe | 09:22 |
vila | jelmer: morning ! | 09:22 |
jelmer | bonjour! | 09:25 |
=== Ursinha-gone is now known as Ursinha | ||
vila | fullermd: bug 712935, if you want to subscribe | 09:39 |
ubot5 | Launchpad bug 712935 in Bazaar Bookmarks Plugin "_get_filename deprecated in bzr-2.3" [Undecided,In progress] https://launchpad.net/bugs/712935 | 09:39 |
jelmer | vila: 2.3.0 uploaded to Debian | 10:34 |
vila | \o/ | 10:34 |
vila | fullermd: mind to test https://code.launchpad.net/~vila/bzr-bookmarks/712935-2.3-compat/+merge/48589 ? | 10:37 |
vila | fullermd: no test suite for the plugin :-/ I did a bunch of manual tests but I may have missed some | 10:43 |
luks | vila: if I reassign bzr-bookmarks to you, will it solve the problem? :) | 10:44 |
vila | luks: wow, instant feedback ! | 10:44 |
vila | luks: ideally you'll assign it to ~bzr (I think) so any bzr dev can participate | 10:44 |
luks | ok | 10:44 |
vila | luks: And thanks for pioneering this config area ! | 10:45 |
vila | luks: you had many good insights showing in the code... | 10:45 |
luks | well, it was always just a hack :) | 10:46 |
luks | anyway, the problem is reassigned | 10:46 |
luks | if you could create a native LP branch and merge your changes, it would be great | 10:46 |
luks | because now I can't :) | 10:46 |
vila | luks: Great ! | 10:46 |
luks | er, the project | 10:46 |
luks | (reassigned) | 10:46 |
vila | I'll look into it asap | 10:47 |
vila | fullermd: feedback even more highly welcome ;) | 10:47 |
=== oubiwann_ is now known as oubiwann | ||
=== Ursinha is now known as Ursinha-afk | ||
=== Ursinha-afk is now known as Ursinha | ||
=== vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | 2.2.4 and 2.3.0 are frozen. Release plugins ! Build installers ! (rm vila) | ||
maxb | vila: Thanks for approving my udd just-cleanup branch. Can I also ask you to land it, as I am not in ~udd ? | 13:42 |
dOxxx | vila: mac installer 2.3 branch is pushed | 13:43 |
vila | maxb: gimme a sec but I won't forget | 13:44 |
vila | dOxxx: great, | 13:44 |
vila | dOxxx: I just froze 2.2.4 but I don't think we want OSX installers for it, 2.3 is the new stable | 13:44 |
dOxxx | yah I saw your email | 13:45 |
vila | dOxxx: if you know someone with an OSX 10.5 host... | 13:45 |
dOxxx | actually, I do... sec | 13:45 |
dOxxx | vila: Craig Sawyer csawyer@yumaed.org, he let me access a OSX 10.5 machine on his network a few times last year until you started building them. | 13:47 |
dOxxx | vila: I don't know if I have time to get it done today though | 13:47 |
vila | dOxxx: if you can forward him the 2.3.0 has gone gold mail so he get the pointers that would be great | 13:48 |
dOxxx | vila: well, he wasn't the one doing the building, he just gave me ssh access to the machine. | 13:48 |
vila | dOxxx: oh, well, then this will need a bit of discussion with him, drop him a note to close the loop then ? | 13:49 |
dOxxx | vila: I'll email you both | 13:50 |
vila | dOxxx: excellent ! | 13:50 |
=== oubiwann is now known as oubiwann_ | ||
=== oubiwann is now known as oubiwann_ | ||
vila | maxb: done | 14:15 |
maxb | thanks | 14:16 |
vila | maxb: but not deployed yet | 14:16 |
vila | maxb: doesn't really matter, just mentioning | 14:16 |
maxb | It has no operational effect, it just makes developer's lives more pleasant | 14:16 |
vila | maxb: indeed ;) | 14:18 |
james_w | ah, thanks vila | 14:19 |
james_w | sorry for not landing it straight away maxb | 14:19 |
vila | james_w: my pleasure | 14:19 |
maxb | no rush. Just didn't want it to sit and be forgotten | 14:19 |
maxb | jelmer: The last revision in lp:bzr-builddeb introduces a new bug. It looks like you missed one call to db.has_pristine_tar_delta(rev) in your refactor | 14:49 |
jelmer | maxb: looking | 14:53 |
=== jasono is now known as Guest68493 | ||
=== zyga is now known as zyga-food | ||
=== beuno is now known as beuno-lunch | ||
trond- | hi room. I've just started with bzr and I'm wondering: I have a website created for one client where code base is going to be used for another client (allowed), how do I do this? | 16:17 |
jelmer | trond-: you should be able to create a clone use "bzr branch" | 16:18 |
=== Ursinha is now known as Ursinha-afk | ||
trond- | jelmer, ok. so then brz branch (name of directory) (name of new/other existing directory)? | 16:20 |
jelmer | trond-: yep | 16:20 |
jelmer | see also the documentation | 16:21 |
trond- | jelmer, I will. Thanks :) just needed the first direction | 16:22 |
=== Ursinha-afk is now known as Ursinha | ||
vila | trond-: name of new, yes. other existing directory... likely to fail | 16:22 |
trond- | vila, yup. it did. :) | 16:26 |
vila | good :) | 16:26 |
=== jasono is now known as Guest97621 | ||
jelmer | vila: thanks for the reviews :) | 16:29 |
vila | np ;) | 16:29 |
vila | warming up for next week :) | 16:30 |
mgz | fullermd caught you about the bookmarks plugins I see vila. | 16:31 |
mgz | I'm a bit suprised it broke, your commit looked like it tried to retain compat. | 16:32 |
vila | mgz: hehe, I will feel less gulty when it'll be merged in core (feature wise) | 16:32 |
vila | mgz: err, really ? That's wasn't my intent ;) | 16:32 |
vila | mgz: err, really ? That wasn't my intent ;) | 16:33 |
vila | Without a test suite, I played it safe and tested my patch against 2.3 err 2.4b1 only | 16:33 |
* vila is bad :) | 16:34 | |
dOxxx | tsk! | 16:34 |
mgz | ah, I see, you detect the old api but didn't continue to provide it. | 16:35 |
vila | mgz: ha ! right, yeah, that's only by fixing bookmarks that I realized I left a hole in the compatibility | 16:36 |
vila | . o O (Freudian slip to push to the new API ? Well hidden...) | 16:37 |
mgz | python doesn't make this stuff easy. | 16:37 |
dOxxx | dynamic typing is both a blessing and a curse :) | 16:38 |
vila | errr, wth is going on ? 57 branches in the active reviews page ? | 16:58 |
mgz | I see a normal number on <https://code.launchpad.net/bzr/+activereviews>, which page are you looking at? | 17:01 |
vila | https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev/+activereviews | 17:01 |
vila | how did I arrive there ??? | 17:01 |
dOxxx | click the back button ;) | 17:02 |
vila | from here: https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev | 17:02 |
vila | dOxxx: hehe, no, previous tab :D | 17:02 |
mgz | ...maybe that's a launchpad change to that link. | 17:02 |
dOxxx | heh | 17:02 |
vila | and from here: https://code.launchpad.net/~jelmer/bzr/extra-branch-formats/+merge/48608 I clicked the Merge Into: lp:bzr link... | 17:02 |
vila | the weird thing is that these two branches are supposed to be the same one... | 17:03 |
dOxxx | hmm that seems wrong | 17:03 |
dOxxx | looks like launchpad is resolving lp:bzr wrong? | 17:03 |
mgz | http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/changes/12274 <- that page is slightly annoying to try and read | 17:06 |
mgz | launchpad's multiline commit messages don't really work with the loggerhead output | 17:07 |
vila | got it, the long page shows the wips | 17:07 |
vila | no idea why | 17:07 |
mgz | bug 707808 | 17:08 |
ubot5 | Launchpad bug 707808 in Launchpad itself "Unmerged revisions list does not exclude merged revisions" [Critical,Fix released] https://launchpad.net/bugs/707808 | 17:08 |
mgz | ...nope, not that | 17:08 |
mgz | bah, too much stuff. | 17:10 |
mgz | "some launchpad change". | 17:10 |
=== beuno-lunch is now known as beuno | ||
=== deryck is now known as deryck[lunch] | ||
jelmer | :) | 17:25 |
=== zyga-food is now known as zyga-fk | ||
=== zyga-fk is now known as zyga-afk | ||
=== deryck[lunch] is now known as deryck | ||
vila | jam: -Dxxx Critical ? Isn't it a bit excessive ? We know we'll blame mgz anyway, don't be too hasrsh :D | 18:37 |
jam | vila: it's poolies fault | 18:37 |
jam | and I've tracked it down | 18:37 |
mgz | ...whaddidibreak? | 18:37 |
jam | but yes critical | 18:37 |
jam | vila: We used to track how many bytes a command took. we now *always* get 0 | 18:37 |
jam | IMO, that is a regression | 18:38 |
jam | hence critiacl | 18:38 |
jam | critical | 18:38 |
jam | not data loss critical | 18:38 |
jam | but I probably would have blocked the release if I had known | 18:38 |
jam | mgz: you didn't break it, though I suspected you first, too :) | 18:39 |
mgz | :D | 18:39 |
jam | I thought the get_transport() stuff changed us tracking the bytes transferred | 18:39 |
jam | but we still tracked it. | 18:39 |
jam | but it turns out we through away the info right before we went to log it | 18:39 |
jam | threw away | 18:39 |
jam | vila: also, -Dbytes only shows it to the user. we always log it so that we can go back and see if a command is being reasonable | 18:41 |
mgz | will people throw pots at me if -Dthing is important not to break, it should have tests? | 18:42 |
mgz | +I say | 18:42 |
vila | jam: what I don't get is how none of us saw it before, I'm running from trunk and most of my usages are from the command line... | 18:43 |
vila | ...hmmm, wait, is it for all operations or for uploads ? | 18:43 |
vila | Nah, I also push manually... | 18:43 |
vila | mgz: I didn't suspect you for one second :) But between you and jelmer, I thought it would be funniest with you :D | 18:44 |
jam | vila: all operations | 18:45 |
vila | jam: we have switched and tested multiple times around the hack-around-the-hook | 18:45 |
jam | and yes, I run bzr.dev | 18:45 |
jam | what happens is that if the number of bytes is 0, then it doesn't print anything | 18:45 |
jam | so even though I have '-Dbytes' set to always on | 18:45 |
jam | I don't notice that it isn't reporting | 18:45 |
vila | ha, but that doesn't impact the progress, only the end report in log ? | 18:46 |
jam | right | 18:46 |
jam | the final log is not correctly showing | 18:46 |
jam | nor is it being logged to .bzr.log correctly | 18:46 |
jam | I noticed because of the emacs question | 18:46 |
jam | so I went to see how much is transferred, and it was saying "0" | 18:46 |
jam | :) | 18:46 |
vila | . o O (My evil plan to market bzr as the fastest dvcs for internet just died...) | 18:47 |
vila | anyway, I've EOWed, I must really go ;) | 18:47 |
vila | I'll try to check later ! | 18:48 |
vila | Have fun all ! | 18:48 |
sobersabre | hi guys. | 19:38 |
sobersabre | I see there is a 2.3.0 release. | 19:38 |
sobersabre | when will the windows build be online on https://launchpad.net/bzr/+download ? | 19:38 |
vila | sobersabre: where did you see that ? It hasn't been officially announced *because* we want as many installers available as possible when we do | 20:17 |
vila | sobersabre: anyway, 2.3.0 frozen yesterday, release *planned* Thursday :) | 20:45 |
vila | sobersabre: the rhythm these releases is: freeze on Thursay, releases on Tuesday, but we take a bit more time to start our new stable release, so: Thursday | 20:46 |
vila | jam: well done ! I wonder if we want some king of hook there to make it easier to avoid this kind of failure (but you've probably added a test already) | 20:47 |
jam | vila: working on a test right now | 21:04 |
=== Ursinha is now known as Ursinha-afk | ||
=== Ursinha-afk is now known as Ursinha | ||
=== elmo is now known as elmo_away | ||
peitschie | mornin all :) | 23:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!