| dOxxx | poolie: I think maybe a -2 build | 00:16 |
|---|---|---|
| poolie | that could be good | 00:18 |
| poolie | the next 2.3 release is probably about a month away, so it'd be good to get it out there | 00:18 |
| jelmer | maxb: hi | 00:27 |
| jelmer | maxb: unfortunately that's blocking on a bug: bug 803353 | 00:28 |
| ubot5 | Launchpad bug 803353 in subvertpy "segfault during iconv close from ra cleanup" [High,Triaged] https://launchpad.net/bugs/803353 | 00:28 |
| === medberry is now known as med_out | ||
| RenatoSilva | verterok: hi verterok | 01:38 |
| RenatoSilva | verterok: are you there? | 01:38 |
| dcrane | hi, when I try to make do bzr branch on another hard drive, all of the file permissions are changed, so it shows up as every file being modified, with bzr diff showing "(properties changed: -x to +x)" for every file. Is there a way around this? | 01:53 |
| bob2 | is this because you copied it to/from a fat32 filesystem? | 01:56 |
| dcrane | no | 01:57 |
| dcrane | erm, yes | 01:57 |
| === tchan1 is now known as tchan | ||
| poolie | spiv, hi, your inline diff branch landed | 04:48 |
| poolie | well, i guess you saw | 04:48 |
| spiv | poolie: oh good, thanks! | 04:54 |
| poolie | but it's not on qas yet | 04:54 |
| spiv | Unfortunately I've been spending most of the day lying down with a nasty headache :/ | 04:55 |
| poolie | sorry for the false alarm | 04:55 |
| poolie | :/ | 04:55 |
| poolie | nice weather for it | 04:55 |
| spiv | Heh. | 04:55 |
| poolie | if it deploys i will have poke at it for you | 04:55 |
| spiv | Thanks! The main thing for QA I think is to see that without the feature flag it doesn't break the branch merge proposal page (I'm sure it'll be fine), | 04:56 |
| poolie | there's a separate bug saying it would be nice if devs could edit them directly on qas | 04:56 |
| spiv | and then if the feature flag is set (maybe just for canonifolk or beta-testers?) that the expanders exist and work on that page. | 04:57 |
| spiv | Yeah, that would be nice | 04:57 |
| poolie | hi vila | 05:22 |
| vila | poolie: :) | 05:24 |
| vila | not there yet, coffee time | 05:24 |
| fullermd | Hmmwhut? Coffee? | 05:24 |
| * fullermd perks up. | 05:24 | |
| vila | poolie: dunno what happened with rypple, I still had the lp URL I pasted in the comment in my clipboard... | 05:26 |
| poolie | vila, rms asks that you mention bzr is a gnu package in every release announcement | 05:53 |
| poolie | you should probably mention Canonical too | 05:53 |
| poolie | and use your real name, unless there's some compelling reason not to | 05:53 |
| vila | real name ? | 05:55 |
| poolie | From: vila <v.ladeuil+lp@free.fr> | 05:55 |
| * vila nods at GNU & Canonical, it's so obvious to me I forget to mention them | 05:55 | |
| poolie | i know | 05:55 |
| poolie | and this is just a minor update | 05:55 |
| poolie | perhaps put it at the bottom | 05:55 |
| poolie | that is to say, after the text about the purpose of the release, before your sig and the mail | 05:56 |
| fullermd | vila: Don't worry, we all already know about your shameful past anyway. The assumed name isn't fooling anybody :p | 05:59 |
| vila | fullermd: hehe, quite the contrary in fact, it's a well known fact from companies and political parties that changing names works, people have a bad memory | 06:01 |
| fullermd | Hah, I bet those 17 nuns and 23 schoolchildren remember all too well! | 06:04 |
| vila | fullermd: what's the previous name of Accenture ? | 06:12 |
| lifeless | enron ? :P | 06:13 |
| fullermd | Oh, you were responsible for THAT, too? No wonder you changed your name... | 06:14 |
| vila | no, seriously, how many people still remember the old name ? | 06:16 |
| fullermd | Nobody even remembers the current name. That's what google is for. Memory is SO 20th century. | 06:16 |
| poolie | vila, rm, how would you feel about having just one set of release notes per whole of 2.5 | 07:06 |
| poolie | rather than splitting per beta | 07:06 |
| poolie | my sense is that it's really the main releases that matter now | 07:06 |
| poolie | perhaps not enough people look at them for it to be worth changing | 07:07 |
| vila | poolie: I'd rather stick with one per release if only to stay in sync with lp and make it easier to diagnose | 07:08 |
| vila | bugs or other feedback from beta testers | 07:08 |
| poolie | oh because they're split out on lp | 07:08 |
| poolie | fair enough | 07:08 |
| poolie | i should read your RM tweaks | 07:08 |
| vila | that would be good | 07:09 |
| vila | I'm not sure reading the diff only makes sense though, | 07:09 |
| vila | but as I said, I've read this doc far too much | 07:09 |
| poolie | maybe you could build it and put up the html? | 07:09 |
| poolie | i think that helps for doc changes | 07:11 |
| poolie | also helps catch markup errors | 07:11 |
| vila | I did check locally with 'make docs' and 'make docs-sphinx' and firefox, will put a sphinx version online, justasec | 07:12 |
| vila | done at http://people.canonical.com/~vila/ | 07:15 |
| vila | -doc is the regular one, -sphinx is the.. sphinx one | 07:16 |
| vila | doesn't match doc.bazaar.canonical.com though, missing dependencies probably | 07:16 |
| vila | hmm | 07:16 |
| vila | I think generating them locally is easiest :) | 07:17 |
| poolie | diff --using meld helps too | 07:19 |
| vila | oooh, using the remote branch you mean ? Or with the reviewed branch already pulled locally ? | 07:24 |
| poolie | ok done | 07:29 |
| poolie | thanks for doing all that work | 07:29 |
| poolie | i pulled it, but i guess i could have done it remotely | 07:29 |
| poolie | boy i'm tired | 07:29 |
| vila | meh, given 2.3.4-0ubuntu1 and 2.3.4-0~bazaar1~natty1 available, shouldn't the former be considered more recent than the later ? | 07:36 |
| vila | oh, priorities between their archives | 07:37 |
| vila | here we go, dandling /etc/apt/preferences :) | 07:39 |
| Riddell | good morning bazaar | 08:10 |
| vila | _o/ | 08:16 |
| jam | morning all | 08:17 |
| vila | jam: good morning ! | 08:17 |
| * jelmer waves | 08:27 | |
| jelmer | vila: I've updated the special-chars doc a bit: http://pastebin.ubuntu.com/648943/ | 09:28 |
| jelmer | vila: comments welcome - does this address your concerns? | 09:28 |
| vila | jelmer: excellently :) | 09:30 |
| vila | jelmer: thanks a lot for your patience ! | 09:30 |
| jelmer | vila: thanks for the reviews :) | 09:33 |
| jelmer | next, I'll have a look at updating the colocated support branch | 09:34 |
| bialix | jam: hi | 10:02 |
| jam | hi bialix | 10:02 |
| bialix | jam: today I've made releases of QBzr and Explorer for bzr 2.4. I've updated windows-installer metadata, I hope this branch can be landed before bzr 2.4 final: https://code.launchpad.net/~bialix/bzr-windows-installers/qbzr-explorer-for-2.4/+merge/68649 | 10:03 |
| bialix | jam: due to my mistake with ~bzr membership I'm not able to push directly to windows-installer branch, so I have to create MPs instead | 10:05 |
| jam | no problem, I'm landing that one know | 10:05 |
| jam | now | 10:05 |
| bialix | I don't know what must I do now | 10:05 |
| bialix | jam: ok, thank | 10:06 |
| maxb | bialix: jam could put you into ~bzr ? | 10:07 |
| bialix | maxb: I think so | 10:07 |
| jam | bialix: I'll check | 10:07 |
| jam | bialix: you're added | 10:08 |
| bialix | thank you jam | 10:08 |
| jam | I think it is still reasonable to make mps, just to track the changes, but it isn't critical | 10:08 |
| maxb | Oh, jelmer is no longer away. I should pick up the discussion on merging ~bzr-core into ~bzr | 10:10 |
| jelmer | maxb: hey, what's up? | 10:16 |
| maxb | Hi | 10:16 |
| maxb | I'd been looking at what it would talk to get rid of all of ~bzr's structural subscriptions such that there would no longer be a reason to split ~bzr-core | 10:16 |
| maxb | Most of them seemed fairly reasonable, except that ~bzr includes ~bzr-git, and ~bzr-git has some structural subscriptions for bzr-git | 10:17 |
| maxb | er | 10:18 |
| jelmer | I'm happy with changing the subscriptions for ~bzr-git | 10:18 |
| jelmer | to match what we do for other plugins | 10:18 |
| maxb | or at least, I thought that was what the problem was, but my old email is contradicting me | 10:18 |
| maxb | Oh, whoops | 10:19 |
| maxb | When I said ~bzr-git, I meant ~bzr-gtk in this case | 10:19 |
| jelmer | ah, ok | 10:19 |
| maxb | https://launchpad.net/~bzr-gtk/+structural-subscriptions | 10:19 |
| jelmer | I have the same opinion for bzr-gtk, though we'd probably have to check with some other people too | 10:19 |
| maxb | The other teams that contribute structural subscriptions to ~bzr are ~bzr-upload-devs (vila) and ~qbzr-bugs (garyvdm) | 10:20 |
| bialix | what's about ~bzr-bugs? | 10:21 |
| bialix | what's about ~qbzr-bugs? | 10:21 |
| maxb | Per my email of June 14th, there does not appear to be any consistent pattern to which plugins do or do not get included in ~bzr's subscriptions | 10:21 |
| bialix | do you need just remove it? | 10:21 |
| maxb | bialix: ~qbzr-bugs has ~bzr as a member to give ~bzr members bug supervisor rights over qbzr, but it also has a structural subscription to qbzr's bugs | 10:22 |
| maxb | The issue is that I don't think ~bzr membership should imply defaulting sending people much, if any, email | 10:22 |
| bialix | maxb: right now only ~bzr-qa is member of ~bzr-bugs | 10:22 |
| bialix | maxb: yep | 10:23 |
| maxb | ~bzr is a member of ~bzr-qa | 10:23 |
| bialix | weird | 10:23 |
| bialix | maybe at the past it sounded reasonable to have more bug mails for qa/bug supervisor teams | 10:24 |
| maxb | Basically it comes down to it really never making sense to use the same grouping of people for access control as for sending email | 10:24 |
| bialix | I don't see any value in ~qbzr-bugs team today | 10:24 |
| bialix | ~qbzr-bugs group only can triage bugs, IIRC | 10:25 |
| maxb | So, in short, my plan is to attempt to get agreement in removing all subscriptions from ~bzr-gtk, ~bzr-upload-devs and ~qbzr-bugs, then proceed to removing bug subscriptions from ~bzr, and then proceed to a final proposal to merge ~bzr-core into ~bzr, ending the confusion | 10:25 |
| jelmer | maxb: +1 | 10:26 |
| bialix | I'll be happy to remove ~qbzr-bugs team as well | 10:26 |
| jelmer | vila: ^ | 10:26 |
| maxb | bialix: Remove the team? Or just remove its bug subscription? | 10:26 |
| maxb | I assume the team exists to manage bug supervisor permissions on qbzr | 10:27 |
| bialix | maxb: main QBzr developers team is ~qbzr-dev | 10:27 |
| bialix | maxb: I think so | 10:27 |
| maxb | Right - so ~qbzr-bugs exists to allow you to permit non-developers to have bug triage access | 10:27 |
| bialix | maxb: right, but I think nobody but ~bzr-dev and poolie has done that | 10:28 |
| bialix | sorry, I meant ~qbzr-dev | 10:28 |
| vila | jelmer: +0, I don't have issues (almost) with lp mail, so I don't feel qualified to comment there. It may change the day I *miss* mails, but that doesn't seem to be the case with the proposal | 10:30 |
| bialix | if removing subscription means mute bug mails -- I'm ok | 10:32 |
| jelmer | vila: you can always personally subscribe to those projects | 10:33 |
| bialix | today the number of bzr mails I got is way too much. | 10:33 |
| jelmer | vila: thanks to the new bug subscription work by the lp team | 10:33 |
| jelmer | (I think that's what prompted maxb's proposal?) | 10:33 |
| vila | yeah, I'm unclear about why all these teams changes are still required... | 10:34 |
| vila | I'm all for *reducing* the number of teams anyway | 10:34 |
| maxb | vila: The work done by the LP team means it's possible to opt out of inherited subscriptions. It doesn't make it easy or convenient | 11:06 |
| maxb | Also, I don't think defaulting to sending ~bzr bugmail about stuff actually makes sense | 11:06 |
| jam | vila: as the current PP, care to look at: https://code.launchpad.net/~jameinel/bzr/2.5-verbosity-knob-812928/+merge/68559 | 11:16 |
| jam | I know Barry thought the changes were good, I'd like at least someone else's opinion. | 11:17 |
| jam | jelmer: a question about bzr-svn and tags | 12:22 |
| jam | I just poked at lp:gcc-linaro, and it has 2626 tags that are not in the repository. | 12:22 |
| jam | Is this because svn creates a new commit when creating a tag | 12:22 |
| jam | and bzr-svn then imports that as a separate commit. | 12:22 |
| jam | ? | 12:22 |
| jam | So *most* bzr-svn converted repositories are going to have 90%+ of their tags not in the main trunk history? | 12:23 |
| maxb | igh | 12:25 |
| maxb | ish | 12:25 |
| maxb | bzr-svn does the right thing if the tag is a "simple copy" made via a url-to-url copy, or a copy from a svn wc that is at a single revision | 12:25 |
| jam | maxb: what is slightly worse is that because bzr-2.4 is going to start copying those tags by default, anyone using a shared repository locally that has those revs, is going to start pushing them up to all of their stacked branches. | 12:25 |
| jam | maxb: http://paste.ubuntu.com/649052/ | 12:26 |
| maxb | However, if the svn tag was made by copying from a svn working copy that was at mixed revisions, bzr-svn attempts to represent this as an off-trunk revision | 12:26 |
| jam | maxb: so if you just "tag" your local checkout, it re-creates the layout as a tagged rev? | 12:27 |
| maxb | In practice, this isn't really what most people would want, and I have an idea that bzr-svn ought to do more checking of the nature of the tagged tree, and possibly intelligently pretend the tag is on trunk, if that won't affect the tree content | 12:27 |
| maxb | jam: exactly | 12:28 |
| jam | maxb: well, the cat-is-mostly-out-of-the-bag since changing the scheme creates a different set of revs, right? | 12:28 |
| maxb | I think we could just pretend otherwise in this case | 12:28 |
| maxb | We'd only be changing the logic that says what revid a tag points to, not the data in any revision itself | 12:29 |
| jelmer | jam: sorry, just got back from lunch | 12:29 |
| jam | jelmer: np | 12:29 |
| jam | I was hoping the new fetch behavior would make bug #388269 less problematic, because we would be seeding lots of search points. | 12:29 |
| ubot5 | Launchpad bug 388269 in Bazaar "many get_parent_map calls during walk to common revisions when branching into empty repository" [High,Confirmed] https://launchpad.net/bugs/388269 | 12:29 |
| jam | but... they are all ghosts... | 12:29 |
| jelmer | jam: svn tags are basically copy operations, and bzr-svn only tags them on the mainline if they don't have any additional changes | 12:29 |
| jelmer | jam: some people will create tags for e.g. a release that make a trivial additional change, like the equivalent of setting 'final' in the version string in bzr | 12:30 |
| maxb | Yes - though there's a class of additional change which are essentially no-ops, which I think bzr-svn ought to ignore | 12:30 |
| jelmer | maxb: what sort of changes? | 12:31 |
| maxb | If the tag is made from a mixed revision svn working copy, svn will record all the mixed revisions. But, if in fact the working copy could have been "svn update"d to the newest revision involved in the tag without actually causing any tree changes, it would be nice if bzr-svn could recognize that as a simple tag | 12:31 |
| jelmer | maxb: can you give an example of ta tag where that has happened? | 12:32 |
| jam | jelmer: well, out of 2690 tags in lp:gcc-linaro, only about 64 are actually present in the repository | 12:32 |
| maxb | Pretty much any tag made by the maven-release-plugin, so I should be able to find an example in the apache repo | 12:32 |
| jam | so whatever trick is "common" apparently happened there a lot | 12:33 |
| maxb | http://paste.ubuntu.com/649064/ | 12:35 |
| vila | jam: sorry, just got back from lunch | 12:35 |
| maxb | jam: Wait, are these ancient tags dating back to cvs days? | 12:35 |
| jam | maxb: not sure, I see svn ones when I poke at it briefly | 12:36 |
| maxb | jelmer: So, in my paste, you can see a tag constructed via a copy from 701933, and a subtree replace of 701941. But, by checking the history of the copy source, we can see that the resultant tree is exactly the same as a direct copy from 701941. | 12:37 |
| jam | vila: long lunch :) no problem | 12:37 |
| maxb | Representing the tag as a direct copy from 701941 is clearer and closer to the user's intent, and avoids the extra revision | 12:38 |
| jelmer | maxb: the file changed in between, in 701934 | 12:38 |
| maxb | jelmer: Yes, but the tag incorporates this change | 12:38 |
| vila | jam: yeah, had some shopping to do, it's amazing how it always took longer with girls... | 12:38 |
| maxb | R /maven/plugins/tags/maven-antrun-plugin-1.3/pom.xml (from /maven/plugins/trunk/maven-antrun-plugin/pom.xml:701941) | 12:38 |
| maxb | That particular file is promoted to a revision after the change, in the tag | 12:38 |
| jelmer | maxb: I'd consider that a svn bug | 12:39 |
| jelmer | maxb: analysing history to figure out that sort of thing can become really complicated | 12:39 |
| maxb | Well, less of a bug, and more a complete failure to design for what users actually want. | 12:40 |
| maxb | And yes, producing a nicer conversion by history analysis is definitely complicated | 12:40 |
| maxb | It would, however, lead to nicer user experience of bzr and bzr-svn, and a more faithful representation of the original intent in bzr | 12:41 |
| jelmer | maxb: this can get really complex (and time consuming) on some tags if a lot of history is involved | 12:41 |
| maxb | Yes, this might turn out to be too complicated to be actually worth doing in bzr-svn | 12:42 |
| jelmer | maxb: I don't think this is worth considering until bzr supports versioned tags | 12:42 |
| maxb | However, it's definitely worth doing if bzr-svn ever grew support for doing extra work in a one-time conversion mode | 12:43 |
| jelmer | vila, Riddell: if you are still patchpiloting, did you see https://code.launchpad.net/~jelmer/bzr-loom/fix-record-entry-contents/+merge/68426 ? | 13:05 |
| vila | jelmer: approved, which a question :) | 13:08 |
| jelmer | vila: dankuwelmerci | 13:10 |
| vila | hehe | 13:12 |
| vila | bhaa | 13:12 |
| vila | with a question (that my browser didn't want to send for unkown reasons 8-/) | 13:13 |
| vila | jelmer: In what context was the test failing and why not sooner ? | 13:13 |
| vila | jelmer: location-commas also approved | 13:15 |
| jelmer | vila: I'm not entirely sure why it didn't fai earlier; perhaps we didn't use the parent inventories in record_entry_contents before in some cases? | 13:15 |
| jelmer | vila: posted the backtraces | 13:15 |
| vila | jelmer: LeYSME ? Isn't tmpfile funny sometimes :) | 13:16 |
| jelmer | vila: I had nothing to do with that, promise :) | 13:17 |
| jelmer | vila: thanks for the location-commas review | 13:17 |
| jelmer | vila: I'll also wait for John, as he is one of the heavy users of comma's in names | 13:18 |
| === med_out is now known as medberry | ||
| === medberry is now known as med_out | ||
| bdestefanis | anyone else having trouble opening bazaar explorer? | 15:53 |
| bdestefanis | i'm getting a key error '\x00' | 15:54 |
| === deryck is now known as deryck[lunch] | ||
| bdestefanis | in commands.pyo and most recent call is in pickle.pyo | 15:54 |
| bdestefanis | more details here: https://bugs.launchpad.net/bzr/+bug/814151 | 15:55 |
| ubot5 | Ubuntu bug 814151 in Bazaar "bazaar explorer no longer opens" [Undecided,New] | 15:55 |
| bdestefanis | does bazaar use windows domain certificates for anything? | 15:57 |
| mgz | bdestefanis: delete $BZR_CONFIG/explorer/history.dat | 16:08 |
| mgz | bzr version will tell you where the config dir is | 16:08 |
| mgz | on windows it's probably %APPDATA%\bazaar\2.0\explorer\history.dat | 16:09 |
| bdestefanis | i think i may have caused this problem. | 16:20 |
| bdestefanis | by trying to unversion a directory. | 16:20 |
| mgz | possibly. | 16:20 |
| bdestefanis | now the main branch has a lot of unresolved conflicts | 16:21 |
| mgz | but it's a bug in explorer whatever | 16:21 |
| bdestefanis | that i can't seem to revert | 16:21 |
| bdestefanis | let me try what you suggested | 16:21 |
| mgz | if you could find the file, and upload it to the bug, that might make things clearer | 16:21 |
| mgz | you may want to check it for personal info first (it's a binary format though) | 16:21 |
| bdestefanis | wow. deleting the history.dat file fixed it. | 16:22 |
| bdestefanis | thanks! :) | 16:22 |
| bdestefanis | this new version of bazaar seems to be a bit faster too :) | 16:24 |
| mgz | bdestefanis: if it's still in your recycle bin, uploading it to the bug might help us work out what caused the problem in the first place | 16:28 |
| bdestefanis | i renamed it to history.backup | 16:29 |
| bdestefanis | i will attach it to the bug | 16:29 |
| mgz | thanks! | 16:33 |
| bdestefanis | on other thing you guys are probably already aware of | 16:33 |
| bdestefanis | for whatever reason....anytime i perform an operation in bazaar explorer ...it takes about 60 seconds or more to become responsive after the operation is completed. | 16:34 |
| bdestefanis | the window goes into the "Not Responding" state | 16:34 |
| bdestefanis | and if you wait long enough you can use Bazaar Explorer again | 16:34 |
| bdestefanis | this is on Windows 7 64-bit | 16:35 |
| mgz | that doesn't sound typical, would be good to find out what it's doing during that minute | 16:36 |
| bdestefanis | yeah, i'm using a path like \\ip.address.goes.here\c$\www\bzrversioneddir | 16:36 |
| bdestefanis | but it doesn't seem to make a difference if i use http | 16:37 |
| === med_out is now known as medberry | ||
| bdestefanis | i have wireshark i suppose i could see if anything is happening on the wire | 16:39 |
| bdestefanis | i have no idea what my boss did to the repository ...but now i have all this garbage and i can't revert it. i think i'm going to killl myself. | 16:39 |
| bdestefanis | from wireshark | 16:42 |
| bdestefanis | it looks like it is using SMB to iterate over all of the paths in the bzr versioned directory | 16:42 |
| bdestefanis | these are requests from the server to my machine | 16:43 |
| bdestefanis | i'm sorry | 16:43 |
| bdestefanis | reverse that | 16:43 |
| bdestefanis | they are requests from my machine to the server | 16:43 |
| awilkins | I wonder if his boss did a checkout on the server | 16:52 |
| awilkins | That causes things to REALLY slow down | 16:52 |
| awilkins | But it looks like it was a checkout anyway | 16:52 |
| awilkins | Hmm | 16:52 |
| === beuno is now known as beuno-lunch | ||
| DonDiego | hi | 17:14 |
| DonDiego | bzr rebase moved a few of my commits into limbo (after stumbling over a merge i think) | 17:15 |
| DonDiego | is there something like "git reflog" in bzr that i can recover them with? | 17:15 |
| DonDiego | googling hasn't provided answers... | 17:15 |
| jelmer | DonDiego: there isn't anything like reflog, but you can use "bzr heads --dead" to find bzr revisions that exist but do not have anything pointing at them | 17:17 |
| * jelmer runs off to dinner | 17:17 | |
| === hunger_ is now known as hunger | ||
| DonDiego | jelmer: thanks, that helped | 17:28 |
| jo-erlend | In 11.04, I installed bzr-gtk. Didn't that use to come with a gui for bazaar where you could see files, diffs, etc? | 17:52 |
| === joey` is now known as joey | ||
| === beuno-lunch is now known as beuno | ||
| lxsameer | hi, my connection lost in middle of a cloning , how can i resume cloning? ( .bzr dir exists ) | 18:21 |
| LeoNerd | http://www.pastie.org/2250474 <== wtf did that just do.. and how do I undo it? | 20:44 |
| LeoNerd | I think I've branched history somehow.. do not want. | 20:45 |
| maxb | LeoNerd: you bzr upped in a bound brach with commits ahead of the bound location | 20:52 |
| LeoNerd | Yes... | 20:53 |
| LeoNerd | It used to fail-and-die when I did that. I want that behaviour back | 20:53 |
| maxb | accordingly bzr fetched the new commits, and moved the local commits to a pending merge | 20:53 |
| LeoNerd | Yeah.. I reeeally dislike that behaviour | 20:54 |
| maxb | so, just committing the pending merge should be fine | 20:54 |
| LeoNerd | I don't want it to appear as a merge, though | 20:55 |
| maxb | why not? | 20:55 |
| LeoNerd | Because I dislike the unneatness that'll appear in the history | 20:55 |
| maxb | it *is* a merge, stop trying to pretend otherwise :-) | 20:56 |
| LeoNerd | It should'nt be | 20:56 |
| LeoNerd | It should appear as a strict new revision | 20:56 |
| maxb | delph wants to know if you're still at work :-) | 20:56 |
| LeoNerd | Athome | 20:57 |
| maxb | he's leaving the pilot now | 20:57 |
| LeoNerd | Hrm.. remind me again how I update back to a dead head... It's complaining it doesn't exist.. :/ | 20:58 |
| LeoNerd | Oh.. bah. I wanted pull | 20:59 |
| LeoNerd | There we are. bzr heads --dead-only.. find revid. bzr pull -r revid:...; bzr push | 20:59 |
| LeoNerd | And now my history is linear again :) | 20:59 |
| === Sith is now known as Guest85737 | ||
| RenatoSilva | verterok: hi | 21:24 |
| verterok | RenatoSilva: hey | 21:24 |
| RenatoSilva | verterok: did you see the new proposal? the conflicts were simple to solve... | 21:28 |
| verterok | RenatoSilva: yes, will review it asap. thanks! | 21:28 |
| RenatoSilva | verterok: thanks too | 21:28 |
| verterok | RenatoSilva: fyi, I'll be moving the project to tycho (maven 3) | 21:29 |
| verterok | RenatoSilva: that way anyone can build the thing easily | 21:29 |
| verterok | RenatoSilva: and execute the tests without configuring everything in eclipse | 21:30 |
| RenatoSilva | verterok: I've heard of it on some merge and thought it was just a plugin, not the codename to maven 3 | 21:31 |
| verterok | RenatoSilva: it's a plugin, but it requires maven 3 | 21:32 |
| RenatoSilva | verterok: ah ok | 21:32 |
| RenatoSilva | verterok: how about those old encoding problems in bzr-xmloutput heh... no volunteer to fix them :( | 21:32 |
| verterok | RenatoSilva: are still there :( | 21:33 |
| RenatoSilva | verterok: (required to cut some edges in bzr-eclipse) | 21:33 |
| verterok | RenatoSilva: I thinking in moving it out of the command based approach | 21:33 |
| RenatoSilva | someone please bzr-eclipse needs help! (and hence bzr-java-lib/bzr-xmloutput) | 21:33 |
| verterok | RenatoSilva: to use a real rpc | 21:33 |
| verterok | RenatoSilva: basically stop using commands, it's a lot of work and not even started with it :/ | 21:34 |
| RenatoSilva | verterok: I somewhat remember one of our discussions on calling bzrlib directly, but it would require some other project to evolute enough or something... can't recall | 21:35 |
| verterok | RenatoSilva: yes, jython | 21:36 |
| verterok | RenatoSilva: jython isn't there yet | 21:36 |
| RenatoSilva | verterok: is it by any chance the lack of C-implemented python modules? | 21:38 |
| RenatoSilva | verterok: which is required by bzrlib? | 21:38 |
| verterok | RenatoSilva: ctypes | 21:38 |
| * RenatoSilva thinks is required | 21:38 | |
| RenatoSilva | verterok: so jython hasn't implemented ctypes yet? bah | 21:41 |
| verterok | RenatoSilva: only a small part | 21:41 |
| RenatoSilva | does bzrlib use stuff which requires native code or is it made by native code too? | 21:41 |
| verterok | RenatoSilva: it requires some platform specific stuff | 21:44 |
| RenatoSilva | verterok: do you remember the other option of porting bzrlib to Java? Not sure if it's insane and which one would be harder (this or completing ctype) | 22:01 |
| verterok | RenatoSilva: that's a lot of work (the porting of bzrlib) | 22:01 |
| RenatoSilva | and the syncing | 22:02 |
| RenatoSilva | brb | 22:03 |
| vila | finally: http://babune.ladeuil.net:24842/job/selftest-chroot-natty-proposed/32/testReport/ | 22:11 |
| vila | 2.3.4-0ubuntu1 installed in a natty chroot | 22:13 |
| poolie | hi vila, jelmer | 23:16 |
| jelmer | hi poolie | 23:19 |
| poolie | spiv: alive? | 23:26 |
| spiv | poolie: yes, and apparently over a degree cooler than yesterday. | 23:26 |
| poolie | you are? | 23:27 |
| poolie | hm i guess that's good | 23:27 |
| poolie | the bmp stuff should now be live on qastaging, so i was going to see which one of us should test it | 23:27 |
| spiv | Ah, cool, I'll poke at it. | 23:27 |
| poolie | in some ways having someone else test might be better? | 23:28 |
| spiv | Well you can too :) | 23:28 |
| poolie | if you're ready now we can ask the losas to turn it on | 23:28 |
| jelmer | g'morning spiv | 23:28 |
| jelmer | spiv: I added some feedback to bug 718944, sorry for not noticing it earlier | 23:29 |
| ubot5 | Launchpad bug 718944 in bzr-builddeb "bzr-builddeb merge sorts the changelog by version order, rather than preserving existing ordering" [High,In progress] https://launchpad.net/bugs/718944 | 23:29 |
| spiv | jelmer: ooh, thanks for the links to the other bugs! | 23:30 |
| spiv | I guess I'll merge that today then, the feedback on the list was (cautiously) positive too. | 23:31 |
| jelmer | cool, that'll make quite a few ubuntu devs happy(ier) | 23:33 |
| jelmer | have a good day | 23:33 |
| * jelmer gets some sleep | 23:33 | |
| poolie | sleep tight | 23:38 |
| === medberry is now known as med_out | ||
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!