| === Leonidas_ is now known as Leonidas | ||
| jderose | quick question: what's a good tool for visualizing a complicated history of branches and merges with a lot of criss-cross? | 00:24 |
|---|---|---|
| jelmer | jderose: qlog probably | 00:26 |
| jderose | jelmer: cool, thanks :) | 00:26 |
| === frakturfreak_ is now known as frakturfreak | ||
| === BasicPRO is now known as BasicOSX | ||
| lifeless | vila: testtools is in unstable now | 09:35 |
| lifeless | 0.9.8 | 09:35 |
| lifeless | vila: I don't know how that hepls the SRU | 09:36 |
| vila | lifeless: great ! | 09:36 |
| vila | lifeless: it's rather involved: we need the related bug to be fixed in natty, which needs testttools and from there, cascading effects unblocks the SRU | 09:36 |
| lifeless | so | 09:37 |
| vila | so we needed testtools in unstable so it can get into natty | 09:37 |
| lifeless | you'll need to get python-fixtures | 09:37 |
| lifeless | python-testtools | 09:37 |
| lifeless | synced to natty - if they haven't synced themselves | 09:38 |
| lifeless | python-fixtures is there already | 09:38 |
| lifeless | so just python-testtools is all thats needed | 09:38 |
| vila | hmm, never heard about python-fixtures before | 09:39 |
| lifeless | build-dep on python-testtools, like python-twisted | 09:40 |
| vila | don't tell me it's a new dependency not present in main or the whole circus will start again | 09:40 |
| lifeless | its a build dep | 09:40 |
| lifeless | so is python-twisted | 09:41 |
| vila | yes, that's exactly what python-testtools is for bzr and why we needed an up-to-date version | 09:41 |
| vila | and why I asked for python-testtools to be included in main, so back to square one :-( | 09:41 |
| lifeless | I don't know the details | 09:42 |
| lifeless | but it seems like you're making the change bigger than necessary, no ? | 09:42 |
| vila | I'm trying to comply with the defined rules... | 09:43 |
| lifeless | I'd challenge the 'must be fixed in natty' component | 09:44 |
| vila | bug #684099 should gives you the entry point | 09:44 |
| ubot5 | Launchpad bug 684099 in python-testtools (Ubuntu) "[MIR] python-testtools" [Undecided,Fix released] https://launchpad.net/bugs/684099 | 09:44 |
| vila | bug #659950 | 09:44 |
| ubot5 | Launchpad bug 659950 in Bilboplanet "Statistique Nombres de post manquant" [Medium,Fix committed] https://launchpad.net/bugs/659950 | 09:44 |
| vila | shudder | 09:44 |
| vila | bug #659590 | 09:44 |
| ubot5 | Launchpad bug 659590 in Bazaar 2.3 "dput sftp upload hangs after all files successfully uploaded" [Critical,Confirmed] https://launchpad.net/bugs/659590 | 09:44 |
| lifeless | well | 09:45 |
| lifeless | keep me in the loop | 09:45 |
| lifeless | but I expect us to add more build-deps as we add support for scenarios, other frameworks and so on to testtools | 09:46 |
| lifeless | I'm sure we can figure something out, but there is a balancing act between running the testtools tests and dragging lots of stuff into main transitively. | 09:47 |
| vila | well, I'm pretty sure this means we should just give up then, the SRU is blocked since ~2010-10-13 and obviously we can't keep up | 09:47 |
| lifeless | I do wonder if the transitive requirement is entirely necessary for things like built deps | 09:47 |
| vila | the middle path would be to have >= 0.9.5 available without added deps | 09:48 |
| lifeless | python-twisted is in main | 09:48 |
| vila | maxb: what do you think ? ^ | 09:48 |
| lifeless | python-fixtures has no unusual build-deps of its own | 09:48 |
| lifeless | you probably just need an MIR for python-fixtures, which the distro team may do for you when python-testtools attempts to sync and FTBFS on natty | 09:49 |
| vila | hopefully your're right | 09:51 |
| * vila off | 09:51 | |
| vila | jelmer: thanks for the upgrade bugs triaging ! Good reminder as I'm tweaking fullermd's proposal. | 11:15 |
| jelmer_ | vila: np, I suspected there were some dupes | 11:18 |
| jelmer_ | there weren't, but it does seem like a week of upgrade hacking might be a useful thing to do at some point | 11:19 |
| vila | jelmer_: Yeah... some of them may be addressed by the proposal but this was an unfinished job (there are empty tests there) so it's a bit hard to see where the tweaks should end and where a new submission starts | 11:21 |
| vila | but definitely it would be good to clear some backlog there | 11:22 |
| * jelmer_ waits for testtools to enter sid so he can upload bzr 2.3b4 | 11:43 | |
| maxb | vila: It looks like we have no choice but to MIR python-fixtures | 13:48 |
| vila | maxb: thanks for the feedback | 13:49 |
| vila | maxb: yet, we should not need python-fixtures on maverick for the SRU right ? | 13:49 |
| vila | s/yet/still/ ? | 13:49 |
| maxb | We're fine there because 2.2 doesn't need the newer python-testtools | 13:50 |
| vila | maxb: ok, so this doesn't propagate, good | 13:50 |
| vila | maxb: so, if 0.9.8 enters natty (main) will it brings p-x with it ? (aka is the MIR implicit or not) | 13:51 |
| vila | not p-x p-f == python-fixtures | 13:51 |
| maxb | Well, it'll sync, then FTBFS, and someone will check it and see the reason is a component-mismatch, and then consider MIR-ing at that point | 14:04 |
| maxb | On a different note, I need somewhere to put a shell-script that I use for some of the bzr ppa maintenance. I don't want to put it in lp:bzr, because I don't want to have to do the MP-and-PQM dance for every change | 14:06 |
| maxb | The script in question pleases me greatly, because I just did: | 14:06 |
| maxb | bzrppa-backport -s -u ppa:bzr/proposed -U medium -D "maverick lucid karmic jaunty hardy" python-fixtures_0.3.5-1.dsc | 14:06 |
| maxb | for a one-liner upload of python-fixtures to all relevant series, stating just with the unmodified debian source :-) | 14:07 |
| maxb | oh yay, python-fixtures tests are broken in python 2.5 | 14:53 |
| * maxb wonders what to do about updating python-testtools for hardy in the ppa | 14:53 | |
| vila | maxb: sry was away, let me re-sync | 14:56 |
| vila | maxb: you use the script locally only right ? | 14:57 |
| maxb | yeah | 14:57 |
| vila | maxb: then lp:bzr is still the best place for many reasons | 14:57 |
| maxb | and as it turns out, fixtures is FTBFS on hardy anyway, so I still needed to go back and do proper branches anyway | 14:57 |
| vila | maxb: and as far as mp-pqm dance, since that's not blocking I don't quite get your reticences | 14:58 |
| vila | maxb: additionally the constraints for such a script are vastly different than for the code so there shouldn't be issues | 14:59 |
| vila | maxb: if I had some, it would be about clarifying the constraints about the branches handled locally, but it would be absurd to complain about that | 14:59 |
| vila | maxb: I meant *blocking* a mp would be absurd | 15:00 |
| vila | so, my point is: submit whatever works for you as soon as you can :D | 15:00 |
| vila | maxb: I would even say: ask help from the pp if you feel some parts are missing, be it tests, docs, whatever | 15:01 |
| maxb | i guess so | 15:01 |
| vila | maxb: and if the pp is too slow for your taste, nag the RM ;) | 15:02 |
| txdv | what is the default command to start bzr-gtk? | 16:38 |
| jelmer_ | maxb: as you might've seen I've uploaded loggerhead | 17:18 |
| lifeless | txdv: bzr-gtk has a bunch of cli accessible commands, and optional nautilus integration | 17:52 |
| lifeless | txdv: you may be thinking of 'olive', a gtk ui along the same lines as bzr-explorer - its separate to bzr-gtk | 17:53 |
| lifeless | AIUI | 17:53 |
| lifeless | maxb: is that bug 691916 ? | 17:55 |
| ubot5 | Launchpad bug 691916 in Python Fixtures "tests are broken on python 2.4" [Undecided,New] https://launchpad.net/bugs/691916 | 17:55 |
| lifeless | maxb: or something idfference again? | 17:55 |
| lifeless | *different* | 17:55 |
| === Kilroo1 is now known as kilroo | ||
| txdv | lifeless: but i cant find it anywhere in the ubuntu reps | 19:10 |
| exarkun | bzr svn-import exploded with an out of memory error, when I run it again, this happens, http://pastebin.com/AcEjtq0H | 19:12 |
| Peng | exarkun: After making triple-sure there really isn't another bzr process running, bzr break-lock /media/sda1/divmod.org/bzr/Divmod/branches/flattener-error-formatting-2808 | 19:15 |
| exarkun | Thanks | 19:20 |
| lifeless | txdv: sorry, what are you looking for ? | 19:24 |
| txdv | olive | 19:26 |
| lifeless | jelmer_: where does olive live these days? | 19:26 |
| exarkun | Hm | 19:33 |
| exarkun | I did the break-lock, but svn-import failed the same way | 19:33 |
| lifeless | exarkun: does that file exist? | 19:36 |
| lifeless | if its a file rather than a dir, remove it (no idea how that would happen) | 19:37 |
| exarkun | it's a directory, with a directory `held` in it | 19:37 |
| exarkun | with a file `info` in that | 19:37 |
| exarkun | Oh. But I guess the break-lock didn't do anything. | 19:43 |
| exarkun | Coz it's still all there afterwards. | 19:43 |
| Peng | How does break-lock not break the lock? o_O Permissions issue? | 19:49 |
| Peng | Then I expect it would die horribly, though... | 19:50 |
| exarkun | does this help, http://pastebin.com/WR10kDR5 | 19:51 |
| Peng | That makes my brain hurt. | 19:59 |
| lifeless | uhm | 20:02 |
| lifeless | I think it failed very early on in making the branch | 20:02 |
| exarkun | There's very little in here, yes | 20:02 |
| lifeless | yeah | 20:02 |
| lifeless | delete that 'branch' entirely | 20:02 |
| exarkun | http://pastebin.com/k217x2fv | 20:02 |
| exarkun | Hrm. Out of memory again. | 20:24 |
| jelmer_ | lifeless, txdv: Olive lives at https://launchpad.net/olive these days | 20:34 |
| jelmer_ | exarkun: hi | 20:34 |
| exarkun | jelmer_: Hello | 20:35 |
| txdv | hm | 20:36 |
| txdv | thanks | 20:36 |
| jelmer_ | exarkun: I just got back - you're having locking issues running svn-import? | 20:36 |
| Peng | jelmer_: exarkun is having svn-import-OOMs-and-leaves-behind-locks issues. | 20:37 |
| exarkun | jelmer_: First I had memory issues so the import got interrupted. That seems to have led to a locking issue. | 20:37 |
| jelmer_ | exarkun: I guess I can see how that could cause locking issues | 20:40 |
| jelmer_ | exarkun: how big is the repository? | 20:42 |
| exarkun | 374MB | 20:42 |
| jelmer_ | hmm, that doesn't seem too bad | 20:43 |
| jelmer_ | what bzr/subvertpy/bzr-svn versions are you running? | 20:43 |
| exarkun | bzr 2.2.2, bzr-svn 1.0.4, subvertpy 0.6.9-1 | 20:44 |
| exarkun | no sorry, subvertpy 0.7.5 | 20:44 |
| exarkun | 0.7.5-1~bazaar1~karmic1 | 20:45 |
| exarkun | latest run is now stuck, using 3GB of RAM and 100% CPU. Not sure if the previous attempts entered this state before they died, I wasn't paying that close attention. | 20:46 |
| jelmer_ | exarkun: is one of the files particularly large? | 20:46 |
| exarkun | cd | 20:47 |
| jelmer_ | cd? | 20:47 |
| exarkun | sorry, wrong window | 20:47 |
| exarkun | there are a few files a little over 100kB | 20:48 |
| exarkun | nothing bigger than that | 20:49 |
| exarkun | maybe there's a lot of branches? | 20:49 |
| exarkun | it's converted 244 branches at this point | 20:50 |
| RenatoSilva | if your branch is outdated with trunk but you're about to merge, what do you prefer, merge from trunk then into trunk, or merge into trunk directly? | 21:17 |
| jelmer_ | RenatoSilva: there isn't a particular reason for merging trunk into your feature branch first | 21:17 |
| RenatoSilva | jelmer_: not sure but maybe leave the conflict stuff in the merge from trunk not the merge in trunk from that branch? | 21:19 |
| RenatoSilva | jelmer_: so that when you qlog trunk and click the merge, you see a clear diff without hidden for-conflict-solving lines | 21:21 |
| RenatoSilva | I mean, when you don't know which lines were result of merge conflict | 21:22 |
| RenatoSilva | that way you'd be sure no conflict happened because you fixed it when merging from trunk | 21:22 |
| RenatoSilva | and hence the diff of the merge from branch into trunk would be clear, without lines targeted at fixing conflicts | 21:23 |
| RenatoSilva | Do I make any sense? | 21:24 |
| lifeless | RenatoSilva: that only works on projects with a small number of branch merges a day, or both trunk and the branches maintained by the same person | 21:30 |
| lifeless | RenatoSilva: otherwise, by the time someone has merged trunk and fixed conflicts | 21:31 |
| lifeless | trunk will have new commits | 21:31 |
| RenatoSilva | I see, but in that case, isn't it interesting? | 21:31 |
| lifeless | to some people, perhaps. | 21:31 |
| lifeless | I think having trunk always build-and-test-cleanly is much more interesting than how things get into trunk. | 21:32 |
| RenatoSilva | merging from trunk immediately before merging into it is a way to ensure that | 21:33 |
| lifeless | lets say you have 50 developers | 21:33 |
| lifeless | and your test suite takes 40 minutes | 21:33 |
| lifeless | if each developer does one patch a day, you have 2000 minutes of tests to run per day (which fits, 3600 minutes in a day) | 21:34 |
| RenatoSilva | withing these 40 minutes there would probably be a new commit in trunk | 21:34 |
| lifeless | right | 21:34 |
| RenatoSilva | *within | 21:34 |
| lifeless | if you have a serialised queue of things to land on trunk | 21:34 |
| lifeless | and test the test suite one at a time, you can avoid trunk regressions | 21:35 |
| lifeless | if you merge trunk to a branch, test *that*, then commit to trunk without testing - interactions between branches can easily - and often do for the Launchpad project which does it this way - break trunk. | 21:35 |
| exarkun | jelmer_: is there something I can do to reduce the memory requirements for the conversion? or do I just have to switch to a 64bit machine? | 21:36 |
| jelmer_ | exarkun: Our memory requirements are pretty heavy, but what you're describing sounds more like a memory leak of some sort | 22:21 |
| jelmer_ | exarkun: I guess a 64 bit machine might work around it, but I'm still curious what would be going wrong. | 22:22 |
| RenatoSilva | lifeless: that's what I mean, you need to be as much updated with trunk as possible | 22:38 |
| RenatoSilva | lifeless: so that you can run the tests on your branch before merging into trunk, so that there are less diff as possible when that happens and hence trunk is less likely to break | 22:39 |
| lifeless | RenatoSilva: but thats different | 22:52 |
| lifeless | RenatoSilva: you are saying 'do this thing*in a branch*' | 22:52 |
| lifeless | RenatoSilva: I'm saying '*do this thing as part of the merge to trunk*' | 22:52 |
| RenatoSilva | lifeless: run the tests locally? ok | 22:57 |
| lifeless | well | 23:15 |
| lifeless | not necessarily locally | 23:15 |
| lifeless | but as part of the do-a-merge-to-trunk-process | 23:15 |
| lifeless | however you're doing that | 23:15 |
| RenatoSilva | ok | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!