[00:24] <igc> morning
[01:05] <poolie> hello igc
[01:08] <poolie> spiv, (garyvdm): so what was the outcome re that patch and 1.12?
[01:09] <igc> hi poolie
[01:12] <lifeless> igc: hi
[01:12] <lifeless> igc: is it ok with you if I rename 1.12-preview to development4, or whatever the current sequence number is up to ?
[01:12] <lifeless> igc: (its why we use a different namespace, the problem of predicting when-ready)
[01:13] <igc> lifeless: the format's ready. It's just not reviewed :-) :-)
[01:14] <igc> lifeless: seriously ...
[01:14] <igc> my concern with developmentN in this case is that ...
[01:15] <igc> it's not related to any of the other development formats in any meaningful way ...
[01:15] <lifeless> igc: why is that a concern?
[01:15] <igc> i.e. it's not built on N-1, not is it an experiement towards N+1
[01:15] <igc> potential confusion
[01:16] <igc> lifeless: I'm happy to rename it btw ...
[01:16] <igc> just not sure developmentN is the best choice but it's no big deal
[01:16] <lifeless> can you read the rationale in doc/developers/development-repo.txt
[01:16] <igc> I did
[01:16] <lifeless> its a little repo centric, but I did envisage branch and tree doing the same thing
[01:17] <igc> at the time, new development formats were coming thick and fast in brisbane-core
[01:17] <lifeless> 1.12-preview is just as confusing as devN IMO - see the question from Karl
[01:17] <lifeless> 1.12-preview as named appears more solid than dev4, when its really a separate dimension, as we both know
[01:18] <lifeless> I'd personally prefer devN because we have docs about that, and a defined way for people to find out what it does differently
[01:18] <lifeless> lower learning curve
[01:19] <igc> fair enough. I don't want to waste our time arguing about this btw ...
[01:19] <lifeless> alternatively, if you want a different approach, perhaps use a namespace that maps to tree ;P
[01:19] <lifeless> igc: me neither, was just trying to be clear
[01:19] <lifeless> igc: thank you
[01:19] <igc> "maps to tree"?
[01:19] <lifeless> well, development-wt1
[01:19] <lifeless> or something
[01:20] <igc> ok, that's better by me
[01:20] <lifeless> cool, its fine by me.
[01:20] <igc> lifeless: would development-wt5 be ok you think?
[01:21] <lifeless> igc: yeah, thats fine IMO.
[01:21] <igc> lifeless: I'll put a patch up.
[01:21] <lifeless> igc: it does lead to 'how do we do a new tree+branch+repo' as a question, but we can cross that another time, or just collapse back to developmentN
[01:21] <igc> lifeless: just reviewing your unshelve patch now btw
[01:22] <lifeless> igc: thanks
[01:22] <igc> lifeless: did you get any feedback from abentley on it so far?
[01:23] <lifeless> none that I can see
[01:27] <Phill> Hey, I used the bzr remove command on something I shouldn't have removed, how can I find the file and bring it back from the death?
[01:28] <Odd_Bloke> Good evening.
[01:30] <igc> hi Odd_bloke. Nice to see the patches flowing from you again!
[01:30] <Phill> Up, nevermind, I figured it out.
[01:30] <igc> Odd_Bloke: ^^
[01:30] <Odd_Bloke> igc: It's nice to have found some time to send them. :)
[01:31] <Odd_Bloke> Thanks for the reviews, BTW.
[01:31] <igc> np
[01:31] <jelmer> hey Odd_Bloke
[01:31] <jelmer> Managed to get home safely?
[01:31] <Odd_Bloke> jelmer: Yup.
[01:31] <jelmer> hi Ian
[01:33] <Odd_Bloke> jelmer: How was your journey?
[01:33] <jelmer> Odd_Bloke, pretty good
[01:33] <jelmer> Odd_Bloke, there was some power blackout
[01:33] <jelmer> which meant that the train was redirected *through* my home town, saving me some transfers
[01:34] <jelmer> (and causing them for most of the others)
[01:34] <Odd_Bloke> Heh, nice.
[01:34] <Odd_Bloke> Well, not so nice for them. :p
[01:35] <igc> hi Jelmer
[01:35] <garyvdm> poolie,spiv: I've hacked a quick fix for qbzr re:TooManyConcurrentRequests bug.
[01:36] <poolie> in to bzr or into qbzr?
[01:37] <garyvdm> poolie: into qbzr
[01:37] <poolie> ok
[01:37] <poolie> so we're ok to merge that if we want?
[01:37] <garyvdm> Sure
[01:37] <garyvdm> Yes
[01:43] <Odd_Bloke> The test suite seems much slower than it used to be.
[01:44] <lifeless> thanks igc
[01:51] <KhaZ> Ooh.  Just encountered that TooManyConcurrentRequests error.  Is there a good end-user work around for it?
[01:51] <KhaZ> (Win32, bzr 1.11)
[01:54] <garyvdm> KhaZ: is it in qbzr?
[01:54] <lifeless> KhaZ: using the gui?
[02:00] <garyvdm> Khaz: if you are using bzr 1.11 -  then it can't be the same bug I was talking about just now. Please could you file a bug report.
[02:19] <Odd_Bloke> garyvdm: Thanks for the pointer to the upload stuff, I'll look at that when I'm next looking at stuff.
[02:19] <Odd_Bloke> garyvdm: On a sidenote, are you aware that your Reply-To is set to<EMAIL_ADDRESS>[02:20] <garyvdm> Odd_Bloke: Pleasure
[02:20] <garyvdm> Yes
[02:20] <Odd_Bloke> Cool.
[02:20] <Odd_Bloke> I think I shall call it a night.
[02:20] <garyvdm> gmail does not allow you to change you reply-to for 1 msg :-(
[02:20] <garyvdm> Forgot to change it back
[02:22] <KhaZ> OK.  I'm using bzr from the command line on windows
[02:23] <KhaZ> If anyone wants to have a look: http://pastebin.com/m66706082
[02:23] <KhaZ> I'll put it into the tracker however.
[02:25] <lifeless> KhaZ: from the CLI it probably indicates a permissions issue or something similar
[02:26] <lifeless> KhaZ: it *may* be a bug
[02:30] <KhaZ> Hrmm.  I suppose that's a possibility.    THe backtrace in the client is barfing on '_send_request'... I'm guessing the server hasn't even been involved yet.
[02:33] <KhaZ> What is a 'SMartSSHClientMedium' anyhow?
[02:34] <lifeless> one step up from serialisation, its a broker for requests to the server
[02:35] <garyvdm> Night all
[02:38] <fullermd> About halfway between SmartSSHClientRare and SmartSSHClientWelldone.
[02:39]  * KhaZ drums a rimshot
[02:39] <KhaZ> Ah, you know what, I bet you're right and this is a permissions issue.  I just rebuilt my MSYS on windows, and I bet it's trying to log me in with the wrong case....
[02:39] <KhaZ> Hrmmm.. Now where do I set my ssh username in bzr...
[02:41] <KhaZ> Oh holy hell.  The whole concept of --local just made sense to me.
[02:41] <KhaZ> So if I bzr branch off some other server to my local copy, I'm essentially commiting against that 'other server's copy of code, yeah?
[02:41] <fullermd> Not if you branch, no.
[02:41] <lifeless> if you checkout
[02:41] <KhaZ> ANd --local emulates as if I've got a local repository on my HD, until such time as I commit normally?
[02:41] <fullermd> --local is for shooting yourself in the foot if you checkout.
[02:41] <KhaZ> Hahah
[02:42] <lifeless> KhaZ: --local is for treating a checkout like a branch for a short period of time
[02:42] <KhaZ> Hrmm..  So checkout is more akin to svn co, I guess.
[02:42] <KhaZ> Right.
[02:42] <lifeless> KhaZ: checkout is intended to be identical to svn co/cvs co/etc
[02:42] <KhaZ> Can I see whether I have a branch or a checkout somehow?
[02:42] <lifeless> bzr info
[02:43] <KhaZ> Faaaaancy.
[02:43] <KhaZ> Hrmm, so apparently I am bound with the right username.  Bizarre.
[02:46] <lifeless> KhaZ: two things
[02:47] <lifeless> KhaZ: firstly you don't need '.' in your commit line
[02:47] <lifeless> its the default ;)
[02:47] <lifeless> secondly, the 'bash: bzr: command not found' says to me bzr can't find bzr on the server
[02:50] <KhaZ> Hrmm.  Good catch.  Definitely tr...
[02:50] <KhaZ> Oh damn
[02:50] <KhaZ> I switched the server over from using gentoo's version of bzr to the copy I have with a patch.
[02:50] <KhaZ> I bet that's got something to do with it.
[02:51] <KhaZ> THank God, too.   :P
[02:53] <KhaZ> Haha.
[02:54] <fullermd> Well, it's early morning, and I'm desperately trying not to have to get into the work I need to do...
[02:54] <KhaZ> fullermd: You in Australia/NZ?
[02:54] <fullermd> Oh, no.  US.
[02:54] <fullermd> I'm just surrounded by people who keep weird hours   :p
[02:55] <fullermd> (~300 million of them to be precise.  My life would be so much easier if they'd just stay in sync with me...)
[02:55] <KhaZ> fullermd: Try ReasonablyIntelligentRSync and work up. ;)
[02:55] <KhaZ> HeeHee, it is fun!.
[03:03] <KhaZ> Hrmm.  Does bzr do it's actions in some sort of different usermode than if I were to ssh in manually?  It must, I just can't figure how to emulate it.
[03:04] <lifeless> KhaZ: no, 'ssh host bzr --serve --allow-writes /' or something like that
[03:04] <lifeless> there is an environment variable to control what it thinks bzr is called - BZR_REMOTE_SSH or something like that
[03:06] <fullermd> BZR_REMOTE_PATH
[03:06] <KhaZ> Right.  Just weird - bzr exists on the command line in the path.  I'm guessing that it's in /usr/local/bin that's the problem.  Just not sure where/who I have to say "Hey!  Look in /usr/local/bin, douche!" to.
[03:06] <KhaZ> Right, but that's a per repository or per client setting, yeah?
[03:06] <KhaZ> I'm thinking it's better if I just fix my server.. This *was* working.
[03:06] <lifeless> yes :P
[03:08] <KhaZ> ... now if only I could find out where. ;)
[03:19] <lifeless> late fooding
[03:45]  * igc lunch
[03:50] <poolie> lifeless: ping?
[03:50] <poolie> lifeless: i'm thinking about whether to push for an SRU for a whole bzr release
[03:50] <poolie> or just to get it into backports
[04:21] <lifeless> poolie: well, backports is a good start
[04:21] <lifeless> but an SRU isn't done trivially
[06:31] <Demosthenes> i've done some searches with little luck. what is the status of nesting repositories?
[07:15] <vila> hi all
[08:14] <mwhudson> in a test suite, i want a revision object
[08:15] <mwhudson> oh hm
[08:57] <davidstrauss> Is it possible to clean up unused revisions stored in a shared repository?
[08:58] <Lo-lan-do> davidstrauss: Not yet, but LarstiQ and I (but mostly LarstiQ :-) started a gc plugin two days ago at FOSDEM.
[08:59] <davidstrauss> nice
[08:59] <davidstrauss> Lo-lan-do: gc plugin?
[08:59] <Lo-lan-do> I'm about to migrate to a proper workplace in a few minutes, but I'll be online again later.
[08:59] <Lo-lan-do> garbage collector
[08:59] <Youssef> hi guys!
[08:59] <davidstrauss> ah
[08:59] <Youssef> how are u?
[09:00] <davidstrauss> Happy that the Drupal Paris sprint is underway
[09:01] <lifeless> davidstrauss: excellent
[09:02] <lifeless> davidstrauss: hey, we haven't reproduced that windows users bug yet
[09:02] <davidstrauss> lifeless: Let me email him for his directory
[09:02] <lifeless> davidstrauss: but a different issue I've found which caused the 'corruption' is something I will be fixing, which at least would mean things get pushed correctly
[09:02] <lifeless> davidstrauss: I think you gave us a copy already?
[09:02] <davidstrauss> lifeless: Not *his* checkout
[09:02] <davidstrauss> lifeless: I'd be happy implementing something that would have caught this pre-commit.
[09:03] <davidstrauss> lifeless: If there's an immediate error, it will be much easier to catch in the future
[09:18] <dholbach> hi guys
[09:18] <dholbach> jelmer: where does Debian get python-subvertpy from?
[09:18] <dholbach> jelmer: just checking out the bzr* sync requests
[09:19] <dholbach> bug 325930 is the one I was stumbling over
[09:21] <lifeless> davidstrauss: indeed, but we need a good theory of what happened to do that :P
[09:21] <davidstrauss> lifeless: We know it failed bzr check after that revision got added.
[09:22] <davidstrauss> lifeless: So it's detectable, albeit inefficiently.
[09:36] <jelmer> dholbach, hi
[09:36] <jelmer> dholbach, subvertpy is in NEW
[09:36] <dholbach> jelmer: hrm :-/
[09:36] <dholbach> makes it somewhat hard to sync :-/
[09:37] <jelmer> dholbach, I can upload to REVU if that makes things easier for Ubuntu
[09:38] <dholbach> jelmer: or just put it up somewhere and link to it in the bug report - I'll review and ask the archive admins what needs to be done
[09:38] <dholbach> (the source package)
[09:38] <dholbach> luckily the bzr-svn is in universe so we don't need to write a main inclusion report for subvertpy :)
[09:39] <jelmer> dholbach: :-)
[09:39] <dholbach> jelmer: thanks for helping out there!
[09:39] <jelmer> dholbach, I'll upload a source package this afternoon, gotta run now
[09:40] <dholbach> rock and roll
[09:40] <dholbach> have a great day
[10:53] <Youssef> hi guys
[10:53] <Youssef> I have a problem
[10:54] <Youssef> im working with vista
[10:54]  * Lo-lan-do sympathizes
[10:54] <Youssef> looool
[10:54] <Youssef> yes but
[10:54] <Youssef> okay
[10:55] <Youssef> I explain
[10:55] <Youssef> im creating a folder it looks like this check
[10:57] <Youssef> I would like to create a folder with my project
[10:57] <Youssef> but i want it to work in a server
[10:57] <Youssef> im working with my computer
[10:57] <Youssef> alo?
[10:57] <Youssef> i there someone?
[10:58]  * Lo-lan-do doesn't understand the problem
[10:58] <Youssef> lol
[10:58] <Youssef> okay
[10:59] <Youssef> i repeat more clearlly
[10:59] <Youssef> mmhhh
[10:59] <Youssef> just a second
[10:59] <Youssef> localy I create a server
[10:59] <Youssef> with a shared foler
[10:59] <Youssef> check
[11:00] <Lo-lan-do> What's a server?
[11:02] <Youssef> C:\>mkdir MyOfficialProject
[11:02] <Youssef> C:\>cd MyOfficialProject
[11:02] <Youssef> C:\MyOfficialProject>bzr init
[11:02] <Youssef> Standalone tree (format: pack-0.92)
[11:02] <Youssef> Location:
[11:02] <Youssef>   branch root: .
[11:02] <Youssef> C:\MyOfficialProject>bzr add
[11:02] <Youssef> Added files
[11:02] <Youssef> C:\MyOfficialProject>bzr commit -m "Initial Commit"
[11:02] <Youssef> Committing to: C:/MyOfficialProject/
[11:02] <Youssef> Added files.
[11:02] <Youssef> Committed revision 1.
[11:02] <Youssef> C:\MyOfficialProject>bzr serve
[11:03] <Youssef> listening on port:  4155 ...
[11:03] <Lo-lan-do> Please use pastebin for pasting stuff!
[11:03] <Youssef> this is what a do for a dedicated server
[11:03] <Youssef> Oops sorry
[11:03] <Youssef> really sorry
[11:04] <Youssef> I prefer rafb
[11:04] <Youssef> http://rafb.net/p/FHobII85.html
[11:04] <Youssef> check
[11:05] <Youssef> Logically my folder is a shared folder
[11:05] <Youssef> no?
[11:05] <Lo-lan-do> I don't know.  What do you mean by shared folder?
[11:05] <Lo-lan-do> (I'm clueless with Windows, you'll have to forgive me)
[11:06] <Youssef> hmm :)
[11:06] <Youssef> I imagine
[11:06] <Youssef> okay
[11:07] <Youssef> listen i just want to create a project in a distant server from where ill be able to simply checkout it to my laptop
[11:07] <Youssef> how a can do that please?
[11:07] <Lo-lan-do> Can't you connect to your server?
[11:08] <Youssef> no no i can connect but when I chek it out he is the server log
[11:08] <Youssef> http://rafb.net/p/M991cN26.html
[11:10] <Youssef> what is it?
[11:13] <Lo-lan-do> Not sure.  Firewall?
[11:13] <Lo-lan-do> How did you try to access the server?
[11:18] <LarstiQ> Lo-lan-do: thanks, I branched bzr-gc
[11:18] <Lo-lan-do> LarstiQ: You probably saved yourself, oh, I don't know, at least five minutes of work :-)
[11:18] <Youssef> in localhost
[11:19]  * LarstiQ grins at Lo-lan-do
[11:19]  * Youssef hope in Lo-lan-do
[11:19] <Lo-lan-do> LarstiQ: Thanks by the way, bzrlib is no longer a scary monster to me.  It's just a large unknown beast now.
[11:19] <Lo-lan-do> Youssef: Command line?
[11:19] <Youssef> ???
[11:20] <Youssef> what?
[11:20] <LarstiQ> Lo-lan-do: the motivational aspect is the important bit, I'm going on a ~24 hour trip now, so I'm hoping to hack more on it if the power is with me.
[11:20] <Lo-lan-do> What was the command like you used?
[11:20] <LarstiQ> Lo-lan-do: that's good to hear
[11:20] <Youssef> okay check
[11:21] <Youssef> WHAT?
[11:21] <Youssef> Lo-lan-do:
[11:21] <Youssef> when i do => C:\LocalCopy>bzr branch bzr://localhost/
[11:21] <Youssef> Branched 1 revision(s).
[11:21] <Youssef> and it copy the folder where i am
[11:22] <Youssef> is it correct?
[11:22] <Lo-lan-do> Looks like so.
[11:26] <Youssef> when
[11:26] <Youssef> C:\LocalCopy>bzr checkout bzr//localhost
[11:26] <Youssef> bzr: ERROR: Not a branch: "C:/LocalCopy/bzr/localhost/".
[11:27] <Lo-lan-do> Missing :
[11:29] <Youssef> Lo-lan-do! juste come back to : http://rafb.net/p/FHobII85.html
[11:29] <Youssef> is it correctly done?
[11:30] <Youssef> with my computer it seems to be correct
[11:30] <Lo-lan-do> It looks like it is, and since you managed to branch from it I don't see what the problem is.
[11:30] <Youssef> hhmm okay
[11:30] <Youssef> stay there im comming
[11:31] <Youssef> forgot the branch
[11:32] <Youssef> okay
[11:32] <Youssef> now
[11:32] <Youssef> when my server works
[11:32] <Youssef> as client what do i have to do to get a copy of the project
[11:34] <Youssef> bzr checkout bzr://localhost/MyOfficialProject ?
[11:35] <Youssef> C:\LocalCopy>bzr checkout bzr://localhost/MyOfficialProject
[11:35] <Youssef> bzr: ERROR: Not a branch: "bzr://localhost/MyOfficialProject/".
[11:35] <Lo-lan-do> You did it already: bzr branch bzr://localhost/
[11:36] <Youssef> yeah but do I have to do it first i chekcout?
[11:36] <Lo-lan-do> ?
[11:37] <Youssef> lol okay in english now
[11:37] <Youssef> do I have to do a branch before a checkout?
[11:37] <Lo-lan-do> Depends on what you want to do.  Do you want a branch or a checkout ?
[11:37] <Youssef> first a checkout
[11:38] <Lo-lan-do> Then just do a checkout.
[11:38] <Youssef> in a simple directory ? or a have to do sometings before a ckekout
[11:39] <Lo-lan-do> Just do a checkout :-)
[11:39] <Lo-lan-do> You're not using git, things are supposed to just work here.
[11:40] <Youssef> loooool the checkout successed ppfff
[11:40] <Youssef> okay stil stay with me
[11:41] <Youssef> I have done a "C:\LocalCopy>bzr checkout bzr://localhost/"
[11:47]  * Lo-lan-do → food
[14:15] <matkor> Hi ! I did bzr push bzr+ssh://<remote>/<dir>         Now how can I see WT in <dir> ?
[14:15] <beuno> matkor, no, push to remote locations doesn't produce WT
[14:15] <matkor> bzr update   gives:   bzr: ERROR: No WorkingTree exists for <dir>
[14:16] <matkor> bueno: So how can I get WT in <dir> ?
[14:16] <beuno> matkor, via a plugin
[14:16] <awilkins> ssh me@remote ; cd <dir> ; bzr up
[14:16] <beuno> you have either push-and update
[14:17] <beuno> or, bzr-upload, which *just* uploads the WT
[14:18] <matkor> awilkins: I get bzr: ERROR: No WorkingTree exists for "file:///<dir>/.bzr/checkout/"
[14:18] <jdong> he meant bzr co
[14:18] <jdong> you run bzr co the first time, bzr up subsequent times :)
[14:19] <jdong> (check out a working tree, update existing working tree)
[14:20] <matkor> Ah ! Right. Thank you very much jdong, awilkins
[14:20] <matkor> and bueno
[14:32] <Toksyuryel> I just thought of something. for a "clone" checkout (i.e. where the user is downloading the tree for the very first time and does not currently have a working copy) is it really necessary to send each file one-by-one? would it be better to compress and archive them first and just send that?
[14:33] <Lo-lan-do> I think what goes over the network is actually the repository, and the files are checked out of the new copy.
[14:34] <phinze> hey so how does bzr play with symlinks in a repository?  i'd like to have a "latest" symlink in my "releases" subdir that points to the last release branch
[14:34] <phinze> will that confuse bzr?
[14:34] <Lo-lan-do> phinze: It my experience it seems to work.
[14:34] <Lo-lan-do> But that may confuse users, since the contents of a stable URL may change.
[14:35] <phinze> Lo-lan-do: it's for internal use in a department where we have a weekly release cycle
[14:35] <Lo-lan-do> I'm jus' sayin' :-)
[14:35] <phinze> right, this is true
[14:36] <Lo-lan-do> It's basically the same as rebasing a public branch.  If your users expect it, no problem.
[14:36] <phinze> also, thanks :)
[14:36] <phinze> sounds good
[14:41] <phinze> so now if i have a local branch of "latest", and the symlink has been moved to a new release, i can "bzr pull"? or must i remove and rebranch?
[14:42] <Lo-lan-do> You can pull if the new one is a direct descendant of the previous "latest".
[14:42] <phinze> hmm... new one will be branched off a later revision of trunk
[14:42] <Lo-lan-do> If histories have diverged, you'll need to either merge or pull --overwrite.
[14:42] <phinze> not sure if that constitutes "direct descendent"
[14:43] <fullermd> pull --overwrite will probably be faster and easier than removing and rebranching...
[14:43] <phinze> probably pull --overwrite will be what i want, as it will just be used as a mirror for diffing
[14:43] <fullermd> Roughly speaking, if the "release branch" is an older version of trunk, the history isn't diverged.
[14:44] <fullermd> It diverges if a commit is made on the release branch that wasn't pulled from trunk.
[14:44] <fullermd> So it really depends on what "release branch" means.
[14:44] <phinze> ahh okay
[14:45] <phinze> yeah we're still developing our software release procedure w/ bazaar, but we're thinking in the case of an emergency we'll have a commit directly to the release branch that we merge back into trunk
[14:45] <phinze> so in that case we may have diverged
[14:45] <fullermd> If it's merged back into trunk, then trunk becomes a superset of the release branch, so pull can work.
[14:45] <phinze> ah wow
[14:45] <phinze> nice
[14:46] <fullermd> It's all revision based.  If trunk contains the head revision of the release branch, it's a proper superset, and if it's a proper superset, you can pull.
[14:46] <phinze> cool
[14:46] <phinze> man i'm still only scratching the surface of this domain of knowledge :)
[14:47] <fullermd> An alternative would be to use tags for the releases, and a sliding tag for the latest.  If it's very rare that you commit onto a release branch, that may be simpler.
[14:47] <fullermd> (or it may not, considering tag propogation issues)
[14:48] <phinze> yeah we looked into that, but we were hesitant because of a bug we encountered having to do with tags not being pulled until a revision is bumped in some other way
[14:48] <phinze> perhaps that is referring to the "tag propogation issues" you mention
[14:49] <fullermd> Mmm.  I'm pretty sure they always pull.  Maybe they don't propogate with merge unless there are revs to merge.
[14:49] <fullermd> I was thinking more of the lack of versioning causing headaches when they change.
[14:49] <phinze> ah yeah that's another issue
[14:50] <fullermd> (wihch doesn't matter for the release tags, but sure as heck does for a slider)
[14:51]  * fullermd waves at bialix.
[14:51] <phinze> right right
[14:51]  * bialix waves at my here
[14:51] <bialix> err
[14:51] <bialix> pfff
[14:51] <bialix> sorry
[14:51] <bialix> hi fullermd
[14:51] <bialix> I wish to have nested trees year ago
[14:54] <bialix> LarstiQ: new layout almost finished
[14:54] <bialix> LarstiQ: i.e. Ive started using it. I think nested trees should be killer feature. Sad they are not here
[14:56] <bialix> ubotu
[14:56] <bialix> ubottu
[15:00] <bialix> sorry for noise
[15:03] <Odd_Bloke> jelmer: Thanks for the reviews. :)  I'll look at the tweak this evening.
[15:12] <kirkland> is it possible to edit an existing commit message, for a previous revision?
[15:14] <beuno> kirkland, no
[15:14] <beuno> but you can uncommit
[15:15] <beuno> and commit again with a new message
[15:15] <kirkland> ah
[15:15] <kirkland> beuno: beuno
[15:16] <beuno> recursive me!
[15:16] <kirkland> :-)
[15:26] <awilkins> kirkland: Problem with uncommit is if other people have branches based on the revision(s) you've uncommitted
[15:33] <kirkland> awilkins: thanks, gotcha.  i think this is just a one time deal
[15:58] <vila> abentley: ping
[15:59] <abentley> vila: pong
[15:59] <vila> is read_bundle_from_url still useful or can it be deprecated ?
[15:59] <vila> abentley: the reason I ask is that it causes problems in tests
[16:00] <abentley> vila: lemme see...
[16:00] <vila> because it's an url based API, it fools the test framework when special purposes transports must be used
[16:01] <vila> the root cause is the get_transport call in read_mergeable_from_url (i.e. we have read_bundle_from_url -> read_mergeable_from_url -> read_mergeable_from_transport)
[16:04] <abentley> vila: So read_bundle_from_url is a problem but read_mergeable_from_url is not?
[16:04] <vila> it's a problem too but I found a work around for it in the tests ;-)
[16:05] <vila> because it accepts a possible_transports parameter !
[16:05] <abentley> vila: That does not sound good, but I'm okay with deprecating read_bundle_from_url.
[16:05] <vila> I can add a possible_transports parameter to read_bundle_from_url too, but I thought that if some cleanup was possible it was better to do so
[16:06] <vila> I agree, that's not the proper fix, the problem is that there are tests that are buggy today
[16:06] <vila> i.e. they declare to test a transport while in fact they use another
[16:06] <abentley> vila: You may also be able to eliminate the _do_directive parameter.
[16:07] <vila> nobody can detect that yet, I ran into it while using a special https transport
[16:07] <vila> eliminate the _do_directive parameter ?
[16:08] <abentley> vila: I believe it's only false when called by read_bundle_from_url.
[16:09] <vila> aah, you mean once read_bundle_from_url is deprecated ?
[16:09] <abentley> I did, but actually, that must wait until it's removed.
[16:09] <vila> ok
[16:09] <vila> thanks, I'll do that (deprecate) then
[16:45] <theAdib_> does bzr handles svn branches via https? i.e. bzr branch https://server/pathtorepos
[16:47] <jelmer> theAdib_, yes
[17:02] <theAdib_> jelmer, so how can I enter username and password for that connection? I get: Unable to handle http code 401: Authorization Required
[17:07] <jelmer> theAdib_: make sure you have a new bzr-svn (0.5.0) and specify the username in the URL
[17:15] <theAdib_> I am on win32 using latest bzr 1.11,
[17:16] <theAdib_> and that worked thx, jelmer ! :-)
[17:32] <KhaZ> There's no way to do partial checkouts of a tree in bzr, correct?
[17:34] <santagada> KhaZ: partial checkouts of a branch is not supported ATM
[17:36] <jelmer> KhaZ, there's a partial implementation waiting to (hopefully) go into 1.12
[17:37] <phinze> a partial implementation of partial checkouts? ;D
[17:37] <jelmer> :-P
[17:46] <KhaZ> exxxxciting.
[17:46] <KhaZ> How partial, exactly?
[17:46] <santagada> jelmer: will it need changes on the repo format or is it only a client thing?
[17:46] <santagada> or is it client/server thing but not repo format dependant?
[17:47] <jelmer> it needs a new repository format (which will not be stable as of 1.12)
[17:47] <jelmer> it's partial in that it is specific to the working tree
[17:47] <jelmer> you'll still need the full branch history
[17:57] <KhaZ> jelmer: Is 'full branch history' just everything under .bzr ni a repo?
[17:58] <jelmer> KhaZ, yeah, basically
[17:58] <KhaZ> OK, I supopse that's not so bad.  A bit bizrre to think that one directory will sync almost 900 MB, but not as bad as the 2 GB in the full repo!
[18:35] <phinze> what's a good way to get patch-level confirmation of a merge?
[18:35] <phinze> "yes this, not that, not that, yes this" etc
[18:38] <nDuff> phinze, ...patch-level, not hunk level? AIUI, it's most common to do cherry-picking (what that workflow is called) on the commandline setting up the merge, not afterwards but prior to committing.
[18:38] <phinze> nDuff: sorry i meant hunk level
[18:39] <asabil> phinze: check the bzr-interactive plugin
[18:39] <nDuff> phinze, (actually, doing it patch-level *is* supported, too: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#reverse-cherrypicking)
[18:39] <asabil> well the bzr-interactive only gives you interactive commits for now
[18:39] <nDuff> phinze, ...but hunk level, I most often cheat and rely on shelve.
[18:40] <phinze> nDuff: yeah i was wondering if it could be used in that way
[18:40] <phinze> how does that work for you?  (i.e. what commands are you running roughly in what order?)
[18:40] <phinze> asabil: that looks promising, but atm i'm interested in interactive merge
[18:41] <asabil> phinze: adding interactive merges shouldn't be difficult
[18:41] <asabil> you can try to extend it, that would be pretty neat
[18:42] <phinze> asabil: cool, perhaps i'll look into it
[18:43] <phinze> nDuff: nm i can imagine it pretty well... bzr merge, then bzr shelve, and shelve things you dont want to commit
[18:49] <jdobrien> is there any clearer guidance available about the --no-trees option for init-repo?
[18:55] <jdobrien> thanks rockstar ^^^ nice post http://theironlion.net/blog/2009/01/23/more-advanced-bazaar-concepts/
[18:56] <rockstar> jdobrien, thanks!
[18:56] <rockstar> jdobrien, did that answer your questions, or do you still need help?
[18:57] <jdobrien> i think so.
[18:59] <jdobrien> rockstar: can I push my (feature) branches to launchpad from the lightweight checkout?
[18:59] <rockstar> jdobrien, yeah.  I almost never have to go into the ~/Projects/repos folder at all.
[18:59] <jdobrien> rockstar: sweet, that's what I'm looking for
[19:01] <garyvdm> jdobrien: you can run bzr push -d :bound
[19:02] <garyvdm> Then it will use the saved push location of the bound branch.
[19:02] <jdobrien> thanks garyvdm, i'll have to look that up.
[19:03] <jdobrien> i wonder how long it will take to master bzr .. probably never will
[19:06] <jdong> garyvdm: what other :names are available?
[19:06]  * jdong didn't know bzr supported those
[19:06] <garyvdm> :push, :pull
[19:07] <nDuff> Are the bzr and bzrtools releases in the PPA out-of-sync?
[19:07] <garyvdm> There must be a list somewhere, but I don't know where.
[19:07] <garyvdm> nDuff: yes
[19:07] <jdong> garyvdm: are those documented somewhere?
[19:08] <garyvdm> jdong: probably - but I don't remember where.
[19:11] <bialix> garyvdm: well done, thanks
[19:12] <garyvdm> Hi bialix - Everything correct?
[19:12] <Peng_> jelmer: ping?
[19:12] <jelmer> Peng_, pong
[19:12] <bialix> garyvdm: well, one tiny detail: you forgot to update QBzr page at bazaar-vcs.org/QBzr
[19:13] <bialix> but this is easily fixable
[19:13] <garyvdm> bialix: Oh - Do I still need to do it?
[19:13] <bialix> I can do it
[19:13] <bialix> garyvdm: actually I have  a question to you about qlog
[19:13] <garyvdm> Ok
[19:13] <Peng_> jelmer: Oh hi. Errm.
[19:14] <garyvdm> jdong: from the source code:
[19:14] <bialix> is it possible to show not all history, but revision range instead in the qlog?
[19:14] <garyvdm> :parent, :submit, :public, :push, :this, and :bound are currently supported.
[19:15] <garyvdm> bialix: there is no ui
[19:15] <jdong> garyvdm: good sleuthing; thanks :)
[19:15] <bialix> garyvdm: do you mean command-line interface UI?
[19:15] <garyvdm> and if we add a ui to do it - it would not improve the performance
[19:16] <Peng_> jelmer: I used bzr-svn 0.4 to branch an svn branch, and committed locally a few times, but never pushed back. Now that I'm using 0.5, it wants to use svn-v4 revids, confusing everything. Advice?
[19:16] <garyvdm> bialix: command-line nor gui
[19:16] <bialix> garyvdm: let's say specific example: is it possible to show qlog for pending revisions?
[19:17] <garyvdm> bialix - not yet - but I'm hopeing to do that soon - so I can reuse the new log_list widget in qcommit
[19:17] <bialix> garyvdm: or if I want to implement cherrypicking dialog to show selected revisions for picking?
[19:18] <bialix> I'm thinking exactly about situation with revision range for some spefic use cases
[19:18] <garyvdm> bialix: if you just want to filter, that easy. What tricky is to filter, and not have to load the whole revision graph.
[19:19] <bialix> at least it's the start
[19:21] <bialix> Good evening, dear bzr hackers! Is it possible to collect code coverage info for the tests?
[19:22] <garyvdm> bialix: I've just merged my log refactoring into trunk.
[19:22] <bialix> garyvdm: cool
[19:24] <bialix> garyvdm: one more question about qlog: can we create revision picker dialog based on qlog?
[19:24] <garyvdm> Yes!
[19:24]  * bialix mulling this idea very long time
[19:25] <bialix> it was super-optimistic!
[19:25] <jelmer> Peng_, 0.5 wants to use svn-v4 revids when?
[19:25] <garyvdm> Should be very easy now.
[19:25] <bialix> great! really-really great!
[19:25] <Peng_> jelmer: Whenever. "bzr merge" or whatever.
[19:26] <garyvdm> I want to use the log widget in qcommit, qannotate, and make a revision selector for push, pull, tag, merge etc...
[19:26] <Peng_> jelmer: Since I never committed back to the svn repo with 0.4, it doesn't know any better.
[19:26] <bialix> jam who knows everything: can you suggest something about coverage? mensieur vila? anybody?
[19:26] <bialix> garyvdm: you simply read my mind
[19:27] <jelmer> Peng_, "bzr svn-upgrade" should fix that
[19:27] <bialix> jelmer: hi, can you suggest something about coverage statistics?
[19:28] <vila> bialix: I think selftest has a --coverage option but AFAIK it's broken for plugins
[19:28] <jelmer> Peng_, merge isn't aware of foreign branches (yet)
[19:28] <bialix> vila: I've thoughts so, but I've re-read selftest -h 5 times and I don;t see this option
[19:29] <bialix> broken for plugins: :-[
[19:30] <bialix> it's not my day then
[19:30] <vila> bialix: That's because it's not in the online help, that's for devs, they don't read help :-)
[19:30] <bialix> ah
[19:30] <bialix> yes
[19:30] <vila> seriously, that's a bug, it should be documented
[19:30] <bialix> oh no
[19:30] <vila>     --coverage
[19:30] <vila>         Generate line coverage report in the specified directory.
[19:30] <bialix> it's not bug
[19:31] <vila> that's a global option
[19:31] <bialix> yep, PEBKAC
[19:31] <bialix> I need addtional module I guess
[19:31] <bialix> coverage.py from Ned Batchelder, is it?
[19:32] <beuno> poolie, hi. Are there still known problems with the new progress bars, or should I report the bug that status text concatenates instead of replacing eachother?
[19:32] <bialix> vila: why you said it's broken for plugin?
[19:32] <vila> bialix: I don't think it's a very serious bug, I don't remember the details but I think it has to do with the fact that the plugins aren't in PYTHON_PATH or something
[19:32] <vila> bialix: did you try it ?
[19:32] <bialix> oops
[19:33] <vila> My memory may be wrong, it may have been fixed...
[19:33] <bialix> I'd like to
[19:33] <Peng_> jelmer: "svn-upgrade" sounds a little scary. And wouldn't I need to install the rebase plugin?
[19:33] <jelmer> Peng_, yeah, that depends on the rebase plugin
[19:33] <vila> bialix: bzr --coverage cover selftest -s bp.qbzr
[19:33] <bialix> -s bp.qbzr?
[19:34] <vila> bialix: don't tell me you don't know -s bp.qbzr !!!
[19:34] <vila> Just try: bzr selftest -s bp.qbzr
[19:34] <bialix> me me me
[19:34] <bialix> I don't remember
[19:34] <bialix> I've not followed your bzr toys many months
[19:35] <vila> bp.qbzr expands to bzrlib.plugins.qbzr it will speed up running your plugin tests by orders of magnitude
[19:35] <vila> I'm sorry I didn't publicize that much :-/
[19:35] <Kobaz> mmm
[19:35] <bialix> right
[19:35] <bialix> I recall it now
[19:35] <bialix> it was your patch
[19:35] <bialix> in first half of 2008, yes?
[19:36]  * bialix using full form -s bzrlib.plugins.scmproj
[19:36] <vila> Could be, can't remember that sort of date generally :-)
[19:36] <vila> bialix: haaaa, ok, so the shortcuts are far more recent yes.
[19:36] <bialix> found in the HACKING.txt
[19:36] <bialix> Test coverage
[19:36] <bialix> [19:36] <vila> As are the ability to specify mutiple ones
[19:36] <bialix> All code should be exercised by the test suite.  See `Guide to Testing
[19:36] <bialix> Bazaar <testing.html>`_ for detailed information about writing tests.
[19:36] <bialix> not so many info
[19:37] <vila> bialix: that's right --coverage is underused :-/
[19:37] <bialix> vila: -s bp.xxx -- it's worked! nice!
[19:38] <bialix> I have obscure feeling it was the patch from spiv
[19:38] <vila> --coverage is from spiv yes
[19:38] <bialix> oh no, it soo loong to wait for oz people to wake up
[19:39] <bialix> well, thanks, you gave ne a clue
[19:39] <bialix> will test how it selftest :-)
[19:39] <vila> bialix: are you in the Kiev TZ ?
[19:39] <bialix> aha
[19:40] <bialix> UTC+2
[19:41] <vila> bialix: I see, yes, waiting for NZ will be a bit hard for you :-/
[19:41] <bialix> vila: bzr --coverage FILENAME -- that's right?
[19:41] <bialix> vila: are you not in Europe?
[19:41] <vila> bialix: no --coverage DIRECTORY
[19:42] <vila> bialix: I am in France
[19:42] <bialix> what DIRECTORY?
[19:42] <vila> bialix: one that will contain files whose names are the python modules
[19:43] <bialix> vila: should I think waiting is not so hard to you? ;-)
[19:43] <vila> try it on a sample and look (you may have to create it first, I don't remember) looking at the results things should be obvious
[19:43] <bialix> sample?
[19:43] <vila> bialix: one hour less :)
[19:43]  * bialix downloading coverage.py
[19:44] <vila> huh ?
[19:44] <bialix> you think I should not?
[19:44] <vila> I don't remember needing an additional package... I may be wrong, checking
[19:44] <bialix> vila: I'd like to not start using python-based bzr if I can
[19:45] <bialix> bzr.exe is much pleasure
[19:45] <vila> haaa. sry
[19:46] <bialix> I knew only one actively maintained coverage lib: http://nedbatchelder.com/code/modules/coverage.html
[19:46] <bialix> I suppose spiv used it
[19:47] <vila> can you just try ./bzr selftest --coverage cover -s bt.test_read_bundle
[19:47]  * bialix trying
[19:48] <vila> A quick look seems to imply using the standard trace python module
[19:48] <vila> Ok, I just run it, no need to create the cover directory, it's created automatically
[19:49] <bialix> PermissionDenied: blah-blah-blah: I've almost forgot this stuff
[19:49] <vila> rats, tests failing ?
[19:50] <bialix> 51 tests, tests passed
[19:50] <bialix> 16 leaking tests :-P
[19:50] <vila> do you have a cover directory ?
[19:50] <bialix> have the "cover" dir full of files
[19:51]  * bialix m-m-m
[19:51]  * bialix looks
[19:51] <vila> bialix: get it ? '>>>' not executed, 'n' number of executions
[19:52] <bialix> >>> not executed? you kidding
[19:53] <bialix> or the result id weird
[19:53] <bialix> how it can't execute def blah(foo):
[19:54] <bialix> vila: you're right
[19:54] <bialix> vila: about plugins
[19:54] <bialix> it don;t see my plugin
[19:54] <bialix> only launchpad
[19:55] <vila> A workaround can be to install your plugin in a directory XXX/bzrlib.plugins with XXX in PYTHON_PATH
[19:55] <bialix> so... if I'm put it inside bp, perhaps it will collect the info
[19:55] <bialix> ja!
[19:56] <vila> be aware to *not* leave it in .bazaar/plugins though...
[19:56] <vila> Bah, that's gross, we should really fix that
[19:56] <bialix> this makes my job harder
[19:56] <bialix> but actually I keep my plugins in the BZR_PLUGIN_PATH dir
[19:57] <vila> I know, that's the bug :)
[19:57]  * bialix will try suggested hack
[19:58] <bialix> merci beaucoup
[19:58] <vila> :-)
[19:59]  * bialix mutters: "I just need to create special lightweight checkout and blow"
[20:00] <vila> I'm off, report your results, I'll read it tomorrow !
[20:00] <bialix> ok!
[20:02] <imnotparanoid> hello all! I'm a new bzr user, and need some help with my "workflow" (just a quick question). can anyone spare a few minutes?
[20:04] <Peng_> jelmer: svn-upgrade doesn't edit the subversion repo or anything, right?
[20:04] <jelmer> Peng_, no
[20:04] <bialix> shoot your quick question
[20:04] <Peng_> jelmer: Alright.
[20:05] <imnotparanoid> i have a shared repo, a checkout using bzr-svn. i branch and work on them, etc. how can i create a branch on a flash drive, for example, so I can work at home?
[20:06] <imnotparanoid> (i have copied a normal branch.. but, the revisions were in the repo.. so i could not use it at home)
[20:06] <bialix> what's your OS?
[20:06] <imnotparanoid> XP @ work (where i have the repo), linux @ home. bzr 1.11 on both
[20:07] <bialix> ok
[20:07] <ericvw> Where should I post about getting an appropriate version of bzrtools in the PPA?
[20:07] <Peng_> Ergh, wait a minute. I branched off of the bzr branch too. How do I svn-upgrade the child?
[20:07] <Peng_> An idmap-file?
[20:07] <bialix> 1. create treeless repo at flash: bzr init-repo --no-trees E: (or other drive letter of your USB)
[20:07] <jelmer> Peng_, no, the upgraded ids are consistent
[20:08] <bialix> err, actually you need sensible patg
[20:08] <jelmer> Peng_, Just run svn-upgrade there as well
[20:08] <bialix> path
[20:08] <Peng_> jelmer: Oh, nifty.
[20:08] <imnotparanoid> ok.. next step
[20:08] <bialix> then do bzr push from your branch to the repo on flash
[20:08] <imnotparanoid> do i need to use the --create-prefix ?
[20:08] <bialix> you'll get the new branch inside repo on flash with full history
[20:09] <bialix> more specific example, let's say your flash drive letter E: and you create repo/ dir
[20:09] <bialix> bzr init-repo --no-trees E:/repo
[20:09] <bialix> cd your-local-branch
[20:09] <Peng_> Argh, how the heck do I tell svn-upgrade where the original svn branch is?
[20:10] <bialix> bzr push E:/repo/trunk
[20:10] <jelmer> Peng_, it's the first argument
[20:10] <bialix> this will create new branch called trunk
[20:10] <Peng_> jelmer: You mean the one that causes it to say "No repository present"?
[20:10] <jelmer> Peng_, ah, you have to give it a repository URL
[20:11] <jelmer> Peng_,  not a branch URL
[20:11] <imnotparanoid> thank you! I think I can handle it from here!
[20:11] <bialix> because you're using bzr-svn you need to specify format --rich-root-pack (or more recent) for init-repo
[20:11] <Peng_> jelmer: Oh.
[20:11] <imnotparanoid> (it hasn't crossed my mind to create another repo on the flash drive)
[20:11] <Peng_> jelmer: Indeedy, that worked.
[20:11] <Peng_> jelmer: Thank you for the help. :)
[20:11] <jelmer> np
[20:11] <imnotparanoid> (yes, i know about the --rich root-pack from the initial repo)
[20:11] <bialix> you may want to look at repo-push plugin
[20:12] <bialix> and/or multi-pull command (from bzrtools)
[20:13] <imnotparanoid> i'm still reading the documentation (i'm not sure - yet - about the differences between push/commit/branch or pull/checkout).
[20:14] <ericvw> why isn't the new 1.11 version of bzrtools in the PPA?
[20:14] <imnotparanoid> thank you for your time. i'm going to give it a try tonight! have a nice evening!
[20:15] <bialix> good luck
[20:19] <Peng_> jelmer: Thank you for the help. "bzr svn-upgrade" seems to have gone fine. :)
[20:21] <jelmer> Peng_, np
[20:21] <jelmer> Peng_, ideally "bzr merge" will do the right thing in the future
[20:21] <jelmer> once revision-id aliases work :-)
[20:23] <poolie> hello all
[20:24] <bialix> jelmer: rev-id aliases?
[20:24] <jelmer> 'morning poolie
[20:24] <bialix> hello poolie
[20:25] <jelmer> bialix, yeah, though hooks in the graph code might be sufficient for the moment
[20:26] <bialix> poolie: I hope this patch will go into 1.12: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C497A0CD9.7030005%40arbash-meinel.com%3E
[20:27] <bialix> it should fix many problems
[20:27] <poolie> it looks good to me too
[20:27] <poolie> you keep asking me about patches i've approved :)
[20:27] <poolie> although admittedly yesterday to say it caused breakage
[20:27] <bialix> no, yesterday it was garyvdm
[20:27] <poolie> is jam still around? he should be
[20:28] <jam> poolie: I'm around
[20:28] <jam> bialix, poolie: It works for "shelve" but causes some tests for things like "diff" to break
[20:28] <bialix> rats
[20:28] <jam> I can give specifics
[20:28] <jam> but basically, our lock ordering is a bit haphazard
[20:29] <poolie> diff probably has to work :)
[20:29] <poolie> i was going to start the release in about 5 hours from now
[20:29] <jam> poolie: yeah, I would guess it is something like "bzr diff -r branch:" not working correctly.
[20:30] <bialix> so, I'd better won't try to ping you both then
[20:30] <jam> poolie: you're up early, btw
[20:30] <poolie> i am
[20:30] <jam> bialix: I'll see if I can't get it working today
[20:30] <poolie> i wanted to review ian's patches
[20:30] <poolie> i don't know if they'll land for this release but my review of them is pretty overdue
[20:30] <bialix> jam: I was in big hope about locks problem'
[20:31] <bialix> but I can live without shelve2
[20:31] <jam> I still have some hope for it
[20:32] <bialix> but shelve1 required patch.exe to be present
[20:33] <bialix> anyway, I'd better stay on the side
[20:34]  * bialix hides
[20:40] <jam> btw, poolie, you forgot to package bzrtools in the ppa during the 1.11 release, which seems to cause troubles for a lot of people, we should both get it packaged, and keep an eye out for that with the 1.12 release
[20:41] <poolie> yes, i saw :/
[20:41] <poolie> also, i think it would be easier to just merge everything across
[20:41] <poolie> i wonder if people are actually using bzrtools features, or if (as one person said) they were just told it's good so they keep it installed
[20:55] <jelmer>     s = self.filesock.readline(size)
[20:55] <jelmer> TypeError: readline() takes exactly 1 argument (2 given)
[20:55] <jelmer> anybody else seeing this?
[20:55] <lifeless> jam: pooliee: I believe that is what johnf wants to help by doing
[20:55] <lifeless> jelmer: yes, it was on the list, post b john on sunday
[20:56] <jelmer> lifeless, ah, thanks
[20:56] <jam> jelmer: vila and I have posted a fix. It has to do with https and python<2.6
[21:09] <bialix> jelmer: you've mentioned launchpadbugs recently. is it the separate library?
[21:10] <jelmer> jam, ah
[21:10] <jelmer> bialix, yeah - see lp:python-launchpad-bugs
[21:11] <bialix> jelmer: is it possible to use it to mark all bugs related to milestone to mark as "Fix Released"?
[21:11] <jelmer> bialix, not out of the box
[21:11] <jelmer> but you could write a script using it that would do such a thing
[21:12] <bialix> it's very boring task, so I'm ready to write the script
[21:13] <mwhudson> beuno: hello
[21:14] <beuno> mwhudson, howdy
[21:14] <mwhudson> beuno: do you know what History.get_merge_point_list is trying to do in loggerhead?
[21:15] <mwhudson> and simplify_merge_point_list
[21:16] <beuno> mwhudson, the latter, no idea. The former, IIRC, is used to find out what revisions to look at to get the files changed in a mainline revision
[21:16] <beuno> but I get dizzy everytime I try and go in there
[21:17] <mwhudson> ok
[21:17] <mwhudson> i guess it's time to step back and say
[21:18] <mwhudson> "what information is interesting to display"
[21:18] <beuno> right
[21:18] <beuno> well
[21:18] <beuno> I think the information we're displaying is fine
[21:18] <beuno> we *could* drop the merged in revno
[21:19] <lifeless> I'd like a datestamp
[21:19] <beuno> so we don't pay the cost of the dotted revno
[21:19] <lifeless> more than a revno
[21:19] <mwhudson> i have to say
[21:19] <mwhudson> i have _no idea_ what's going to appear in the "merged in" section
[21:19] <lifeless> in a 'query again' interface, a revno is essential
[21:19] <lifeless> in a 'click through' interface, its noise unless requested
[21:20] <beuno> mwhudson, good enough reason to drop it  ;)
[21:21] <beuno> if we do manage to load stuff more lazily, then the ajax bits would be a huge performance improvement
[21:22] <beuno> igc's new API makes it pretty easy, and if we can tweak the plugin to save the cache somewhere else, everything is going to feel *very* fast
[21:22] <beuno> but, AFAICT, we have to re-write quite a few bits in LH before being able to use it
[21:22] <mwhudson> beuno: well, i harbour a perhaps naive belief that there is something useful to display here
[21:22] <mwhudson> so about revision numbering
[21:23] <mwhudson> the thing is that, in today's reality at least, numbering _one_ off-mainline revision does enough work to number them all
[21:24] <mwhudson> so taking one revision number off the page doesn't really help
[21:25] <beuno> mwhudson, if we don't fetch non-mainline revs in the changelog view, we can use jam's lazy revno API
[21:27] <mwhudson> i think that would hurt usefulness too much
[21:27] <phinze> eek! "[Errno 11] Resource temporarily unavailable"
[21:27] <mwhudson> phinze: not as scary as it sounds, are you doing a diff during a commit or something?
[21:27] <phinze> revert
[21:28] <phinze> bzr break-lock, bzr: ERROR: The lock for '/home/phinze/proj/uiris3/trunk' is in use and cannot be broken
[21:28] <phinze> but bzr info doesn't list any locks
[21:29] <beuno> mwhudson, really? The default changelog view doesn't really have to display dotted revnos. We could check to see if it's mainline revs being navigated or not
[21:31] <phinze> a ha
[21:31] <phinze> found a zombie process
[21:31] <phinze> that was running a diff | vim -
[21:31] <phinze> disaster averted :)
[21:31] <mwhudson> beuno: the unexpanded view doesn't, i guess
[21:32] <mwhudson> beuno: can i ask you to step back some more?
[21:32]  * beuno steps back more
[21:32] <mwhudson> beuno: i'm trying to think about what information we want to display, and it feels like you're trying to optimize revno display
[21:33] <beuno> alrighty
[21:34] <mwhudson> beuno: so i actually think the unexpanded changelog view is more or less right already
[21:34] <beuno> agreed
[21:35] <mwhudson> in the drop down thingy
[21:35] <mwhudson> i think we could show a bit more about the merged revisions
[21:36] <mwhudson> beuno: do you remember this screenshot? http://people.ubuntu.com/~mwh/hacked_up_changelog_view_3.png
[21:36] <mwhudson> obviously that's not right, but...
[21:37] <beuno> mwhudson, yeap, showing more information would be good
[21:37] <beuno> basically, bzr log -v, I guess
[21:37] <mwhudson> yes
[21:37] <beuno> I'd add the date next to the merged revs
[21:37] <beuno> as lifeless pointed out
[21:38] <mwhudson> yeah
[21:39] <mwhudson> i do think branch nick is useful too
[21:40] <beuno> sure, maybe even group commits by branch nick
[21:41] <beuno> would make weird sorting sometimes though
[21:41] <mwhudson> mm
[21:41] <mwhudson> i guess you need to be careful about displaying too much information too
[21:41] <mwhudson> argh argh where to start
[21:42] <beuno> mwhudson, I can think of two (very different) places:  1) start refactoring things so we can be clearer about what is being accessed, or, 2) finally implement your screenshot
[21:43] <beuno> something basic intially, just the revno, author, shortened commit message and date
[21:43] <mwhudson> what i was trying to do last night was removing history.py somewhat
[21:44] <mwhudson> i hate the way you have template -> controller -> history.py -> bzrlib
[21:44] <mwhudson> it makes the intent so hard to unpick
[21:44] <beuno> that sounds like my favorite thing  :)
[21:44] <beuno> of course, it's probably the hardest
[21:45] <mwhudson> but now i've bumped into this line of code
[21:45] <mwhudson>             merge_revids = self.simplify_merge_point_list(
[21:45] <mwhudson>                                self.get_merge_point_list(change.revid))
[21:45] <mwhudson> which is where we started :)
[21:46] <beuno> right
[21:46] <beuno> maybe that flattens it into a list instead of a graph?
[21:46] <beuno> I remember debugging it at some point
[21:48] <mwhudson> so one interpretation of a 'merge point' is 'oldest mainline revision that has it as an ancestor'
[21:49] <mwhudson> which is actually something that's a little annoying to determine with the command line client
[21:51] <poolie> hello beuno
[21:51] <beuno> hiya poolie
[21:53] <igc> morning
[21:53]  * beuno goes home, bb in ~20'
[21:53] <igc> morning beuno, mwhudson
[21:53] <beuno> mhey ig
[21:53] <beuno> er
[21:53] <beuno> "hey igc"
[21:53] <beuno> "I hate my internet connection today"
[21:54] <mwhudson> hi igc
[22:25] <veritos> Is it possible to pull just one directory from a repository, à la Subversion?
[22:26] <bob2> no
[22:26] <veritos> Thank you.
[22:26] <bob2> well, you could bzr split, but that doesn't reduce the amount of downloaded date
[22:34] <jml> you know, that call was shorter than I expected :)
[22:35] <mwhudson> yesd
[22:35] <mwhudson> we only veered off once or twice, and not for very long
[22:35] <jam> interestingly, it is easier not to veer off when you know there are 10 other people around
[22:36] <jam> though it was still fairly long given that you have that many people to deal with
[22:36] <jam> (it wasn't *longer* than expected, just expectedly long)
[22:42] <mwhudson> beuno: i guess you're on the phone now?
[22:42] <phinze> so i've got 6 distinct commits i want to pull out of trunk before we deploy, and i'm at a loss for how to proceed
[22:42] <beuno> mwhudson, in theory, but not in practice
[22:42] <phinze> reverse merge each one and commit?
[22:42] <beuno> thumper left me for abentley
[22:43] <mwhudson> beuno: heh
[22:43] <abentley> beuno: It's alright, you can have him now.
[22:43] <mwhudson> beuno: how long are you going to be around for tonight?>
[22:43] <mwhudson> not necessarily for in depth discussion, just for sounding-board type stuff
[22:44] <beuno> mwhudson, I have quite a few more things to do, so probably within the range of "hours", on and off while I go for a run and eat
[22:44] <mwhudson> cool
[22:45] <Peng_> phinze: Probably, yeah.
[22:52] <jml> igc: the patch at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cd06a5cd30901260349v321f27a8uc1ab6a75bacb0f06%40mail.gmail.com%3E has all the tweaks in it.
[23:07] <phinze> gah, some of the commits i want out of trunk are sub-commits of other commits
[23:07] <phinze> sigh, i think i'm just going to comment out the crucial changes we don't want deployed :(
[23:08] <Odd_Bloke> There doesn't seem to be a great deal of shelve/unshelve blackbox testing.
[23:12] <Odd_Bloke> Is there ongoing shelve/unshelve work somewhere?
[23:17] <spiv> Odd_Bloke: not that I know of
[23:18] <spiv> Odd_Bloke: well, ISTR lifeless sent a small bug fix for it to the list recently.
[23:19] <beuno> poolie, hi. Are there still known problems with the new progress bars, or should I report the bug that status text concatenates instead of replacing eachother?
[23:19] <spiv> beuno: report
[23:19] <beuno> will do, thanks spiv
[23:20] <Odd_Bloke> spiv: OK, cool.  It seems there are a few things that could be made nicer, so I wanted to check I wasn't duplicating effort.
[23:20] <Odd_Bloke> Do all new errors need a test in bzrlib.tests.test_errors?
[23:21] <spiv> Odd_Bloke: yes, please.
[23:21] <lifeless> spiv: its merged
[23:21] <spiv> Odd_Bloke: it's amazing how easy it is to create an Exception with a broken __str__ :)
[23:25] <Odd_Bloke> Heh, like the one I was about to commit. >.<
[23:26] <lifeless> jam: if you return tonight, I filed a bug on annotate on thursday I think
[23:26] <lifeless> vila: ^ or you
[23:28] <Odd_Bloke> Two quick questions: 1: does 'shelf' seem like a reasonable bug tag to people (1.5: do we have a process for choosing bug tags?), and 2: what do people think of named shelves?
[23:29] <lifeless> Odd_Bloke: yes.no nice
[23:30] <spiv> Odd_Bloke: what lifeless said
[23:32] <igc> jml: so merging that diff, the tip is "Jonathan Lange 2009-01-25 Blackbox tests, forgot to add these earlier."
[23:32] <jml> igc: yep
[23:32] <igc> jml: that include everything?
[23:32] <jml> igc: it does.
[23:32] <jml> igc: I just checked :)
[23:33] <igc> jml: cool. Sending it off now ...
[23:33] <jml> igc: thanks.
[23:36] <lifeless> spiv: sync(
[23:38] <eydaimon> I've got a checkout on a host<EMAIL_ADDRESS>I want to clone it to my laptop. bzr clone<EMAIL_ADDRESS>doesn't work. what am I doing wrong?
[23:39] <eydaimon> the error is "ERROR: Not a branch"
[23:39] <Peng_> eydaimon: The path is relative to the root, not your homedir.
[23:39] <eydaimon> ok, thank you
[23:39] <Peng_> eydaimon: So, unless you actually have a directory called "/my_checkout", alongside "/usr" and "/dev"...
[23:47] <spiv> lifeless: the current code is at lp:~spiv/bzr/fetch-streaming
[23:49] <Odd_Bloke> What does 'f' in the shelve prompt mean?
[23:49] <Odd_Bloke> Looking at the code it means 'yes to all'.  So 'force'?
[23:51] <lifeless> Odd_Bloke: sounds plausible
[23:51] <lifeless> spiv: ok...
[23:52] <lifeless> spiv: I'm fooding; may I ring?
[23:52] <spiv> lifeless: sure.


[04:39] <rick_h_> evening
[04:41] <mrgoodcat> hey
[04:41] <mrgoodcat> you're up later than usual
[04:41] <rick_h_> yea, just getting back to the hotel
[04:43] <mrgoodcat> long day?
[04:44] <rick_h_> just a bit :)
[04:44] <mrgoodcat> missed you at CHC. craig said you were out of town
[04:46] <rick_h_> yea, OH today/tomorrow
[04:48] <mrgoodcat> how were the storms down there?
[06:05] <mrgoodcat> traceroute -m 254 -q1 obiwan.scrye.net
[10:47] <cmaloney> Good morning
[13:07] <jrwren> -m 254?
[13:08] <jrwren> that is a lot of hops, and I don't mean beer flavor
[13:15] <mrgoodcat> jrwren: yea but it's worth it
[13:15] <mrgoodcat> run the traceroute
[13:21] <jrwren> oh, the star wars thing.
[13:21] <jrwren> classic
[13:21] <mrgoodcat> yea
[13:21] <mrgoodcat> was playing around with all the linux joke things yesterdayu
[13:21] <mrgoodcat> apt-get moo is pretty good
[13:22] <mrgoodcat> aptitude moo
[13:22] <jrwren> many nerds went nuts over that not just because of the dns names, but because of all the play IPs required to do it.
[13:22] <jrwren> N: Unable to locate package moo
[13:22] <mrgoodcat> yea that is a lot
[13:22] <mrgoodcat> not install
[13:22] <mrgoodcat> apt-get moo
[13:23] <jrwren> oh, lol
[13:23] <jrwren> cowsay thanks
[13:24] <jrwren> cowsay -f elephant I\'ll never forget
[13:27] <mrgoodcat> fortune | b1ff | cowsay
[13:27] <mrgoodcat> requires fortune cowsay and filters
[13:27] <mrgoodcat>  _________________________________
[13:27] <mrgoodcat> Q: WHAT IZ GREEN + LIVEZ IN THE \
[13:27] <mrgoodcat> \ OCEAN??1??! A: MOBY PICKLE.     /
[13:27] <mrgoodcat>  ---------------------------------
[13:27] <mrgoodcat>         \   ^__^
[13:27] <mrgoodcat>          \  (oo)\_______
[13:27] <mrgoodcat>             (__)\       )\/\
[13:27] <mrgoodcat>                 ||----w |
[13:27] <mrgoodcat>                 ||     ||
[13:32] <jrwren> b1ff is a new one to me.
[13:32] <jrwren> well played
[15:33] <jrwren> https://sandstorm.io/
[15:33] <bookiebot> http://goo.gl/ozolBk - Sandstorm
[16:04] <brousch__> Hm, am I seeing this right? Ubuntu 14.04 server is only available in powerpc and 64bit? http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/14.04/release/
[16:04] <bookiebot> http://goo.gl/WgN5lO - Index of /pub/ubuntu-iso/DVDs/ubuntu/14.04/release
[16:06] <brousch__> Ah, 32bit is available via torrent
[17:23] <mrgoodcat> brousch__: what do you need the 32 bit server for?
[17:25] <greg-g> 4 gigs of RAM is enough for anyone
[17:31] <mrgoodcat> {{number}} {{unit}} of {Disk/RAM} is enough for anyone.
[17:31] <mrgoodcat> {{tech mogul from relevant era}}
[17:32] <mrgoodcat> mogul might be the wrong word
[17:32] <mrgoodcat> "All technology predictions suck." -Me
[17:41] <brousch__> mrgoodcat: To install on a 8 year old computer
[17:44] <mrgoodcat> wow
[17:44] <mrgoodcat> home/work/project?
[17:48] <brousch__> home firewall
[17:49] <mrgoodcat> !rotw ah
[17:50] <mrgoodcat> oh shoot
[17:50] <mrgoodcat> just meant to say ah
[17:50] <mrgoodcat> accidentally tapped "up"
[17:50] <mrgoodcat> brousch__: linux or bsd?
[17:50] <mrgoodcat> oh wait
[17:50] <mrgoodcat> nevermind
[17:51] <mrgoodcat> don't answer that
[17:51] <mrgoodcat> 12:04:56 < brousch__> Hm, am I seeing this right? Ubuntu 14.04 serv....
[18:33] <greg-g> what's the right make/model (size independent) SSD to buy these days?
[18:33] <greg-g> rick_h_: jcastro ^^
[18:37] <mrgoodcat> greg-g: right in what regard? speed/durability/size/price?
[18:37] <greg-g> durability,mostly
[18:37] <greg-g> consumer grade though
[18:37] <mrgoodcat> relevant article incoming
[18:37] <greg-g> not willing/wanting a commercial grade
[18:38] <mrgoodcat> http://techreport.com/review/26523/the-ssd-endurance-experiment-casualties-on-the-way-to-a-petabyte
[18:38] <bookiebot> http://goo.gl/ukNQcz - The SSD Endurance Experiment: Casualties on the way to a petabyte - The Tech Report - Page 1
[18:40] <mrgoodcat> page 3 has the drives that made it to a petabyte
[18:41] <jcastro> greg-g, I prefer intel but samsungs are also good
[18:41] <jcastro> also crucial MX series
[18:43] <jrwren> greg-g: samsung
[18:43] <greg-g> looks like that
[18:43] <greg-g> the samsung evo 840 (pro optional)
[18:43] <mrgoodcat> in that extremely unscientific article i linked the intel was among the first to die
[18:43] <mrgoodcat> the samsung uses TLC which dies a bit faster
[18:43] <greg-g> see also: http://thewirecutter.com/reviews/the-best-ssds/
[18:43] <bookiebot> http://goo.gl/jGQ67j - 403 Forbidden
[18:43] <jrwren> plus, the 840 non-pro is near .5$/GB
[18:43] <greg-g> http://www.extremetech.com/extreme/184253-ssd-shadiness-kingston-and-pny-caught-bait-and-switching-cheaper-components-after-good-reviews
[18:43] <bookiebot> http://goo.gl/5KSuls - SSD shadiness: Kingston and PNY caught bait-and-switching cheaper components after good reviews | ExtremeTech
[18:43] <jrwren> which is a good price point IMO
[18:44] <greg-g> jrwren: yeah
[18:44] <jrwren> 840evo 500GB is $250 on amazon... still kinda $$$ for me, but the 250 for $135 is not bad.
[18:45] <greg-g> yeah, 250gig is fine with me
[18:45] <greg-g> I don't need it all on laptop
[18:45] <greg-g> I have too much music and too many pictures for anything less than a TB to make sense to do "all"
[18:45] <jrwren> if you run VMs on laptop, 250 can get tight
[18:45] <greg-g> so I'm already going to do a subset
[18:45] <greg-g> nope, luckily
[18:49] <mrgoodcat> greg-g: i'd do this one http://www.amazon.com/Samsung-Electronics-EVO-Series-2-5-Inch-MZ-7TE250BW/dp/B00E3W1726/?
[18:49] <bookiebot> http://goo.gl/qD4P78 - Amazon.com: Samsung Electronics 840 EVO-Series 250GB 2.5-Inch SATA III Single Unit Version Internal Solid State Drive MZ-7TE250BW: Computers & Accessories
[18:49] <greg-g> yep
[18:49] <mrgoodcat> just a good deal
[18:49] <mrgoodcat> tomshardware++
[18:49] <greg-g> that's what I'm going to go get from best buy up the road
[18:50] <greg-g> same price, in fact
[18:57] <brousch__> I'm very happy with the 840 pros. I have 6 of them currently in use with no problems
[18:58] <brousch__> I have had 100% of my OCZ and Kingston SSDs fail. That's 2/2
[19:03] <jrwren> i'm soooo tempted to click buy it now on that..
[19:03] <jrwren> why are you linking me to such awesome?
[20:49] <greg-g> fuck this day, that is all
[21:37] <cmaloney> greg-g: Saw someone mention en.wikipedia was down
[21:37] <cmaloney> and all I could think was that greg-g was having a bad say
[21:37] <cmaloney> day
[22:07] <greg-g> yep
[22:07] <greg-g> first: ssd on laptop died
[22:07] <greg-g> while I'm at best buy, the parser cache falls over
[22:35] <brousch__> greg-g: What make/model SSD died?
[22:37] <greg-g> can't remember
[22:37] <greg-g> haven't had time to disassemble yet
[22:37] <greg-g> see above
[22:38] <brousch__> I assumed you were all set since you are chatting on here ;)
[22:38] <greg-g> irssi lives on a colo'd server
[22:39] <greg-g> and irc is part of work, sooo
[22:58] <greg-g> how could one debug things like "alt+num" not being passed through to irssi through gnome-terminal -> mosh -> server with irssi running
[22:58] <greg-g> works on my (now dead x200s install of debian jessie but not this x230 with an install of debian jessie
[22:58] <greg-g> s/dead/dead)/


