[00:03] <ToyKeeper> Heh, I wouldn't exactly say it hurts, but it can definitely confuse people who don't expect it.
[00:05] <fullermd> NOBODY expects the rich root transition!
[00:05] <mathepic> I know rich-root adds some info thats not in the others, but what specifically is that?
[00:08] <spiv> The root of the tree gets a unique file-id and version like any other directory.  This means operations like "bzr mv . subdir" can be tracked accurately, and is also useful for merging a branch into a subdir of an unrelated branch, as well as just generally making our data model a little more consistent.
[00:09] <spiv> (IIRC some (all?) non-rich-root formats did allow the file-id to be stored, but they didn't support tracking a version; it was just implicitly considered to be last modified by the current revision)
[01:01] <igc> morning
[03:12]  * igc lunch
[03:34] <davidstrauss> Where can I find the docs on X.Y.Z revision numbers?
[03:36] <Peng_> I know the current scheme was explained in detail on the list back when it was designed . . . .
[04:35] <RenatoSilva> Is there a way to make 'bzr ignore' use the conf in ~, not the branch?
[07:02] <bialix> hello all
[07:05] <mneptok> ssssshhhhhhh! the maestro is decomposing.
[07:06] <bialix> ?
[07:12] <mneptok> looking for meaning in anything i say is like looking for the hot dog vendor at a bar mitzvah.
[07:17] <igc> hi bialix, mneptok
[07:17] <bialix> hi igc
[07:17] <bialix> igc: do you need windows installer for bzr-explorer?
[07:17] <igc> bialix: if you get a chance, yes please
[07:18] <mneptok> igc: good morning!
[07:18] <bialix> mneptok: what is mitzvah?
[07:19] <bialix> mneptok: ok, I found
[07:19] <bialix> hot dogs are not cosher food?
[07:20] <mneptok> no. anything from a pig is not kosher.
[07:22] <bialix> never think that sausage made from pig
[07:29] <vila> hi all
[07:31] <bialix> bonjour vila
[07:31] <vila> hi bialix
[07:39]  * vila restore babune after yesterday crash, may be on and off for a couple of hours
[07:43] <bialix> igc: after translations update it makes sense to run `python setup.py build_mo` to refresh auto-generated english translation
[07:43] <igc> bialix: oh - ok
[07:44] <bialix> installer has uploaded
[07:44] <igc> bialix: thanks
[07:44] <bialix> my pleasure
[07:44] <igc> bialix: wrt http://doc.bazaar-vcs.org/explorer/en/processes/making-a-release.html ...
[07:45] <spiv> vila: when are you going to finish and land lp:~vila/bzr/405745-http-hangs btw?  It's been lingering in the queue for a while.
[07:45] <igc> is step 2 needed there? or only after downloading the translations?
[07:46] <igc> bialix: I tried python setup import_po btw and it fell over IIRC
[07:46] <vila> spiv: I should mark it in progress because it hangs under some circumstances,
[07:46] <igc> see http://doc.bazaar-vcs.org/explorer/en/processes/updating-translations.html
[07:46] <igc> hi vila!
[07:46] <bialix> igc: step 2. Build binary translations files (bialix to confirm) -- required for installer
[07:46] <bialix> step 3 has error: should be iscc extras/explorer.iss
[07:47] <vila> spiv: that was an important motivation to work on  bug #392127 but,
[07:47] <vila> spiv: while I reached a point where hardy. jaunty and karmic weren't failing nor hanging in any way,
[07:47] <bialix> igc: fellover?
[07:47] <bialix> igc: fell over?
[07:47] <igc> bialix: yes
[07:48] <bialix> how?
[07:48] <vila> spiv: I'm now experiencing hangs again on Freebsd and OSX :-/
[07:48] <bialix> traceback?
[07:48] <spiv> vila: Ah :(
[07:49] <bialix> igc: traceback?
[07:49] <igc> bialix: yes.
[07:49] <bialix> igc: can I see it?
[07:49] <igc> it was late so I didn't collect it :-(
[07:49]  * igc tries again
[07:49] <bialix> you can run it again
[07:50]  * vila needs to reboot, bbl
[07:51] <igc> bialix: http://pastebin.com/d8883196
[07:51] <bialix> interesting
[07:51] <bialix> tarball support is broken for you?
[07:52] <bialix> igc: what is your python version?
[07:52]  * bialix suspects bad thing
[07:53] <igc> bialix: 2.6.4rc1
[07:53] <bialix> python devs killed Kenny?
[07:53] <spiv> lifeless: Mind if I "bzr upgrade --2a lp:bzr-pqm" ?
[07:55] <bialix> igc: oh, I see, explorer -> po/explorer <-- there is no file extension, should be explorer.pot -> po/explorer.pot
[07:55] <bialix> igc: can you send me export tarball?
[07:55] <igc> bialix: sure
[07:55] <bialix> it seems lp devs killed Kenny and changed the format of export tarball again
[07:56] <spiv> lifeless: (I have a slightly rough patch to allow me to pqm-submit branches I don't have locally, but my local copy of the bzr-pqm branch has already been upgraded to 2a)
[07:57] <lifeless> spiv: doit
[07:57] <spiv> lifeless: ta
[07:58]  * spiv blows away the old backup.bzr
[07:59] <bialix> igc: http://pastebin.com/d36e98da0
[08:00]  * bialix starts to hate python 2.6
[08:00] <bialix> igc: I dunno why it does not work for you
[08:00] <bialix> igc: maybe recent regression in 2.6.4rc1?
[08:00] <igc> bialix: ok - thanks for looking
[08:01] <igc> bialix: while I have your attention ...
[08:01] <igc> that qexport patch?
[08:01] <igc> what's required to tweak it to make you happy?
[08:01] <bialix> igc: ha!
[08:01] <bialix> igc: I've got the same error with pythopn 2.6 on my machine
[08:02] <bialix> Python 2.6.2
[08:02] <igc> bialix: I'm planning to fix some qbzr bugs over coming nights
[08:02] <bialix> igc: qexport?
[08:02] <igc> bialix: is there a rough date for the 0.15 release?
[08:02] <bialix> igc: that old discussion how to better
[08:03] <bialix> igc: when it will be ready
[08:03] <bialix> igc: I'm too busy at work until the end of the month
[08:03] <igc> bialix: end of month is good for me fwiw
[08:04] <bialix> igc: about qexport: I'm not quite agree with your latest changes
[08:04] <bialix> you saw my comments though
[08:04] <igc> bialix: I did. There were lots of comments though - I'll take another look soon
[08:05] <bialix> from other hand I don't have enough time to polish it right now, so I can close my eyes if you merge anything you think is appropriate for you or bzr-explorer
[08:05] <igc> bialix: ok. I'll land the bits we agree on
[08:05] <bialix> igc: my main concern is change of controls order
[08:06] <bialix> igc: I don;t agree that archive format should be first item
[08:06] <igc> bialix: fair enough
[08:06] <igc> bialix: my bigger issue was defaulting to zip on Windows ...
[08:07] <bialix> ping me or send mail to qbzr ml if needed so we can reach some consensus
[08:07] <igc> and sohlud tar.gz instead of tgz, etc.
[08:07] <igc> showing
[08:07] <igc> sure
[08:07] <bialix> what's problem with zip default on Windows?
[08:07] <igc> no problem - it defaults to tgz now
[08:08] <igc> zip is better known to windows users
[08:08] <bialix> in some unmerged-yet-patch it was changed
[08:08] <igc> yep - this one :-)
[08:51] <fullermd> igc: ping
[08:51] <igc> hi fullermd
[08:51] <fullermd> Howdy.  You wanna chat about revspecs?
[08:51] <igc> sure
[08:52] <fullermd> So, re your (2) (where revid falls in the list), one of my criteria in order choice was a WAG of relative expenses.
[08:53] <igc> wag?
[08:53] <fullermd> I figured checking if a name exists as a tag is fairly fast, since it's a list in one place that's probably pretty short.  Checking the history for a revid would take longer 'cuz there's more to look at.
[08:53] <fullermd> Wild Ass Guess.
[08:53] <fullermd> And date would take longer than revid, 'cuz you have to peek inside the revs.
[08:54] <spiv> fullermd: all of a sudden I'm imagining Aretha Franklin singing "R-E-V-S-P-E-C, find out what it means to me..."
[08:54] <igc> :-)
[08:54] <fullermd> That was weighed against my feeling for how often we'd enter certain things.  I'd want to paste in tags all the time, and revids probably next.
[08:55] <fullermd> (though it's kinda a tossup how often I'd put in dates vs revids maybe, but given the expenses...)
[08:55] <fullermd> And branch:...  well, I sorta threw that in 'cuz I could   :p
[08:55] <al-maisan> hello there, I have a question re. ignored files: they continue to appear in "bzr diff" output .. is there a way to *not* have ignored files in "bzr diff" output?
[08:55] <spiv> Although thinking about it, "You wanna chat about revspecs" sounds more like "Let's talk about revspecs baby, let's talk about you and me..."
[08:55] <spiv> al-maisan: only versioned files appear in "bzr diff" output
[08:56] <al-maisan> ignored files are versioned files
[08:56] <igc> spiv: it's clearly late there :-)
[08:56] <igc> fullermd: hmm
[08:56] <al-maisan> spiv: so there's no way to exclude them from "bzr diff" output
[08:56] <fullermd> al-maisan: The main thing 'ignore' directly affects is whether 'bzr add' will add it; it doesn't have any affect on files that are already versioned.
[08:57] <al-maisan> fullermd: I see, thanks.
[08:57] <spiv> al-maisan: the ignore rules don't control which files which files are versioned, they control which files are automatically added by 'bzr add', and which unversioned files 'bzr st' will complain about, etc.
[08:57] <spiv> You can always explicitly add a file that matches an ignore rule.
[08:57] <al-maisan> OK .. understood.
[08:57] <igc> fullermd: one simple answer is to take revid out of the dwim list altogether
[08:58] <spiv> al-maisan: you might find the filterdiff command helpful
[08:58] <igc> fullermd: we can always add it in later
[08:58] <fullermd> I don't overly like that.  It and tags are the two things that first occured to me I'd want to DWIM.  What's the motivator?
[08:58] <al-maisan> spiv: thanks for the hint .. will take a look.
[08:58] <spiv> al-maisan: it's part of the 'patchutils' package on ubuntu
[08:59] <igc> fullermd: and the trade-off of speed vs convenience worries me, cause revids aren't convenient regardless
[08:59] <igc> fullermd: in bzr, revids can worry in form based on where they came from
[08:59] <igc> vary
[09:00] <igc> e.g. a svn import has svn:...
[09:00] <Peng_> For me, DWIM revids are most useful.
[09:00] <igc> which *looks* like a revspec
[09:01] <fullermd> Well, but is "-rsvn:asdf" more eyetwisting than "-rrevid:svn:asdf"?
[09:01] <fullermd> You're probably unlikely to type a meaningful revid without meaning to, thinking you're typing a revno or tag or something.
[09:01] <igc> the problem is that svn:xxx is a real revspec for xxx in the svn repo
[09:01] <spiv> Looking to see if a single revid is present or absent in a repo should be pretty quick... what's the concern about speed?
[09:02] <igc> so, iiuic, a dwim revspec for foreign branches will break?
[09:02] <spiv> igc: I think the svn revids are svn-v4:...?
[09:02] <fullermd> Oh.  Well, in that case, that would never get to the DWIM (since it checks for a registered revspec first)
[09:03] <fullermd> So you'd have to use the full revid:blah form.
[09:03] <spiv> andrew@steerpike:~/code/twisted/trunk$ bzr revision-info
[09:03] <spiv> 15278 svn-v4:bbbe8e31-12d6-0310-92fd-ac37d47ddeeb:trunk:27226
[09:03] <spiv> (or svn-v3 for earlier versions of bzr-svn, and anything before that is simply ancient...)
[09:03] <igc> spiv: I wonder whether git and hg also have the same form - probably
[09:04] <fullermd> Well, 'ancient' is no counter-argument; it's a VCS, ancient craps stays around forever  ;)
[09:04] <spiv> So for the specific case of revisions converted by bzr-svn its shouldn't be an issue.
[09:04] <spiv> And I think it's probably good practice for foreign revid mappings to be versioned like that.
[09:04] <fullermd> So, that case seems like "not all revids can just be DWIM'd, 'cuz they'll be grabbed earlier".  I don't think that's a deal-breaker, it just means you can't always use the short form.
[09:04] <spiv> fullermd: "bzr foreign-mapping-upgrade" :P
[09:05] <spiv> igc: I'd guess the bzr-git and bzr-hg plugins do, but I don't know for sure.
[09:05] <igc> spiv: right, but there's no certainly re what form a revid will take
[09:05] <igc> it can be almost anything
[09:06] <spiv> Yeah, you're right that a revid could look like a revspec.
[09:06] <fullermd> Yah.  But "Most Of The Time"(tm), they probably won't start with "valid-revspec:", so would DWIM OK.  And when it does, you'd just have to disambiguate.
[09:06] <spiv> But weird revids are definitely not the norm.
[09:07] <igc> spiv: the issue we're discusisng btw is dwim ordering ...
[09:07] <igc> fullermd is proposing ...
[09:07] <Peng_> Oh man, I forgot about "foreign-mapping-upgrade" when bzr-git's revids changed, and wound up pulling everything again. Shoot!
[09:07] <igc> revno, tag, revid, date, branch iirc
[09:07] <spiv> Peng_: but it's such a memorable command name! ;)
[09:07] <igc> spiv: I suggested moving revid to last
[09:07] <fullermd> So the big trap would be when it starts with valid-revspec:, AND the remainder under that revspec actually translates to a revision.  I don't think that's likely enough that it would cause problems in practice.
[09:07] <igc> or putting it immediately after revno
[09:08] <igc> fullermd: I agree it's most unlikely
[09:08] <Peng_> Would the DWIM stuff actually break reverring to revspec:whatever explicitly if "whatever" looks like a revno/tag/etc.?
[09:08] <Peng_> referring*!
[09:09] <fullermd> No, once it catches revspec: it passes to that class to handle it.  DWIM only triggers when you fall off the end of from_string()
[09:09] <fullermd> (the place where it used to assume it was a revno if it were numeric, else die)
[09:09] <spiv> igc: hmm.  It's too late in the day here for me to form a sound opinion on that, I think :)
[09:09] <Peng_> fullermd: OK, good.
[09:10] <fullermd> igc: So, one reason (perf to one side) I like it after tag is because the user controls tags; revids, generally not.
[09:10] <Peng_> I've always liked that bzr's revspecs are unambiguous, so you can have tags like "123" or "2009-10-14" or whatever you want. :)
[09:10] <spiv> igc: I do think that in practice there will never be ambiguity between a tag, a date, a branch name, and a revid.
[09:10] <fullermd> So if there IS a tag that mirrors a revid (unlikely though that may be), it's because the user meant it to, so we should probably prefer that.
[09:10] <spiv> Er, I mean:
[09:10] <igc> fullermd: right.
[09:10] <fullermd> (and in general, if a tag mirrors a valid date/branch/etc, we should prefer it)
[09:11] <spiv> never be ambiguity between a revid and any one of of those others.
[09:11] <spiv> (i.e. revid vs. date, revid vs tag, etc.  I can imagine tag vs. branch or date clashing)
[09:12] <fullermd> I don't have any religious objection to changing the order; it just feels right to me as-is.
[09:12] <igc> fullermd: i like your order ...
[09:12] <igc> I'm just not sure where revid best fits within it :-)
[09:13] <igc> the others are good
[09:13] <spiv> If we're uncertain, let's try fullermd's ordering and see how it feels?  I don't really see where revid is placed mattering very much, because it's so unlikely to conflict.
[09:14] <fullermd> Well, until we get branch-by-name rather than branch-by-location, specifying branches is going to be pretty rare.  So having that last fits.
[09:14] <igc> if a user cut-and-paste a revid, they really would expect it
[09:14] <fullermd> I mostly added it because I looked at the list of revspecs, and it said to me "Hey, I s'pose people might use me, sometimes..."
[09:14] <igc> fullermd: so let's go with your order given no-one feels strongly
[09:15] <fullermd> (also rare because I can never mentally figure out whether/how a branch: spec is going to WORK...)
[09:15] <spiv> And because revids are so unlikely to conflict, I think that a) we don't need to worry about it now, and b) if we change where revid is in that order later, no-one will be disturbed.
[09:15] <igc> I just wasn't sure and though we ought to open it up for debate
[09:15]  * fullermd nods.
[09:15] <fullermd> 'k, so that leaves your (1) (quick-fail if it looks like a revno but wasn't).
[09:16] <fullermd> About the only thing that's likely to trigger on if it gets past there is probably tag.  Though I guess you could have a branch at a path like ./5.
[09:16] <igc> tag is the only clash in my mind
[09:17] <spiv> fullermd: well, there's another possibility...
[09:17] <fullermd> So if you expected a revno and one wasn't there (and you don't have a tag named that), it means bzr eats more time before handing you the error.
[09:17] <spiv> fullermd: try them *all*, and if multiple dwim candidates match refuse to guess.
[09:17] <spiv> fullermd: (and so force the user to disambiguate with an explicit revspec)
[09:17] <igc> that gets expensive
[09:18] <fullermd> Yeah.  I'd guess thatn 95% (or 99%) of the time, you're entering a revno.
[09:18] <fullermd> So going through the expense of loading the whole history tree and checking the timestamp of each rev would be Bad(tm).
[09:18] <fullermd> After all the work to AVOID doing all that extra work on simple stuff, I'd get lynched for suggesting that  ;)
[09:19] <spiv> Incidentally, this discussion suggests to me that perhaps we should disallow tags that look like a natural number...
[09:19] <igc> spiv: we can't I feel - roundtripping
[09:19] <spiv> i.e. any matching '[1-9][0-9]*'.  But probably few users would do that, and won't be too surprised by the results if they do.
[09:20] <spiv> igc: *nod*
[09:20] <igc> spiv: I just think if something looks like a revno, we should assume it is
[09:20] <spiv> Yeah.
[09:20] <igc> not try tags
[09:21] <spiv> Even if there is no revno 99999, but there is a tag 99999?
[09:21] <spiv> I think that's probably reasonable.
[09:21] <igc> and we can encourage projects to use tag names that aren't revno like
[09:22] <igc> and they get nicer dwim revspecs for their trouble :-)
[09:22] <spiv> Right.
[09:22] <spiv> Ok, I'm off.
[09:22] <spiv> Happy UI designing :)
[09:22] <fullermd> Is the motivation "If user entered a numeric, they'd be unpleasantly surprised if it hit something that wasn't a revno", or "Get the error back to the user faster without loading all the history"?
[09:23] <igc> more the former
[09:24] <fullermd> OK.
[09:24] <igc> it's not a strong feeling though - more a preference
[09:25] <fullermd> So I have a mild preference to keep going, on the theory "if it hits something else, it's because the user probably meant to".
[09:25] <igc> fair enough
[09:25] <fullermd> It's not a particularly strong conviction, but more than an offhand whim.
[09:26] <fullermd> We can let democracy take its course on that I guess.
[09:26] <bialix> igc: http://kashfarooq.wordpress.com/2009/10/12/integrate-bazaar-source-control-with-your-preferred-merge-application/
[09:26] <igc> fullermd: so I think it's worth emailing the list just to see if others feel strongly either way
[09:26] <bialix> igc: this man wrote series of articles already
[09:26] <fullermd> (when two people disagree enough to not just abandon their positions, but not enough to fight for them, you don't even get good flamewars  ;)
[09:26] <igc> fullermd: otherwise, I'm happy to change my vote to approve
[09:28] <fullermd> 'k.  I'll drag it onto the list later.  Thanks   8-}
[09:32] <igc> bialix: interesting. I want to make qconfig easier to configure merge tools. I'll look at that soon.
[09:32]  * igc dinner
[09:33] <bialix> yeah, this old nasty problem with merge tools :-/
[09:44] <bialix> igc: re import_po error: in python2.6 getnames() method of opened tarball archive now returns names of directories as well as plain files. in 2.5 there was no directories in list. and nothing mentioned about this fact in 2.6 documentation. nice, huh?
[09:48] <bialix> igc: no, I'm wrong! even funny. Now directory name has no trailing slash in 2.6.
[09:50] <bialix> anybody knows what's difference between REGTYPE and AREGTYPE (re tarball items)?
[09:55] <fullermd> A glance at google says AREGTYPE is for historic compatibility.
[09:55] <bialix> hm... ok
[09:56] <fullermd> (so the same thing, just don't use AREG for new stuff)
[09:57] <jelmer> igc: hi
[09:57] <jelmer> igc: I managed to convert svn-fast-export to subvertpy-fast-export
[09:58] <jelmer> igc: as far as I can tell it's not leaking any file escriptors (highest fd is around 10 or 11 usually)
[09:59] <jelmer> igc: I'm on GPRS at the moment so uploading is a bit expensive, I'll push later today
[09:59] <spiv> jelmer: hooray!
[09:59] <bialix> jelmer: cool
[09:59] <bialix> igc: problem with import_po has fixed
[10:01] <jml> what _exactly_ does 'bzr ls' print by default?
[10:03] <spiv> jml: bzr: ERROR: Not a branch: "/home/andrew/".
[10:03] <spiv> ;)
[10:03] <spiv> As for the question you meant to ask, I don't know :)
[10:05] <jml> spiv, wow, now I feel confused, belittled and still unhelped :P
[10:05] <spiv> A new personal best!
[10:05] <jelmer> :-)
[10:06] <LarstiQ> jml: unrecursive argument listing iirc
[10:07] <jml> LarstiQ, it also seems to list the contents of the tree. afaict, it behaves like regular 'ls' unless told otherwise.
[10:07] <LarstiQ> jml: yes
[10:07] <jml> LarstiQ, ok, thanks.
[10:56] <igc> jelmer: my hero! thank-you!
[10:56] <igc> bialix: thanks - I'll try it
[11:28] <fullermd> jelmer: BTW, re adding a registry for DWIM specs: It's not entirely trivial, since there are differing lists of exceptions to catch.
[12:18] <igc> night
[13:02] <bialix> anybody knows the nick of jszakmeister
[13:02] <bialix> ?
[13:03] <bialix> what it means "super client" as in jszakmeister’s article: http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/
[13:03] <spiv> bialix: https://launchpad.net/~jszakmeister says it is jszakmeister
[13:04] <spiv> I don't know if that's accurate or not.
[13:04] <bialix> ok, thanks spiv. because it's not here right now can you shed some light on english words?
[13:06] <spiv> I've only just glanced at that link, but I think there "super" is in the sense of "better" or "has a superset of features" compared to SVN's native client.
[13:07] <bialix> ok, thanks
[13:08] <spiv> No worries.
[13:08] <bialix> ok, I won't :-)
[13:15] <ploum> Hello
[13:15] <ploum> More than a year ago, I've set a shared repository to host our project with loggerhead interface
[13:15] <ploum> works fine
[13:16] <ploum> but now I realize that every project is under the very same shared repository
[13:16] <ploum> which is not, AFAIK, the goal of shared repository (because our project have nothing in common)
[13:17] <ploum> also, while doing big push the whole server is nearly frozen, all the ram being taken
[13:17] <ploum> is there a way to optimize this and to "unshare" a shared repository ?
[13:18] <beuno> ploum, you can unshare a branch with "bzr reconfigure --standalone"
[13:18] <beuno> ploum, also, what format are the branches?
[13:18] <beuno> the new format is a *lot* faster
[13:19] <beuno> (bzr info should tell you the format)
[13:20] <ploum> I upgraded
[13:20] <ploum> so it's the latest format
[13:20] <beuno> ploum, have you run "bzr pack" on it?
[13:21] <ploum> no
[13:21] <ploum> what is bzr pack ?
[13:21] <ploum> I admit that the new format is faster but it also seems to take more ram
[13:21] <beuno> it should re-pack it to optimize it's size
[13:22] <beuno> right, I hear that's the current trade off
[13:22] <ploum> is there any risk to run bzr reconfigure --standalone ?
[13:22] <ploum> what will it do, exactly ?
[13:22] <beuno> but, to be honest, I stopped having memoery problems when upgrading 2a, so I'm not sure how true that is
[13:22] <beuno> ploum, it should create a standalone branch
[13:22] <beuno> as I understand it, there's close to zero risk
[13:22] <beuno> as usual, backup, etc
[13:26] <ploum> on the server, I did bzr reconfigure --standalone then bzr pack in one of the repository
[13:26] <ploum> now, pushing to it from an existing branch craches bzr
[13:28] <ploum> ah ok, it was just a permission problem
[13:28] <ploum> repacking as root, I have to chown everything to www-data
[13:30] <beuno> yeah, root is always trouble
[13:30] <ploum> yep but www-data has no shell on the server
[13:31] <ploum> so, it works
[13:31] <ploum> do you believe it makes sense to make every repository a standalone one with this method ?
[13:31] <ploum> and (I ask a lot ;-) )
[13:32] <beuno> well, if they don't share revisions, then it doesn't make sense to have a shared repo
[13:32] <ploum> how can I change the repo so, from now, every new repository pushed to the repository is automatically a standalone one
[13:32] <beuno> not 100% sure that can have such a large impact on performance, but I wouldn't be surprised if it did
[13:33] <beuno> to do that, you will need to completely remove the shared repo, as bzr will look for it whenever you push
[13:33] <beuno> be sure that all the branches are standalone before removing it
[13:33] <beuno> (and that they work properly)
[13:33] <ploum> ok
[13:33] <ploum> simply removing the .bzr folder is enough ?
[13:34] <beuno> yeap
[13:34] <ploum> nice
[13:34] <ploum> very informative talk
[13:34] <ploum> thanks a lot
[13:34] <beuno> glad it helped
[14:01] <ploum> is there a way to delete the history of a repository ?
[14:02] <ploum> I've some old repositories with heavy changes in binary files but I'm not interested anymore in the history
[14:03] <gioele> ploum: bzr fast-export and bzr fast-import --filter (available in a separate plugin)
[14:06] <beuno> ploum, me aware that such a change will make existing branches incompatible
[14:06] <beuno> so make sure nobody has an existing branch if you're going to re-write history
[14:06] <ploum> understood
[14:06] <ploum> it makes sense
[14:07] <ploum> but it's the case here
[14:07] <ploum> in the case of one of our branch that was used by a student to store big binary files
[14:34] <spiffyte1h> Does anyone know of a Debian Stable backport for a newer version of bzr-svn?
[14:34] <spiffyte1h> The version in the Stable repo has a critical bug.
[14:36] <vila> spiffyte1h: you want jelmer for an answer, providing version numbers for what you found may help him though
[14:37] <vila> spiffyte1h: Or maybe LarstiQ is aware of the available debian versions and packaging policies...
[14:42] <spiffyte1h> jelmer, LarstiQ: Debian Stable ships with bzr-svn version 0.4.10-2, which has a critical bug (see bzr-svn bug #343543, Debian bug #496164). the bzr-svn ticket indicates that newer versions of bzr-svn resolve the issue, and I'd like to find a .deb package to upgrade with.
[14:43] <spiffyte1h> Ooooo, that's nice.
[14:44] <vila> ubottu: good bot, have a cookie
[14:47] <gioele> ubottu: so you prefer chips to cookies, don't you?
[14:49] <jam> mroning vila
[14:49] <vila> hi jam !
[14:49] <jam> did you check if my 64-bit patch fixed buildbot for you? (It should be in bzr.dev now)
[14:51] <vila> jam: I'm running a bunch of runs on babune now if only because installing pyrex on tiger and leopard trigger the leaking-tests bugssss
[14:51] <jam> really...
[14:51] <vila> jam: go figure....
[14:51] <jam> because they actually start running the tests?
[14:51] <jam> or because that triggers the bug?
[14:52] <vila> jam: not sure exactly yet, I'm searching for a revision old enough and still passing the whole suite
[14:52] <jam> there may be a significant bug in the new "SimpleSet" code.
[14:52] <jam> I'm seeing some weird stuff trying to do a full 'bzr branch'
[14:53] <vila> my gut feeling is that running with the extensions compiled on OSX brings more tests, change the way they are split, trigger the leak bug, nothing SimpleSet realted
[14:53] <jam> vila: k, I just wonder if I have a stray pointer somewhere
[14:53] <jam> which can cause all sorts of undefined behavior
[14:53] <vila> yeah :-/
[14:54] <vila> jam: so far, hard(32), jaunty(64), karmic(64), gentoo(??), freebsd8(64) passed the full test suite
[14:54] <vila> hardY
[14:55] <awilkins> Ok, weird bug
[14:55] <vila> err, freebsd8 is still running
[14:55] <vila> awilkins: no thanks, I have ,u share already
[14:55] <awilkins>  - I have a file in my tree and bzr has decided that if it's x-bit is set, then it was originally unset, and that's a diff
[14:56] <awilkins> But if you clear the x-bit, it then thinks that it should be set, and that's also a diff
[14:56] <awilkins> So you can't win. Every time you revert the file it flips the x-bit and still thinks it's been flipped afterwards
[14:56] <jam> awilkins: do you know what version of bzr you have? (and what platform)
[14:56] <vila> awilkins: that vaguely rings a bell, I'm sure it should ring one for bialix or jam too...
[14:57] <jam> I remember that behavior with really old versions of bzr on win32
[14:57] <awilkins> jam: bzr 2.0.0 ubuntu jaunty
[14:57] <jam> and that would just be weird
[14:57] <awilkins> The one thing I can think of is the file name is fairly unusual in that it has a comma in it
[14:58] <awilkins> That sounds pretty tenuous though
[14:59] <awilkins> No idea why all the x-bits are turning up flipped in here anyway, unless someone is using bzr on a posix machine accessing a FAT32 partition
[14:59] <awilkins> Not using any plugins that claim to handle xbit myself
[14:59] <awilkins> ls
[14:59] <awilkins> oops
[15:00] <awilkins> Still does it without plugins
[15:01] <vila> awilkins: waitaminute you're seeing that on jaunty ?
[15:01] <awilkins> vila: Yes
[15:01] <vila> awilkins: then you can look at the x bit with 'ls -l' and check whether it has changed or not
[15:01] <vila> if it keeps changing, *someone* or *something* is changing it, but not bzr
[15:02] <awilkins> Colours say that they are all set in this folder
[15:02] <awilkins> They have no reason to be set
[15:02] <awilkins> Now, they came from an SVN repo, so I'll check the x-bit props on the original branch
[15:02] <awilkins> All these files are DITA resources
[15:03] <vila> s/D/P/ ? :D
[15:03]  * vila has no idea what DITA means otherwise...
[15:03] <awilkins> First time I didn't know what it was and got a lot of nice videos of an attractive lady in a giant martini glass
[15:04] <awilkins> It's one of the multitude of XML documentation authoring frameworkds
[15:06] <awilkins> Ok... SVN has not got their x-bits set
[15:06] <fullermd> Ah, so 'P' is right then.   :p
[15:07] <awilkins> That's really rather annoying
[15:07] <awilkins> ONE of the files in this folder has no x-bit
[15:07] <awilkins> All the others do. One of the files is doing this "flip" thing
[15:08] <vila> fullermd: hi !
[15:09] <vila> fullermd: there was rumors about vim on freebsd8 not being recent enough for its fans.... a bit chinese for me so I promised to ask you about that :)
[15:12] <fullermd> Well, it's currently at patch 239...
[15:12]  * fullermd checks vim.org.
[15:13] <fullermd> So 267 is the current patch.
[15:14] <fullermd> 239 was from July.  David usually updates the pl every few months or so...
[15:15] <vila> hmm, strange, it looks like vim wasn't installed.... may be "they" used vi instead ?
[15:16] <vila> thanks for checking anyway
[15:16] <fullermd> Well, the base system 'vi' is nvi, not vim.
[15:16] <fullermd> So, I guess you could say it's a really old vim maybe   :p
[15:19] <awilkins> This x-bit thing is a real bug methinks
[15:20] <awilkins> I'm getting the impression that one particular inventory item is causing the global xbit state to flip.. and thereafter the xbit gets set for the rest
[15:21] <awilkins> or maybe it's horrible disk corruption...
[15:21] <fullermd> Always think positive   :)
[15:22] <fullermd> "Hey, these new light bulbs are pretty bright...   or maybe the sun's just going supernova."
[15:22] <awilkins> I have a bad history with USB drive controllers
[15:22] <awilkins> They last a few months and then go phut
[15:22] <awilkins> All the ones I've bought use the chipsets from the same manufacturer when you look inside
[15:23] <awilkins> However, the rest of my system is running off the same drive and isn't dead yet...
[15:23] <awilkins> A fresh checkout seems better
[15:24] <awilkins> Or not
[15:24] <awilkins> Lots of x-bits still
[15:24] <awilkins> Where none are warranted
[15:25] <awilkins> Oh boo, maybe I'm wrong
[15:25] <awilkins> They are set in SVN
[15:25] <awilkins> Just my lame-ass SVN gui client that doesn't display the properties in a grid properly
[15:25] <vila> still a bug, different target :)
[15:26] <awilkins> The flipping thing was weird
[15:26] <vila> but came from the svn side right ?
[15:26] <awilkins> I don't know
[15:27] <awilkins> I don't think it should happen that it considers the original  xbit value to be the opposite value of what's present
[15:27] <awilkins> I don't think the svn:executable property takes "heisenberg" or "schroedinger" as a parameter
[15:28] <fullermd> You'll never know 'till you take it out of the box.  And then it's too late to set it.
[15:28] <ploum> hello
[15:28] <ploum> does loggerhead now includes smart-server ?
[15:28] <awilkins> I can't build this damn source anyway... the author has made it depend on a whole toolchain on his machine and not mavenized it properly. Git.
[15:28] <awilkins> so that was a charming and joyful waste of an hour
[15:29] <jam> ploum: you can always try it and see... :) but last I checked they had not hooked up calls to .bzr/smart
[15:29] <fullermd> Well, it took me longer than that to get Mosaic running the other month   :p
[15:29] <awilkins> The xbit flipping thing is now happening in the other branch too.
[15:29] <fullermd> So really, you're ahead.  Sorta.
[15:29]  * awilkins curses
[15:30] <awilkins> ls
[15:30] <ploum> jam: because the bug is closed but I can make it work
[15:30] <jam> ploum: "can't" ?
[15:30] <awilkins> AHAHAHAHAHAHAHAH
[15:30] <awilkins> I think I've got it
[15:30] <awilkins> Maybe
[15:30] <awilkins> Ah, might be my fault
[15:31] <awilkins> I ran a "link files to save space" script on this folder
[15:31] <awilkins> And I think it's linked some files that have an x-bit to some files that don't
[15:31] <awilkins> Hardlinked, that is
[15:32] <awilkins> You clear the x-bit on a file that's linked in another folder, and it pops up in the next one
[15:32] <awilkins> Stupid number of x-bit for files that are resources though
[15:32] <jam> ploum: it looks like there might be something if you do "bzr serve --http" w/ loggerhead 1.17 or so
[15:32] <jam> but I'm not user if that also does the smart server
[15:33] <fullermd> Data compression.  You can use the x bit as an overflow to save a bit in the file contents.
[15:33] <ploum> jam: indeed, can't ;-)
[15:34] <jam> looking at it, I don't see it actually setting up the rpc stuff
[15:35] <jam> ploum: well, nm, it is there
[15:35] <jam> def app_for_bazaar_data(self, relpath):
[15:35] <jam>     if relpath == '/.bzr/smart':
[15:35] <jam>         wsgi_app = wsgi.SmartWSGIApp(self.transport)
[15:35] <jam>         return wsgi.RelpathSetter(wsgi_app, '', 'PATH_INFO')
[15:36] <ploum> but I'm using loggerhead through an apache proxy
[15:36] <ploum> maybe it's related
[15:37] <ploum> I was also wondering how you could have permission support in loggerhead
[15:38] <jam> ploum: Are you using loggerhead 1.17?
[15:38] <ploum> 1.17-0ubuntu1
[15:38] <jam> second, from the places I've been able to trace, it seems to always go to BranchesFromTransportServer, which handles smart requests
[15:38] <jam> (or thinks it does :)
[15:39] <ploum> (not sure I understand everything you are saying ;-) )
[15:39] <jam> ploum: The code looks like it should be handling '.bzr/smart' requests
[15:40] <jam> someone like beuno or mwhudson might know more
[15:40] <ploum> is there a need for any .htaccess in my repository ?
[15:47] <jam> ploum: so... once I actually got loggerhead to start, it indeed exposes smart requests
[15:47] <ploum> even through apache ?
[15:47] <jam> the specific problem *I* had was that inside their code base
[15:47] <jam> 'import loggerhead' worked
[15:48] <jam> but 'import loggerhead.apps.branch' did not (from a subdir)
[15:48] <jam> ploum: doing 'bzr serve --http"
[15:48] <jam> presumably from apache you just redirect requests to a given ":80/URL" to ":8080/"
[15:49] <jam> beuno: When you get a chance, I'd like to help debug why loggerhead wouldn't "just work" for me.
[15:49] <ploum> yes, that's what I'm doing
[15:49] <ploum> # Loggerhead proxies.
[15:49] <ploum> RewriteRule ^bzr2/(.*)$ http://localhost:8080/$1 [L,P]
[15:52] <beuno> jam, hi
[15:52] <beuno> jam, what's up?
[15:52] <jam> beuno: https://bugs.edge.launchpad.net/loggerhead/+bug/451335
[15:53] <jam> basically, from inside 'bzrlib.plugins.loggerhead/__init__.py"
[15:53] <jam> "import loggerhead" seems to work
[15:53] <jam> but "import loggerhead.apps.branch" fails
[15:53] <jam> I'm guessing a subtle python2.6 breakage
[15:53] <jam> I'm running from bzr source and loggerhead in my $PLUGINS directory
[15:54] <beuno> jam, I think the LH plugin broke a while back
[15:55] <jam> anyway, if i change the line, the import fails, so it sets the path, and things work again
[15:55] <jam> I don't quite understand why just "import loggerhead" works
[15:55] <jam> my short guess is that python2.6 is trying to be somewhat compatible
[15:55] <jam> but fails at full backwards compatibilty for relative imports
[15:56] <jam> of course, my recommendation is to switch to absolute imports ... :)
[15:56] <jam> though I guess the code base is a bit divided
[15:56] <jam> between wanting to be a plugin
[15:56] <jam> and wanting to be a standalone app
[15:56] <jam> with the latter being the original code
[15:58] <ploum> must go
[15:59] <ploum> thanks for the chat and the informations
[16:04] <jam> beuno: maybe something like this: http://docs.python.org/whatsnew/2.6.html#pep-366-explicit-relative-imports-from-a-main-module
[16:05] <beuno> jam, can you see if it happens with 2.5 as well?
[16:05] <beuno> ah
[16:05] <beuno> that sounds like it's it
[16:07] <jam> I get stuff like: "No module named pkg_resources" I assume I need to install more of the dependency chain, etc.
[16:07] <jam> give me a bit
[16:07] <beuno> I thought we removed the deps on setuptools
[16:09] <jam> beuno: obviously not entirely
[16:09] <jam> I did see that commit
[16:09] <jam> I get the same failure w/ python2.5
[16:09] <jam> $ bzr serve --http
[16:09] <jam> bzr: ERROR: No module named loggerhead.apps.branch
[16:09] <jam> You may need to install this Python library separately.
[16:09] <jam> sorry
[16:09] <jam> well, the first line is wrong, but the rest is the same
[16:10] <beuno> I did see it break with a landing, I don't recall which
[16:10] <beuno> I think mwhudson knows about it
[16:10]  * beuno tries to remember what the issue was
[16:14] <jam> well, I can't run using bzr.dev with anything less than 386...
[16:15] <jam> with the 'bzr-2.0.x' branch, I get the same failure at revno 370
[16:15] <jam> and the first version that supports bzr-2.0.x is 368, also has the failure
[16:17] <beuno> jam, I'll try and look into it this afternoon. I'm sure I have a note *somewhere* about the problem and the potential fix
[16:17] <beuno> thanks for filing the bug
[16:17] <jam> beuno: well, IME the fix is as simple as updating the import line :)
[16:18] <jam> also, the original fix that jelmer did to 'avoid polluting sys.path' means that it probably actually runs the wrong version of loggerhead
[16:18] <jam> at least, it would run one from a different location.
[16:18] <beuno> jam, to what would you update it?
[16:18] <jam> 'import loggerhead.apps' is enough to trigger the bug
[16:18] <jam> and get sys.path updated
[16:19] <jam> the alternative is to just *always* update sys.path
[16:19] <jam> well, *an* alternative
[16:23] <beuno> jam, as in every __init__?
[16:23] <beuno> sys.path.append(os.path.dirname(__file__))
[16:24] <vila> jam: so it seems that bzr.dev pass the full test suite for freebsd8 after all but I can't find any revision passing for OSX (tiger & leopard), and I'm back to 1.16 :-/
[16:24] <jam> beuno: in 'serve_http'
[16:24] <jam> vila: ouch... but not *my* fault :)
[16:24] <jam> I thought you submitted quite a few patches for a clean test suite on OSX
[16:24] <beuno> jam, ah, so basically remove the try
[16:25] <vila> jam: not your fault at all, except for pushing me to install pyrex..
[16:25] <vila> jam: Oh yes, I fixed a bunch of visible issues, now I'm discovering new ones :-)
[16:26] <jam> *argh****
[16:26] <jam> PyObject_IsTrue(Py_NotImplemented) == TRUE
[16:26] <jam> bastards
[16:26] <vila> now that I started scratching that thread/socket leak bug, it's triggering all over the places, even where it was silent before, well know fact about vicious bugs that behaviour :)
[16:26] <jam> beuno: right
[16:30] <beuno> jam, we have 5 failing tests due to this same problem: http://paste.ubuntu.com/293202/
[16:30] <beuno> removing the import doesn't fix them
[16:31] <jam> beuno: that only triggers if you are running serve_http
[16:31] <jam> and why are you running 'nosetests' rather than
[16:31] <jam> bzr selftest -s bp.loggerhead
[16:32] <jam> I would at least think the latter would be the way to test loggerhead as a plugin
[16:32] <jam> ah, you know what
[16:32] <jam> the issue is that "." is called "loggerhead" *and* it has an __init__.py
[16:33] <jam> I bet when doing "import loggerhead.apps" it is trying to import higher up
[16:33] <jam> though in your case it is named 'trunk'
[16:33] <jam> so that wouldn't necessarily be it
[16:33] <jam> I don't know how nose sets the path, thuogh
[16:33] <jam> though
[16:34] <beuno> me neither. Imports make me dizzy, which is why I haven't addressed this yet  :)
[16:35] <beuno> if I remove the __init__.py on the root dir, the tests work just fine
[16:49] <jelmer> spiffyte1h: You should be able to use the package from testing
[16:49] <jelmer> spiffyte1h: it wouldn't be very trivial to get a fixed version in, we'd need to also upload subvertpy
[16:52] <spiffyte1h> jelmer: OK, thanks
[17:21] <phinze> alright, i've run into this problem so many times, that i've attempted to document it along with a couple of potential solutions
[17:22] <phinze> http://gist.github.com/210162
[17:22] <phinze> if anyone is willing to take a look and give me a "you're doing it wrong" with some advice, i would appreciate it muchly :)
[17:23] <luks> question in form of a blog post?
[17:23] <luks> :)
[17:23] <phinze> luks: well it turned into that
[17:23] <phinze> summary would be: how to handle directories shared across multiple branches of mainline development
[17:24] <phinze> perhaps 'mainline' is not proper term, perhaps 'heavy active'
[17:26] <luks> I'm not sure I understand the branch structure
[17:29] <luks> as long as I understand if, you are using bzr branches like a svn repository
[17:29] <luks> that is, you have several "projects" in one branch
[17:29] <phinze> luks: yeah sorta... mostly centralized development too
[17:30] <phinze> luks: ack i gotta run to lunch now -- back in ~1hr... :(
[17:30] <luks> ok, so that would be the "you're doing it wrong" point
[17:30] <luks> the best solution is to use one branch per project
[17:30] <phinze> luks: oh sorry no each project is it its own branch
[17:31] <luks> where the shared libraries should be considered separate projects
[17:31] <phinze> ahh
[17:31] <phinze> yes so that would be #3 below
[17:31] <phinze> but how do we pull the libraries in to BLUE and RED?
[17:31] <phinze> svn:externals is dead, no?
[17:31] <luks> bzr doesn't have a good built-in solution for that yet
[17:31] <luks> in svn I'd use svn:externals
[17:31] <phinze> yeah
[17:32] <luks> there is http://bazaar-vcs.org/ScmProj which might or might not work for you
[17:32] <phinze> ahh that looks interesting
[17:32] <phinze> i'll have a look at that this afternoon, thanks luks :)
[17:33]  * phinze zooms
[17:33] <luks> if you have a problem with scmproj, you can ask on the mailing list
[17:33] <luks> bialix (the author of scmproj) is usually active there
[17:36] <jam> phinze: the other possible solution is to have your developers *not* commit changes to BLUE at the same time they commit changes to SHARED_LIB-X
[17:36] <jam> so that 'bzr merge -c1001' can grab just the changes you want.
[17:36] <luks> jam: you would still have to cherry-pick
[17:36] <jam> luks: sure, but it would be a bit cleaner
[17:36] <luks> I expect that would turn bad eventually
[17:36] <jam> luks: I completely agree that separate projects is the $RIGHT way
[17:37] <jam> but it is not trivial to set up (yet)
[18:44] <eross> should I use sourceforge or launchpad for simple game development in ubuntu/linux and prob cross-platform? which represents the open source ideal better?
[18:46] <beuno> eross, for starters, Launchpad's full source code is open source
[18:46] <vila> eross: which one runs with open source ?
[18:47] <vila> beuno: That's cheating ! You shouldn't give the answers before the question !!
[18:47] <beuno> :)
[18:47]  * beuno always blows it
[18:47] <eross> thanks beuno, sorry vila.. i've got googly eyes :P
[18:55] <eross> oh gawd.. it tracks 'karma', i'm going to be so negative on my simple project
[18:57] <eross> have to purchase $250/year for a commerical project
[18:58] <beuno> yes, didn't you say it was for open source?
[19:00] <eross> yes but i like to twist the knife
[19:02] <beuno> then sure
[19:38] <jam> is there a losa around?
[19:38] <jam> like, perhaps, mthaddon ?
[19:40] <Chex> jam: hello I am around
[19:40] <jam> hi Chex. mthaddon just created a couple of pqm managed branches for me, but when I try to submit anything to them
[19:40] <jam> they seem to get blackholed
[19:40] <jam> I don't get an error
[19:40] <jam> but I don't see any progress, either.
[19:40] <jam> ah... maybe it just took a hile
[19:41] <jam> as I finally see something about 10min later...
[19:41] <jam> Chex: however, I submitted from a couple different places. Can you check if there are some failures in the log that I'm missing?
[19:43] <Chex> jam: can you give me a link to one of the branches, please? I am missing context
[19:43] <jam> lp:~bzr-pqm/bzr/2.0.1
[19:48] <jam> Chex: maybe it is just something weird about the email setup. As suddenly I'm seeing everything in the queue. But usually it takes <1min, and this time it took > 10
[19:49] <jam> Chex: anyway, you probably don't need to spend a lot of time on it. as things seem to be working. I just got a bit concerned, as I'm trying to get a release out.
[20:14] <mathepic> When you made a branch specifically for a bugfix and its merged now, should you remove it from LP if you don't think it needs any more development?
[20:18] <beuno> mathepic, I don't see any reason to
[20:18] <beuno> branches stack on launchpad, so they don't use up much space
[20:45] <jam> mathepic: also, the default view hides branches marked as 'Merged'.
[20:45] <jam> I generally don't bother deleting old things, especially since they might be useful later
[20:46] <jam> (tracking down a bug, etc.)
[21:03] <mathepic> k
[21:03] <mathepic> I'm giving -p to bzr mkdir
[21:03] <mathepic> When it adds, should it always use smart_add
[21:03] <mathepic> or only use smart_add if -p is enabled
[21:04] <mathepic> And same thing for adding the directories (always use os.makedirs or use os.mkdir if -p is not enabled)
[21:10] <mathepic> Oops, I need to check
[21:30] <jam> mathepic: I don't think you want 'smart_add' during makedirs because I *think* it adds all children, and you probably just want to add that one dir
[21:30] <jam> also, I would say "makedirs" is dangerous if you are intending to create only one entry.
[21:30] <jam> typos, etc.
[21:38] <mathepic> Can you take a look at the diff at https://code.edge.launchpad.net/~mathepic/bzr/mkdir-recursive/+merge/13380?
[21:38] <mathepic> Oh, your right
[21:38] <mathepic> Does add add recursively
[21:40] <mathepic> I checked the docs, apparently not
[21:40] <mathepic> Since it is working with "bzr mkdir", in theory, there wouldn't be any files in the directory anyway
[21:41] <mathepic> Because "bzr mkdir" fails if the directory itself already exists
[21:44] <mathepic> Oh wait, it won't work because if its multiple directories, then the files in the lower directories would be added as well
[21:45] <mathepic> is there any method in bzrlib that adds directories recursively but does not add the files?
[21:45] <jam> mathepic: tree.add(['dir', 'dir/subdir', 'dir/subdir/subdir'])
[21:45] <mathepic> So I just need to build that list myself in the code?
[21:49] <jam> mathepic: probably
[21:49] <mathepic> Question about smart_add: Does it add files in parent directories of the target subdirectory?
[21:49] <jam> you also don't want to add things that are already there
[21:49] <jam> smart_add does add parent dirs, IIRC
[21:49] <mathepic> Okay
[21:52] <mathepic> I'm looking at the smart_add code to try and find a way to do this - Is this the part where it finds all the parent dirs it needs to add?
[21:52] <mathepic>         # only walk the minimal parents needed: we have user_dirs to override
[21:52] <mathepic>         # ignores.
[21:52] <mathepic>         prev_dir = None
[21:52] <mathepic>         is_inside = osutils.is_inside_or_parent_of_any
[21:52] <mathepic>         for path in sorted(user_dirs):
[21:52] <mathepic>             if (prev_dir is None or not is_inside([prev_dir], path.raw_path)):
[21:52] <mathepic>                 dirs_to_add.append((path, None))
[21:53] <mathepic>             prev_dir = path.raw_path
[21:53] <mathepic> L429 in mutabletree.py
[21:53] <jam> mathepic: i think that is 'minimizing' the set of paths passed in, but I may be wrong "or_parent_of_any" makes me wonder
[21:58] <mathepic> The help of cmd_mkdir is that it is equivalent to constructing the directory and then adding it
[21:59] <mathepic> So therefore, is it possible that it SHOULD use smart_add since "mkdir DIR + bzr add DIR = bzr mkdir DIR"
[22:02] <mathepic> I just did a test - bzr add does not add files in parent directories of the target directory
[22:02] <mathepic> So therefore it should work fine
[22:27] <mathepic> Is there any particular reason why lazy_import generates an error when attempting to host a pydoc server over bzrlib?
[22:31] <venia> Ok, need to ask a quick question.
[22:31] <venia> I'm involved in a project on launchpad, pulled the code off and everything, made some changes.
[22:32] <venia> Now I go to push it back and it gives me this error: bzr: ERROR: RemoteRepository([...]) is not compatible with KnitPackRepository([...]) different rich-root support
[22:32] <venia> Any ideas how to fix that?
[22:38] <fullermd> Well, depends on which is which (I wish the error message told more details).  But probably the remote is RR and your local isn't.
[22:39] <fullermd> If that's the case, upgrade your local to a RR format (2a probably, unless the remote is on an older one)
[22:43] <mathepic> When making a blackbox test, what do I need to include in load_tests
[22:43] <venia> Thanks for the reply fullermd. So I just run 'bzr update --default-rich-root'?
[22:45] <bob2> --2a
[22:46] <venia> Ah, thanks
[22:46] <fullermd> venia: Yeah, that'll probably work.
[22:47] <fullermd> The potential downside is that if you go 2a and the remote is in a pre-2a RR format (1.9-rich-root, say), shuffling data between them could be slow.
[22:47] <fullermd> It's probably fairly likely that the remote IS 2a though.  If they made the poor->rich transition since you branched (otherwise you'd have a RR branch already), they probably went 2a.
[22:49] <venia> Wait, (I'm new to bzr) the project leader told me to get the code by doing a bzr pull. Was that wrong? If so, what was I supposed to do?
[22:50] <fullermd> Well, it's not obviously wrong.
[22:54] <venia> Sorry, but nothing is "obvious" to me right now. Still trying to get my head around bzr. Are there any decent starting documents out there? (I looked at the manual and it was so immense it made my brain hurt) :p
[22:56] <fullermd> Well, what you're "supposed to" do depends on what precisely you're trying to accomplish.  Without knowing the former, it's impossible to judge the correctness of means   :)
[22:56] <venia> Ah, gotcha. :)
[22:56] <fullermd> However, "pull" is how you (roughly speaking) update a mirror of code, so it stands a reasonable chance of being the correct thing to have done.
[22:56] <venia> Well, let me explain.
[22:56] <venia> I didn't have the code or the bzr repository.
[22:57] <venia> And I needed to get them. So I used pull.
[22:57] <fullermd> No, you didn't, 'cuz that wouldn't work.
[22:57] <venia> (which apparently something didn't sink or was changed on the server)
[22:57] <fullermd> You used branch.
[22:57] <venia> sync*
[22:57] <fullermd> (pull only updates, it won't create)
[22:58] <venia> I'm pretty sure--oh.
[22:58] <venia> In my naive-ness I must have 'bzr init' then done a 'bzr pull'
[22:58] <venia> Which probably cause those errors, correct?
[22:59] <fullermd> No, not really.
[22:59] <fullermd> When you 'branch', it uses [some of] the format[s] of the remote branch to determine the local formats (in this case, the repository format).
[22:59] <venia> Alright.
[22:59] <fullermd> Well..  wait.  Maybe I'm...   mmm...
[23:00] <fullermd> Alright, let's stop guessing.  What format does 'bzr info' say your local branch is in?
[23:00] <mathepic> Can someone help me with making a blackbox test for Mkdir?
[23:01] <mathepic> I have the functions written out
[23:01] <mathepic> I just need the load_tests()
[23:01] <mathepic> Whatever
[23:02] <jam> mathepic: you probably don't need a 'load_tests' function, just add the 'test_mkdir.py' to blackbox/__init__.y
[23:02] <jam> lifeless: are you around?
[23:02] <venia> fullermd: Which version thing? It has 3.
[23:03] <jam> lifeless: I'm on my way out... pqm tests seem to be running slow (about 2hrs to run 2.0.1's test suite). ISTR something about /tmp getting full on that machine, does it ring a bell?
[23:03] <fullermd> venia: Just the rollup name from the first line.
[23:03] <fullermd> venia: Unless it's 'unknown', of course.  In that case, the Repo format is probably enough.
[23:04] <venia> repository: Packs containing knits with rich root support
[23:04] <venia> That the one?
[23:04] <fullermd> Huh.  That's weird.  You must have specified a --format to 'init'; no rr pack format was ever the default.
[23:05] <fullermd> OK, so the problem is the other way around; you've got a rich root repo, and the remote doesn't.  That's uglier.
[23:06] <venia> So what are my options? To upgrade the server (probably to be avoided at all costs even if even possible) or to start over?
[23:06] <fullermd> venia: So the basic issue is that you can't put rich-root revisions in a poor-root repo.
[23:07] <fullermd> So you'd need to either get the remote side moved to RR (which WILL happen sooner or later, but they may not be ready to do right now), or recreate your revs in a poor-root repo.
[23:07] <venia> My revisions will be easy, I didn't do much actual editing, just added some files
[23:08] <venia> So to proceed from here I actually do the 'bzr branch' thing?
[23:09] <venia> And then move my files over?
[23:09] <mathepic> I've been running the development bzr directly with bzr.py in my bzr.dev directory
[23:09] <mathepic> But I just tried to selftest
[23:10] <mathepic> bzr: ERROR: exceptions.ImportError: cannot import name user_encoding
[23:10] <mathepic> It works fine on bzr 2.0
[23:11] <lifeless> jam: we've had various things; /tmp is in a chroot, but its still worth checking.
[23:11] <lifeless> jam: we haven't had a repeated 'X makes it slow and happens repeatedly' though - we've fixed each occurence completely each time.
[23:11] <fullermd> venia: Yah.
[23:12] <venia> fullermd: Alright, thanks I think that answers my question :)
[23:13] <venia> Oh, one other thing. What's the difference between checkout and branch?
[23:14] <fullermd> A checkout is a working tree (which is hooked to a branch somewhere).  A branch is...   well, a branch.
[23:14] <fullermd> So the difference is whether your changes are made on the existing branch, or on a new one.
[23:14] <venia> Ok.
[23:15] <venia> Switching computers really quickly
[23:17] <venia> Alright, back, sorry about that.
[23:18] <venia> So a checkout it linked, say the remote server and all commits go straight to it?
[23:19] <venia> Whereas a branch is a copy of whatever is on the remote server and your commits to your copy, then you 'push' them to the remote server, correct?
[23:20] <fullermd> That's a way of looking at it, yah.
[23:21] <fullermd> When you run 'branch', what you [generally] get is a branch, and a colocated checkout of that new branch.  When you run 'checkout', you get a local checkout of the remote branch ('remote' may just mean somewhere else on the local filesystem of course).
[23:21] <venia> So I guess what had me confused was branches as the command, and branched as the launchpad thing.
[23:22] <fullermd> So any time you run 'commit', you're technically doing it in a checkout, not a branch; and the new rev goes into the branch that checkout points at, whether it be right-there or off-somewhere.
[23:22] <mathepic> checkout = centralized, branch = distributed.
[23:23] <venia> I see now.
[23:23] <venia> So what's the benefit of using either way?
[23:23]  * jelmer hugs spiv
[23:23] <jelmer> ~ expansion in bzr+ssh URLSs \o/
[23:24] <fullermd> Well, that you use the means what fits what you're trying to do   ;)
[23:25] <venia> Ah. Makes sense. :)
[23:25] <fullermd> Checkouts can certainly be used for all sorts of setups, but the most common (and mathepic alluded to) is a centralized dev style, where multiple people work on a single branch.
[23:25] <spiv> jelmer: :)
[23:25] <venia> Thanks, this discussion has enlightened me much more than 10's of manuals and technical documents. :p
[23:25] <fullermd> (everybody just has their own checkout; it's just like working with CVS/SVN)
[23:26] <venia> Ah, gotcha.
[23:26] <mathepic> Benefit of using branch is that you don't have to waste time with net connections and such
[23:27] <venia> So just to clarify this again, a when you commit and push a branch, it goes straight to the original, correct?
[23:28] <fullermd> Mmm.  Kinda.
[23:28] <fullermd> I'd avoid thinking in terms like "original"; it biases you toward thinking of a hierarchy of some sort.
[23:28] <venia> Ok, the "trunk" I think they call it.
[23:28] <fullermd> Which is perfectly correct socially, but meaningless technically.  Technically, all branches are peers.
[23:29] <fullermd> 'push' takes revs from one branch and stuffs them into another.  Usually, the 'one' is a local branch you're in [a checkout of], and the other is a branch "off somwhere".
[23:29] <venia> I'm really getting tempted to write a bzr for utter newbies right now. :p
[23:30] <fullermd> And it can be common to 'branch' from one place, 'commit' some changes, and then 'push' back to the same place.  But it's far from the only place you might push, so...
[23:30] <fullermd> Give in to temptation.  It might not pass your way again.
[23:31] <venia> Yeah. It'd be helpful, but I've got NO experience writing docs.
[23:31] <fullermd> That's too ba...   hey, I just thought of a neat way you could get some experience writing docs!
[23:32] <venia> So if you have a fork (that's what they're called right?) how do you get changed from one to the trunk?
[23:32] <venia> Uh-oh! 0.o
[23:32]  * venia looks for a place to hide.
[23:32] <venia> Err, get the changes*
[23:33] <fullermd> Not quite sure I'm parsing the question...   ah.
[23:33] <fullermd> So phrase it as "How can I see the differences between one branch and another".
[23:33] <venia> And move those changes between branches.
[23:33] <fullermd> The answer is probably 'missing', which shows you which revs each branch has that the other doesn't.
[23:33] <fullermd> (possibly, you might mean 'diff', looking at the actual textual differences between branches, but you probably mean 'missing')
[23:34] <venia> Sorry, sometimes my typing/grammar skills aren't up to par, especially when I'm tired.
[23:34] <venia> Gotcha.
[23:34] <fullermd> As for shuttling the changes amongst branches, the general ways are 'push', 'pull', and 'merge'.
[23:35] <fullermd> I did a big elaboration on that a few weeks ago here...  I should really pull it out of my logs and stick it somewhere to reference.
[23:35] <venia> Gotcha, so you can push and pull between repos's? I'll have to look the syntax up on that.
[23:35] <venia> Yeah, totally.
[23:35] <venia> Bazaar has a wiki, right?
[23:35] <fullermd> Don't really have time now, though; I've got a lot of work to try and get done tonite   :|
[23:36] <fullermd> Yah.  Not quite sure how to directly hit it since the new site was rolled out though, other than by knowing a URL that's on it.
[23:37] <venia> I'll probably look around and maybe start building "For Newbs" document
[23:37] <venia> Best way to learn is by doing! :)
[23:37] <venia> That's fine, I know the feeling of a crunched schedule. School does that to me. =\
[23:38] <venia> Thanks for the help!
[23:38] <fullermd> Ask me again in a week or so, hopefully I can find time to at least C&P the logs somewhere.
[23:38] <venia> Sure.
[23:38] <fullermd> (it's the best way, really.    Win-win  8-)
[23:39] <venia> Hehe. Totally.
[23:40] <venia> Anyway, again, thanks for the help, now I need to go get my fixes up!
[23:52] <igc> morning
[23:54]  * fullermd waves at igc.
[23:54] <mathepic> Hi.
[23:54] <igc> hi fullermd, mathepic
[23:55] <fullermd> igc: I forwarded some notes on that review to the list; make sure I didn't misrepresent your position.
[23:55] <igc> ok
[23:55] <fullermd> (I'm all scatterbrained today  :|)


[01:13] <RichW> I get "internal server error" with http://bazaar.launchpad.net/~richies/hypernucleus-server/PylonsPort/revision/3
[01:13] <RichW> help me please :)
[01:14] <thumper> RichW: hi
[01:14]  * thumper looks
[01:14] <RichW> thumper, hi thumper
[01:15] <RichW> is this right channel for launchpad explosions?
[01:15] <thumper> yes it is
[01:15] <thumper> although unfortunately there isn't a lot I can do right now
[01:15] <thumper> the admins are meeting in europe for a sprint
[01:15] <RichW> quite ironic how its called laundpad and it crashed haha
[01:15] <RichW> launchpad*
[01:15]  * thumper smiles
[01:17] <RichW> I graduate with software engineering couple years maybe one day i can iron these bugs lol
[01:18] <thumper> RichW: you don't have to wait
[01:18] <thumper> :)
[01:18] <thumper> we have had several people help with the codebase while still at uni
[01:18] <RichW> oh yeah they open sourced it
[01:19] <RichW> i'd need some way of finding the traceback
[01:20] <thumper> RichW: with the next rollout (Thursday) we add OOPS handling to the code browser
[01:20] <thumper> which will give tracebacks
[01:20] <thumper> (to developers)
[01:20] <RichW> wow! impressive. I could just download a local copy and hack away :)
[01:20] <RichW> oh I see
[01:20] <RichW> devs only
[01:21] <thumper> RichW: ?
[01:21] <RichW> You guys use zope, I use pylons normally, is it pretty similar?
[01:21] <thumper> what I mean is that the traceback will be shown to members of the launchpad developer team
[01:21] <thumper> others will just get an OOPS id
[01:21] <thumper> but if running locally
[01:21] <thumper> you'll be able to see the traceback
[01:21] <thumper> I don't know pylons
[01:22] <RichW> oh yeah fair enough :)
[01:22] <thumper> but zope has lots of weirdness
[01:22] <thumper> RichW: I don't see anything wrong with your branch
[01:22] <thumper> it is likely that the codebrowser has wandered off into lala land
[01:22] <thumper> and needs to be shot
[01:22] <RichW> It has happened before
[01:23] <RichW> and that time a guy fixed it in about 10 minutes
[01:23] <thumper> it would have been fixed by one of our admins
[01:23] <RichW> yes
[01:24] <RichW> 2GB ppa! wow
[02:16] <micahg> thumper: still here?
[02:16] <thumper> aye
[02:16] <micahg> there seems to be a stuck builder or 2
[02:16] <micahg> https://edge.launchpad.net/builders/terranova
[02:17] <micahg> https://edge.launchpad.net/builders/shipova
[02:18] <micahg> make that 3: https://edge.launchpad.net/builders/lemon
[02:30]  * thumper wanders around blindly looking for someone who has the ability to shoot stuck builders
[02:32] <jmarsden> LOSA ^^
[02:33] <jmarsden> thumper: That issue of stuck builders has been around for a couple of days now, on and off... something is strange with the build farm.
[02:34] <thumper> jmarsden: yeah, I'll make sure I tell bigjools when he gets up, also the LOSAs are sprinting this week, so no-one is around right now
[02:42] <micahg> thanks thumper
[02:48] <wgrant> jmarsden: It's actually unrelated to the issues over the weekend.
[02:48] <wgrant> Just some unhappy builder hardware, by the look of things.
[02:49] <jmarsden> wgrant: Fair enough... quite a coincidence, the builders seem (from my casual PPA user perspective) to generally be very reliable.
[02:50] <wgrant> They're not too bad, but the few problems that do appear can stack up when nobody's around to fix them.
[03:23] <wyh> hi there. is the po file uploading problem solved now?
[03:25] <lifeless> what problem ?
[03:27] <wyh> lifeless: I see there's an email in the mailing list mentioning  that. but I didn't care much.
[03:27] <wyh> lifeless: will it work properly if I upload a po file?
[03:28] <lifeless> I'm not aware of a system issue, - nothing in /topic
[03:28] <wyh> lifeless: so, where to post this topic?
[03:29] <lifeless> I don't understand the question
[03:29] <wyh> lifeless: who should I ask for help?
[03:30] <lifeless> what help do you need ?
[03:30] <wyh> lifeless: I just wonder if uploading po file works fine now
[03:31] <lifeless> what happened when you last uploaded one?
[03:31] <wyh> lifeless: and whether it will be properly merged
[03:33] <wyh> lifeless: eh, nothing. I just saw a bug announcement in the mailing list about it. I don't use uploading frequently recently
[03:33] <lifeless> wyh: Like I say, I'm not aware of a system wide issue at the moment.
[03:33] <lifeless> If there was an announcement, it should have instructions about when to do things again, or the bug that they referenced. I suggest re-reading the announcement.
[03:34] <wgrant> I don't recall seeing such an announcement recently.
[03:35] <wyh> lifeless: yes, but I thought there's some one in this channel to tell me clearly whether its fixed.
[03:37] <wyh> well, if no one knows, I'll re-read the mail. Thank you all.
[03:38] <nigelb> that was strange.
[03:38] <wgrant> That was.
[03:38] <lifeless> yes
[03:49] <nigelb> I hate it when loggerhead gives me "Internal server error"
[03:49]  * nigelb stabs F5
[03:49] <johnnie_> so i'm not the only one?
[03:49] <wgrant> It seems to be down at the moment.
[03:50] <wgrant> And the sysadmins are all in Europe this week.
[03:50] <nigelb> Ah, IS sprint!
[03:53] <ajmitch> so this will be the week when everything falls over
[03:54] <wgrant> ajmitch: And we even have an LP upgrade to help things along :)
[03:54] <ajmitch> that'll go smoothly, I'm sure :)
[03:54] <nigelb> heh.
[03:54] <wgrant> An LP upgrade with big recipe build schema changes, too.
[03:54] <nigelb> Which is a good thing in itself, unless it breaks everything else.
[04:00] <zubin71> hi, which all version control systems are supported at launchpad? just bzr?
[04:01] <zubin71> I could'nt find any details, so I guess its only bzr as of now
[04:01] <nigelb> for code hosting, yes.  bzr.
[04:01] <zubin71> are there plans to include other version control systems too?
[04:01] <zubin71> (just curious)
[04:01] <lifeless> lp can import from most VCS systems into bzr for you
[04:02] <zubin71> ok, thanks nigelb lifeless !
[05:47] <harpreet> ursinha, matsubara, garyposter, bac : Hi Gud morning
[05:48] <harpreet> ursinha, matsubara, garyposter, bac : I have problem while logging in to launchpad, can any one please help me.
[05:49] <harpreet> this is the error which I get http://dpaste.com/226498/
[05:58] <thumper> harpreet: there seems to be something wrong with the account
[05:59] <harpreet> thumper: can you please guide me on how to fix it OR get it fixed...
[06:01] <thumper> harpreet: Have you changed the email address linked to your account recently?
[06:01] <thumper> harpreet: I'm not sure what is causing the issue
[06:03] <harpreet> thumper: not recently but yes have changed, it used my 1 id as defult i changed it to the other
[06:04] <thumper> when did you change it?
[06:04] <harpreet> sorry dont rememeber exactly when  :-(
[06:05] <harpreet> thumper: but now it is allowing me to change it back to the old id, but gives same error with that also.
[06:05] <wgrant> thumper: Have you merged one of your accounts into another?
[06:06]  * thumper has to run out to collect people
[06:06] <harpreet> wgrant: not merged, but i used this second id to another account which was almost dead for me, so released this id from that account attached it to this current account and deleted the dead account
[06:07] <wgrant> harpreet: By 'id' do you mean 'email address'?
[06:07] <harpreet> wgrant: yes
[10:13] <wgrant> [A2
[10:28] <geser> someone an idea why http://launchpadlibrarian.net/52599395/buildlog_ubuntu-maverick-armel.opendrim-lmp-battery_1.0.0-0ubuntu1_MANUALDEPWAIT.txt.gz is correctly marked as DEPWAIT while http://launchpadlibrarian.net/52805733/buildlog_ubuntu-maverick-powerpc.opendrim-lmp-battery_1.0.0-0ubuntu1_FAILEDTOBUILD.txt.gz is marked as FTBFS (for the same reason)?
[10:29] <geser> is it perhaps because the output has changed slightly?
[10:29] <wgrant> Indeed.
[10:30] <wgrant> Easy enough fix.
[10:30] <wgrant> Can you file a bug?
[10:30] <wgrant> I'll get it done tonight.
[10:30] <geser> sure, against launchpad-buildd?
[10:30] <wgrant> Yep.
[10:42] <geser> wgrant: bug #615286
[11:11] <Whistler36> just created account & created SSH key using PuTTYGen. SSH-2 RSA 1024 bits. Can't get Launchpad to accept key.
[11:15] <spiv> Whistler36: the key needs to be in OpenSSH's format; I think that's the -L option for the puttygen command line tool.
[11:16] <Whistler36> ok. I exported the key using the menu option in puttygen as openssh. In the file the key is marked private.
[11:16] <spiv> Launchpad needs the public key, not the private key.
[11:17] <spiv> Only you need the private key :)
[11:17] <Whistler36> ok
[12:41] <micahg> did the subscribers box disappear?
[12:43] <micahg> deryck: ^^
[12:44] <deryck> micahg, shouldn't have.  Can you point me at a bug where's it not there?
[12:44] <micahg> deryck: all of them for me
[12:44]  * micahg wonders if it's my browser
[12:44] <deryck> micahg, hmmm, yeah, I have a subscribers box on every bug I look at.
[12:45]  * micahg tries in another browser
[12:46] <deryck> even looking at some ubuntu bugs with lots of duplicates and subscribers the lists appear fine.  a little slower to load, obviously.
[12:46] <micahg> deryck: yeah, seems to be something in FF, let me try a clean profile
[12:47] <micahg> deryck: sorry for the noise, seems to be bad cache data in my browser
[12:48] <deryck> micahg, no worries.  Better to ask an be sure.
[12:48] <deryck> s/an/and/
[12:53] <czajkowski> is mrevell on hols?
[13:12] <micahg> deryck: I figured it out, it was my user agent (was set to IE8 -- was testing something last night)
[13:13] <nigelb> micahg: so full of fail to use IE
[13:13] <nigelb> micahg: also, how did you do that?
[13:13] <micahg> nigelb: user agent switcher extension
[13:17] <nigelb> micahg: thanks :)
[13:20] <deryck> yeah, there is a quite different experience of lp with IE than FF or Chrome.
[14:15] <jemadux> i have one serious problem w/ my acc in launchpad
[14:15] <jemadux> Launchpad requires a REFERER header to perform this action. There is no REFERER header present. This can be caused by configuring your browser to block REFERER headers.
[14:15] <jemadux> Unblock REFERER headers for launchpad.net and try again, or see the FAQ Why does Launchpad require a REFERER header? for more information.
[14:15] <jemadux> You can also join the #launchpad IRC support channel on irc.freenode.net for further assistance.
[14:53] <abhijit> hello
[14:53] <abhijit> if anyone wishes to contact me through launchpad then does he must have launchpad account?
[14:56] <beuno> abhijit, yes
[14:57] <abhijit> beuno, ok
[15:00] <abhijit> beuno, thanks. bye
[16:56] <proppy> bug #1 broken ? https://launchpad.net/ubuntu/+bug/1 (I get an OOPS)
[16:57] <proppy> oh, now it's ok
[16:57] <proppy> sorry for the noise
[17:43] <salgado> Launchpad encountered an error during the following operation: generating the diff for a merge proposal.  The source branch has pending writes.
[17:44] <salgado> I'm getting that (via email) for all merge proposals I create
[17:44] <salgado> rockstar, do you know if there's anything wrong with diff generation?
[17:44] <rockstar> salgado, that's a known bug.
[17:44] <rockstar> salgado, wait, for ALL of them?
[17:45] <rockstar> salgado, https://bugs.edge.launchpad.net/launchpad-code/+bug/612171 Is this what you're experiencing?
[17:45] <salgado> I've created two mps for two distinct branches and got that in both occasions
[17:45] <rockstar> salgado, hm, I wonder if there's a race somewhere.
[17:46] <rockstar> salgado, please comment on the bug.
[17:46] <salgado> sounds like it, but why would my branch have pending writes?
[17:47] <rockstar> salgado, are you pushing before you send the merge proposal via email+
[17:47] <salgado> yes
[17:48] <rockstar> salgado, hm, there might be another of those requestMirror bugs we've had since eliminating the hosted area.
[17:52] <salgado> rockstar, when it happened earlier I resubmitted my proposal and even then it wasn't able to generate the diff
[17:52] <rockstar> salgado, that's very odd.
[18:00] <cperrin88> Hey, is someone here familiar with how launchpadlib handels the WADL files. Does it download the whole root file at first?
[18:05] <cperrin88> Very talkative chat ^^


