| poolie | hi jam | 00:15 |
|---|---|---|
| jam | hi poolie, I tried calling earlier | 00:29 |
| poolie | hi there | 00:31 |
| poolie | want to talk now? | 00:31 |
| jam | sure | 00:36 |
| jam | espec if we can make it quick | 00:36 |
| poolie | give me a call? | 00:38 |
| * maxb uploads the fourth try at 2.3b2 to beta ppa :-) | 01:16 | |
| lifeless | 2.3b2.4? | 01:20 |
| lifeless | could be a confusing version number | 01:20 |
| lool | slangasek: pong | 01:44 |
| slangasek | lool: hi - sorted now, no worries :) | 01:44 |
| lool | slangasek: Ok; sftp to what branch? | 01:45 |
| lool | slangasek: Ok :) | 01:45 |
| maxb | ugh, failed test again | 01:50 |
| maxb | Here goes 2.3.0~beta2-1~bazaar1~maverick5, may it have better luck than the last 4 | 01:59 |
| poolie | hi spiv? | 02:39 |
| spiv | poolie: hi poolie | 02:39 |
| spiv | I'm nearly done with split-NEWS | 02:39 |
| poolie | cool | 02:39 |
| spiv | Just writing up docs on how to start a new release with it, which of course reveals improvements I should make to that process :) | 02:39 |
| spiv | Or rather, how to start a new series. | 02:40 |
| maxb | yay successful build | 02:43 |
| * spiv -> lunch | 02:45 | |
| maxb | So, fixes to make the testsuite work on the buildds.... should I target those at 2.2? 2.1? | 02:51 |
| poolie | i'd say 2.2, or maybe even only trunk | 02:51 |
| poolie | how likely is it to have adverse consequences? | 02:51 |
| maxb | Very little, given I only touch setup.py and test code | 02:56 |
| maxb | And actually, having touched the test code, I don't technically need to touch setup.py | 02:56 |
| poolie | 2.2 sounds good then | 02:57 |
| poolie | could you nag or whatever the sru team? | 02:57 |
| maxb | Do we actually have test results in the bug yet? | 02:58 |
| maxb | Also, perhaps I should target my test fixing into 2.1, in case we want to SRU lucid again | 02:58 |
| peitschie | spiv: are you around? | 04:39 |
| spiv | peitschie: I am, yes | 04:49 |
| peitschie | spiv: was just wanting to quickly check if you'd heard anything regarding the data we were playing with yesterday? | 04:49 |
| spiv | I think jelmer & jam have basically identified the cause | 04:50 |
| spiv | What remains is to figure out what to do about it :) | 04:50 |
| peitschie | oh! that was quick! | 04:50 |
| peitschie | is it likely to be a difficult thing to fix? I ask as i'm being pushed to decide if we do branching in svn... or whether we can continue with bazaar | 04:51 |
| peitschie | tho i'd love to stay with bzr for the project... this bug in particular is causing mega hassles trying to get changes committed back to svn, or merge changes in from svn :S | 04:51 |
| spiv | I'm not sure, I don't think I've seen the full discussion between jam and jelmer. It's related to what happens after a ghost is filled in. | 04:54 |
| peitschie | ah k :)... sounds like it might be safest to let the project do the branching in svn... then i'm not under time pressures (or emotional pressures!) for this to get fixed immediately | 04:55 |
| spiv | It sounds like there needs to be some clarification/decision about precisely what bzr's expectations are there (so that bzr-svn can meet them), but also how to do that in a way that is as useful as possible. | 04:55 |
| peitschie | yes... thats understandable. bzr-svn does seem to be the cutting edge of ghost handling in bzr world | 04:55 |
| spiv | Yes, it seems so! | 04:56 |
| spiv | It seems likely that there is a corebzr issue here, but bzr itself doesn't tend to make it easy to create ghosts. | 04:57 |
| spiv | They in practice tend to come from imports/conversions from foreign systems. | 04:57 |
| peitschie | yes... i had noticed that a lot of core bzr seemed to struggle with ghosting in various ways... though the most recent version definitely has been a huge improvement | 04:57 |
| peitschie | either way... i'm very gratified to hear the probable cause was found! | 05:00 |
| spiv | Me too:) | 05:03 |
| poolie | hi spiv, | 05:40 |
| poolie | when you're done with news could you look at james's bug 653307? | 05:40 |
| ubot5 | Launchpad bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys (affected: 1, heat: 7)" [Critical,Triaged] https://launchpad.net/bugs/653307 | 05:40 |
| spiv | Sure. Another one :/ | 05:42 |
| chx | never know whether diff -r 17210..17200 include 17200 and 17210 or not | 05:58 |
| chx | does it or not...? | 05:58 |
| poolie | chx: it names two trees | 05:58 |
| poolie | the one committed by 17210 and the one committed by 17200 | 05:58 |
| poolie | and it gives the diff between them | 05:58 |
| chx | that does not help me :) | 05:58 |
| chx | does it include the differences introduced in 17200? | 05:58 |
| poolie | so it excludes the first and includes the right | 05:58 |
| poolie | stewart: want to be a bzr-stats maintainer? | 05:59 |
| stewart | poolie, sure. | 05:59 |
| poolie | :) | 05:59 |
| poolie | congrats | 06:00 |
| stewart | poolie, next thing i was going to add was some extra mapping of email addresses to the same people... the mysql tree is rather chaotic with what people committed as. | 06:00 |
| poolie | by all means still ask for reviews | 06:00 |
| poolie | but now you can merge them yourself | 06:00 |
| chx | poolie: so it exclude 17200 and includes 17210? | 06:02 |
| chx | poolie: that sort of "includes the first" sitll does not help me :( | 06:03 |
| chx | poolie: yes. it does. i see. i do not understand at all. | 06:05 |
| chx | poolie: but i see. | 06:05 |
| stewart | poolie, great. | 06:05 |
| chx | poolie: thanks | 06:07 |
| poolie | chx it's easier if you remember that the numbers are assigned when you commit, after you finish changing the tree | 06:09 |
| chx | poolie: i still do not understand a word. what tree? | 06:09 |
| chx | anyways, back in ten. | 06:09 |
| vila | hi all ! | 07:25 |
| peitschie | hi villa | 07:33 |
| peitschie | *vila | 07:33 |
| vila | _o/ | 07:34 |
| peitschie | thats the cutest wave eva lol | 07:40 |
| vila | \o_ \o/ _o/ _o_ hop hope morning exercise | 07:41 |
| vila | s/hope/hop/ typo | 07:41 |
| poolie | hi there vila | 07:42 |
| poolie | i'm trying to work out if we actually agreed on not having rcs | 07:42 |
| vila | Seen my last comment on the review ? I misremember ? | 07:43 |
| vila | It seem I fail to reach agreement for even the tiniest details these days :( | 07:43 |
| poolie | ah, it's ok | 07:44 |
| poolie | isn't my graph nice? :) | 07:44 |
| vila | I believe the agreed plan is that we will do an API freeze in the last | 07:44 |
| vila | beta, then make a 2.3 branch, then release 2.3.0 directly off that | 07:44 |
| vila | branch, then possibly a 2.3.1 etc into Natty. rcs are unnecessary | 07:44 |
| vila | overhead since the final source is normally good. | 07:44 |
| vila | straight from your mail | 07:45 |
| vila | Message-ID: <AANLkTim4JhUYhHkWhMFr6bqPo5KhjtCFZmrUJw_iZQX7@mail.gmail.com> | 07:45 |
| vila | and indeed part of the [RFC] Releases planning thread | 07:45 |
| vila | graph.. which graph ? :) | 07:46 |
| poolie | "less open bugs" | 07:46 |
| vila | wow fix vs confirmed... amazing | 07:50 |
| poolie | and it's really pulled ahead the last few months | 07:51 |
| vila | Wow in progress decreasing, excellent. I still need to purge my queue... | 07:51 |
| vila | the 1700 figure is also interesting to compare with the one reported by fixed-in (~1142 or something) | 07:52 |
| vila | I'm not sure I de-dupe in fixed-in for that matter | 07:52 |
| spiv | A loosely related graph I find interesting: http://webnumbr.com/active-bzr-branches-on-lp | 07:58 |
| spiv | Which is climbing, but perhaps indicates more that LP's classification of "active" is incorrect than anything else. | 07:59 |
| vila | https://code.edge.launchpad.net/ubuntu is still surprising to me | 08:00 |
| vila | but indicates a strong activity nevertheless | 08:01 |
| ddaa | are those all native lp hosted bzr branches? | 08:03 |
| ddaa | or some kind of automated churn? | 08:03 |
| spiv | vila: ta, created http://webnumbr.com/bzr-branches-for-ubuntu ;) | 08:09 |
| spiv | (although sadly the point-and-click thingy failed and I had to go read some xpath docs) | 08:09 |
| vila | spiv: great thanks ! | 08:10 |
| vila | ddaa: who knows... | 08:12 |
| CcxCZ | so when is next stable release planned? (whether I should bother publishing ebuild w/ py2.7 fix) | 08:13 |
| vila | CcxCZ: are you subscribed to the bazaar ML ? | 08:15 |
| CcxCZ | nope | 08:16 |
| CcxCZ | is it on gmane? | 08:16 |
| vila | I think so | 08:17 |
| spiv | http://news.gmane.org/gmane.comp.version-control.bazaar-ng.general I think | 08:17 |
| vila | The topic is under discussion, and two points are relevant for you if you're involved in gentoo packaging | 08:17 |
| CcxCZ | I'm not an official packager, I just try to fix bugs when I bum pinto them | 08:18 |
| vila | CcxCZ: One is that it would be very nice to know which bzr/plugins versions are carried (any gentoo command to get that updated will be awesome) | 08:18 |
| vila | the other is that https://edge.launchpad.net/bzr/+series is supposed to be the most up-to-date source for release dates | 08:19 |
| vila | as far as 2.3 is concerned, we expect to release it next February | 08:20 |
| vila | for 2.2 we say 2.2.2 should be released 2010-11-18 but I think that would be later (we will release it *iff* we encounter critical bugs) | 08:20 |
| vila | CcxCZ: what fix are you referring to ? | 08:21 |
| CcxCZ | launchpad/xmplrpc | 08:22 |
| vila | do you have the bug number ? | 08:23 |
| CcxCZ | wait, I'll get it | 08:23 |
| CcxCZ | https://code.launchpad.net/~toshio/bzr/python27-lp-fix/+merge/35487 | 08:25 |
| * vila cries lp in maintenance mode | 08:25 | |
| * ddaa hands vila a tissue | 08:26 | |
| ddaa | careful with the faux-amis :-) | 08:26 |
| vila | CcxCZ: let's try again later, but what I'm trying to understand is whether the fix has landed in the 2.2 branch or not and whether you are backporting it to 2.2.1 in gentoo only or use the lp:bzr/2.2 branch | 08:27 |
| vila | ddaa: cries is not about crying ? | 08:27 |
| vila | with tears of blood ? | 08:27 |
| vila | :) | 08:27 |
| ddaa | ah okay, I assumed you merely meant "shouts" :-) | 08:28 |
| vila | ddaa: nah, I use ALLCAPS when shouting but I alsmot never shout for work related problems, I keep that for private stuff and even there... | 08:28 |
| CcxCZ | no, I had to apply the patch to 2.2.something | 08:28 |
| vila | CcxCZ: err, so you mean you backported it to gentoo only right ? | 08:29 |
| CcxCZ | backported it to my personal gentoo overlay, yes | 08:29 |
| CcxCZ | 2.2.1 it was I think | 08:31 |
| vila | CcxCZ: ok, so excuse my poor gentoo knowledge here, but will this patch find its way to the 'official' gentoo distro ? | 08:33 |
| vila | CcxCZ: I'm trying to understand how we could reduce the overall work here and whether we should apply your patch to the lp:bzr/2.2 branch or not | 08:34 |
| vila | ha, lp is back, so the fix has landed in 2.3b2 already | 08:35 |
| CcxCZ | nope, unless I convince the dev he should add it, so I came here to check whether I should bother to do so, or should I just wait for next release | 08:36 |
| vila | CcxCZ: ok, hmm, right, I see the patch now, definitely not critical so unlikely to get backported to 2.2, | 08:38 |
| vila | CcxCZ: I think that answers your question: it will be available in 2.3 only | 08:39 |
| vila | CcxCZ: now, do you know a way in gentoo to get which bzr/plugins versions are installed ? | 08:39 |
| CcxCZ | gtg now, back in few minutes, kay? | 08:40 |
| vila | CcxCZ: Sure ! | 08:40 |
| spiv | vila: I don't think 'critical' is precisely the criteria for a backport to a stable branch | 08:40 |
| spiv | It's more 'is the benefit worth the risk (and effort)?' | 08:40 |
| spiv | So a medium importance bug that has an utterly safe fix would be a good candidate for a backport, for instance. | 08:41 |
| vila | spiv: that doesn't really fly with the SRU policy, but it seems I can't summarize this sort of thing so feel free to amend our doc on the subject | 08:41 |
| spiv | vila: I believe it does fit the SRU policy | 08:42 |
| spiv | "# Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel)." | 08:43 |
| spiv | Especially as part (1) is bolstered by our large automated test suite. | 08:43 |
| spiv | It also fits with what I recall poolie saying in the past. | 08:43 |
| vila | spiv: I'm not the one that needs to be convinced... my understanding of the current situation is that 2.2.1 is still not in maverick-updates | 08:44 |
| spiv | That's more to do with a smooth, effort-free path for getting our stable micro releases into -updates than anything else though, isn't it? | 08:45 |
| vila | spiv: and for this particular case, unconditionally overriding the python implementation is a risk to miss more 2.7 fixes | 08:45 |
| spiv | (And making our test suite pass in the package build environment helps create that smooth path) | 08:46 |
| spiv | vila: haha 2.7 fixes | 08:46 |
| spiv | vila: | 08:46 |
| spiv | 2.7 is already being handled more conservatively by upstream than previous 2.x releases for updates, because they don't plan any more 2.x at all. | 08:47 |
| vila | right, more conservatively in this case still means they broke 2.6 compatibility... | 08:48 |
| spiv | Right, but this fix is fine on 2.6 too | 08:49 |
| vila | ... which I won't remember in 6 months | 08:49 |
| spiv | Well, to be less abstract: I think the risk that this specific workaround for 2.7 might cause problems later is pretty low. | 08:50 |
| spiv | And if a future 2.7 does break it, and passes the SRU process for maverick-updates, then I'm sure a corresponding fix for bzr would be accepted for maverick-updates too :) | 08:51 |
| spiv | We should get the python package build to pass bzr's test suite too, not just the bzr package ;) | 08:52 |
| CcxCZ | vila: I'm back but I'm not sure I understand the question. Plugins (except for launchpad) are packaged as normal gentoo packages: dev-vcs/bzrtools, dev-vcs/bzr-svn, ... | 09:01 |
| vila | CcxCZ: I only have a basic knowledge of gentoo, so this may be obvious to you, I'd like to know what command or series of commands I should use to get the plugin list and their associated versions | 09:03 |
| CcxCZ | bzr version / bzr plugins seems best to me :-) but I just used `equery list -f 'bzr'` to get all packages with 'bzr' in name | 09:05 |
| CcxCZ | note that equery is in gentoolkit package and not installed by default | 09:06 |
| CcxCZ | vila: what do you need it for? | 09:06 |
| vila | CcxCZ: doh, good point on bzr version / bzr plugins :-D | 09:09 |
| vila | CcxCZ: I need it to get a distro point of view about what is packaged | 09:10 |
| vila | CcxCZ: but bzr version/plugins may do it, I need to make sure my setups don't interfer here | 09:10 |
| vila | which BZR_PLUGIN_PATH=+site:+core should do | 09:11 |
| vila | CcxCZ: sounds like a very good plan, portable, easy to explain, usable by anybody, excellent | 09:12 |
| CcxCZ | equery belongs -f '/usr/lib(64)?/python.*/site-packages/bzrlib/.*' | 09:13 |
| CcxCZ | should search for packages that installed files matching regex | 09:13 |
| CcxCZ | since gentoo ebuilds are usually written in version-agnostic way, the version numbers should match | 09:14 |
| vila | CcxCZ: ok, so both commands (and bzr version/plugins too for that matter) tells me about *installed* packages (and my VM only has bzr itself installed) | 09:21 |
| vila | CcxCZ: is there a variant that can tell me about plugins that *can* be installed ? | 09:21 |
| CcxCZ | not really, because ebuilds don't have any identificator marking it as 'bzr plugin', but equery list -pf 'bzr' should give you an idea (or -pof if you want to search overlays) | 09:24 |
| CcxCZ | or you can use online tool http://gpo.zugaina.org/Search?search=bzr | 09:25 |
| vila | CcxCZ: some result: only bzr-2.2.0 | 09:26 |
| vila | ha, let me try that | 09:26 |
| vila | CcxCZ: hmm, from http://gpo.zugaina.org/dev-vcs/bzr-git, 'gentoo' is the official and 'funtoo' an overlay ? What is bzr-git-9999 ? | 09:28 |
| CcxCZ | 9999 means current head is pulled from developers' vcs | 09:29 |
| * spiv wonders what happens if the branch has more than 9999 revisions... | 09:29 | |
| vila | ha, and the Overlay: bazaar (layman) just has no icon right ? | 09:30 |
| CcxCZ | use gentoo-portage.com to see only normal portage | 09:30 |
| CcxCZ | spiv: it's bumped with some nines :-) | 09:30 |
| CcxCZ | there are packages like that | 09:30 |
| CcxCZ | (they use date as version number iirc) | 09:31 |
| spiv | CcxCZ: heh :) | 09:31 |
| vila | CcxCZ: excellent, I think gentoo-portage.com is a good starting point for me now | 09:33 |
| vila | for me for now ? | 09:33 |
| vila | CcxCZ: so http://gentoo-portage.com/dev-vcs/bzr says that 2.0.1, 2.0.4, 2.2.0 and 2.2.1 are available right ? (As in the user can decide which one is installed) | 09:34 |
| CcxCZ | note the keywords: 'arch' means stable, '~arch' means testing (for now) | 09:36 |
| vila | CcxCZ: I was about to ask :) | 09:37 |
| vila | CcxCZ: weird, http://gentoo-portage.com/Search?search=dev-vcs%2Fbzr doesn't mention qbzr even if http://gentoo-portage.com/Search?search=qbzr says it's part of dev-vcs... | 09:38 |
| vila | CcxCZ: anyway, food for thought, thanks for the juicy pointers ;) | 09:39 |
| CcxCZ | also you may want to read this: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3 | 09:39 |
| CcxCZ | maybe http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2 before that | 09:40 |
| vila | CcxCZ: thanks | 09:41 |
| CcxCZ | vila: the uri you posted searches for dev-vcs/bzr* but qbzr is dev-vcs/qbzr | 09:41 |
| vila | ha, implicit globs... | 09:42 |
| vila | we should lobby the qbzr devs to switch to bzrq :) I'm sure they will love the idea :D | 09:43 |
| CcxCZ | substring search raher than glob, but whatever :-) | 09:45 |
| vila | CcxCZ: indeed: http://gentoo-portage.com/Search?search=bzr is the best fit | 09:48 |
| vila | net-libs/libzrtpcpp is irrelevant but fun anyway :) | 09:48 |
| vila | http://packages.gentoo.org/category/dev-vcs?full_cat is a good summary too, even if I don't understand everything there :) | 09:52 |
| jelmer | yeah, libzrtpcpp always comes up in searches for bzr in debian/ubuntu as well :-) | 09:53 |
| CcxCZ | vila: just msg me if you need anything gentoo-specific | 10:13 |
| vila | CcxCZ: ok, thanks ! | 10:14 |
| sender | jelmer: hi, are you available? :) | 14:19 |
| jelmer | sender, hey | 14:22 |
| jelmer | sender, I'm at work at the moment, I can help later tonight though | 14:22 |
| === Ursinha-afk is now known as Ursinha | ||
| mgz | launchpad seems slow today. making lots of nutty packages? | 15:45 |
| mgz | *natty | 15:46 |
| vila | naughty ? | 15:47 |
| mgz | very. | 15:48 |
| mgz | wonder if I can find a big enough chunk of time today to look at hooks... | 15:51 |
| vila | don't tell me :-/ | 15:52 |
| rubbs | I created a repo and one of my devs can not add a .bzrignore file. He's in the group that owns .bzr dir and it's mod'd to 775 at this point. am I missing something? bzr: ERROR: Cannot lock /home/httpd/smackemyackem.com/dev/.bzr/checkout/dirstate: [Errno 13] Permission denied: u'/home/httpd/smackemyackem.com/dev/.bzr/checkout/dirstate' | 15:55 |
| Glenjamin | sounds like something inside .bzr isn't owned by him | 15:56 |
| vila | rubbs: mod'd -R ? | 15:57 |
| jam | morning vila | 15:58 |
| vila | jam: morning ! | 15:58 |
| rubbs | yeah. I'm bombing the whole thing and running again. It's possible I missed something, and this is more for instructional purposes. | 15:58 |
| rubbs | It's possible I have an odd sticky bit set up or something | 15:59 |
| vila | /home/httpd implies this is also served via http ? As such it's owned by the web user ? | 15:59 |
| vila | nah, www user or whatever is used for your install | 16:00 |
| rubbs | also I had one other quick question. My devs like to connect to the dev server with this: http://www.expandrive.com/windows It's basically sshfs for windows. Would this cause problems if their working tree is on the sshdrive, but they are working in windows? with a windows version of bzr? | 16:00 |
| vila | ouch | 16:00 |
| rubbs | vila: /home/httpd in this case is misleading. it's not a web directory at this point. | 16:00 |
| rubbs | mostly being used as an "example" to teach bzr | 16:01 |
| vila | there have been problems with sshfs in the past about renames and locks (not sure about locks) | 16:01 |
| rubbs | ah, and originally we had a lock problem. I think I manually fixed that. | 16:02 |
| vila | I *used* to work with sshfs, I still use nfs a bit, but as a rule... mounted file systems are more trouble than benefits IME | 16:02 |
| rubbs | k | 16:02 |
| rubbs | so maybe I should have them pull things locally and bind to the dev machine. | 16:02 |
| vila | that being said, we support it AFAIK | 16:02 |
| vila | rubbs: yup | 16:02 |
| rubbs | k | 16:02 |
| rubbs | thanks for all your help/advice. I'll have to check into a few things | 16:03 |
| vila | maxb: yeehaa for the beta-ppa ! | 16:03 |
| vila | maxb: does this mean the tests are running there ? For bzr only or did you try for some plugins too ? | 16:05 |
| vila | maxb: did you remove the install-related failing one ? | 16:05 |
| === Ursinha is now known as Ursinha-afk | ||
| vila | mgz: was your lanchpad remark about 'updating diff' ? Because I see that right now for two mps of mine | 16:08 |
| vila | mgz: and it's more than slower than normal... | 16:08 |
| === Ursinha-afk is now known as Ursinha | ||
| mgz | yeah, and slowness of sending out email too. | 16:08 |
| mgz | ha, funny indentation error, wonder who the blame is on | 16:10 |
| === Ursinha is now known as Ursinha-lunch | ||
| mgz | wow, that's ancient. vila from rev 2900? | 16:12 |
| vila | me ? Can't be. blame emacs :) | 16:12 |
| vila | where is that ? | 16:12 |
| mgz | well it's you or jam from rev 1185 | 16:13 |
| mgz | bzrlib\config.py line 965 | 16:13 |
| mgz | causes this: | 16:13 |
| mgz | http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/bzrlib.tests.test_config/TestIniBaseConfigOnDisk/test_reload_see_new_value/ | 16:13 |
| vila | wow indenting the first mkdir address that ? | 16:15 |
| vila | and it never failed before on windows ??? | 16:15 |
| jam | vila: I would imagine that the first time we have to mkdir 2.0 we have to mkdir the parent dir | 16:16 |
| jam | and we never have a case where one-but-not-both needs to be created | 16:16 |
| vila | which reminds me that I never really grok that code, what if we need to create more than 2 parents ? | 16:17 |
| vila | mgz: revno 2900... was only fixing a module.symbol :) | 16:18 |
| mgz | it was 2900.something, does qblame have a mainline revs only option somewhere? | 16:18 |
| vila | mgz: dunno, but in the file graph window you have a contextual menu including show file differences | 16:19 |
| mgz | anyway, it's an easy fix to get us down to 4 failures on windows babune +- random sftp failures | 16:19 |
| vila | shoot ! | 16:20 |
| mgz | and I think I've got bugs on the remaining ones too. | 16:20 |
| vila | random as in ? | 16:20 |
| mgz | oh, maybe not the test_unicode_bzr_home one, the error on that changed recentlyish | 16:21 |
| mgz | as in, sometimes they fail, sometimes they don't | 16:21 |
| vila | haha | 16:21 |
| vila | but *how* do they fail :) | 16:21 |
| jam | vila: well, the changes that AppData don't exist are pretty much NIL... | 16:22 |
| vila | I see so many different spurious failures that I kind of lost track sometimes | 16:22 |
| jam | but yes, it could be turned into an os.makedirs() | 16:22 |
| jam | it is pretty old code | 16:22 |
| mgz | with PermissionError but if we're lucky fixing your transport cleanup with fix those too | 16:22 |
| vila | jam: not throwing stones (or I should throw them at myself) as I was never able to run these specific tests when I was looking at the code | 16:23 |
| mgz | http://babune.ladeuil.net:24842/job/selftest-windows/196/ <- see two new sftp failures hiding the fact I just fixed two tests | 16:23 |
| === deryck is now known as deryck[lunch] | ||
| mgz | ^I think that config code is fine bar the missing indent | 16:23 |
| mgz | ...is it worth adding a test just for this... hmmm... nah. | 16:24 |
| vila | mgz: no ! We already have a failing test ! | 16:24 |
| mgz | righty. | 16:24 |
| vila | http://babune.ladeuil.net:24842/job/selftest-windows/189/testReport/bzrlib.tests.test_bundle/TestReadMergeableFromUrl/test_smart_server_connection_reset/ is surprising, we don't translate the exception correctly ? | 16:26 |
| mgz | that's bug... | 16:27 |
| vila | err, sry for the url in an old build, I just check it has been failing consistently for a while | 16:27 |
| mgz | bug 581311 | 16:27 |
| ubot5 | Launchpad bug 581311 in Bazaar "bt.test_bundle.TestReadMergeableFromUrl.test_smart_server_connection_reset fails on windows (affected: 1, heat: 5)" [Medium,Confirmed] https://launchpad.net/bugs/581311 | 16:27 |
| mgz | see comment #1 for my thinking. | 16:27 |
| mgz | I'm not completely certain just wrapping the error is right. | 16:28 |
| vila | just reading | 16:28 |
| vila | I don't remember if we reconnect automatically on CONNRESET, but if we do, then I see no reason to not do it too for CONNABORTED | 16:29 |
| === zyga_ is now known as zyga | ||
| vila | does CONNABORTED exist on *nix ? | 16:30 |
| mgz | yup. | 16:31 |
| mgz | errno.ECONNABORTED on nix. | 16:32 |
| mgz | now gmail has decided to be pants as well as launchpad. will someone please unbreak the internet? | 16:34 |
| vila | sudo repair internet | 16:34 |
| Kinnison | This incident has been reported to your systems administrator. | 16:35 |
| vila | :) | 16:41 |
| Glenjamin | Does anyone else run bzr smart over HTTP+WSGI? | 16:42 |
| Glenjamin | i've been getting some weird errors lately, which have mostly been fixed by disabling the pyrex-built C extensions. I reported one, but haven't really had time to sit down and make reproducible test cases | 16:43 |
| Glenjamin | (as i need to make my server work :)) | 16:43 |
| vila | mgz: the only explanations I can find about ECONNABORTED only mentions the *server* side and it occurs if the client close the socket between the listen() and the accept()... | 16:43 |
| mgz | Glenjamin: I have done, but found it's pretty much always worse than just http | 16:43 |
| mgz | unless you really need push, and then I don't really trust it to be correct | 16:43 |
| Glenjamin | mgz: writeable with access controller by ldap (through apache) | 16:44 |
| mgz | ^right, I don't think we expect to be hitting it under unix semantics, but winsock is slightly different | 16:44 |
| vila | mgz: all in all, I think we shouldn't care and just process it as a CONNRESET | 16:45 |
| vila | mgz: the specific error code is raised only on windows anyway | 16:46 |
| mgz | okay, but then do we only catch the windows varient? | 16:46 |
| mgz | can bzr use ldap directly? | 16:46 |
| vila | mgz: your call, if you can write the associated tests with sufficient precision :-P i.e. just *add* the windows specific one on windows, who knows if/when someone will ever unify them... | 16:47 |
| Glenjamin | mgz: it could actually, but there's not really a clean place to slot in smart-server authentication | 16:53 |
| Glenjamin | and/or access control | 16:53 |
| Glenjamin | Aside from "just use ssh", which in most cases is a good solution | 16:54 |
| === deryck[lunch] is now known as deryck | ||
| Glenjamin | with a short nickname on a remote master branch, and then doing "bzr nick" on a local bound branch, I'm getting part of the progress bar left over | 17:08 |
| === bigjools is now known as bigjools-afk | ||
| === beuno is now known as beuno-lunch | ||
| Glenjamin | and can't reproduce on loggerhead :< | 17:13 |
| Glenjamin | *launchpad even | 17:13 |
| vila | Glenjamin: with which bzr version ? | 17:14 |
| vila | Glenjamin: whatever, file a bug, poolie has fixed quite a few in this area and is definitely the one to talk to about it | 17:15 |
| Glenjamin | 2.1.1 on ubuntu | 17:15 |
| Glenjamin | i'll try an upgrade first | 17:15 |
| vila | wow, yes, try an upgrade | 17:16 |
| vila | Glenjamin: still on lucid ? Try maverick :-D | 17:16 |
| Glenjamin | LTS :) | 17:16 |
| vila | Glenjamin: use the stable ppa ! | 17:16 |
| vila | :D | 17:16 |
| Glenjamin | don't upgrade servers that aren't broken! | 17:16 |
| Glenjamin | we do, but we don't update packages very often | 17:17 |
| vila | Glenjamin: you just said it was broken ! (Ok, I stop :) | 17:17 |
| Glenjamin | dunno why I didn't try that first, it's fixed | 17:17 |
| === Ursinha-lunch is now known as Ursinha | ||
| === bigjools-afk is now known as bigjools | ||
| === beuno-lunch is now known as beuno | ||
| dev001 | @ a 'bzr multi-pull' in my system_wide_plugins dir, i'm, today, getting a bunch of " ... minimum exported version ..." errors: http://pastebin.com/6YN3sGxw. Some, not all, of my pulls are failing. What to do here? | 19:40 |
| jelmer | dev001, is that repeatable? I mean, after you've done that multi-pull don't most errors go away? | 19:44 |
| dev001 | jelmer: hm. took three iterations, but, yes ... the errors are all gone now. anything to worry about ? | 19:46 |
| jelmer | dev001: no | 19:47 |
| dev001 | jelmer: that's what i like to hear :-) thx. | 19:47 |
| === mwhudson_ is now known as mwhudson | ||
| === Ursinha is now known as Ursinha-bbl | ||
| === Chex changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | 2.3b2 is officially released, test it ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | Launchpad down/read-only from 22:00 - 00:00 UTC for a code update | ||
| metaperl | hello... it seems that bzr has the concept of revision (http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief) by default which means it's fairly easy to track back in history ... that seems to be missing from git unless you manually do some sort of tagging of each commit? | 22:21 |
| maxb | metaperl: revision == commit, more or less. I don't understand what difference you are seeing | 22:28 |
| metaperl | maxb: it may just be my inability to use github, but I have problems moving back in time to find a file that is no longer in my repository. that being said, I just browsed around on launchpad and tried to move through various revisions of the bzr source and did not find that straightforward either. I might be better off with the old school svn | 22:30 |
| maxb | hah! | 22:31 |
| maxb | I don't think it's any easier there | 22:31 |
| poolie | hi maxb, jam | 22:39 |
| mgz | what's the easiest way of creating a working tree with bzr over sftp? | 22:41 |
| poolie | bzr-upload? | 22:42 |
| poolie | fix wts to work over transports? :) | 22:42 |
| poolie | i've been meaning to do that for years :/ | 22:42 |
| mgz | heh. I read the note in the push docs, and thought someone might have already done it. | 22:42 |
| peitschie | morning everybody | 22:43 |
| mgz | is that bug 606249 or is there also an earlier one poolie? | 22:45 |
| ubot5 | Launchpad bug 606249 in Bazaar "WorkingTree should use transport (affected: 1, heat: 3)" [Medium,Confirmed] https://launchpad.net/bugs/606249 | 22:45 |
| poolie | i don't see why it would actually be all that hard | 22:47 |
| poolie | it is that one, but i wouldn't be surprised if there's an equivalent old bug | 22:47 |
| mgz | bug 44663 also talks about the restriction but isn't about lifting it | 22:48 |
| ubot5 | Launchpad bug 44663 in Bazaar "When push can't create a working tree, some basic info should be made available (affected: 0, heat: 0)" [Wishlist,Confirmed] https://launchpad.net/bugs/44663 | 22:48 |
| poolie | mgz i think basically we just need to audit for the places it uses local directory access | 22:51 |
| thumper | abentley: bzrtools is bitching about versions | 22:51 |
| thumper | abentley: just a FYI | 22:51 |
| poolie | check all those capabilities are supported by transports, or update them if not | 22:51 |
| poolie | make sure that it doesn't get substantially slower using a localtransport | 22:51 |
| poolie | (which is basically an aspect of the previous point) | 22:52 |
| mgz | all sounds doable. | 22:55 |
| jbowtie | Just pinging for feedback on my new sphinx theme ( http://lists.ubuntu.com/archives/bazaar/2010q4/070526.html ) | 22:55 |
| mgz | I like it bar the orange. | 22:55 |
| mgz | I'm not convinced by the ubuntu font for paragraph content, but it's nice for headlines. | 22:56 |
| jbowtie | I'm kind of punting on the color selection until I see the proposed overhaul of the main site - I know someone has been working on it. | 23:00 |
| jbowtie | But I think we really need to bring the main site, wiki, and documentation together visually. | 23:00 |
| jbowtie | mgz: I could dial back on the ubuntu font for para content, but it actually looks great in print. I'll take a fresh look in a couple of weeks when I'm less besotted with it. | 23:02 |
| mgz | yeah, that's worth doing. twas, emmajane? that did a rehaul of the main site last yearish, I'm not really sure more big changes there are a good plan, but tightening everything up would really help. | 23:03 |
| jelmer | 'morning poolie, mgz, jbowtie | 23:03 |
| mgz | hey jelmer. | 23:04 |
| mgz | ...just about to ask you about a bug, but launchpad is going down so I'll leave it for next time I remember. | 23:04 |
| poolie | hi there jelmer | 23:07 |
| peitschie | mornin jelmer | 23:07 |
| jbowtie | Hi jelmer - it seems to me bzr-svn never has to deal with branch divergence; do you have some magic code that prevents that? | 23:08 |
| jbowtie | Every time I commit from bzr-tfs subsequent pulls complain about branch divergence for some reason, trying to track that down. | 23:09 |
| jelmer | mgz: Ah, yep - I guess it's time for our new release. :-) | 23:10 |
| jelmer | hi peitschie | 23:10 |
| jelmer | jbowtie: bzr-svn sets the branch tip manually when pulling, it has its own code to notice branch divergence | 23:11 |
| jelmer | jbowtie: Which methods are you overriding exactly? | 23:11 |
| jbowtie | jelmer: For branches, just pull and is_compatible | 23:16 |
| jbowtie | Most of the stuff I'm doing is in the repository classes. | 23:17 |
| jelmer | jbowtie: Branch.pull() or InterBranch.pull() ? | 23:17 |
| jbowtie | jelmer: GenericInterBranch.pull() - don't really have a TFS-native representation due to silliness in TFS workings. | 23:18 |
| poolie | hi jbowtie | 23:19 |
| jbowtie | hi poolie, thanks for the feedback on the binary diff/merge stuff. | 23:20 |
| poolie | you're welcome, thanks for tackling it | 23:20 |
| poolie | i can see the point about just handling big files well but it's not really either/or | 23:21 |
| jbowtie | I agree, but fixing big file support is likely a harder problem - need to rethink repository format for that one. | 23:23 |
| jbowtie | I've also got plans for .xcf files as well - my real driver - but I think tackling archives first will cover a much wider array of use cases. | 23:25 |
| jbowtie | jelmer: Do you know where the branch tip is being set in bzr-svn? I'm not seeing anything obvious in branch.py | 23:30 |
| jelmer | jbowtie: It should be in InterBranch.update_revisions(), look for a call to self.target.generate_revision_history() | 23:31 |
| jbowtie | jelmer: Found it, thanks. Looks like it is exactly the chunk of logic I need to implement to fix my bug. | 23:36 |
| jelmer | jbowtie: Great. :-) | 23:37 |
| jelmer | jbowtie: Btw, I was wondering whether it was possible to use bzr-tfs against codeplex.com, apparently it runs a Team Foundation Server. Have you tried that? | 23:38 |
| jbowtie | jelmer: I have not tried that yet, I suspect they're running TFS 2010 which bzr-tfs doesn't support yet (though someone submitted a patch I need to review) | 23:40 |
| jelmer | jbowtie: They have a broken (what I assume is a) tfs-to-svn bridge, which is causing strange errors when bzr-svn is used against it. | 23:40 |
| jelmer | jbowtie: Ah, ok. | 23:40 |
| jbowtie | jelmer: I'll have a look at supporting that once I've fixed the disappearing revision bug (revisions make it to the repository but not the branch) | 23:42 |
| GungaDin | when cherry picking, will there ever be a way to track history of these revisions in the future? or is it now just like a regular merge of the deltas? | 23:42 |
| GungaDin | or the text? | 23:42 |
| jbowtie | Which is, you know, kind of an issue... | 23:42 |
| jbowtie | GungaDin: Tracking cherry picks is something on the roadmap for the future. See http://wiki.bazaar.canonical.com/CherryPick | 23:45 |
| GungaDin | but when it's done in the future, will it possible for cherry picked revision in the past? | 23:46 |
| dash | bzr, the global causality violating VCS | 23:46 |
| peitschie | lol | 23:47 |
| fullermd | Causality? Bah. What did it ever do for me? | 23:47 |
| jbowtie | GungaDin: I assume not, but that depends on how it is ultimately implemented. With a cherry-pick we currently preserve the revid but not the ancestry. | 23:49 |
| jbowtie | In theory you could reconstruct the ancestry via repository forensics. | 23:49 |
| jbowtie | I think I just coined a new job description. | 23:49 |
| dash | jbowtie: please, we prefer to be called "programmer-archaeologists" | 23:50 |
| jbowtie | dash: Depends on whether you consider it a reconstruction of ancient history or solving a case of patricide. | 23:52 |
| fullermd | I think it's more matricide, 'cuz when you find out it happened the first word out of your mouth will be "mother-". | 23:52 |
| jbowtie | fullermd: Actually depends on whether it's the left -hand or right-hand parent that's lost. | 23:55 |
| jbowtie | Besides if it's repository forensics, I can put "Private Eye" on my business cards. P | 23:56 |
| fullermd | Ah, a whole new field of ancestral chirality is opening up. | 23:56 |
| jbowtie | GungaDin: Did that answer your question? | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!