[15:11] <balloons> phillw, ping
[15:12] <smartboyhw> phillw, ping
[15:12] <smartboyhw> lol
[15:15] <phillw> balloons: pong
[15:15] <smartboyhw> Yay
[15:27] <smartboyhw> phillw, balloons: You guys ping and not say anything??/
[15:27] <balloons> phillw, ping pong.. Sorry mate
[15:27] <balloons> just got off the weekly call
[15:28] <smartboyhw> The weekly call>.
[15:28] <balloons> anyways, I sent a mail to lubuntu-qa regarding the ppc stuff we spoke about
[15:28] <balloons> trying to catch up on everything and then dive back into the testcases
[15:28] <silverarrow> hi
[15:28] <balloons> hello silverarrow
[15:28] <phillw> balloons: yeah, just got the mail.
[15:29] <smartboyhw> lol
[15:31] <phillw> balloons: the consensus seems to be to make alternate the priority as it can run on lower spec ppc's. Desktop would be great, but is not as vital.
[15:31] <balloons> phillw, ok
[15:31] <balloons> I was going to ask you about if you got a shortlist of blocking bugs or anything
[15:32] <balloons> but thought I'd just send the mail
[15:32] <phillw> let the guys who have ppc's reply as at least one of critical bugs does not show on a virtual machine.
[15:32] <smartboyhw> balloons: We are thinking of a Ubuntu Studio specialized testcase (me and ailo), but we're not gonna do anything till astraljava1 comes back, so...
[15:33] <balloons> smartboyhw, right.. that's the right idea
[15:33] <silverarrow> ok, minimal install works somewhat with xorg at least now?
[15:33] <balloons> an optional testcase for your specific bits
[15:34] <smartboyhw> Grrrrr...Since astraljava1 is not here we are not gonna do anything, I don't wanna get beaten
[15:34] <silverarrow> I have a iBook G4
[15:34] <balloons> smartboyhw, use the sandbox.. you can write something up
[15:34] <smartboyhw> Grrrrrrrrrr....I wanna put ailo in then...
[15:34] <phillw> silverarrow: minimal or alternate?
[15:35] <smartboyhw> ailo = Kaj Ailomaa, the Ubuntu Studio doc lead
[15:35] <balloons> put ailo in?
[15:35] <balloons> I'm confused by what your saying
[15:35] <smartboyhw> yeah he is making dev docs
[15:35] <silverarrow> I am used to regular GUI install
[15:35] <silverarrow> lol
[15:35] <smartboyhw> I mean the testcase admins team
[15:35] <balloons> you could draft something up, and then you yourself could even place it on the sandbox page
[15:35] <smartboyhw> He is a good guy trust me
[15:35] <smartboyhw> Geeee.......
[15:35] <balloons> making a testcase doesn't require any special powers :-)
[15:36] <smartboyhw> I still got the publishing one to finish in the coming week....
[15:38] <phillw> silverarrow: I'm unsure what you are saying... Have you installed a 12.10 version of lubuntu onto your iBook G4?
[15:38] <silverarrow> struggeling to do so now
[15:38] <silverarrow> I am rereading some of the workarounds to make installer run
[15:39] <silverarrow> has the daily main is changed at all the last days ?
[15:39] <silverarrow> or just the update part
[15:46] <phillw> silverarrow: I'm not sure what has been comitted to the ppc builds in recent days
[15:47] <silverarrow> I am downloading the current listing just in case
[15:47] <silverarrow> both ubuntu and lubuntu
[15:47] <phillw> an easy was to check is to zsync up your current iso & see if it grabs new stuff. Zsyncing is far faster than a complete doownload as it only updates the parts that have changed.
[15:49] <silverarrow> I hope the build is stable enough to run
[15:49] <phillw> silverarrow: if you're unsure on using zsync, there is a wiki page for it at https://help.ubuntu.com/community/ZsyncCdImage
[15:49] <silverarrow> it makes bug reporing much easer, even if it runs badly
[15:54] <phillw> yes, a failure to install does cause problems reporting :)
[15:59] <balloons> heh..
[16:16] <phillw> balloons: good news! we have a passed install on lubuntu desktop ppc :)
[16:17] <balloons> woot!
[16:28] <phillw> balloons: who should someone prepared to look after the Chromium ppa's in ubuntu contact? He already maintains his own set.
[16:32] <balloons> ?
[16:32] <balloons> phillw, did you miss a word in that sentence, or I am just not reading it right? :-)
[16:34] <phillw> hmm, i think all the words are there. But to summise, bug 1044307 There is someone who maintains a daily & stable ppa (see comment #4)
[16:35] <phillw> i contacted him and would be happy to help out, but I don't know to ask him to contact.
[16:35] <phillw> *and he would be*
[16:56] <balloons> ok, so you want to contact alex shkop?
[16:58] <phillw> balloons: I've already contacted him & he has replied that he is happy to help. I just need to inform him of who to contact with his offer :)
[16:58] <balloons> contact about what?
[16:58] <balloons> there are no official ppa's
[16:58] <balloons> by design all ppa's are third party :-)
[16:59] <phillw> https://launchpad.net/chromium-project
[16:59] <balloons> the package inside ubuntu comes from debian, but of course, ubuntu doesn't update the package from debian after the initial pull at the start of development.. and certainly not after release
[16:59] <balloons> the chromium team is micah
[17:00] <balloons> micahg.. heck, he's even in this channel ;-)
[17:00] <balloons> does that help?
[17:01] <phillw> balloons: yes, I'll try and catch micahg next time he is active :)
[17:01] <balloons> I think I get what your meaning now.. he wants to help restart the old ppa that most everyone was using
[17:01] <phillw> indeed he does :)
[17:02] <phillw> seems silly to turn the offer down :D
[17:05] <phillw> I get the gripes about chromium via my bug link to all lubuntu applications and the lubuntu mailing list (They do grumble :) )
[17:06] <balloons> phillw, yes, since lubuntu is shipping it, it's rather important
[17:06] <phillw> tell me about it :D
[18:14] <wxl> so i work in a bike shop. it's standard bike shop humour to talk about the guy who's got a problem that happened while he was "just riding along." well, i've got the computer equivalent here. wonder if anyone might be able to shed light on it. lubuntu quantal running upgrades in terminal. meanwhile upgrade manager pops up as usual. i had some sort of problem upgrading lxsession that forced me to apt-get -f install and somewhere along the way i get a
[18:45] <balloons> wxl, somewhere along the way you get a ?
[18:45] <balloons> get a what? ;-)
[18:45] <balloons> btw, <3 biking
[19:00] <wxl> balloons: biking indeed, but there was no action asked for on my part except the standard crash dialogue for chromium and just an ok dialogue for the weird error
[19:00] <wxl> not to pitch the wares but if you're really curious we technically are a bike manufacturer: http://bikefriday.com
[19:00] <balloons> wxl, perhaps it was simply my client, but most of your message is cut off
[19:01] <balloons> hence my question
[19:01] <balloons> ahh yes, I've heard of those :-0
[19:01] <wxl> oh
[19:01] <wxl> ok lemme break it down
[19:01] <wxl> lubuntu quantal running upgrades in terminal. meanwhile upgrade manager pops up as usual. i had some sort of problem upgrading lxsession that forced me to apt-get -f install and somewhere along the way i get apport running and chromium (which wasn't open) crashing.
[19:02] <balloons> ok, odd.. so is the question as to why chromium popped up?
[19:02] <wxl> end result: no report and apport complains "unpack requires a bytes object of length 4."
[19:02] <wxl> no it more has to do with that ↑ error
[19:02] <wxl> which i have never seen before
[19:02] <balloons> :-)
[19:02] <balloons> I also haven't heard of it
[19:03] <balloons> however, have a look in /var/crash
[19:03] <wxl> oh there we go
[19:03] <balloons> you can resubmit the crash manually
[19:03] <wxl> forgot about that
[19:03] <balloons> if apport complains the same way, file a bug on apport, and attach the crash :-)
[19:03] <wxl> none of these are dated today
[19:04] <wxl> oh wait there's one from lxsession
[19:04] <wxl> lxsession failing to upgrade seemed to trigger all this
[19:04] <wxl> however 0-length
[19:04] <wxl> strangely it's an .uploaded file which almost suggests to me that it's finished
[19:05] <wxl> is that an intermediate file in ubuntu-bug/apport's process?
[19:17] <balloons> .uploaded is a state file
[19:17] <balloons> it's written when it starts the upload though
[19:17] <balloons> err well
[19:17] <wxl> well written when finished uploaded
[19:17] <balloons> it may well represent that your crash did make it
[19:18] <wxl> and then i'd assume deleted when the process is complete?
[19:18] <balloons> however, you were not able to file the bug to accompany it
[19:18] <wxl> cuz i have no others
[19:18] <wxl> it seems? honestly i'm not sure what it filed it against
[19:20] <balloons> it filed no bug
[19:20] <balloons> just the crash data went into the db
[19:20] <balloons> if you didn't file a bug, there is no bug report for it :-)
[19:20] <balloons> however, the .uploaded file I'm believing means the data was successfully uploaded to the crash db
[19:20] <balloons> I could very well be wrong on this
[19:20] <balloons> that
[19:21] <balloons> that's simply my understanding.. we'd have to ask ev or someone else
[19:21] <wxl> so where do i go from here? i mean i have no idea what events really led to the crash so i have nothing intelligent to say in filing a bug report. without the data, i don't know what else to do.
[19:22] <balloons> ahh.. that's a good question
[19:23] <wxl> well i'll just leave it as is, i guess, but if you have some insight, let me know
[19:24] <wxl> i'll go back to trying to figure out why my touchpad randomly acts stupid
[19:24] <balloons> wxl, so you didn't find a .crash file with any data in it?
[19:24] <wxl> i've written a script where i can basically get every piece of diagnostic data lickety split
[19:24] <wxl> i have a crash file from 14 september
[19:24] <wxl> an .upload also from same time 14 sep
[19:25] <wxl> but the .uploaded is 17 sep
[19:25] <wxl> no other files for anything 17 sep (today in case it's not obvious; dunno your time zone)
[19:25] <balloons> yes, today is 17 sep still
[19:25] <balloons> ok, so can you re-create it?
[19:26] <wxl> not sure
[19:26] <wxl> it seemed that upgrading lxsession was the trigger
[19:26] <wxl> so if it's already upgraded…
[19:26] <balloons> btw, https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1017338
[19:26] <balloons> also this is 12.10 I assume yes
[19:26] <balloons> ?
[19:26] <wxl> yep, lubuntu
[19:27] <wxl> from .crash:
[19:27] <wxl> SegvAnalysis: Skipped: missing required field "Disassembly"
[19:27] <wxl> also complains that lxsession, et al. are out dated
[19:28] <wxl> this may be a fluke
[19:28] <wxl> i guess i'll wait to see if it happens again
[19:29] <wxl> i just HATE when i have bugs and i don't know why they happened
[19:30] <wxl> i'm just going to leave a comment on that bug
[19:30] <wxl> might not be related but if it turns out it is it might help
[19:36] <kanliot> i'm using software updater, why does it pull in more new stuff than apt-get dist-upgrade does?
[23:19] <kanliot> http://www.hanselman.com/blog/EverythingsBrokenAndNobodysUpset.aspx  < guy whining about bugs well taken
[23:30] <smartboyhw> balloons: went asleep or?