[00:16] <dOxxx> poolie: I think maybe a -2 build
[00:18] <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:27] <jelmer> maxb: hi
[00:28] <jelmer> maxb: unfortunately that's blocking on a bug: bug 803353
[01:38] <RenatoSilva> verterok: hi verterok
[01:38] <RenatoSilva> verterok: are you there?
[01:53] <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:56] <bob2> is this because you copied it to/from a fat32 filesystem?
[01:57] <dcrane> no
[01:57] <dcrane> erm, yes
[04:48] <poolie> spiv, hi, your inline diff branch landed
[04:48] <poolie> well, i guess you saw
[04:54] <spiv> poolie: oh good, thanks!
[04:54] <poolie> but it's not on qas yet
[04:55] <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:56] <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:57] <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
[05:22] <poolie> hi vila
[05:24] <vila> poolie: :)
[05:24] <vila> not there yet, coffee time
[05:24] <fullermd> Hmmwhut?  Coffee?
[05:24]  * fullermd perks up.
[05:26] <vila> poolie: dunno what happened with rypple, I still had the lp URL I pasted in the comment in my clipboard...
[05:53] <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:55] <vila> real name ?
[05:55] <poolie> From: vila<EMAIL_ADDRESS>[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:56] <poolie> that is to say, after the text about the purpose of the release, before your sig and the mail
[05:59] <fullermd> vila: Don't worry, we all already know about your shameful past anyway.  The assumed name isn't fooling anybody   :p
[06:01] <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:04] <fullermd> Hah, I bet those 17 nuns and 23 schoolchildren remember all too well!
[06:12] <vila> fullermd: what's the previous name of Accenture ?
[06:13] <lifeless> enron ? :P
[06:14] <fullermd> Oh, you were responsible for THAT, too?  No wonder you changed your name...
[06:16] <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.
[07:06] <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:07] <poolie> perhaps not enough people look at them for it to be worth changing
[07:08] <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:09] <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:11] <poolie> i think that helps for doc changes
[07:11] <poolie> also helps catch markup errors
[07:12] <vila> I did check locally with 'make docs' and 'make docs-sphinx' and firefox, will put a sphinx version online, justasec
[07:15] <vila> done at http://people.canonical.com/~vila/
[07:16] <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:17] <vila> I think generating them locally is easiest :)
[07:19] <poolie> diff --using meld helps too
[07:24] <vila> oooh, using the remote branch you mean ? Or with the reviewed branch already pulled locally ?
[07:29] <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:36] <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:37] <vila> oh, priorities between their archives
[07:39] <vila> here we go, dandling /etc/apt/preferences :)
[08:10] <Riddell> good morning bazaar
[08:16] <vila> _o/
[08:17] <jam> morning all
[08:17] <vila> jam: good morning !
[08:27]  * jelmer waves
[09:28] <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:30] <vila> jelmer: excellently :)
[09:30] <vila> jelmer: thanks a lot for your patience !
[09:33] <jelmer> vila: thanks for the reviews :)
[09:34] <jelmer> next, I'll have a look at updating the colocated support branch
[10:02] <bialix> jam: hi
[10:02] <jam> hi bialix
[10:03] <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:05] <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:06] <bialix> jam: ok, thank
[10:07] <maxb> bialix: jam could put you into ~bzr ?
[10:07] <bialix> maxb: I think so
[10:07] <jam> bialix: I'll check
[10:08] <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:10] <maxb> Oh, jelmer is no longer away. I should pick up the discussion on merging ~bzr-core into ~bzr
[10:16] <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:17] <maxb> Most of them seemed fairly reasonable, except that ~bzr includes ~bzr-git, and ~bzr-git has some structural subscriptions for bzr-git
[10:18] <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:19] <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:20] <maxb> The other teams that contribute structural subscriptions to ~bzr are ~bzr-upload-devs (vila) and ~qbzr-bugs (garyvdm)
[10:21] <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:22] <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:23] <bialix> maxb: yep
[10:23] <maxb> ~bzr is a member of ~bzr-qa
[10:23] <bialix> weird
[10:24] <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:25] <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:26] <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:27] <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:28] <bialix> maxb: right, but I think nobody but ~bzr-dev and poolie has done that
[10:28] <bialix> sorry, I meant ~qbzr-dev
[10:30] <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:32] <bialix> if removing subscription means mute bug mails -- I'm ok
[10:33] <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:34] <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
[11:06] <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:16] <jam> vila: as the current PP, care to look at: https://code.launchpad.net/~jameinel/bzr/2.5-verbosity-knob-812928/+merge/68559
[11:17] <jam> I know Barry thought the changes were good, I'd like at least someone else's opinion.
[12:22] <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:23] <jam> So *most* bzr-svn converted repositories are going to have 90%+ of their tags not in the main trunk history?
[12:25] <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:26] <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:27] <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:28] <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:29] <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] <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:30] <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:31] <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:32] <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:33] <jam> so whatever trick is "common" apparently happened there a lot
[12:35] <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:36] <jam> maxb: not sure, I see svn ones when I poke at it briefly
[12:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <maxb> However, it's definitely worth doing if bzr-svn ever grew support for doing extra work in a one-time conversion mode
[13:05] <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:08] <vila> jelmer: approved, which a question :)
[13:10] <jelmer> vila: dankuwelmerci
[13:12] <vila> hehe
[13:12] <vila> bhaa
[13:13] <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:15] <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:16] <vila> jelmer: LeYSME ? Isn't tmpfile funny sometimes :)
[13:17] <jelmer> vila: I had nothing to do with that, promise :)
[13:17] <jelmer> vila: thanks for the location-commas review
[13:18] <jelmer> vila: I'll also wait for John, as he is one of the heavy users of comma's in names
[15:53] <bdestefanis> anyone else having trouble opening bazaar explorer?
[15:54] <bdestefanis> i'm getting a key error '\x00'
[15:54] <bdestefanis> in commands.pyo and most recent call is in pickle.pyo
[15:55] <bdestefanis> more details here: https://bugs.launchpad.net/bzr/+bug/814151
[15:57] <bdestefanis> does bazaar use windows domain certificates for anything?
[16:08] <mgz> bdestefanis: delete $BZR_CONFIG/explorer/history.dat
[16:08] <mgz> bzr version will tell you where the config dir is
[16:09] <mgz> on windows it's probably %APPDATA%\bazaar\2.0\explorer\history.dat
[16:20] <bdestefanis> i think i may have caused this problem.
[16:20] <bdestefanis> by trying to unversion a directory.
[16:20] <mgz> possibly.
[16:21] <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:22] <bdestefanis> wow. deleting the history.dat file fixed it.
[16:22] <bdestefanis> thanks! :)
[16:24] <bdestefanis> this new version of bazaar seems to be a bit faster too :)
[16:28] <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:29] <bdestefanis> i renamed it to history.backup
[16:29] <bdestefanis> i will attach it to the bug
[16:33] <mgz> thanks!
[16:33] <bdestefanis> on other thing you guys are probably already aware of
[16:34] <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:35] <bdestefanis> this is on Windows 7 64-bit
[16:36] <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:37] <bdestefanis> but it doesn't seem to make a difference if i use http
[16:39] <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:42] <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:43] <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:52] <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
[17:14] <DonDiego> hi
[17:15] <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:17] <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:28] <DonDiego> jelmer: thanks, that helped
[17:52] <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?
[18:21] <lxsameer> hi, my connection lost in middle of a cloning , how can i resume cloning? ( .bzr dir exists )
[20:44] <LeoNerd> http://www.pastie.org/2250474  <== wtf did that just do.. and how do I undo it?
[20:45] <LeoNerd> I think I've branched history somehow.. do not want.
[20:52] <maxb> LeoNerd: you bzr upped in a bound brach with commits ahead of the bound location
[20:53] <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:54] <LeoNerd> Yeah.. I reeeally dislike that behaviour
[20:54] <maxb> so, just committing the pending merge should be fine
[20:55] <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:56] <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:57] <LeoNerd> Athome
[20:57] <maxb> he's leaving the pilot now
[20:58] <LeoNerd> Hrm.. remind me again how I update back to a dead head... It's complaining it doesn't exist.. :/
[20:59] <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 :)
[21:24] <RenatoSilva> verterok: hi
[21:24] <verterok> RenatoSilva: hey
[21:28] <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:29] <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:30] <verterok> RenatoSilva: and execute the tests without configuring everything in eclipse
[21:31] <RenatoSilva> verterok: I've heard of it on some merge and thought it was just a plugin, not the codename to maven 3
[21:32] <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:33] <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:34] <verterok> RenatoSilva: basically stop using commands, it's a lot of work and not even started with it :/
[21:35] <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:36] <verterok> RenatoSilva: yes, jython
[21:36] <verterok> RenatoSilva: jython isn't there yet
[21:38] <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:41] <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:44] <verterok> RenatoSilva: it requires some platform specific stuff
[22:01] <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:02] <RenatoSilva> and the syncing
[22:03] <RenatoSilva> brb
[22:11] <vila> finally: http://babune.ladeuil.net:24842/job/selftest-chroot-natty-proposed/32/testReport/
[22:13] <vila> 2.3.4-0ubuntu1 installed in a natty chroot
[23:16] <poolie> hi vila, jelmer
[23:19] <jelmer> hi poolie
[23:26] <poolie> spiv: alive?
[23:26] <spiv> poolie: yes, and apparently over a degree cooler than yesterday.
[23:27] <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:28] <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:29] <jelmer> spiv: I added some feedback to bug 718944, sorry for not noticing it earlier
[23:30] <spiv> jelmer: ooh, thanks for the links to the other bugs!
[23:31] <spiv> I guess I'll merge that today then, the feedback on the list was (cautiously) positive too.
[23:33] <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:38] <poolie> sleep tight


  Maybe longer.