[03:02] <troughton> i have perchased a compaq presario v6000 but i am having nothing but dificulty getting it to work the touch pad mouse seems to have a mind of its own can anyone help ?
[03:15] <SpacePuppy> wow.. he stayed 4 whole minutes. must be a record!!
[05:54] <RMorris84> i did a apt-get update/dist-upgrade, and when i rebooted, my wireless didnt work and when i clicked the monitor it said: SIOCGIFFLAGS error: No such device, what do i need to do? i couldnt find any help on the forums
[01:11] <troughton> i have just perchased a compaq presario v6000 but am having nothing but bother installing it can anyonehelp talk a newb through installing a dificult laptop
[01:13] <Fujitsu> troughton, try #ubuntu. This isn't a support channel.
[01:13] <troughton> ok thanks
[01:22] <Nailor> Anyone got any experience speeding up suspend to ram?
[01:45] <Treenaks> Buying faster RAM?
[01:46] <Nailor> Har. :)
[01:47] <Nailor> Well, the windows suspends in about the same time (maybe little less) than Ubuntu, but it sure comes up a lot faster
[01:47] <Nailor> It's like opening lid and pressing the key
[01:47] <Nailor> When in ubuntu it's opening lid, pressing key, waiting, waiting, moving mouse, waiting.
[01:49] <Nailor> Of course, it might be a driver issue, but still.
[03:08] <Infecto> my fan dont work after resume from suspend to ram
[03:08] <Infecto> :(
[03:08] <Infecto> on -9 kernel
[04:05] <mjg59> Infecto: We know. You've already mentioned that.
[05:06] <Infecto> mjg59: but i mentioned it on -8 kernel
[05:07] <Infecto> now i`v got -9 and the problem is the same
[05:32] <bjornchristian> hi. anyone tried getting webcams to work in ubuntu? i got this Dell M1210 with a logitech cam stuck to the screen
[05:32] <bjornchristian> so far its only sitting there consuming power and doing no good..
[07:03] <mjg59> Infecto: Nothing relevant has been changed in the kernel
[07:04] <Infecto> mkey
[07:04] <Infecto> you think when it will be repair  ?
[07:04] <Infecto> you know the problem wher it is ?
[07:04] <mjg59> I have absolutely no idea
[07:05] <mjg59> I'm not in the right country to fix it at the moment
[07:32] <Infecto> :) ok i onderstud that


[00:02] <UBuxuBU> whoah
[00:02] <UBuxuBU> why so long
[00:18] <MKUltraMagnus> the price of a volunteer, open-source software project of any non-trivial size
[00:22] <kumool> MKUltraMagnus, ??
[00:35] <MKUltraMagnus> for the bugs to be fixed you need to have people who have both skill, time, interest, resources, and experience (depending on the nature of the bug and where its placed)
[00:36] <MKUltraMagnus> xubuntu can rely on some paid support / updates flowing downstream from the core ubuntu project (which does have some commercial funding or support) but otherwise you're at the mercy of the perfect storm of an interested developer finding the time to do it, and if its complicated enough of a fix, then sticking with it long enough to see it through the dev lifecycle
[00:37] <kumool> the state of OSS would be fixed with a issue/bounty system where funds could be allocated by anyone for any purpose
[00:38] <MKUltraMagnus> they tried that already in a lot of places, all it lead to was people farming the system by just powering through all the easy bugs and not handling the other ones, or the funding only goes towards bugs whose resolution benefit particular interests only
[00:38] <kumool> nah, they haven't
[00:39] <MKUltraMagnus> they launch new versions of that every year in the cybersecurity fields
[00:39] <kumool> tell me where i can easily add funds to whichever feature i want
[00:40] <kumool> they try and they fail, because they don't know how to do it
[00:40] <kumool> so far, i have not seen one
[00:41] <kumool> well, just one
[00:42] <MKUltraMagnus> bountysource and hackerone are the two that spring to mind
[00:42] <MKUltraMagnus> hackerone just does company sponsorships iirc which is just a roundabout way of doing 'paid internships where you only work on one thing'
[00:43] <MKUltraMagnus> oracle did a security-focused one if i remember right as well
[00:44] <kumool> yeah but the project maintainer needs a cut as well
[00:44] <kumool> it seems there is no incentive to merge
[00:44] <MKUltraMagnus> if management wants the rewards they should do the work
[00:45] <kumool> maintainer, that is, whoever is in charge of the project
[00:46] <MKUltraMagnus> besides ive been a software dev for like a decade now and i can tell you that anyone who can claim that they are 100% solely responsible for resolving anything is just straight-up lying
[00:46] <kumool> from what i see in bountysource they don't want to merge the code
[00:47] <kumool> i mean, sometimes its true
[00:49] <MKUltraMagnus> trust me, a good tester or qa person is twice as important as your average code monkey
[00:50] <MKUltraMagnus> and if it involves ui? find an ux and accessiability person to be your best friend
[00:50] <MKUltraMagnus> writing code can take time and skill but it's usually straightforward
[00:56] <UBuxuBU> well the fix i need is quite easy
[00:56] <UBuxuBU> its a no brainer
[00:56] <UBuxuBU> in fac tthe fix is already out there somewhere right now
[03:36] <xubuntu79i> hello
[03:37] <xubuntu79i> did anybody install xubuntu to an external hard drive then use it at work instead of windows like me?
[12:30] <nopja> how can i change the name that secound login after the crypt password
[12:35] <gnrp> nopja: What name do you mean?
[12:37] <nopja> gnrp i mean the login that comes up after logging out and to change user screen, how do i change that name?
[12:39] <gnrp> you mean the full name? That is in your personal details
[12:39] <gnrp> or do you mean the name that is there by default?
[12:47] <nopja> gnrp i mean the secound login promp after i have logged in on the first one crypto login. sorry i dont know how to explain it, hope you understand
[12:52] <Iolo> By "crypto login", do you mean unlocking an encrypted hard drive?
[13:12] <nopja> theres one login thats crypto password then a secound login prompt as in username
[13:13] <nopja> i want to use that username where all user accounts are displaid
[13:14] <nopja> to change  that
[16:29] <xubuntu01w> I just reinstalled 18.04. As with a previous installation there my Rosewill usb pcie card does not show up, and the flash drives connected into it.
[16:29] <xubuntu01w> Any advice?
[16:33] <xubuntu01w> This is a link in amazon.com: rosewill rc-508 usb 3.0 pci-e express card with 4 usb 3.0 ports
[16:35] <brainwash> and how are we supposed to help you?
[16:35] <brainwash> did you already google "card name + linux"?
[16:36] <xubuntu01w> Well, Xubuntu 16.04 did recognize all my flash drives and usb connections, but the new installation does not. Is there a fix?
[16:37] <xubuntu01w> Out of frustration previously I returned to an old installation. This may be the only answer to the problem for now.
[16:37] <brainwash> then it may be a known issue
[16:38] <xubuntu01w> Yes.
[16:40] <brainwash> https://askubuntu.com/questions/1060167/issue-with-rosewill-rc-508-pcie-usb3-0-card-not-connecting-ubuntu-16-04
[16:41] <xubuntu01w> Thanks for the information!
[16:41] <brainwash> according to that user, the card does not work 100% in 16.04 either
[16:46] <xubuntu01w> I haven't experienced problem in 16.04.
[16:49] <brainwash> then it may be something that you should report to the bug tracker
[17:42] <_freenoder> When i connect to my vpn and try to download a torrent it goes at a snails pace, doesn't matter the torrent be it an utuntu iso or somethign else
[17:43] <_freenoder> i tried xubuntu live and installing the vpn and downloading a torrent and it was a normal speed Mbits instead of bits
[17:43] <_freenoder> so it seems its something on my box and not the vpn provider
[17:43] <_freenoder> how can i go about diagnosing the problem? logs etc?
[18:12] <_freenoder> nada?
[18:14] <brainwash> _freenoder: maybe test with a second user account
[18:14] <brainwash> checking the logs is obviously something that should be done too
[18:14] <_freenoder> hadnt thought about that. thx, will give that a try
[18:15] <_freenoder> sorry, but where/which logs?
[18:15] <brainwash> it could be something specific to a user setting
[18:15] <brainwash> well, "dmesg" and "journalctl"
[18:15] <brainwash> also, check ~/.xsession-errors
[18:16] <_freenoder> ah, again thanks, will give it a try
[19:32] <pwaring> Is anyone aware of a bug whereby a laptop screen powers off after inactivity, after upgrading to 18.10?
[19:33] <pwaring> Nothing seems to bring it back up
[19:47] <brainwash> pwaring: caused by the screen locker?
[20:04] <xubuntu038> Hello I need help with getting a Canon printer to scan.
[20:07] <pwaring> brainwash: seems so, in the end I rebooted and changed power saving prefs
[20:07] <pwaring> Didn't happen on 18.04
[20:07] <brainwash> pwaring: power saving?
[20:07] <brainwash> I was talking about the screen locker
[20:07] <brainwash> the thing that locks the user session
[20:11] <pwaring> It looks like this bug:
[20:12] <pwaring> https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1259339
[20:45] <xubuntu038> Still hoping someone can help me get my Canon mulitifunction printer to scan. I would be exceedingly grateful.
[20:46] <brainwash> xubuntu038: best to ask in #ubuntu then
[20:47] <brainwash> way more users over there
[20:51] <xubuntu038> OK, will try that. Thanks Brainwash.
[21:03] <xubuntu592> Hello. I was just chatting with brainwash. Can you help me register my nick (I am confused). Ubuntu wants it.
[21:20] <UBuxuBU> does anyone know why i am getting this silly error message in xubuntu 184 04   http://i.imgur.com/hfFL73y.png
[21:21] <UBuxuBU> very strange thinng to add to the OS
[21:23] <UBuxuBU> the OS darkens my screen if i  dont use ot for a lil while then i log back in and get this ridiculous message
[21:40] <brainwash> xubuntu592: https://freenode.net/kb/answer/registration
[21:43] <xubuntu592> Thanks, Brainwash. I tried, but forgot the /. Oops
[21:50] <xubuntu592> Now I am confused as to how to log in. Gonna try <account>:<password>
[21:51] <xubuntu592> Sorry, Brainwash. Just tried and revealed my password again. Now I need to configure SASL?
[21:53] <brainwash> you don't have to, and you only can if you use a non web IRC client
[21:54] <brainwash> did you register "xubuntu592"?
[21:58] <xubuntu592> I do not think so. The email was addressed to the "name assigned by freenode" where I sent the proper message (with/) at ubuntu freenode channel.
[22:00] <xubuntu592> And the messages there said I was registered and stated my reg. name and password. (sorry for the confusion about another channel)
[22:01] <xubuntu592> So I guess I am live on that channel, but how do I log in here, when I get the message that there is some sort of problem and only registered nicks are allowed? Just asking.
[22:03] <brainwash> well uhm
[22:04] <xubuntu592> Says I am verified, but does not look right. Still has that "need to register" message at top. No messages other than people leaving and connecting.Sorry, for my utter lack of experience.
[22:05] <brainwash> you could join #freenode and ask for assistance
[22:06] <xubuntu592> But I am listed as connected on list at right. Very top line still says ubuntu unregged.
[22:06] <brainwash> other than that, try to log in via https://webchat.freenode.net/
[22:06] <xubuntu592> Gonna try freenode.
[22:06] <brainwash> or via a desktop IRC client
[22:31] <xubuntu592> Sorry. I registered just fine, but when I try to re connect to the Ubuntu channe, I am not logged in. Do I try <account>:<password>?
[22:39] <xubuntu592> I tried that, and just revealed my password, but am not logged in. Can I get some more help in logging in at the Ubuntu help channel?
[22:42] <kumool> its better to go in #help for irc related help
[22:43] <kumool> xubuntu592, change your nick first to the nick that you want
[22:44] <kumool> then type { /msg nickserv help register } and follow the instructions
[22:44] <kumool> followed by /msg nickserv identify <your password goes here>
[22:44] <kumool> you can change your password as well, but if you never registered dont worry about it
[22:46] <xubuntu592> It said I registered. Now I am very confused. Sorry. CTCP version?
[22:46] <kumool> dont worry about that
[22:46] <xubuntu592> How di I change nicks?
[22:46] <kumool> xubuntu592, what are you confused about?
[22:46] <kumool> type /nick <nick>
[22:49] <xubuntu592> I got an email confirming account registration. Addressed me by the name that Ubuntu IRC channel had assigned me. I just tried /nick <nick> and nothing happened (which I assume means I did something wrong).
[22:50]  * kumool sighs
[22:50] <xubuntu592> Sorry to elicit sighs. This syntax and nomenclature are brand new to me today.
[22:51] <kumool> /nick <take off the brackets>
[22:51] <kumool> /nick <names cant have spaces either>
[22:51] <xubuntu592> OK
[22:51] <kumool> its fine, its been a long day
[22:52] <kumool> oh my
[22:52] <kumool> well thats not a good nick but ok
[22:53] <kumool> anyway, if thats the nick you chose and its registered, try /msg nickserv identify <password>
[22:53] <qwebirc45255> That is the name under which I am registered. Yes, I never would have chosen that nick, and in fact tried / thought I used another, but what am I gonna do except plow onward?
[22:54] <kumool> you can just register another, but if its temporal it doesnt matter
[22:54] <Unit193> See also: /msg nickserv help group  and  /msg nickserv help set accountname
[22:56] <qwebirc45255> I am not identified, and I might be wrong, but I think my password just went out. Now, I think I get it. I can use something like /msg nickserv <account>:<password> to log in when I get to Ubuntu unregged IRC.
[22:56] <qwebirc45255> I meant NOW identified. I have problems typing accurately also which does not help in the least.
[22:57] <kumool> /msg nickserv <account>:<password> will fail though
[22:58] <qwebirc45255> Please set me right. I promise to omit < and >.
[23:00] <kumool> what you're doing is sending a private message to nickserv, so /msg nickserv <command> <parameter>, if you would like to see the list of commands nickserv has, then /msg nickserv help
[23:02] <kumool> help being the command, you can try help account or help identify for more info
[23:03] <kumool> on those commands
[23:03] <kumool> bbl, good luck!
[23:05] <qwebirc45255> I'm looking. Nickserv- GROUP would log me in when I am at the Ubuntu unregged channel? This is what I need, but I realize I am not even asking the question which would solve this for me.
[23:06] <qwebirc45255> I might seem dense or uncooperative, but this is my very first day at this.
[23:08] <qwebirc45255> Have I lost the use of my nick? I thought I /it was registered.
[23:10] <qwebirc45255> OK. Account and nick are different.
[23:10] <qwebirc45255> NickServ- Group
[23:10] <kumool> qwebirc45255, wait wait wait
[23:11] <kumool> what channel are you trying to join qwebirc45255 ?
[23:12] <kumool> qwebirc45255, you are logged in already, you can /join #ubuntu
[23:12] <kumool> and ask your question
[23:12] <kumool> though i thought ubuntu was public
[23:12] <Unit193> It is +r
[23:12] <kumool> restricted? i forgot what that meant
[23:13] <qwebirc45255> I need to join Ubuntu help. Do I connect and then use NickServ- <GROUP> where <GROUP> would be #ubuntu
[23:13] <Unit193> Registered only.
[23:13] <kumool> ah
[23:13] <kumool> qwebirc45255, type /join #ubuntu
[23:13] <kumool> and then you'll be in #ubuntu
[23:13] <kumool> but you can ask for support here for your question
[23:15] <qwebirc45255> I guess it is true. Even tiny acts of technology seem like magic to the uninitiated. I am now in #ubuntu "not restricted". Thank you kumool
[23:16] <kumool> any questions about irc go to #help (as in, /join #help)
[23:18] <qwebirc45255> Got it. Not to complain, but two hours ago, I started trying to get help here, was sent to #ubuntu, registered, now I can try to ask my question there. Thank you kumool again, and I guess I do like to complain.
[23:33] <MKUltraMagnus> anyone else having a 50/50 crash of plymouthd on startup?


[00:00] <teward> Eickmeyer: ack.  i'm not busy and feeling fairly better but still not 100% i'll do a cursory review
[00:00] <teward> though my review may not be of as high a quality as normal because i'm still recovering from the appendectomy
[00:00] <Eickmeyer> Sounds good. My packaging skillz keep getting better and better (yes, that's a z).
[00:00] <Eickmeyer> Yeah, I get that.  It's already in the archive so it would be a simple upload for you. It's at https://launchpad.net/redkite. Simple git repo.
[16:34] <RikMills> can't do now, but I will look in a few hrs
[16:35] <Eickmeyer> Just needs to be cloned, pristine-tar checkout, debuild -S, and dput. It's ready to go. However, if I get movement from the DMB then don't worry about it. :)
[16:37] <RikMills> ok, lets see
[16:38] <RikMills> pristine tar. yuk!
[16:38] <Eickmeyer> That's the way I was told to do it...
[16:39] <RikMills> it's just not in my normal workflow, where we always use just packaging in git + the upstream tar
[16:39] <Eickmeyer> Ah, gotcha.
[16:39] <Eickmeyer> You can bame cyphermox for teaching me this method.
[16:40] <teward> lol
[16:40] <teward> RikMills: Eickmeyer uses a gbp-esque workflow :P
[16:40] <teward> its a pain xD
[16:40] <Eickmeyer> Again, blame cyphermox.
[16:41] <teward> (this said I use gbp for xca in Debian so I mean...)
[16:41] <RikMills> kde would kill LP git if we pristine tar all our stuff! :P
[16:41] <Eickmeyer> RikMills: FWIW, plasma-wallpaper-dynamic will be a thing as soon as the AAs review the package. The way it works is pretty nice.
[16:42] <RikMills> Eickmeyer: did that get uploaded? sorry I did not get to that. I am short of time
[16:42] <Eickmeyer> Yeah, teward took care of it.
[16:44] <RikMills> plus I have a short expected life expectancy of odd KDE things from github or other non kde repos
[16:45] <RikMills> there have been many 'KDE' things like that that got an initial upload, then bitrotted
[16:46] <Eickmeyer> Yeah. I'm in communication with upstream on this one. I think it'll be a neat addition to KFocus too, and I'm working with Mike on that.
[16:47] <RikMills> teward: kubuntu uses a very customised gbp implementation for nearly all our uploads. designed so that we just have the debian folder in git
[16:47] <RikMills> Eickmeyer: nice :)
[17:00]  * Eickmeyer will be out a majority of the day
[17:09] <RikMills> Eickmeyer: as usual, printine tar fails patheticallyv to make a source package. please put a real source package somewkere if you want sponsorship
[17:09]  * RikMills glares at typos
[23:35] <Eickmeyer> RikMills: I'm confused, printine tar?
[23:35] <Eickmeyer> teward: ^?
[23:37] <Eickmeyer> RikMills: Doesn't matter anyhow, I got it uploaded myself. It's in my packageset.
[23:38] <Eickmeyer> Oh, pristine tar.
[23:38] <Eickmeyer> Gotcha.
[23:38] <Eickmeyer> Weird...