[07:08] <fabbione> i didn't decide to upgrade
[07:08] <fabbione> my ISP did lower the prices
[07:09] <fabbione> and they did send me a notification that they will increase my bw for the same price
[07:09] <fabbione> from 2M/512 to the above
[07:09] <fabbione> i can decide to lower the price and keep the bw :)
[07:09] <fabbione> but more bw > *
[08:30] <infinity> I assume you just carry partial mirrors?
[12:55] <Riddell> doko: did you see that wv2 needs recompiled for gcc 4?
[12:55] <daniels> christ, 6mb
[12:56] <daniels> infinity: armadale doesn't have the iinet dsl2 infrastructure?
[01:10] <elmo> infinity/lamont?
[01:10] <elmo> sorry, my bad.
[01:10] <elmo> laminity: ?
[01:11] <elmo> daniels: I got suckered into upgrading a breezy chroot and have a fucked X (libx11-6 vs xlibs-data, file overwrites and conflicts)
[01:12] <elmo> daniels: is there a safe way to get out of this, or shall I just brute --force my way out?
[01:12] <Mithrandir> elmo: --force-depend-ing in the libx11-6, then just running apt-get -f install works, iirc.
[01:15] <elmo> Mithrandir: good call, that seems happy.  thx
[01:17] <daniels> elmo: yeah, need to fix that, thanks
[01:48] <infinity> elmo : You rang?
[01:48] <infinity> daniels : No, our exchange (Malvern) is scheduled to get iinet DSLAMs in Q3 this year.
[01:49] <daniels> nice
[01:50] <infinity> elmo : Also, when do my two dead buildds get CPR? :/
[01:51] <elmo> infinity: tomorrow, I hope
[01:51] <elmo> infinity: hoary-backports is ready
[01:51] <elmo> on the katie side - are buildds ready?
[01:52] <daniels> you're shitting me
[01:52] <infinity> They will be first thing in the (my) morning, tomorrow.
[01:52] <daniels> backports.
[01:54] <infinity> daniels : Bring it up tomorrow, if you want to hear a drunken rant on the subject.
[01:55] <daniels> sounds like a plan
[01:55] <daniels> it sounds like arseloads of crack though
[01:55] <daniels> (and I do mean literal arseloads -- snorting it off a hooker's arse, in this case)
[01:55] <infinity> elmo : Does it allow source-only uploads from the main keyring, or only automated source "copies"?
[01:55] <elmo> nothing yet
[01:55] <elmo> well, everything atm
[01:56] <elmo> I'm not sure how best to tie it down and/or import source atm
[01:56] <infinity> Right. :)
[01:56] <infinity> Yeah, me neither.
[01:56] <infinity> The whole thing is kinda making me want to cry.  I don't think anyone's really thoguht this through.
[01:57] <infinity> ie: Without compartmentalising this in small "package groups" (ie: backport foo, bar, and baz, which al interdepend, but nothing else, lather, rinse, repeat), are we not going to end up with all backports being built against each other to the point where hoary-backports looks a lot like "breezy on hoary's glibc"?
[01:57] <infinity> I'm frightened. :)
[01:59] <infinity> Oh well.  I'll whine later.  I'll make the buildds go in ~12 hours, and we can shove some source packages through to make sure it's happy or something.
[02:01] <fabbione> infinity: ahhaah
[02:01] <fabbione> "breezy on hoary's glibc"?
[02:02] <fabbione> infinity: what does make you feel so sure that new glibc won't land in backports?
[02:02] <infinity> Because we'll blacklist it?
[02:02] <jbailey> fabbione: If it does, I quit. =)
[02:02] <infinity> I'd prefer to blascklist all of main, but I don't think that'll fly. :/
[02:02] <fabbione> but new glibc are sooooo 31337
[02:03] <fabbione> cya infinity
[02:03] <fabbione> i am going to stop soon too
[02:04] <fabbione> for once i want to try the experience to stop within the contract working hours
[02:16] <chmj> jbailey,
[02:16] <jbailey> Heya Charles
[02:16] <chmj> jbailey, ping
[02:16] <chmj> hello
[03:21] <lamont> elmo: buildd's are just waiting to be told to add it to the dist list
[03:21] <lamont> unless infinity already did that
[03:23] <lamont> hrm... crested doesn't seem to be happy
[03:24] <fabbione> hey lamont
[03:25] <fabbione> isn't crested one of the 2 dead amd64 buildd?
[03:25] <fabbione> together with king
[03:25] <jbailey> lamont: Heya, lagging on the gcc-opt stuff I owe you, I'll try soon.
[03:29] <lamont> yeah
[03:42] <doko> jbailey: I was looking into multiarch support, and discovered, that we always include i486-linux, even if we are compiling with -m64. Mithrandir did tell me you do know about it. So currently we cannot add multiarch support until it's fixed.
[03:43] <jbailey> doko: ISTR that I also suggested how to fix it...  I can cook up a patch and pass it around for review.
[03:45] <doko> jbailey: did I miss something? I cannot find a report or an email
[03:46] <jbailey> No, when I told Tollef.
[03:47] <doko> ahh, ok
[04:31] <doko> infinity: ping