[00:28] <jelmer> yay, bzr-svn is now feature complete \o/
[00:28] <spiv> jelmer: oh?
[00:28] <jelmer> spiv, annotate and eliminating svn-push were the last remaining bits
[00:30] <james_w> \o/
[00:30] <spiv> jelmer: sweet
[00:30]  * james_w opens the champagne
[00:31] <poolie> wow way to go
[00:33] <spiv> jelmer: someone on another channel asks about svn:externals ;)
[00:33] <jelmer> spiv: that requires bzr itself to support them first :-)
[00:33] <spiv> jelmer: :)
[00:34] <jelmer> the server side ("bzr svn-serve" or "bzr serve --svn") is also not done yet
[00:34] <spiv> jelmer: that's ok, neither is native "bzr serve" ;)
[00:48] <mwhudson> jelmer: yay
[00:50] <mwhudson> jelmer: will there be a 0.6 or will this be 0.5.3 ?
[00:51] <jelmer> mwhudson, 0.5.3 or 1.0.0
[00:51] <mwhudson> jelmer: cool
[00:51] <mwhudson> jelmer: are you going to make lp:bzr-svn non-remote again at some point?
[00:52] <jelmer> mwhudson: Only if there's some way to keep the copy on launchpad up-to-date rather than between 0 and 8 hours out of date
[00:53] <mwhudson> it _should_ be possible to write a hook that uses the api to request a mirror by now
[00:53] <mwhudson> but i don't think one has been written
[00:54] <poolie> lifeless: trailing whitespace just bit me too
[00:56] <lifeless> heh
[00:56] <lifeless> jelmer: grats
[00:56] <lifeless> jelmer: there is an xmlrpc thing you can call, apparently.
[00:57] <poolie> ah actually no
[00:57] <poolie> it was a literal tab, and that was worth catching
[00:57] <lifeless> heh
[00:57] <lifeless> yes they are worth catching
[00:58] <poolie> did you resubmit your test_source patch?
[00:58] <poolie> if not i will
[00:58] <jelmer> mwhudson, yeah, I still need to look at that
[00:58] <jelmer> mwhudson, or hope somebody else does :-)
[00:59] <mwhudson> jelmer: i'll take your requirements on board :)
[00:59] <lifeless> poolie: no, because marius said he would
[00:59] <lifeless> poolie: the more clean version
[01:00] <Jerub> now I remember one of the issues with bzr-svn, it gets exponentially slower as it goes.
[01:01] <jelmer> Jerub, Which version are you using?
[01:01] <Jerub> 0.5
[01:01] <jelmer> Jerub, try 0.5.2
[01:01] <jelmer> that should be significantly faster
[01:01] <jelmer> in particular on large repositories
[01:01] <mwhudson> jelmer: why don't you use hosted branches btw?
[01:04] <Jerub> jelmer: well, I've just cancelled the svn-import that had been going for over an hour
[01:04] <Jerub> jelmer: so I hope this is faster.
[01:06] <jelmer> mwhudson: It ties me into Launchpad, over which I have no control.
[01:07] <jelmer> mwhudson: Hosting on a different machine and mirrorring into launchpad (which is still done, just not into lp:bzr-svn) means there's always a backup
[01:07] <jelmer> *also means
[01:07] <mwhudson> fair enough
[01:07] <mwhudson> though i hope launchpad isn't going to go away any time soon :)
[01:08] <mwhudson> we have backups on tape too
[01:08] <Jerub> why bother? raid is good enough to back everything up.
[01:09] <spiv> Jerub: raid isn't very good at preserving data eaten by fat fingers :)
[01:09] <mwhudson> or fires
[01:10] <spiv> mwhudson: pfft, nature
[01:10] <Jerub> Sorry, I couldn't help it. My sarcasm exploded over the channel.
[01:11] <Jerub> (I've actually had an office fire, and recovered from offsite backups)
[01:12] <spiv> Jerub: :)
[01:13] <mwhudson> http://www.facebook.com/pages/Bazaar/128354670412?sid=7bd5847db77e5312163ecf237785b8c9&ref=s
[01:13] <spiv> Jerub: backup strategies is a topic a bit like editor or vcs preferences...
[01:13] <spiv> mwhudson: that's a bit random
[01:14] <spiv> Maybe we should replace our wiki with a myspace page ;)
[01:17] <Jerub> spiv: I think until you've had to count the minutes until the wholesaler turns their phone system on in the morning so you can ask for immedate delivery of half a dozen servers, you can't really appreciate the value of offsite backups fully.
[01:18] <lifeless> igc1: how are you going
[01:18] <lifeless> spiv: also, I've a _huge_ long pull going from python.org
[01:18] <lifeless> 1448 byte packes
[01:19] <Jerub> jelmer: is there a reason I should be told to upgrade to svn 1.5 if I'm using svn 1.5 already?
[01:19] <lifeless> jelmer: hours now :(. So not sure sure why
[01:19] <spiv> lifeless: 1448 is better than 510!
[01:20] <Jerub> jelmer: also, this is /significantly/ faster. after 20 minutes I'm past branch discovery and on copying revisions, last run I'd not gotten through 75% of branch discovery
[01:20] <lifeless> spiv: 510 was the window size :(
[01:21] <mwhudson> spiv: we should use facebook for canonical's calendaring needs!
[01:21] <jelmer> Jerub: The 1.5 warning should be fixed in the next version
[01:22] <Jerub> jelmer: awesome
[01:26] <lifeless> spiv: I've stopped it after 99m
[01:26] <lifeless> spiv: oh! I have an idea
[01:27] <lifeless> spiv: ping
[01:27] <james_w> you're going to try TCP/spiv?
[01:27] <lifeless> james_w: no, I think we might be partial-reading from the socket
[01:27] <lifeless> which will lead to acking less than we can
[01:28] <james_w> ah
[01:28] <Jerub> lifeless: have you straced it to see how big the reads are?
[01:28] <lifeless> Jerub: about to
[01:29] <spiv> lifeless: pong
[01:30] <lifeless> spiv: see before
[01:30] <spiv> Hmm, read sizes?
[01:32] <spiv> lifeless: it should always be trying 64k when reading from a TCP socket
[01:32] <lifeless> spiv: yeah, I've just validated that
[01:32] <lifeless> spiv: and its often getting way less
[01:33] <lifeless> recvfrom(4<EMAIL_ADDRESS>65536, 0, NULL, NULL) = 5792
[01:33] <lifeless> recvfrom(4, "cc4771:python%2Ftrunk:Lib%2Ftest"..., 65536, 0, NULL, NULL) = 1448
[01:33] <lifeless> recvfrom(4, "\2\377\255\223\273\262\333 \20\206{?\3056\231\330\216\344"..., 65536, 0, NULL, NULL) = 5792
[01:33] <spiv> (It is less optimisitic when reading the pipe from a bzr+ssh connection, but that's not the issue here obviously)
[01:34] <lifeless> spiv: however, we haven't tested raw protocol from the dc
[01:34] <lifeless> spiv: it could be :P
[02:14] <riyo> Hello all! Let's see how much I can learn tonight. First time VCS user, reviewed CVS/SVN/Git, and all those other ones, and decided on this one ^_^
[02:14] <riyo> Just because the commands made alot more sense, then those other ones. Like "whoami", simple, lol
[02:16] <riyo> Anyways, just got through the quick user guide, and my question is this. Okay, I commit my file, lets say I finished my project, and want to look back, how do I do that?
[02:16] <lifeless> bzr log?
[02:17] <riyo> Like, what Im trying to say, I'm working on my project, and I decide to try something new. So I go route A, decide it's "okay", and start going a different route, route B, can I do that? And revert back to the "fork" in the road
[02:19] <riyo> I don't know, I tried that in the documentation, it worked, but isn't working now. And It just showed my commits, not the file itself :/
[02:24] <riyo> also, bzr diff, and log, aren't working anymore, wtf
[02:24] <riyo> do I have to specify a file or something?
[02:24] <riyo> bzr log filename ?
[02:26] <poolie> riyo: no, they default to the whole tree
[02:26] <poolie> riyo: are you in the right directory?
[02:31] <riyo> Yeah I am
[02:32] <poolie> so what do you mean by not working?
[02:32] <poolie> do you get an error msg?
[02:33] <riyo> Let me upload a picture ^_^
[02:35] <riyo> http://i44.tinypic.com/141teu8.png
[02:35] <riyo> There, is it supposed to do that? It just shows comments, which btw, is that a mispelling? commits?
[02:35] <poolie> :)
[02:36] <poolie> that's what bzr log is meant to do, yeah
[02:36] <poolie> 'committer' is the person who committed
[02:36] <riyo> Is that pronounced "comment-er", or "commit-er"?
[02:36] <poolie> the second
[02:37] <poolie> they're called commits, not comments
[02:38] <riyo> But...they....are comments, lol
[02:38] <riyo> How confusing.
[02:38] <riyo> Anyways, what's the point? Don't I want to see what source code of mine changed?
[02:39] <poolie> i don't know, do you? :)
[02:40] <riyo> Ugh, yeah, otherwise theres no point, lol
[02:40] <riyo> I wish it was just a hotkey, for a "snapshot", and I could scroll through each picture, lol
[02:41] <spiv> riyo: you can do "bzr diff -c 2" to see changes made in commit 2.
[02:43] <riyo> WTF does that mean, lol --> @@ -0,0 +1,1 @@
[02:43] <riyo> ...is this some sick joke :P
[02:43] <lifeless> riyo: thats standard notation for showing a textual change of a file
[02:44] <lifeless> riyo: it means from line 0, for 0, to line 1, for 1
[02:45] <riyo> This is overly complciated.
[02:45] <riyo> Is this really the answer I'm looking for?
[02:45] <riyo> Cause heres my problem.
[02:46] <riyo> I create php websites, take the index.php file for example. I work on it, but before I do, I make a backup, just incase I mess up everything
[02:46] <riyo> I end up with 100's of copies, lol, untill I'm finished or have scraped it.
[02:46] <riyo> Is this my solution?
[02:47] <spiv> riyo: yes
[02:47] <spiv> riyo: you might find that some of the GUI tools make exploring the saved history a bit easier
[02:48] <lifeless> riyo: with bzr you won't need as many copies, the bzr-upload plugin can make deploying your websites easier
[02:48] <spiv> riyo: if your installation has the "qbzr" plugin, then "bzr qlog" is quite good.
[02:49] <spiv> riyo: if you just want to view a file as it was at an earlier revision, use "bzr cat -r 2 path/to/file"
[03:14] <riyo> I wish there was a video tutorial. If I ever get the hang of this, I'm so making one.
[03:16] <riyo> bzr: ERROR: QBzr require at least PyQt 4.1 and Qt 4.2 to run. Please check your install
[03:17]  * igc1 lunch
[03:36] <lifeless> spiv: doing get_parent
[03:39] <jml> igc1: ping
[03:50] <igc1> hi jml
[03:50] <jml> igc1: hi
[03:50] <jml> igc1: I have a story about logging that I'd like your help with
[03:51] <jml> igc1: I've heard a rumour that you touched log last?
[03:51] <igc1> jml: :-)
[03:51] <jml> igc1: so... what I want to do is find all the commits that I've made to Launchpad via PQM since the last release.
[03:52] <jml> igc1: the way I can tell if a commit was mine is if I'm the author of one of the parents of a mainline revision
[03:52] <jml> I can write that as a predicate function with little to no worries
[03:52] <jml> igc1: what I want is a way of passing a predicate function to show_log to filter the revisions I see.
[03:53] <igc1> jml: hmm
[03:54] <igc1> jml: log needs restructuring and vila and I still don't agree on how
[03:54] <jml> igc1: ok.
[03:54] <lifeless> I'd do a filter
[03:54] <lifeless> it can buffer a little and so on and feed it out
[03:54] <jml> igc1: so, doing 'if foo(revision): yield revision' is going to be a bit slow, obviously
[03:54] <lifeless> then give the filte ra predicate as a parameter
[03:55] <igc1> jml: I think we ought to add a --user option (or something like that) that matches on a name ...
[03:55] <lifeless> igc1: +1 on more capabilities, -1 on new options, I'd really rather agree on a search language and use that
[03:55] <jml> what I *really* want is Bazaar Query Language
[03:55] <igc1> possibly propagatng upwards to the mainline as file filtering does
[03:55] <lifeless> igc1: so that bzr-search can do it fast
[03:55] <jml> lifeless: great minds :)
[03:56] <igc1> BQL is Python :-)
[03:56] <igc1> jml: as a short-term thing ...
[03:57] <igc1> log --line -n0 | grep Lange
[03:57] <igc1> make it a contenxt grep if that helps
[03:58] <jml> igc1: ... and then filter that to find the mainline revisions ....
[03:58] <igc1> lifeless: bzr-search is nice but it doesn't exclude making log easier to use
[03:58] <igc1> bzr log --user me
[03:59] <igc1> and
[03:59] <igc1> bzr log --user @names-in-file
[03:59] <igc1> have plenty of value to casual users - a query language is just too advanced for them
[04:01] <igc1> lifeless: we can use bzr-search behind the scenes to make it efficent of course
[04:01] <jml> igc1: so, if I could do that and then only see mainline revisions which I pqm-submitted, I'd be happy
[04:01] <igc1> iff it's installed
[04:01] <jml> (although the *real* bug there is that PQM doesn't set author)
[04:02] <igc1> jml: right
[04:02] <igc1> jml: but even if it did, there would still be a use for seeing mainline revisions where a user authored one of the merged revisions
[04:03] <lifeless> igc1: bzr log -m user:me
[04:03] <igc1> I guess the new multiple author field could simplify that
[04:03] <jml> igc1: I do think some sort of domain-specific language/API for specifying searches would be a good idea.
[04:03] <lifeless> igc1: bzr-search is orthogonal yes, but adding many many options is not great
[04:04] <igc1> jml: so *just* matching against a revision isn't smart enough
[04:04] <jml> igc1: agreed.
[04:05] <jml> although it's smart enough if I'm writing the revision-matching function :)
[04:06] <lifeless> igc1: I wasn't proposing depending on bzr-search, I was proposing that many-options is not a better UI
[04:06] <igc1> jml: but log, except for file filtering, isn't structured that way btw
[04:06] <lifeless> igc1: the revision filters are iterators, or they were
[04:06] <igc1> lifeless: sure
[04:06] <lifeless> igc1: so it should handle arbitrary filtering just fine
[04:06] <jml> igc1: ok
[04:07] <igc1> but the level filtering takes out merged revisions it's never going to display before those iterators are called
[04:07] <igc1> so log -n0 only passes you the mainline revisions
[04:08] <igc1> it's all part of "don't generate stuff you don't need"
[04:08] <igc1> "smart" filtering like jml wants means ...
[04:09] <mwhudson> hello knowledgeable people
[04:09] <mwhudson> what port does git talk to the internet over?
[04:09] <igc1> a revision filter needs to say "give me everything and then post filter the levels out"
[04:09] <igc1> except for file filtering, we don't do that currently
[04:10] <igc1> lifeless: I like the -m user:me idea btw
[04:11] <lifeless> igc1: can't the level filtering happen as a normal filter in the chain so you can get there first?
[04:12] <igc1> lifeless: there's a high cost (> 60 sec overhead) for getting all levels for mainline for large repos
[04:12] <igc1> s/for/vs/
[04:13] <igc1> we only want to do it if we really need to
[04:14] <Jerub> oh wow, bzr-svn 0.5.2 actually worked.
[04:15] <igc1> jml: so the short answer is ...
[04:15] <igc1> post processing log --line -n0 is an order of magnitude easier than extending log as you want right now
[04:15] <igc1> hmm - maybe 2 orders of magnitude
[04:16] <jml> heh, ok.
[04:16] <jml> I'm going to try for a middle way, writing my own crappy log-like command.
[04:17] <igc1> lifeless: on anotrher topic and answering your earlier Q, I'm making much better progress ...
[04:17] <igc1> thanks to your assistance yesterday
[04:17] <igc1> I'm hacking repodetails as discussed
[04:18] <lifeless> spiv: ping
[04:18] <Jerub> jelmer: why does bzr-svn count down for 'discovering revisions' while doing a bzr pull
[04:18] <igc1> though *generating* branches in the new formats is still proving painful
[04:19] <igc1> upgrade works for development5 but simply refuses to for ...
[04:19] <igc1> formats like gc-plain-chk255, even for really simple branches
[04:20] <igc1> at least now I know enough to stand a chance of traking down the problems
[04:20] <spiv> lifeless: pong
[04:20] <lifeless> spiv: tommorrow I'm likely to be largely offline
[04:20] <lifeless> spiv: and its freeze then
[04:20] <lifeless> I'm just finishing off branch.get_parent verb
[04:20] <lifeless> have you been working on stacked pull ?
[04:21] <igc1> though the immutable nature of CHKInventories means fastimport is currently out of service as a test branch generation avenue
[04:22] <spiv> lifeless: no, not yet :/
[04:22] <lifeless> igc1: if fastimport was mutating invnetories inRevisionTree's, it was being naughty
[04:22] <lifeless> igc1: thats *never* been a intended capability
[04:22] <Jerub> crud, that was my problem. I thought I wanted bzr svn-import when I actually wanted bzr checkout
[04:22] <igc1> lifeless: it wasn't
[04:23] <igc1> it was copying the basis and then using the API (add/del, rename, remove_recursive_id) to build the new one
[04:23] <lifeless> ok
[04:23] <lifeless> that would be slow
[04:24] <lifeless> using CommitBuilder would be better
[04:24] <lifeless> because it will calculate the per file graph for you
[04:24] <igc1> it now has a code path for building deltas and calling create_by_apply_delta() but the root handling is still screwing me around
[04:24] <lifeless> igc1: how so?
[04:25] <lifeless> essentially there are three interfaces for adding data to a repository - fetch, repository.add_revisions, and get_commit_builder
[04:25] <lifeless> *any* other code path is immediately suspect and probably a reimplementation of one of the others
[04:26] <igc1> it's not clear what the initial root_id of the first inv should be
[04:26] <igc1> I was setting it to inventory.ROOT_ID but then the root mproperty was falling over 'cause self[root_id] didn't exist
[04:27] <igc1> also does the first delta need an entry for the root?
[04:27] <igc1> that sort of stuff is very unclear
[04:28] <igc1> I think the first revision is now genewrating but a subsequence call to directories() is falling over
[04:29] <igc1> anyhow, I'll leave fastexport on hold and get back to repodetails
[04:29] <lifeless> yes it does
[04:29] <igc1> lifeless: fwiw as well, fast-export was *much* quicker not going through commit-builder, at least many months ago
[04:30] <lifeless> igc1: so, either fast-import was buggy, or commit-builder was
[04:30] <lifeless> :P
[04:30] <igc1> commit-builder is good for adding one revision but not optimise at all for multiple revision loading
[04:30] <lifeless> igc1: I don't see why it would be different
[04:31] <igc1> lifeless: let's talk about it next week
[04:31] <lifeless> igc1: anyhow, lets ignore that; we have shiny new things
[04:36] <eferraiuolo> I wrote a blog post detailing my Bazaar setup on my Mac. I thought others maybe interested and wanted to share it with the community:
[04:36] <eferraiuolo> http://925html.com/techniques/using-bazaar-on-a-mac/
[04:47] <jml> lifeless: just landed your addSkip patch
[04:50] <lifeless> thanks
[04:51] <lifeless> so subunit's one needs a review
[05:27] <lifeless> ciao
[05:43] <Kamping_Kaiser> hm. almost an entire branch without a status updae :\
[06:00] <poolie> eferraiuolo: nice
[06:23]  * fullermd sure hopes those streaming changes will improve committing in checkouts across the smart server   :|
[06:28] <spiv> fullermd: almost certainly.  You're welcome to try installing bzr.dev and letting us know how it goes :)
[06:28] <fullermd> Well, I have bzr.dev.  Just only on the client side   :p
[06:28] <fullermd> Just messes with your flow when commit takes upward of 20 seconds...
[06:28] <spiv> Yeah.
[06:29] <fullermd> I'm just trying to figure out whether that's an actual failing of bzr, or a clever trick somebody added to convince people not to work directly on trunk...
[06:30] <spiv> Personally, I think it's a failing.
[06:30] <spiv> I think there are valid use cases for working on a checkout of trunk.
[06:31] <fullermd> Man, some people just don't know how to help build a good conspiracy theory...
[06:33] <fullermd> The proper response would have been something like "Not only is it _intended_, it was intended by SPACE ALIENS, who encoded those coding choices in our DNA while forcing us to build the Pyramids."
[06:35] <fullermd> That way not only do we have an excuse for why it happens, but we demonstrate that bzr is the oldest VCS at the same time.
[06:35] <fullermd> (it was just only circa 2005 that it was translated into python from limestone...)
[06:40] <wgrant> spiv: There are also often valid use cases for working on a checkout of a branch that multiple people are working on at once...
[06:42] <spiv> wgrant: right
[07:35] <vila> hi all
[07:39] <vila> jfroy: pong
[07:40] <jfroy> vila: yo
[07:40] <jfroy> so, I implemented a crude keychain auth provider.
[07:40] <jfroy> Plugin, that is.
[07:40] <vila> jfroy: great, publish it on lp :)
[07:40] <jfroy> I ran into one limitation, and one weird thing while doing so.
[07:41] <jfroy> vila: I need to clear it with Apple legal first.
[07:41] <vila> jfroy: ? You're working for Apple ?
[07:41] <jfroy> Yeah
[07:41] <vila> ok
[07:41] <jfroy> I managed to get Bazaar approved for inclusion in internal builds of Mac OS X :)
[07:42] <vila> jfroy: congrats :)
[07:42] <jfroy> And I want to bundle a few useful plug-ins with it.
[07:42] <jfroy> Eh, well git and hg are already there, but anyways.
[07:42] <jfroy> OK, so first of all, the realm isn't passed down to auth providers
[07:43] <jfroy> I trivially patched bzr.dev to do so
[07:43] <vila> jfroy: send a patch so I can review it
[07:43] <jfroy> It's useful to look up Subversion repository passwords since they are stored as "<scheme://host:port/path> realm" generic passwords
[07:44] <jfroy> Secondly, the authentication.conf section *name* is passed to the auth provider
[07:44] <vila> bzr-svn is taking care of that, so I thought we already fixed the realm bit with Jelmer...
[07:44] <jfroy> Unfortunately, the credentials are needed for probing
[07:44] <jfroy> otherwise, you get prompted *twice* for your credentials.
[07:45] <jfroy> it's a miserable user experience, in other words
[07:45] <vila> jfroy: if the auth provider knows about the credentials, you don't get prompted
[07:45] <jfroy> yes. that's quite correct
[07:46] <vila> if it doesn't (and *because* we don't save credentials so far) you get prompted twice
[07:46] <vila> that's the actual limitation
[07:46] <jfroy> I understand that -- the keychain auth provider works beautifully
[07:46] <jfroy> but it needs all the information to do a useful search
[07:46] <jfroy> host, port, realm, path, username
[07:46] <jfroy> technically, it doesn't need the username
[07:47] <vila> ayou should have them as part of the credentials parameter in decode_password
[07:47] <jfroy> So in any case, passing the auth section name to providers seems odd. Your own netrc plug-in looks for the key "host" in the credentials argument, yet that's *never* stored in the credentials dictionary by bzr.dev
[07:47] <vila> if you don't, that's a bug I should fix
[07:49] <vila> AuthenticationConfig.get_credentials should certainly set the credential attributes from the received parameters, it seems it still doesn't
[07:49]  * jfroy pasted http://pastie.textmate.org/408078
[07:49] <vila> Now that you mentioned it, it may be that Jelmer worked around that and I thought he fixed it when in fact it's still to be fixed
[07:50] <jfroy> that's the current code in bzr.dev
[07:50] <jfroy> so basically in my prototype I hacked some code to create a new AuthenticationConfig object, load its config (private method, bad), get the section using the provided name, and get at the info I need.
[07:50] <vila> jfroy: yup, that's where things should be tweaked, damn, no realm there :-/
[07:51] <jfroy> And even that's not a good solution, since a partial patch based on the keys in the section is possible. The information should come from the actual request.
[07:51] <jfroy> bzr-svn itself handles authentication through the svn libraries
[07:51] <jfroy> there's no work to be done there
[07:51] <jfroy> the probing process is entirely in bzrlib
[07:51] <vila> jfroy: we agree, when I say add the attributes to credentials, I'm talking about the actual request ones
[07:51] <jfroy> right
[07:51] <vila> including realm
[07:52] <jfroy> What I was worried about is that I didn't understand at all how the code works, since with that code, *your* plug-in is also broken
[07:52] <jfroy> it depends on a 'host' key being set in credentials
[07:52] <jfroy> and that's clearly not being done
[07:52] <vila> jfroy: it could be that the tests are not good enough
[07:53]  * jfroy pasted http://pastie.textmate.org/408081
[07:53] <jfroy> from the netrc plug-in
[07:53] <vila> jfroy: indeed, it seems I'm testing at a too low level to catch that and that the tests always provide a host
[07:53] <jfroy> it seems there's a disconnect in the credential provider plug-in protocol / interface
[07:54] <jfroy> If you want, I can provide a comprehensive patch to address those issues tomorrow.
[07:54] <jfroy> There are other issues
[07:54] <vila> jfroy: sure !
[07:54] <jfroy> Namely one of performance
[07:55] <jfroy> get_user and get_password both use get_credentials
[07:55] <vila> jfroy: note that I'll be traveling for the next 48 hours so there will be some lag
[07:55] <jfroy> and they don't cache
[07:55] <jfroy> which implies credentials will be searched for / fetched on average twice
[07:55] <jfroy> that's fine, I'm aiming at getting this in 1.13
[07:56] <vila> jfroy: don't bother about performances here, that's called once per connection which will cost far more anyway
[07:56] <jfroy> I think the changes are low risk enough to be OK.
[07:56] <jfroy> that's not necessarily true
[07:56] <vila> 1.13rc1 is due tomorrow, but try anyway
[07:56] <jfroy> For instance, someone conscious about security might authorize bzr to access his or her keychain only once
[07:57] <jfroy> under this code, he will get prompted twice
[07:57] <jfroy> granted, the keychain provider could cache
[07:57] <jfroy> But it seems to be a flaw that should be addressed upstream
[07:57] <vila> you're talking about UI here, not performance and yes, the keychain provider can cache
[07:57] <jfroy> I'm not going to include that in my patch, it's a secondary and separate issue
[07:58] <jfroy> The last thing is a ER for later.
[07:58] <jfroy> We could add a "probe username" method to the credential provider interface.
[07:58] <jfroy> Certain providers, like the keychain one, can provide credentials with only a the request parameters.
[07:59] <jfroy> That is, you can wildcard the username and request "give me any item that matches the server part of things"
[07:59] <jfroy> This would allow bzr to match the user experience of svn
[08:00] <jfroy> I'm wondering if get_user might not already allow for this to happen
[08:00] <jfroy> And damn, rc1 tomorrow huh....
[08:00] <poolie> hello jfroy
[08:01] <jfroy> poolie: greetings!
[08:02] <vila> jfroy: there is bug #321918 to address that I think
[08:03] <jfroy> Ah yes, true, unless the provider is configured in authentication.conf it won't happen
[08:04] <vila> jfroy: that's the point, user choice is always respected
[08:04] <jfroy> I don't think that's correct
[08:04] <jfroy> Not entirely
[08:04] <vila> jfroy: the user is right
[08:04] <vila> neither you and me can change that :)
[08:04] <jfroy> Respecting user preferences is of the utmost importance
[08:04] <jfroy> *however*
[08:05] <jfroy> Unless the user takes explicit action, defaults should reflect the user's *expected* behavior
[08:05] <jfroy> And on Mac OS X, as far as credential storage and queries go, that's the keychain.
[08:05] <vila> default applies when user says nothing
[08:05] <jfroy> yes, agreed
[08:05]  * igc1 dinner
[08:06] <vila> Once your plugin register itself as being always queried unless the user says otherwise, you get what you're asking for
[08:06] <jfroy> yes, that's the ideal user experience I'm aiming for.
[08:06] <vila> jfroy: we all agree there
[08:07] <jfroy> But there should definitely be a way to disable the provider globally or for a specific host.
[08:07] <jfroy> In any case, that's not for the 1.13 timeline
[08:08] <jfroy> I'm hoping I can write a narrow enough patch for the config module it will make it past what I assume are very stringent requirements for including a patch in a release that's reached RC.
[08:09] <vila> jfroy: don't get focused on releases, send your patch, I'll do my best to get it included asap, even if asap is 1.14 :)
[08:10] <jfroy> I suppose.
[08:12] <poolie> vila, i guess you'll be leaving within 24h?
[08:13] <vila> poolie: yup in less than 8h even
[08:15] <poolie> vila, so should it be you, or bob tanner for 1.13 RM?
[08:15] <poolie> i'd like to expand the group of people who do it but
[08:16] <poolie> he isn't on the core team yet and it's kind of a high responsibility place to starte
[08:16] <poolie> start*
[08:16] <vila> If we can shift the dates by a week, that will be perfect for me
[08:16] <poolie> you'd do it on your last day here?
[08:17] <poolie> that would be ok, except that beuno and james_w would rather we do it sooner so it's in jaunty
[08:17] <vila> because cutting a release while traveling is a sure recipe for disaster
[08:17] <poolie> we can probably still get it in if we do rc1 tomorrow but not if it's a week later
[08:17] <poolie> i know
[08:17] <poolie> what do you think re bob?
[08:18] <vila> That would indeed be the first time someone without vote or pqm access will be RM, which make that harder if only on technical ground
[08:19] <vila> Otherwise I'm fine with bob, as I said I can act as the backup so may be I can team with him and try a double-head RM :)
[09:12] <LarstiQ> jseutter: did you get it to work?
[10:43] <mattions> hi
[10:43] <mattions> where can I find the plugin for network manager?
[10:44] <mattions> the link in the website lead to an empty directory
[11:22] <mattions> Does anybody knows how to make bzr-svn remember my svn password
[11:22] <mattions> ?
[12:39] <igc> night all
[12:49] <loxs> http://dpaste.com/6962/       --- this happens when I try to use bzr on a network drive. Everything is fine when I use it on a local drive. Any ideas?
[12:56] <mneptok> loxs: sorry, haven't used Windows in >10 years
[12:56] <loxs> me too... :(
[12:58] <mneptok> not that it's a Windows issue per se, but backslashes and drive letters make me run away in fright. :)
[13:03] <spiv> loxs: not sure, but what sort of network drive?
[13:04] <loxs> spiv, it's a novell share
[13:04] <spiv> loxs: it looks like the problem is something like a network drive where "mkdir mydir; touch mydir/myfile; mv mydir foo; cat foo/myfile" isn't reliable
[13:05] <loxs> the strange thing is that it worked till yesterday (before reinstall of the system)
[13:05] <spiv> loxs: i.e. bzr has renamed a lock directory, then gone to read the info file out of that directory (to make sure it really is the lock this process owns), and suddenly the info file is gone.
[13:06] <spiv> loxs: it's quite likely to be an intermittent issue if I'm right; i.e. if you try again a couple of times it might work.
[13:06] <spiv> loxs: also
[13:06] <spiv> loxs: it would be interesting to know if S:/Bespoke/Cashless Vending/Cashless
[13:06] <spiv>  Vending/Database/trunk/.bzr/checkout/lock/releasing.n0oxup06wmyexxs1agxg.tmp/in
[13:06] <spiv> fo
[13:06] <spiv> still exists.
[13:07] <loxs> spiv, nothing in the lock directory
[13:07] <spiv> loxs: hmm, interesting!
[13:07] <spiv> loxs: I don't know what could cause that.  It's possible that it's due to wacky network filesystem semantics, but I struggle to imagine plausible network drive behaviour that would cause that.
[13:08] <loxs> you are probably right... as it used to work yesterday
[13:08] <spiv> loxs: a bug report would be appreciated, though.
[13:08] <loxs> spiv, what kind of information should I supply for this?
[13:09] <spiv> loxs: the error message, the traceback from the bzr log file (see 'bzr version' for its location), the fact its a network share, and that the info file isn't there when you look manually
[13:10] <spiv> loxs: oh, and of course that it's *novell* share :)
[13:10] <loxs> ok, I'll do it now
[13:10] <spiv> loxs: plus anything else you think interesting, but we can always ask for more info if necessary.
[13:11] <spiv> loxs: feel free to just paste this IRC conversation into the bug report if that makes your life easier ;)
[13:12] <loxs> thanks :)
[13:18] <loxs> hm, spiv... in the log file... before the error you saw, there it says that it's some kind of translate error    File "bzrlib\transport\__init__.pyo, line 307, in _translate_error
[13:18] <loxs> yesterday, the locales of my workstation were different
[13:22] <spiv> loxs: that's not related to locales
[13:23] <spiv> loxs: that's code for turning errors accessing files and directories from platform-specific into bzr-internal error codes.
[13:30] <loxs> spiv, https://bugs.launchpad.net/bzr/+bug/338220
[13:35] <loxs> spiv, actually the lock directory is not empty... only the windows explorer can't see this files O.o
[13:35] <loxs> when using dir through the command prompt, they are there
[13:38] <spiv> loxs: interesting.  So it does have an 'info' file?
[13:38] <loxs> yes
[13:39] <loxs> and the bad part... that files has broken encoding  bits in it ....
[13:39] <spiv> Ok, then I guess my first hypothesis is correct.
[13:40] <spiv> Oh?
[13:40] <loxs> some of the letters in that file are "squares" probably the encoding on the novell share differs from mine
[13:41] <loxs> no, no problem with this... the squares are unix line terminators
[13:42] <spiv> Oh, right.  Yes, bzr will always use \n as the line terminator in that file.
[14:07] <loxs> spiv, when I enable the "show system folders" option in windows explorer, now I can see these "missing" directories
[14:07] <loxs> but bzr still doesn't work
[14:23] <salgado> Source format does not support stacking, using format: '1.6'
[14:23] <salgado>   Packs 5 (adds stacking support, requires bzr 1.6)
[14:24] <salgado> I got that when trying to push a branch to Launchpad.  does it mean bzr will push all history on that branch?
[14:26] <beuno> salgado, yes
[14:26] <beuno> try upgrading the repository  (ie ~/canonical/lp-branches)
[14:26] <beuno> upgrade --1.9
[14:26] <beuno> you can do 1.6, but 1.9 is fater
[14:27] <salgado> beuno, I don't think it did, though.  it took only a couple minutes to complete
[14:27] <salgado> (just finished)
[14:27] <beuno> s/fater/faster
[14:27] <beuno> that was a very bad typo
[14:27] <beuno> salgado, try:  bzr info
[14:27] <beuno> it should tell you
[14:28] <salgado> Shared repository with trees (format: 1.6)
[14:28] <beuno> and the branch?
[14:28] <salgado> I've pushing branches from this repo for ages, and stacking always worked
[14:28] <salgado> Repository tree (format: unnamed)
[14:29] <beuno> salgado, but rsync sometimes breaks stuff
[14:29] <beuno> where do you get unnamed?
[14:30] <salgado> I got that error after interrupting a push which was working fine (i.e. no message about stacking not being supported)
[14:30] <salgado> s/error/warn
[14:30] <salgado> beuno, on the branch I was trying to push
[14:30] <beuno> salgado, delete de branch and push again
[14:30] <beuno> AFAIK, there's no way to resume pushing a stacked branch
[14:31] <salgado> right, I was not trying that
[14:31] <salgado> this is another branch
[14:31] <salgado> the one I interrupted I deleted
[14:38] <spiv> salgado: 1.6 is a stacking-capable format
[14:39] <spiv> salgado: there's a bug that for some reason bzr.dev sometimes thinks that source branches in a stacking-capable format aren't in a stacking-capable format.
[14:39] <salgado> spiv, for some reason one of the branches in my (1.6) repo ended up created in a different format (unnamed, it seems)
[14:40] <spiv> salgado: so bzr gives that bogus warning.  And "upgrades" 1.9 source branches to 1.6 on the server :(
[14:40] <salgado> sounds like what I just saw
[14:40] <spiv> "unnamed" isn't a format as such, it's just "bzr info" getting confused.
[14:41] <spiv> It gets confused if the combination of branch format and repo format is outside a very narrow set :(
[14:41] <spiv> info -v can be helpful when that happens, because it will describe the components formats individually.
[14:41] <spiv> salgado: jml filed the bug, feel free to subscribe and/or update it with some info
[14:42] <spiv> salgado: we want to fix it for the 1.13 release, although at this stage I'd be doubtful about it getting fixed in time for 1.13rc1
[14:42] <spiv> salgado: also, upgrade to 1.9 already ;)
[14:43]  * spiv -> zzz
[14:43] <salgado> thanks for the help spiv.  I'll do that
[14:45] <vila> spiv: does 'second push failed to complete a fetch set' rings a bell ?
[14:58] <mattions> is there any way to tell the bzr-svn tool to remember my subversion password? I have to type two or three times every commit.
[14:59] <jelmer> mattions: you can get subversion to cache your password for you
[14:59] <mattions> how?
[14:59] <jelmer> mattions, force subversion to cache the password somehow, e.g. by running "svn ls <url>"
[15:01] <mattions> it's strange
[15:01] <mattions> i ran it and it still ask the password
[15:01] <mattions> twice, actually
[15:01] <mattions> svn 0.4.16dev0
[15:02] <mattions> Bazaar (bzr) 1.9dev
[15:02] <jelmer> you may need 0.5 for thi
[15:02] <jelmer> s
[15:02] <mattions> I see
[15:02] <mattions> well, I'm on intrepid
[15:02] <mattions> is there any bzr packages?
[15:02] <mattions> I mean 0.5 is available for intrepid?
[15:03] <mattions> ok, found it
[15:03] <mattions> I'll try
[15:03] <mattions> jelmer: one more question: is the network-manager plugin dismissed?
[15:04] <jelmer> mattions, dismissed ?
[15:05] <mattions> the link brings to an empty directory
[15:05] <jelmer> it's a bzr branch
[15:05] <mattions> ah
[15:05] <mattions> and nothing is showed
[15:05] <mattions> when you look from http
[15:06] <mattions> ok, thanks :)
[15:19] <mattions> the network-manager plugin is not on the PPA right?
[15:20] <jelmer> mattions, no
[15:20] <jblount> I have a branch that gives me "No Public branch set for /path/to/branch_name" on pqm-submit, and I'm a little lost on how to fix this.
[15:20] <jblount> The public branch is a lp branch
[15:30] <jseutter> LarstiQ: Yes, it works fine now.  The problem was with me, not bzr. :)
[15:44] <jam> jblount: echo 'public_branch = lp:...' >> .bzr/branch/branch.conf
[15:45] <jam> Or configure a policy in ~/.bazaar/locations.conf
[15:49] <jblount> jam: Thanks for the help, I had my ~/.bazaar/locations.conf b0rked and didn't remember where the setting came from.
[15:52] <radix> Does anyone know what all needs to be upgraded (software & branch-formats & repository-formats) in order to take advantage of stacked branches (on Launchpad)?
[15:53] <jam> radix: generally your repo needs to be upgraded to 1.6 or newer (I recommend 1.9 a lot)
[15:53] <jam> which implies the bzr version
[15:53] <radix> jam: on which side?
[15:53] <jam> radix: Launchpad already supports 1.9 and newer
[15:53] <jam> so just the client
[15:53] <radix> both sides? only server? only clients?
[15:54] <jam> or is there another server involved?
[15:54] <radix> jam: sure, launchpad supports 1.9, but my repository there is not on 1.9 format
[15:54] <jam> radix: so if you upgrade your local repo to 1.9
[15:54] <jam> when pushing to LP
[15:54] <jam> bzr will create a new branch+repo that can stack on older formats
[15:54] <radix> (at least, I don't think it is. I can't figure out how to check what repo format my lp repo is in)
[15:54] <jam> you *can* upgrade the repo on LP
[15:54] <jam> and there are reasons to do so
[15:54] <jam> but it isn't necessary
[15:54] <jam> stacking cares that the Stacked branch is in the new format, not the stacked-on branch?
[15:55] <jam> does that make sense?
[15:55] <radix> jam: okay, so I should just tell all my developers to upgrade to >= 1.9 and do "bzr upgrade --1.9" in their repositories (anything about branches?)
[15:55] <jam> radix: it is good to upgrade the branches, but not strictly necessary
[15:55] <jam> as we will auto-upgrade when we need to
[15:56] <radix> okay, I'll do this and find out whether it speeds up new branch pushing for my team
[15:56] <radix> thanks very much for the advice jam :)
[15:56] <jam> radix: what team?
[15:56] <radix> landscape
[15:57] <radix> jam: I think what you said about stacked vs stacked-on makes sense, yes.
[15:57] <salgado> jam, if I have a 1.9 repo with a 1.6 branch inside it.  what happens if I create a new branch out of the 1.6 one; will it be 1.6 or 1.9?
[15:57] <radix> jam: but did you actually mean the "Stacked branch's repository" instead of "Stacked branch"?
[15:57] <jam> salgado: 1.9 branches == 1.6 branches. Only the repo changes
[15:58] <salgado> oh, cool.  so upgrading my repo to 1.9 (from 1.6) should be everything I need to do?
[15:58] <jam> radix: for the most part, yes. The stacking location is actually set in the branch (so if you had a shared repo, with lots of stacked branches, they could potentially be stacked on lots of different locations)
[15:58] <jam> salgado: yep
[16:00] <radix> I think there used to be a message printed to the console when doing a push that used a stacking branch, but now I don't see those any more.
[16:00] <radix> oh awit
[16:00] <radix> there it is!
[16:00] <radix> okay, I think I got it working :-)
[16:01] <jelmer> luke-jr, ping
[16:01] <jam> radix: so pushing up a stacked branch doesn't have to push the whole history, but at the moment the data it *does* have to push is a bit slower to transfer than before
[16:01] <jam> so for *small* projects, stacking isn't a win yet
[16:01] <jam> landscape may be big enough
[16:01] <radix> yeah, Landscape is definitely big enough
[16:02] <jam> I believe if everything goes as planned, 1.13 will fix some of the remaining rough edges
[16:02] <radix> our repo is 39MB, and that's really painful for the brazilians and the italians
[16:14] <thekorn> jelmer, I think I fixed 294396, now I would like to test my changes, is there any way to test olive without installing it system-wide?
[16:14] <jelmer> bug 294396
[16:14] <jelmer> ?
[16:15] <jelmer> thekorn, you should be able to run it in-place
[16:15] <thekorn> yeah, sorry, bug of course
[16:16] <jelmer> thekorn, I just mentioned that to trigger ubottu as I wasn't sure what bug or project that was
[16:17] <thekorn> hmm, it always picks the version from /usr/lib/python2.5/site-packages/bzrlib/plugins/gtk/branchbox.py
[16:27] <jelmer> thekorn, you'll need bzr-gtk installed in ~/.bazaar/plugins/gtk
[16:35] <thekorn> jelmer, no this also did not work, "Unable to load plugin 'gtk' from '/home/markus/.bazaar/plugins'", so I just tested my fix in a gtk.Window with two instances of this widget
[16:36] <jelmer> thekorn, please check ~/.bzr.log
[16:38] <thekorn> jelmer, http://paste.ubuntu.com/126791/ looks like another bug, maybe my bzr version is too old
[16:38] <jelmer> thekorn, yes, your bzr is too old
[16:39] <thekorn> jelmer, do you know off hand which version I need
[16:40] <jelmer> 1.10 or 1.11 I think
[16:41] <thekorn> ok, getting 1.12* from the PPA now
[16:45] <thekorn> jelmer, ok, thanks for your help, it worked now, adding a branch with a fix now to this bug
[17:05] <jelmer> thekorn, bzr-gtk doesn't use merge proposals on launchpad
[17:06] <jelmer> thekorn, please submit the merge request to the bzr-gtk mailing list
[17:07] <thekorn> oh, ok
[17:08] <jelmer> Peng_, do notifications work for lp:bzr-svn ?
[17:09] <nekohayo> hey there, I have someone trying to push to launchpad and getting an error that it's locked... while not being able to break the lock
[17:11] <nekohayo> anyone knows what's going on in http://pastebin.ca/1353627 ?
[17:15] <jam> nekohayo: your lp:// url either needs 3 / or none
[17:15] <jam> bzr break-lock lp~woutc/specto/specto-woutc
[17:15] <jam> sorry
[17:15] <jam> bzr break-lock lp:~woutc/specto/specto-woutc
[17:15] <jam> or
[17:15] <jam> bzr break-lock lp:///~woutc/specto/specto-woutc
[17:16] <nekohayo> on the other hand, why was bazaar giving a false suggestion then?
[17:17] <jam> nekohayo: well, it was using a three / url, though it should have stripped the extra numbers from 'lp-XXXX'
[17:18] <nekohayo> is that a known bug?
[17:19] <jam> nekohayo: I believe I've seen that bug reported before, yes
[17:24] <nekohayo> jam: ah, https://bugs.launchpad.net/bzr/+bug/255062 I guess
[18:04] <jelmer> rocky, hi
[18:06] <seb_kuzminsky> i'm transitioning from a git repo to bzr, and i want to reorganize it a bit in the process
[18:06] <seb_kuzminsky> we've got an upstream tarball and a bunch of local patches
[18:07] <seb_kuzminsky> the old git repo has the contents of the tarball as its first commit
[18:07] <seb_kuzminsky> then a bunch of commits of locally-generated patches
[18:07] <seb_kuzminsky> then another patch from upstream, then more local stuff, etc
[18:07] <seb_kuzminsky> it's all in a single branch in the git repo
[18:08] <seb_kuzminsky> what i want in the new bzr repo is an "upstream" branch without any of our stuff in it, and a "local" branch
[18:08] <seb_kuzminsky> the local branch should ideally consist of a branch off the first upstream commit, then some local commits, then a merge from the second upstream commit, etc
[18:09] <seb_kuzminsky> but i'd settle for importing the old git repo as the "local" bzr branch, as long as I could sensibly diff and merge between upstream and local after the inital setup is done
[18:09] <seb_kuzminsky> so i used git-fast-export | bzr fast-import to turn the git repo into a bzr "local" branch, and that worked great
[18:09] <seb_kuzminsky> then i made an "upstream" branch and committed all of upstream's stuff there
[18:10] <seb_kuzminsky> but now when i diff between the bzr branches, it doesnt seem to think the identical files are identical...
[18:10] <seb_kuzminsky> it seems to (correctly) think that the upstream and local branches don't share history
[18:10] <seb_kuzminsky> so my question (finally!) is:  can i fool or bribe bzr into thinking that upstream and local are related now?
[18:11] <seb_kuzminsky> some kind of a fake merge perhaps?
[18:11] <jelmer> seb_kuzminsky, not afaik
[18:11] <seb_kuzminsky> :-(
[18:11] <jelmer> seb_kuzminsky, the only option you have is to recreate one of the two branches
[18:11] <seb_kuzminsky> what do you mean?
[18:11] <jelmer> and while recreating it using the same file ids the other branch is using
[18:14] <jfroy> morning
[18:15] <jfroy> I have a small patch to submit to bzr, is it as simple as using bzr send?
[18:16] <seb_kuzminsky> jelmer: i'd be happy to throw away the current broken bzr repo and re-create it in some new way, but i dont know how
[18:21] <jelmer> jfroy, yep
[18:21] <jfroy> Gotta provide an email now :p
[18:21] <jfroy> Send to<EMAIL_ADDRESS>[18:22] <jelmer> yep
[18:22] <jelmer> seb_kuzminsky, Unfortunately, I don't think there's a way to do that yet
[18:22] <jfroy> well that's awesome
[18:24] <seb_kuzminsky> jelmer: ok thanks, i'll just do it by hand
[18:24] <seb_kuzminsky> luckily our history is pretty short ;-)
[18:33] <rocky> jelmer: heyo
[18:38] <jelmer> rocky, was wondering if you could three revision properties in the cluemapper repo
[18:38] <jelmer> would be set by older (broken) versions of bzr-svn 0.5
[18:38] <jelmer> unsetting them would fix svn-import
[18:39] <jelmer> rocky, bzr:base-revision on r512
[18:41] <rocky> oh
[18:41] <rocky> that should be doable
[18:41] <rocky> "if you could three revision properties" ... think you missed a word there
[18:42] <jelmer> sorry
[18:42] <jelmer> if you could remove three revprops
[18:44] <rocky> what would be the easiest way to remove them?
[18:44] <rocky> and on what paths?
[18:52] <ilia> hi all
[18:52] <ilia> I have a question
[18:53] <ilia> anybody knows, how can I edit branch history? I need to change commiter's e-mails only.
[18:54] <beuno> ilia, you can't
[18:54] <beuno> it's immutable
[18:54] <beuno> you may be able to use bzr-rebase plugin, but it will make the branch incompatible with all the rest
[18:56] <jelmer> beuno, rebase doesn't change that sort of thing
[18:56] <jelmer> rocky, revision properties are set on the revision not on a particular path
[18:56] <jelmer> rocky, svn propdel -r512 --revprop bzr:base-revision <url> should do it
[18:58] <ilia> I have last 13 commits in a branch, which are my own
[18:58] <ilia> and I did it with wrong e-mail
[18:59] <ilia> I can branch from 13 revisions ago and make all changes in a single commit with a right e-mail, but it's an ugly solution
[19:00] <beuno> jelmer, it doesn't?  I thought it let you re-commit in a sense
[19:01] <rocky> jelmer: done
[19:01] <ilia> bueno, what do you mean by "incompatible"?
[19:03] <beuno> ilia, revision IDs change, so existing branches will be completely different and unmergeable
[19:04] <ilia> there were no new branches during last 13 revisions
[19:05] <rocky> jelmer: any part of Clue* you're most interested in ?
[19:05] <ilia> i.e. the revisions I want to edit are currently only in one branch
[19:06] <jelmer> rocky, just browsing
[19:07] <pfanelli> hey, i am trying to setup pqm and can't figure out what goes in the queue and how to get it in there
[19:07] <pfanelli> any ideas?
[19:09] <jelmer> rocky, seems to still be there
[19:10] <beuno> pfanelli, you have to send the location of a branch to PQM
[19:10] <beuno> which PQM should be able to access
[19:10] <beuno> you send those with the bzr-pqm plugin
[19:10] <beuno> which IIUC, it sends it in through RPC with a gpg signature
[19:12] <pfanelli> i am running bzr 1.12, i have the bzr-pqm and bzr-email plugins loaded, i setup the public and target branch settings in the .bazaar/locations.conf file...
[19:13] <pfanelli> i my 'work' branch, i am running 'bzr pqm-submit -m "pqm submit test"...
[19:14] <pfanelli> i also did the 'bzr pqm-submit with a dry-run - and i can see that the email that is going to be emailed to pqm is gpg'ed correctly
[19:14] <pfanelli> and the pqm user is getting the email
[19:14] <pfanelli> then i run the 'pqm -v -d --run' command, but i don't see anything in the queue
[19:14] <LarstiQ> pfanelli: pqm can be a bit difficult to setup
[19:15] <pfanelli> but i have to say that it is awesome
[19:15] <pfanelli> all of this sw is awesome :)
[19:15] <LarstiQ> thank you :)
[19:15] <pfanelli> you guys are fantastic (i have been trying to find a way to start helping you guys out)
[19:17] <pfanelli> started looking at bzr bugs, but not sure where to start
[19:20] <pfanelli> who would be the correct person to ask about setting up pqm?
[19:21] <rocky> jelmer: i issued your cmmand... .svn said property was deleted ... not sure what else
[19:22] <rocky> jelmer: is there a specific path i have to delete it from?
[19:22] <rocky> i'm just doing it at the root of the repo
[19:22] <LarstiQ> pfanelli: Odd_Bloke, lifeless and Kinnison have set up pqm before, but maybe I can try to help debug too
[19:23] <pfanelli> LarstiQ: cool/thx, i am sooooo close on this, just trying to figure out what to ask next :)
[19:24] <LarstiQ> pfanelli: does pqm need to pick the mail up and enter it in the queue maybe?
[19:24] <LarstiQ> pfanelli: the mail arrives for the pqm user, what happens next?
[19:24] <LarstiQ> pfanelli: is there a procmailrc involved?
[19:26] <jelmer> rocky, hmm, that's odd
[19:27] <pfanelli> i took a guess and thought maybe that when i would run 'pqm --run' that it would read the mail in /var/mail, but when i ran 'pqm -h' is said that --run would process the queue...
[19:27] <pfanelli> so that's what got me thinking that, there has to be something in the queue to process
[19:28] <jelmer> rocky, svn propget --revprop -r512 bzr:base-revision https://dev.serverzen.com/svn/cluemapper still works
[19:28] <pfanelli> i think i have a chicken-and-egg thing going on here 8)
[19:29] <LarstiQ> pfanelli: let me take a gander at the pqm source
[19:31] <rocky> jelmer: http://cluebin.appspot.com/pasted/89262
[19:31] <jelmer> rocky, it's lying!
[19:31] <jelmer> rocky, :-)
[19:31] <rocky> lol
[19:31] <jelmer> rocky, do you allow changing of revision properties in hooks/pre-revprop-change-hook ?
[19:32] <jelmer> rocky, you may have to temporarily edit that in order to be able to remove revision properties
[19:32] <jelmer> although it should also be giving you an error rather than silently ignoring you
[19:32] <rocky> jelmer: i've never intentionally changed anything in hooks/pre-*
[19:34] <rocky> jelmer: there is no pre-revprop-change script ... just the .tmpl one
[19:34] <jelmer> rocky, For now, you should be able to just create one that jsut does "exit 0"
[19:34] <jelmer> rocky, and remove it afterwards
[19:35] <rocky> k
[19:36] <pfanelli> LarstiQ: man that's a good idea, i am gonna' look at the unit tests for pqm (man, why didn't i think of this earlier)
[19:38] <rocky> bah, having ssh issues
[19:41] <jsled> I've a branch ("trunk") at revno 6797, and another ("remote") at 6667, which was the last point at which I sent a mergedirective to a coworker.  Why would `bzr send -o update ../trunk` report "Bundling 0 revision(s)."?
[19:48] <rocky> jelmer: ok, i think i've done it ;)
[19:48] <jelmer> rocky, thanks! :-)
[19:49] <jelmer> jsled, there are no revisions in remote that are not in trunk
[19:49] <jsled> Ah.  Cause I'm exactly backwards.  *ahem*  Sorry.
[19:51] <jsled> jelmer: thanks.
[19:55] <jelmer> rocky, the second one is r589, for which bzr:base-revision should also be removed
[19:55] <rocky> jelmer: i just removed that file =P
[19:55] <jelmer> rocky, s/file/property ?
[19:56] <mwhudson> good morning
[19:56] <jelmer> hey mwhudson, abentley
[19:56] <abentley> jelmer: morning.
[19:56] <jelmer> abentley, could you give bundlebuggy a kick?
[19:56] <jelmer> it doesn't seem to be responding atm
[19:56] <rocky> jelmer: no, the pre hook file that allowed me to delete the rev properties =P
[19:57] <jelmer> rocky, ahh :-)
[19:57] <jelmer> rocky, sorry
[19:57] <jelmer> rocky, bzr check said there were 3 such revisions
[19:57] <rocky> ah ok
[19:57] <jelmer> rocky, so there should be another one after the one I just reported
[19:57] <rocky> jelmer: ok, that one's removed
[19:57] <abentley> jelmer: restarted
[19:58] <jelmer> abentley, thanks
[19:58] <jelmer> rocky, thanks
[20:11] <jelmer> rocky, the last one is r591
[20:12] <rocky> jelmer: done
[20:18] <jelmer> rocky, merci
[20:20] <jelmer> jfroy, how are you using the netrc plugin?
[20:32] <jfroy> jelmer: sorry back
[20:32] <jfroy> I'm using using netrc myself
[20:32] <jfroy> But the code is clear
[20:33]  * jfroy pasted http://pastie.textmate.org/408694
[20:33] <jfroy> it at minimum expects a 'host' key in the credentials dictionary
[20:33] <LarstiQ> oh, that sounds familiar
[20:33] <jfroy> and the netrc tests synthesize credential dictionaries with a 'host' key set.
[20:34] <LarstiQ> did I not report that bug? :(
[20:34] <jfroy> however AuthorizationConfig never did set that
[20:34] <jfroy> LarstiQ: maybe :p I honestly didn't check.
[20:34] <jfroy> My patch was written with my keychain credential store plug-in in mind, but also conforms to the expectations of the netrc plug-in.
[20:34] <LarstiQ> jfroy: it's entirely possible, bad larstiq has not been getting to many things on his todo list
[20:35] <fullermd> That keeps other things on the list from getting lonely.
[20:38] <LarstiQ> yes, but any time now they might petition the UN for recognition of their own nation.
[20:39] <fullermd> Hah!  Fat chance.    Clenching the iron fist.
[20:47] <pigmej> Hi everyone,
[20:47] <pigmej> How to get commit message from bzrlib ?
[20:48] <LarstiQ> pigmej: for a given revision?
[20:48] <pigmej> Yes
[20:48] <pigmej> I cannot find that in docs...
[20:49] <LarstiQ> pigmej: revision.message
[20:49] <pigmej> hmmm
[20:50] <LarstiQ> pigmej: say, 'from bzrlib.workingtree import WorkingTree; tree = WorkingTree.open('"."); print tree.branch.repository.get_revision(tree.last_revision()).message
[20:50] <pigmej> Hmm
[20:51] <pigmej> I'm going in other way...
[20:51] <pigmej> like
[20:51] <pigmej> my_branch=branch.Branch.open(....)
[20:51] <pigmej> repo=my_branch.repository
[20:51] <pigmej> repo.lock_write()
[20:52] <pigmej> and then revtree=repo.revision_tree(rev_id)
[20:53] <pigmej> rev_id is previously set to my_branch.last_revision() in that "example"
[20:53] <pigmej> is it better to go trough WorkingTree?
[20:53] <pigmej> i need branches "support"
[20:55] <LarstiQ> no, this is fine
[20:55] <LarstiQ> so then
[20:55] <LarstiQ> repo.get_revision(rev_id).message
[20:56] <pigmej> thanks ;)
[20:56] <pigmej> btw I think that the better api documentation is needed ;d
[20:56] <LarstiQ> pigmej: revision_tree() gets you the RevisionTree of that revision, not the Revision object itself
[20:57] <LarstiQ> pigmej: where did you look to find this information?
[20:57] <LarstiQ> pigmej: ie, what do we need to change to have better helped you?
[20:57] <LarstiQ> pigmej: patches welcome btw ;)
[20:57] <pigmej> http://starship.python.net/crew/mwh/bzrlibapi/
[20:57] <pigmej> here for example ;d
[20:57] <pigmej> and there http://bazaar-vcs.org/BzrGivingBack
[20:58] <LarstiQ> ok, and then, at what pieces of that did you look?
[20:58] <pigmej> LarstiQ: Finally i fetch
[20:58] <pigmej> revison=revtree.inventory()
[21:04] <pigmej> LarstiQ: anyway what is the best way to fech binary files content ?
[21:09] <LarstiQ> pigmej: I don't know about "best", but I'd do "fileid = revtree.path2id('NEWS'); fileobj = revtree.get_file(fileid)"
[21:09] <pigmej> LarstiQ: so the same way that me :d
[21:09] <pigmej> I'm going to write some bzr_wiki ;-)
[21:10] <pigmej> web wiki engine managed via bzr ;)
[21:10] <pigmej> just for fun ;d
[21:10] <LarstiQ> pigmej: ah ok, cool :)
[21:10] <LarstiQ> pigmej: I don't know how up to date the ikiwiki bzr backend is, but you could look at that too
[21:11] <LarstiQ> pigmej: but keep us posted about your progress :)
[21:11] <pigmej> LarstiQ: mine "bzr_wiki" in final ver should have full web access to naturally
[21:11] <pigmej> I will see :)
[21:15] <LarstiQ> pigmej: are you aware of http://bazaar-vcs.org/Integrating_with_Bazaar btw?
[21:16] <pigmej> I have read this :)
[21:17] <pigmej> From that I have revtree ;-)
[21:17] <LarstiQ> ok :)
[21:20] <ferringb> curious, anyone seen failed locks w/ "Transport operation not possible: readonly transport" when doing bzr pull $URL -d $CHECKOUT , yet have it succeed fine when doing cd ${CHECKOUT} & bzr pull $URL # ?
[21:46] <poolie> ferringb: that is strange
[21:46]  * ferringb thought so
[21:47] <ferringb> solution atm is to kill the checkout, which sucks a bit though
[21:47] <poolie> ferringb: does it tell you which transport is readonly? or does the traceback in ~/.bzr.log  give any clues?
[21:47] <ferringb> forgot about ~/.bzr.log
[21:47] <poolie> is it a checkout bound to another branch?
[21:47] <ferringb> sec
[21:49] <jam> morning poolie
[21:54] <ferringb> poolie: remote, bzr server is chucking it
[21:54] <poolie> hello jam
[22:00] <ferringb> poolie: re: checkout bound to another branch, if by that you mean is the checkout w/in a repo... yes, tis.
[22:01] <ferringb> the branch it's pulling from, that side has a similar setup although I'd expect bzr server to handle that- the odd thing is that bzr-server does lack write perms to those directories (intentionally since commits aren't routed through it since when we deployed it bzr-server was raw and questionable), although those issues aren't seen for other ops
[22:28] <pfanelli> this stuff (bzr, pqm, cm, etc...) is fantastic!  I have been working today trying to get pqm setup and working with bzr. I forgot the link in pqm over to the bzr code. I ran the pqm tests and it said I was using 1.13 but needed 1.12. So I ran 'bzr revert -r date:2009-02-13' on my bzr.dev and presto it works.  That's the motto 'it just works'.  Fantastic :)
[23:01] <ferringb> poolie: figured out an additional naggle actually. that co came from a different upstream branch, iow foon.com/repo1, the pull --overwrite fails when it attempts foon.com/repo2 over the same co
[23:07] <spiv> jam: btw, the numbers for time spent generating a stream for the network are 22% in fileids_altered_by_revision_ids, and 16% because _read_records_iter_raw is used rather than _read_records_iter_unchecked
[23:20] <pfanelli> another pqm ?...I have the 'mail_reply=1' set in my .pqm.conf file, but when I run 'pqm -v -d --run --report' i am not seeing any mail reply?  Any ideas why?
[23:54] <pfanelli> any pqm guru's out there? Is this a bad time of the day/night/
[23:54] <pfanelli> ?


[07:42] <dholbach> good morning
[08:14] <elfy> morning dholbach dpm
[08:14] <dholbach> hi elfy
[08:40] <popey> morning
[08:42] <dholbach> hey popey - how are you doing today?
[08:43] <popey> better thanks
[08:44] <popey> co-working with czajkowski today
[08:44] <dholbach> oh nice - where are you two hanging out?
[08:45] <popey> at her house.
[08:45] <popey> she's making breakfast
[08:45] <dholbach> very nice :)
[08:45] <dholbach> and good to hear you're doing better!
[09:01] <dpm> morning elfy
[09:23] <czajkowski> fresh scrambled eggs
[09:23] <czajkowski> nyommy :D
[09:27] <popey> very
[13:12] <dholbach> dpm, mhall119, balloons, popey: who's doing the Q&A today?
[13:13] <popey> I did last week with balloons :)
[13:13] <popey> (which was great fun)
[13:17] <dholbach> mhall119, dpm: you up for a session today?
[13:26] <dpm> dholbach, yep, I'm up for it
[13:26] <dholbach> cool
[14:13] <mhall119> dholbach: sure
[14:13] <mhall119> czajkowski: yup, hung out at the bar for a bit, seems like a great guy
[14:13] <dholbach> mhall119, dpm: I'm happy either way - who of us is going to do it? all 3 of us?
[14:14] <mhall119> I'll be on today, so I don't need to be on next week
[14:14] <dpm> dholbach, the 3 of us sounds like fun if everyone is happy to join, but as long as there is 2 of us, we should be good to go
[14:15] <dpm> I'll definitely join as I've missed at least the last two
[14:41] <czajkowski> mhall119: looking for a name in the florida loco that is not chris
[14:41] <czajkowski> but has a wife and kids and has been in your house when I'm there
[14:41] <czajkowski> and goes to google IO
[14:42] <mhall119> dan trevino?
[14:43] <mhall119> donald organ?
[14:43] <mhall119> really, there have been a lot of people from our loco with a wife and kids who have been in my house
[14:43] <czajkowski> that's it
[14:43] <czajkowski> dan
[14:43] <mhall119> he's not in Florida anymore though
[14:43] <czajkowski> but not all who go to google ip
[14:43] <czajkowski> IO
[14:43] <czajkowski> mhall119: oh where's he gone to ?
[14:43] <mhall119> yeah, but I couldn't remember who alldid
[14:44] <mhall119> he's moved to California I think
[14:44] <mhall119> somewhere out west
[14:44] <mhall119> a few years ago
[14:44] <mhall119> might be working for Google now, I don't really know
[14:46] <czajkowski> mhall119: got an email address for him :D
[14:49] <czajkowski> found him on G+
[14:50] <mhall119> dantrevino is his LP address, so @ubuntu.com should work
[14:50] <czajkowski> mhall119: cheers
[14:50] <mhall119> :)
[15:43] <dpm> mhall119, the Q&A today will be a great opportunity to explain how the ubucon and scale went :)
[15:43] <dholbach> dpm, mhall119: did one of you set up the event and everything?
[15:44] <dpm> dholbach, I haven't, but I've finished what I was doing and can do it now
[15:44] <dholbach> as you like it - I can to it too
[15:44] <dpm> no worries, setting it up now
[15:44] <dholbach> cool
[15:45] <mhall119> dholbach: not I
[15:45] <dholbach> looks like dpm's on it
[15:50] <dpm> mhall119, dholbach, event created and ubuntuonair.com updated. Do you guys want to share on G+ and FB?
[15:58] <dholbach> yep
[17:02] <dholbach> all right... I call it a day - see you all tomorrow! :)
[17:03] <czajkowski> toodle pip dholbach
[17:03] <dholbach> hugs!
[17:15]  * ejat brb


[07:36] <popey> bug 1256797
[07:49] <didrocks> popey: hey, have you tried to only update the second one?
[07:49] <didrocks> (just to see if it creates a bug)
[07:50] <popey> no
[07:50] <popey> i didnt spot it till someone made a comment on G+
[07:50] <popey> -> afk
[08:32]  * popey returns
[08:35] <didrocks> popey: I think this applicaiton is going EOD anyway
[08:35] <didrocks> it will be merged in the system settings panel
[08:36] <popey> *excellent*
[09:00] <ogra_> how about a new build ?
[09:00]  * ogra_ sees an NM upload
[09:02]  * ogra_ fires one off
[09:02] <ogra_> [09:03] <popey> \o/
[09:05] <ogra_> hmm, looking at all these _qmlscene.crash file i wonder if the new UITK broke someting
[09:07] <didrocks> ogra_: it was in the previous UITK, so not in the last last at least
[09:07] <ogra_> ok
[09:07] <didrocks> I think Mirv is looking at them since Friday
[09:28] <Mirv> the backtrace was pointing a bit in mir's direction, but I need to look again
[09:58] <Mirv> so... I filed bug #1256837, but apport actually pointed out I had filed a similar bug already before image 30, on 2013-10-23 at bug #1243665
[09:58] <Mirv> and assigned it to qtubuntu
[10:04] <didrocks> Mirv: you are tracking that with upstream qtubuntu then?
[10:05] <didrocks> Mirv: sil2100: think about updating in the landing spreadsheet as well :)
[10:12] <Mirv> didrocks: yes, although folks may be at a sprint this week
[10:13] <didrocks> Mirv: qtubuntu can be seen by ricmm as well
[10:13] <Mirv> ok
[10:45] <psivaa> ogra_: not sure if phablet-flash also writes the installation logs normally to /var/log/installer/ but like desktop images, after the rsyslog upgrade they are not copied there anymore
[10:45] <ogra_> no, it doesnt
[10:45] <ogra_> the only thing putting something there is livecd-rootfs itself
[10:45] <ogra_> during build
[10:46] <psivaa> ahh, ok
[10:50] <popey> [10:50] <popey> ☻
[10:52] <ogra_> lol
[10:52] <ogra_> thanks
[11:16] <ogra_> 41 still has no kbd coming up and i see thw date bug in the massage indicator for the first time here
[11:17] <ogra_> *the
[11:17] <ogra_> (recieved at 01 Jan 1970 ... 00:10)
[11:17] <ogra_> (this is on maguro indeed)
[11:31] <seb128> g
[11:32] <ogra_> h
[11:33] <t1mp> is the current trusty-proposed image good?
[11:33] <t1mp> if yes, then I flash nwo.
[11:33] <t1mp> *now
[11:34] <ogra_> it boots ... if you mean that
[11:34] <t1mp> ogra_: I mean it doesn't break any important stuff :)
[11:34] <t1mp> I'll flash and have a look.
[11:34] <ogra_> yeah, do that
[12:22] <psivaa> didrocks: I tried to report a bug for mediaplayer-app crash with maguro after retracing on bug 1256902
[12:22] <psivaa> bug we see 'Backtrace stopped: previous frame identical to this frame (corrupt stack?)'
[12:23] <didrocks> psivaa: yeah, most of the time, it's because you miss some debug symbols
[12:23] <didrocks> (no idea why it will unblock it, but it does in practice)
[12:24] <didrocks> psivaa: so, try to install sdk debug symbols, and some qt one maybe
[12:24] <psivaa> didrocks: ack
[12:27] <ogra_> didrocks, i just merged cdimage support for emulator images from rsalveti and would like to do a test build ... and objections ?
[12:28] <ogra_> *any
[12:28] <rsalveti> \o/
[12:31] <didrocks> ogra_: none
[12:32] <didrocks> please go ahead :)
[12:33] <ogra_> [12:36] <psivaa> didrocks: ogra_: r41 tests are still running and i think will be running when r42 is done as well. Do you want me to abort the tests on 41 and let 42 run on them when it's available?
[12:36] <ogra_> oh, crap, sorry. forgot about this
[12:37] <psivaa> :)
[12:37] <psivaa> that's ok, we could delay running the tests on 42 if that's needed
[12:37] <ogra_> well, whatever is less work for you
[12:38] <psivaa> either way is fine for me, the question is that we need a full report on r41
[12:38] <psivaa> if we need a full report i mean
[12:38] <ogra_> i dont think we do ... there was only one package changed vy r40
[12:38] <ogra_> *vs
[12:39] <ogra_> it shouldnt actually differ from 40
[12:39] <psivaa> ack, then once 42 comes in i'll abort the tests on 41
[12:39] <ogra_> ++
[12:39] <psivaa> thanks :)
[12:41] <didrocks> (sounds legit)
[12:41] <rsalveti> ogra_: what is the kdb issue with 41 you said above?
[12:41] <rsalveti> ogra_: do we have a bug for it?
[12:41]  * rsalveti flashing 41
[12:41] <ogra_> rsalveti, no OSK at all on non english locales
[12:41] <didrocks> rsalveti: if you are using a lang != english, it doesn't come up
[12:42] <rsalveti> oh, ok
[12:42] <ogra_> yeah, there is a bug for it
[12:42] <didrocks> rsalveti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyboard/+bug/1255999
[12:42] <rsalveti> great, thanks
[12:42] <didrocks> yw, osomon may have more info today on it
[12:42] <davmor2> didrocks: Morning dude any preference on what Image I test today?
[12:43] <didrocks> davmor2: hey! a new image is coming shortly (already building), I would prefer than one
[12:43] <didrocks> davmor2: image 42 can't go untested :)
[12:43] <ogra_> well, we  *hope* there will be a 42 shortly ... its actually a test build :)
[12:44] <davmor2> didrocks, ogra_: no worries I go for lunch in a minute so just give me a ping when it's up.  I'm going for a fresh phablet-flash with it anyway :)
[12:44] <didrocks> excellent!
[12:45] <popey> 42 is the answer to the ultimate question of course.
[12:59] <sil2100> GPU hangup broke fonts on my system, need a reboot - brb
[13:21] <ogra_> rsalveti, http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20131202.1/
[13:21] <ogra_> :D
[13:21] <ogra_> we has a goldfish !
[13:22]  * ogra_ looks for a fishbowl to put it in
[13:22] <rsalveti> ogra_: great!
[13:22] <rsalveti> ogra_: thanks for the review & merge
[13:22] <ogra_> thanks for the code and the cleanup !!!
[13:23] <ogra_> (specifically for the latter ... we all know my code usually needs that ;) )
[13:23] <rsalveti> :-)
[13:23] <rsalveti> just weird that there's no recovery for goldfish
[13:23] <rsalveti> seems to be missing, but I remember that it was also created by the android package
[13:23] <rsalveti> let me check
[13:24] <ogra_> hmm, livecd-rootfs should have failed
[13:24] <rsalveti> right
[13:24] <ogra_> if there was none
[13:24] <ogra_> i only have an || true for the zzip in place there
[13:24] <ogra_> (whichi'll remove now)
[13:24] <rsalveti> which is indeed more interesting
[13:25]  * rsalveti looks for the livebuild and cdimage logs
[13:25] <ogra_> [TXT] livecd.ubuntu-touch.manifest                                     02-Dec-2013 13:10  35K
[13:25] <ogra_> [ ]   livecd.ubuntu-touch.recovery-armel+goldfish-20131202.1-armhf.img 02-Dec-2013 13:12 5.1M
[13:25] <ogra_> [ ]   livecd.ubuntu-touch.recovery-armel+goldfish.img                  02-Dec-2013 13:12 5.1M
[13:25] <ogra_> [ ]   livecd.ubuntu-touch.recovery-armel+grouper-20131202.1-armhf.img  02-Dec-2013 13:12 7.0M
[13:25] <ogra_> [ ]
[13:25] <ogra_> all there on the livefs builder
[13:26] <ogra_> so it is cdimage
[13:27] <rsalveti> 2013-12-02 13:13:17 URL:http://kishi00.buildd/~buildd/LiveCD/trusty/ubuntu-touch/current/livecd.ubuntu-touch.recovery-armel+goldfish.img [5349376/5349376] -> "/srv/cdimage.ubuntu.com/scratch/ubuntu-touch/trusty/daily-preinstalled/live/recovery-armel+goldfish.img" [1]
[13:27] <ogra_> right, it wgets it ... but does it publish it too ?
[13:27] <rsalveti> checking
[13:28] <rsalveti> Publishing trusty-preinstalled-boot-armhf+maguro.img ...
[13:28] <rsalveti> Publishing trusty-preinstalled-system-armel+maguro.img ...
[13:28] <rsalveti> Publishing trusty-preinstalled-touch-armel+maguro.zip ...
[13:28] <rsalveti> doesn't publish any recovery file for any device
[13:28] <rsalveti> just boot + system + zip
[13:28] <ogra_> hmm
[13:28] <ogra_> it did on the build before
[13:29] <ogra_> so something is wrong with your code here
[13:29] <rsalveti> but why did we get the recovery img for maguro/mako/manta?
[13:29] <rsalveti> and grouper
[13:29] <ogra_> yes
[13:30] <ogra_> 20131202.log has them
[13:30] <ogra_> 20131202.1.log doesnt
[13:30] <rsalveti> let me check
[13:30] <ogra_> ogra@nusakan:~$ grep mako /srv/cdimage.ubuntu.com/log/ubuntu-touch/trusty/daily-preinstalled-20131202.log |grep recovery
[13:30] <ogra_> 2013-12-02 09:42:59 URL:http://kishi00.buildd/~buildd/LiveCD/trusty/ubuntu-touch/current/livecd.ubuntu-touch.recovery-armel+mako.img [8814592/8814592] -> "/srv/cdimage.ubuntu.com/scratch/ubuntu-touch/trusty/daily-preinstalled/live/recovery-armel+mako.img" [1]
[13:30] <ogra_> Publishing trusty-preinstalled-recovery-armel+mako.img ...
[13:31] <ogra_> same for the others ...
[13:31] <rsalveti> yeah, interesting
[13:32] <rsalveti> a bug in my code probably
[13:32] <rsalveti> let me check the code to see
[13:32] <rsalveti> at least it's copying over the files, might be missing something when publishing them
[13:32] <ogra_> right, thats what i would suspect
[13:57] <ogra_> rsalveti,  so looking at lib/cdimage/tree.py lines 1833 to 1843 i see some discrepancy between ubuntu_arch and android_arch usage
[13:57] <rsalveti> ogra_: https://code.launchpad.net/~rsalveti/ubuntu-cdimage/fix-recovery-android-arch/+merge/197372
[13:58] <rsalveti> ogra_: yeah, I tried to post the mr link by fighting with my irc server
[13:58] <ogra_> yeah, exactky that :)
[13:58] <rsalveti> *but
[13:58] <ogra_> now, why did it publish the other arches
[13:58] <rsalveti> ogra_: it shouldn't right? maybe the files were already there
[13:59] <rsalveti> maybe we're not cleaning them up or such
[13:59] <ogra_> 02-Dec-2013 09:43
[13:59] <ogra_> hah !
[13:59] <ogra_> they are from the former build
[13:59] <ogra_> 02-Dec-2013 13:13 ... would be the right stamp
[13:59] <ogra_> yeah
[13:59] <rsalveti> right
[14:00] <rsalveti> ogra_: mind reviewing & merging that mr? next build should be fine :-)
[14:00] <ogra_> on it
[14:00] <rsalveti> awesome, thanks so much
[14:00]  * rsalveti takes a short break
[14:01] <ogra_> done
[14:10] <davmor2> ogra_, didrocks: okay so phone see 42 but I see no tests for it
[14:10] <didrocks> davmor2: what do you mean by no test for it?
[14:11] <ogra_> davmor2, dashboard is delayed by quite some time
[14:11] <davmor2> didrocks: no automation here http://ci.ubuntu.com/smokeng/
[14:11] <didrocks> davmor2: I think they are still not published
[14:11] <davmor2> ogra_: ah that is why then thanks
[14:12] <davmor2> didrocks: is it safe to start running tests on though?  Or do you want me to wait till the automation is run?
[14:13] <didrocks> davmor2: yes please do :)
[14:14] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20131202.1.changes
[14:14] <ogra_> btw ...
[14:14] <ogra_> (thats the r42 changeset ... )
[14:14] <sergiusens> ogra_, those are a nice changeset
[14:15] <davmor2> ogra_: so nothing then
[14:15] <ogra_> right
[14:15] <ogra_> r41 is nearly as big http://people.canonical.com/~ogra/touch-image-stats/20131202.changes
[14:15] <ogra_> :P
[14:20] <psivaa> ogra_: didrocks davmor2: the r42 installation for the dashboard is delayed for jenkins to have some free executors, they are in the queue though
[14:20] <davmor2> psivaa: thanks
[14:21] <fginther> morning
[14:40] <rsalveti> ogra_: thanks
[14:41] <ogra_> i assume you want another test build to see if it works
[14:41] <ogra_> (but lets wait for the tests to be done this time i think ... )
[14:41] <rsalveti> ogra_: yeah, we can wait a few hours, no problem
[14:46] <psivaa> didrocks: ogra_: we have some jenkins issues that still delays image r42 results. retoaded is working on it
[14:47] <ogra_> psivaa, well, you could also kill r42 and i coulld roll an r43 :)
[14:47] <ogra_> there is another cdimage fix that could need a test build (but there is no hurry, it can as well wait a few hours)
[14:48] <psivaa> ogra_: feel free. r42 trigger had issues in jenkins. so when r43 comes. that will automatically be picked up if the jenkins is up by then
[14:49] <ogra_> oh, awesome, ... so yes, lets build an r43
[14:50] <ogra_> [14:50] <ogra_> that should give us the full emulator love now :)
[15:03] <rsalveti> cool
[15:32] <ogra_> rsalveti, http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20131202.2/ all fine now it seems
[15:33] <rsalveti> ogra_: awesome, thanks!
[15:33] <ogra_> now we just need stgraber
[15:35] <ogra_> any new crash files in /var/crash ?
[15:52] <kalikiana_> who would be savvy on how jenkins strips console logs? as it bit me again by hiding large chunks of the real error in here https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-amd64/1238/console
[15:56] <fginther> cyphermox, can this be deleted? https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/indicator-network-tests/+merge/178797
[15:56] <cyphermox> yeah whatever
[15:56] <cyphermox> I'll look at that again some other time and file a new one if needs be
[15:56] <cyphermox> I deleted it
[15:56] <fginther> thanks
[16:13] <kalikiana_> fginther: do you know why/ how Jenkins strips logs? it's caused considerable confusion again by removing the gist of the failure…
[16:15] <fginther> kalikiana_, jenkins is not doing anything to strip the console logs. What data did you find missing and can it be reproduced using pbuilder?
[16:15] <kalikiana_> fginther: well I see the missing bits under "unformatted" so clearly it removes something
[16:16] <kalikiana_> nothing like that happens using 'bzr bd'
[16:18] <kalikiana_> fginther: in this particular case "Totals: 21 passed, 4 failed, 0 skipped" and foregoing test results as missing
[16:20] <fginther> kalikiana_, can you explain "unformatted" more? is that an artifact? is it being generated somewhere else? I'm just trying to find it to get more context
[16:22] <fginther> kalikiana_, are you referring to 1238/consoleText vs 1238/console ?
[16:22] <kalikiana_> fginther: sorry I just guesses the english name since it's localized. it's in the left sidebar, back to project/ status/ changes/ console output
[16:22] <kalikiana_> and in parentheses it has a link for raw logs
[16:22] <fginther> kalikiana_, ahhh
[16:23] <fginther> kalikiana_, right. jenkins does only show the last XXKB of the console log through the console link
[16:24] <fginther> kalikiana_, that's primarily to save bandwidth when using the web UI
[16:24] <kalikiana_> oh. so it literally stops when it's too much regardless of what's there?
[16:25] <kalikiana_> fginther: confusingly it looks very seemless… not sure if it really just cuts
[16:25] <fginther> kalikiana_, right, I'm not sure what the amount is or even if it is configurable. The full log is always available via the unformatted link
[16:26] <fginther> kalikiana_, In my local version, it starts with "Skipping 901 KB.."
[16:26] <fginther> and then a link to the full log
[16:27] <kalikiana_> fginther: yes I see that sentence. but then go to the bottom and you will not think anything is missing
[16:27] <fginther> kalikiana_, my apologies for being confused by your question, didn't think about the links having different names
[16:28]  * kalikiana_ makes a diff of the logs to see where it's cut
[16:41] <kalikiana_> oh my, I think there might be a typo causing it to not abort with the right return value
[16:41] <kalikiana_> that could explain the results after the failure…
[16:42] <kalikiana_> fginther: thanks for clarifying I'll see if this really is mainly due to that typo and maybe what can be done to reduce the output in general
[16:45] <fginther> kalikiana_, you're welcome, let me know if I can help in any way
[17:02] <didrocks> psivaa: robru: coming?
[17:02] <didrocks> kenvandine: ^
[17:03] <psivaa> didrocks: i dont normally attend the afternoon meeting. if you give me the link i could attend since plars is off today
[17:03] <didrocks> psivaa: https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV91cTRvNmQyMWJvNmJ0bm1mcW9xZWtsNTdnOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.cg7k3h1nmqml7psc1nn68223i0
[17:18] <psivaa> didrocks: i dont think notes app test hanging is due to infrastructure issues, if that's what your question was :)
[17:19] <psivaa> sorry my audio input still had issues..
[17:20] <sil2100> ogra_: if I have a build image date, how can I get the build number for that image? ;)
[17:20] <sil2100> ogra_: i.e. 20131129.2
[17:22] <ogra_> sil2100, http://system-image.ubuntu.com/trusty-proposed/mako/index.json
[17:22] <sil2100> ogra_: awesome, thanks!
[17:22] <sil2100> :)
[17:23] <ogra_> ubuntu= is the cdimage version, device= is the android version and version= is the image version as we use it
[17:26] <didrocks> psivaa: excellent, all what I wanted to know!
[17:26] <didrocks> thanks :)
[17:26] <psivaa> didrocks: yw :)
[17:31] <robru> Mirv, what are the steps to reproduce https://bugs.launchpad.net/qtubuntu/+bug/1243665
[20:09] <popey> bug 1257048


[00:55] <Legojoey> Does anyone think they can help me out? A fresh install of Lubuntu on a computer and it's unable or won't connect to a wired network.
[01:01] <KM0201> won'tconnect to a wired network?
[01:02] <KM0201> i wouldn't really have any idea how to trouble shoot that, has it worked on other versions of linux?
[01:10] <Legojoey> Yeah although last time I used the computer being talked about was a year ago.
[01:10] <Legojoey> I've tried stopping /ect/init.d/networking and it said there was no service, may give a go at reinstall cause looking at stuff that should be there =/
[02:57] <cleaninstall> hi folks
[04:29]  * wxl yawns
[05:05] <wxl> so let's assume i have two distros installed on separate partitions of the same drive. can i copy the UUID for swap fom the other distro and use it in /etc/fstab and all is well? cuz it don't seem to be working.
[05:06] <JohnDoe_71Rus> i think its already done
[05:06] <JohnDoe_71Rus> even livecd find swap on hdd
[05:07] <wxl> well i installed lubuntu then mint and when i did the latter i didn't reuse swap and happened to notice that there was no swap, so i set it up.. and now don't have any swap in lubuntu
[05:10] <cleaninstall> i stepped in the middle, you have no swap partition?
[05:11] <cleaninstall> or lub just doesnt see it
[05:11] <JohnDoe_71Rus> wxl: check this /etc/initramfs-tools/conf.d/resume
[05:11] <JohnDoe_71Rus> need uuid swap
[05:12] <JohnDoe_71Rus> after sudo mkinitramfs -o /boot/initrd.img-$(uname -r)
[05:12] <cleaninstall> did you use whole drive in install?  (read a bug about whole drive and swap)
[05:24] <wxl> JohnDoe_71Rus: run that by me a little slower this time so i know what i'm looking at :D
[05:27] <JohnDoe_71Rus> swap record in .../resume need for sleep and hibernate
[05:47] <Ascavasaion> Morning wxl ... do you never sleep? :)
[05:49] <Ascavasaion> 07:48am here in South Africa.
[08:10] <joep_> I have a simple(?) question: How do I get my taskbar visible on all (4) desktops?
[08:17] <brother-> joep_: you don't leave before we tell you how...
[08:17] <brother-> bah
[08:22] <JohnDoe_71Rus> i have ubuntu 10.04. install lxde lubuntu-desktop... setup gdm and login session lubuntu. i want change gdm to lxdm. but if i login in lxdm, get message "can't find lubuntu session" and login in default gnome session
[08:43] <leszek> hi
[08:43] <bioterror> hi
[09:26] <l33_> lubuntu shows wrong and outdated files on usb memory sticks in the filemanager - when using midnightcommander in a shell, the correct files arte
[09:26] <l33_> listed
[09:37] <leszek> l33_: did you refresh the view in the filemanager ?
[09:39] <l33_> yes sure
[09:39] <l33_> also formatted ste stick
[09:39] <l33_> formatted even the mbr /guid
[09:40] <l33_> no chance - still the outdated files are listed
[09:41] <l33_> being thankfull i dont want to yearn about any little minor buggy bug - but this seems serious
[09:47] <leszek> l33_: hmm.. are you sure you unmounted the filesystem ?
[09:47] <leszek> l33_: make sure to unmount and mount it properly by hand.
[09:47] <l33_> yes
[09:47] <l33_> i do
[09:47] <l33_> otherwise i cant format the usb stick with the disc utility
[09:47] <leszek> thats very strange
[09:48] <leszek> is it a special usb stick(i.e. u3) or a normal one
[09:54] <l33_> yes
[09:54] <l33_> its a shitty sandisk i guess with u3
[09:54] <l33_> with U3
[09:55] <leszek> l33_: then it might be the problem
[09:56] <leszek> I really recommened you to try removing the u3 part and test this behavior again
[09:56] <l33_> yes, but how?
[09:56] <leszek> l33_: with the u3-tool (download this package)
[09:57] <l33_> i do so
[09:57] <l33_> and if you like i will give you short info about the progress
[09:57] <leszek> :)
[09:57] <l33_> i need a good corsair stick i know
[09:57] <leszek> the command for removing the cd partition (u3 part) should be
[09:58] <leszek> u3-tool -p 0 /dev/<yourstick>
[09:58] <l33_> aaa
[09:58] <l33_> k
[09:58] <leszek> you need to execute this as root
[09:58] <leszek> so with sudo
[09:58] <l33_> fist installing u3 tool
[09:58] <leszek> make sure no partition is mounted
[09:58] <l33_> sure with sudo
[09:58] <l33_> sure - not mounted
[09:58] <l33_> thank you :)
[09:59] <leszek> np :)
[10:07] <Tabmow> How can I install lubuntu on my oneirc ubuntu installation?
[10:08] <leszek> sudo apt-get install lubuntu-desktop
[10:08] <Tabmow> Doesn't work for me...
[10:08] <Tabmow> Says there is no package
[10:09] <bioterror> sudo apt-get update && sudo apt-get install lubuntu-desktop --no-install-recommends
[10:12] <l33_> or just install lxde..so you wont install all the stuff you probably wont need
[10:12] <bioterror> then he should install lubuntu-core
[10:13] <bioterror> right?
[10:14] <l33_> i would then install just lxde
[10:21] <l33_> dont get me wrong -  i am using lubuntu here and i like it
[10:22] <l33_> but on an installed ubuntu i would just install the lxde ....
[14:14] <chrstphrhrt> hi there, I did the minimal install but grub failed to be installed. anyone run into this before?
[14:14] <chrstphrhrt> wanting to get to just lubuntu-core
[14:18] <stlsaint> chrstphrhrt: you can install grub from the live cd if need be
[14:18] <chrstphrhrt> yeah i'll try that
[16:05] <Osmodivs> Hello. I just installed Lubuntu on my Netbook, but there is no reboot option, What package do I need to install?
[17:01] <l33_> bye
[17:20] <goliat> Hi. I'm having problems playing higher quality videos on the Internet, like youtube. Im getting lag on the videos. Can it be flashplayer acting up?
[17:29] <wxl> goliat: tried html5?
[17:47] <goliat> wxl:How can i try that?
[17:48] <wxl> goliat: https://www.youtube.com/html5
[18:04] <goliat> wxl: Doesn't seem to help. I have lag when i play 720p
[18:12] <goliat> wxl: Im thinking it i'm getting lag because flashplayer is the 32-bit version. Could it help if i tried getting 64-bit flash player?
[18:12] <wxl> goliat: not sure but i'd give it a try
[18:18] <KM0201> why are you using 32bit fash on a 64bit OS?
[18:40] <goliat> KM0201: I think it gets installed by standard. Or is there any way i can check the version?
[18:40] <KM0201> um, i think you can open a browser and :about
[18:41] <KM0201> woops, i mean  about:
[18:41] <bioterror> gsus :D
[18:41] <KM0201> ?
[18:42] <bioterror> apt-cache show flashplugin |more
[18:42] <bioterror> for example
[18:42] <wxl> jesus = gsus?
[18:42] <KM0201> yeah
[18:42] <bioterror> should tell you are you using i686 or amd64
[18:42] <KM0201> oh, i always forget about apt-cache
[18:44] <wxl> apt-cache = my friend
[18:44] <wxl> i have found the easiest way way to get version # is apt-cache policy package
[18:45] <wxl> well, the way that returns the least amount of crap you on't need :D
[18:48] <goliat> Ok i did "apt-cache policy flashplugin-installer" which gave me "Version table:
[18:48] <goliat>  *** <IP_ADDRESS>ubuntu1 0
[18:48] <goliat>         500 http://se.archive.ubuntu.com/ubuntu/ oneiric/multiverse amd64 Packages"
[18:48] <goliat> and im running core 2 duo btw
[18:51] <wxl> why is that not i686?
[18:51]  * wxl is not running 64 so is not of great help here, just using logic
[18:53] <goliat> wxl: should it be that? is i686 intels 64-bit architecture?
[18:53] <wxl> yep
[18:53] <wxl> amd is amd not intel
[18:54] <bioterror> AMD got first into 64bit
[18:55] <bioterror> i686 = i686
[18:55] <goliat> could the issue with my lagging youtube be that im running the amd64 packages?
[18:55] <wxl> that's always a variable to remove in troubleshooting
[18:56] <bioterror> goliat, no
[18:56] <wxl> (or not)
[18:58] <goliat> bioterror: Ive had this problem on fedora but the problem there was that the 32-bit flash was installed and fixed it by changing to the 64-bit. So now im just confused why i cant play youtube in 720 properly :P
[19:20] <bioterror> goliat, can you play anything on vimeo?
[19:20] <bioterror> as vimeo is more demanding
[19:24] <goliat> bioterror: im trying it now
[19:28] <goliat> bioterror: I just played a movie with HD on. no lag at all or I've picked a movie that isnt really HD :S
[19:31] <goliat> It is HD and it runs smooth
[19:32] <goliat> what is the quality on a HD video on vimeo bioterror? 720?
[20:00] <bioterror> goliat, somethin like that, I assume
[20:00] <bioterror> goliat, but the quality on vimeo is a lot better than on youtube
[20:02] <goliat> bioterror: Ok. Strange thought that i can watch a vimeo hd video when it is more demanding than a youtube clip. And i cant play 720 on youtube.
[20:03] <bioterror> sounds like youtube is lagging or something?
[20:11] <goliat> Yeah. but it's flash player running the videos in youtube right? thats why ive been thinking it's flash acting up
[20:16] <goliat> but flash player is running the videos on vimeo to so im confused.
[20:31] <goliat> bioterror: Im not sure but could enabling direct rendering solve my issue perhaps?
[20:40] <goliat> bioterror: nvm direct rendering on.
[20:43] <bioterror> goliat, does it work then?
[20:43] <goliat> bioterror: no, its been on since beginning so it doesnt matter it seems
[20:57] <Osmodivs> Hello. I think I did something wrong here. When I right-click the desktop, there are no "desktop configuration" menu anymore, now I have an "OBconf, Restart, Terminal Emulator", and others, Is there another way to change the wallpaper? There is not even an option in >Preferences.
[20:58] <wxl> Osmodivs: oh yeah you messed up the function of right click
[20:58] <wxl> you're getting the open box menu
[20:58] <wxl> hold
[20:59] <goliat> bioterror: I found a addon for firefox called flash-aid. It installed and choose adobe flash player and do tweaks. I can atleast play 720 with expanded but not fullscreen
[20:59] <Osmodivs> wxl: I think so...
[21:04] <wxl> still looking..
[21:08] <Osmodivs> wxl: I thought you knew, there is nothing on the web already BING it and YAHOO it, even ASK it
[21:08] <wxl> kinda stuck here
[21:08] <wxl> i thought i went through this
[21:08] <wxl> there's an option in the desktop configuration menu
[21:08] <wxl> i was trying to figure out how to get to that
[21:08] <wxl> try middle click
[21:08] <wxl> or ctrl-right click or something
[21:09] <wxl> or clicking both left and right at the same time
[21:09] <Osmodivs> Nothing
[21:09] <Osmodivs> there is a desktop menu with middle button though
[21:10] <wxl> if you find "desktop preferences," click it and your problem will soon be solved
[21:10] <Osmodivs> wxl: No kiddin'
[21:12] <wxl> found it
[21:12] <wxl> run pcmanfm --desktop-pref
[21:12] <wxl> now be nice and say thank you :D
[21:13] <Osmodivs> wxl: Well I'll be damn!
[21:13] <wxl> you sure will!
[21:13] <Osmodivs> wxl: THANK YOU VERY MUCH
[21:13] <wxl> np :D
[21:13] <Osmodivs> wxl: Now, if there where only a way to put that in the menu...
[21:13] <wxl> there is a way
[21:14] <Osmodivs> wxl: Get outta here! really?
[21:14] <Osmodivs> wxl: Tell me how, if you please
[21:15] <wxl> https://help.ubuntu.com/community/Lubuntu/Documentation/FAQ/Guides#I_don.27t_know_how_to_make.2BAC8-add_a_application_to_.22start.22_menu%2E
[21:15] <wxl> make sure the Exec line is:
[21:15] <Osmodivs> Ok, I got it
[21:15] <wxl> Exec=pcmanfm --desktop-pref
[21:15] <Osmodivs> I have to uncheck the box from advance preferences
[21:15] <wxl> yes
[21:15] <Osmodivs> wel... that way too
[21:17] <Osmodivs> For some reason I can't send RED messages, like: ME is doing this, and stuff
[21:18] <Osmodivs> slash ME
[21:18] <Osmodivs> is not working
[21:18]  * wxl wonders if you mean like this?
[21:18] <Osmodivs> wxl: Yep
[21:18] <Osmodivs> How did you...?
[21:18] <wxl> well most likely a client issue
[21:18] <wxl> i'm on irssi
[21:19] <wxl> what are you using?
[21:19] <Osmodivs> Xchat
[21:19] <wxl> ew :D
[21:19] <Osmodivs> :|
[21:19] <Osmodivs> I should try that irssi
[21:19] <wxl> well it's text not gui
[21:19] <wxl> which a lot of people hate
[21:21] <Osmodivs> wxl: Mine already looks like a console http://www.pasteall.org/pic/19801
[21:21] <wxl> weird
[21:21] <wxl> it doesn't come with a me command?
[21:21] <wxl> ok, xchat is stupid
[21:21] <wxl> https://www.youtube.com/watch?v=u0D5_jfaPt8
[21:23]  * wxl wonders if it's because it's called action
[21:23] <wxl> it is
[21:23] <wxl> dumb
[21:24] <xsaidx> hello guys
[21:24] <wxl> Osmodivs: what are those lovely icons you have in your panel?
[21:24] <wxl> yo x
[21:25] <Osmodivs> wxl: On the right there are basic sound, mail, and weather indicators
[21:25] <wxl> there's a weather indicator?
[21:25] <wxl> my sound icons are totally different
[21:25] <wxl> as is my mail
[21:25] <wxl> are you running lxde a la ubuntu or are you actually running lubuntu?
[21:25] <Osmodivs> wxl: I deleted the ON/OFF/Reboot button, but, meh, I can do that in the logout menu
[21:26] <Osmodivs> Lubuntu
[21:26] <wxl> weird
[21:26] <Osmodivs> I deleted Unity, GNOME and other Ubuntu stuff, though I still need Gnome libs for almost anything!
[21:27] <Osmodivs> I had Ubuntu, and installed Lubuntu -desktop
[21:27] <wxl> uhhhh
[21:27] <wxl> ohhhhhhh
[21:27] <wxl> ok that makes sense
[21:27] <wxl> yep, you have something a wee different than lubuntu
[21:28] <wxl> right click on your sound icon.. what's the top menu entry read (actly)?
[21:28] <wxl> s/actly/exactly
[21:29] <Osmodivs> wxl: Nothing, I can't even acces sound preferences
[21:30] <wxl> hm odd
[21:30] <Osmodivs> Login out
[21:32] <osmodivs> Hello?
[21:32] <xsaidx> wxl: i guess theres a sample panel file i j ust dont kno
[21:32] <xsaidx> osmodivs: you fot ur panel back ?
[21:33] <osmodivs> I cant read your name
[21:33] <osmodivs> is in yellow
[21:34] <osmodivs> But yes, I got my panel back, excepet for that ON/OFF button
[21:38] <osmodivs> Hello?
[21:38] <xsaidx> osmodivs: hello my name is written in blue
[21:38] <xsaidx> osmodivs: so i assume your monitor has sumthin wrong ;]
[21:39] <osmodivs> Well, I am using rssi
[21:40] <xsaidx> osmodivs: ohh i dont kno why people love these kind of vey classic things at the 21 century : D
[21:40] <xsaidx> xsaidx: im using pidgin ;]
[21:40] <osmodivs_> This is so weird,
[21:41] <osmodivs_> Is someone trying to ban me?
[21:41] <osmodivs_> Or is it another bug?
[21:42] <xsaidx> osmodivs mybe
[21:42] <osmodivs> I had to Terminals open
[21:42] <osmodivs> Anywho...
[21:43] <osmodivs> How do I custom PopUp a message in irssi?
[21:44] <osmodivs> \osmodivs wonders how to
[21:45] <osmodivs> nah, it doesen't work with eithr slash / \
[21:45] <KM0201> isn't it "/me"
[21:45]  * osmodivs slaps in the forhead
[21:45] <osmodivs> Well I'll be damn
[21:46] <KM0201> that's not client dependant
[21:46] <osmodivs> That's what wxl Said
[21:46] <osmodivs> "Xchat is dumb"
[21:46] <osmodivs> So I had to download rssii
[21:46] <osmodivs> just to do this.
[21:46]  * osmodivs likes rssii
[21:47]  * osmodivs likes Lubuntu, but hates bugs and disapearing button
[21:48]  * osmodivs can't go back to Ubuntu anymore
[21:48]  * osmodivs has to go
[21:49]  * osmodivs waves and leaves room, then return to turn off PC
[21:54] <wxl> is there something like pastebinit for screenshots
[21:55] <KM0201> imagebin
[21:55] <KM0201> http://imagebin.org/?page=add
[22:13] <KM0201> has anyone noticed that Gnomebaker is no longer in the ubuntu repos?  kinda sad, it's a good cd/dvd burning app
[22:42] <bodhi_zazen> KM0201: I hated gnomebaker, always made coasters for me
[22:42] <bodhi_zazen> xfburn FTW !!!
[22:43] <KM0201> bodhi_zazen: just the opposite for me, i never ever had issues w/ gnomebaker, and really liked it
[22:43] <KM0201> i hate xfburn
[22:43] <KM0201> guess i'll try brasero
[22:45] <bodhi_zazen> k3b ?
[22:46] <KM0201> i like k3b, but the thought of installing all thoe kde libs scares me
[22:46] <bodhi_zazen> Why ? do you have a small hard drive ?
[22:46] <KM0201> no
[22:46] <KM0201> have plenty of hard drive space
[22:47] <bodhi_zazen> so go for k3b then, it does not pull in all of kde
[22:47] <KM0201> i just checked, if i install k3b, i will have to install 217mb worth of dependencies
[22:47] <KM0201> no thanks
[22:48] <bodhi_zazen> use cdrecord then
[22:49] <KM0201> i can tell you're not really getting the whole point of this conversation.
[22:49] <bodhi_zazen> I do not understand why 217 mb of dependencies is a problem
[22:49] <bodhi_zazen> bandwidth ?
[22:50] <bodhi_zazen> hard drive space ?
[22:53] <KM0201> like i said, i don't really think you get it.
[22:57] <bodhi_zazen> If you explain the problem, we might have a better solution
[22:58] <bodhi_zazen> 217 mb of dependencies for a functional, full featured burner seems quite reasonable


[00:40] <gamerchick02> uh no? it was working fine before i took the graphics card out
[00:40] <gamerchick02> i didn't unplug anything except the graphics card.
[00:43] <gamerchick02> i'm going to bed in a bit... work starts early. booo
[00:57] <cmaloney> So is the mobo using the internal card?
[01:30] <jrwren> just general troubleshooting stuff. I haven't done PC repair professionally for 20yrs, but things haven't changed.
[01:30] <jrwren> oh, maybe when she comes back :)
[12:38] <cmaloney> morning
[12:39] <rick_h> morning
[12:40] <cmaloney> wb
[12:40] <cmaloney> :)
[12:41] <rick_h> ty, good to be back
[12:41] <rick_h> Well...Except for the snow and cold and ...
[12:41] <cmaloney> Heh
[21:02] <cmaloney> Pretty sure coding interviews are just a nice way of telling me that my math skills are shit.
[21:16] <_stink_> they are stupid.
[21:16] <_stink_> those interviews, i mean
[21:19] <cmaloney> Well, it would be nice if they gave you some construvtive feedback
[21:19] <gamerchick02> lenovo chromebook is awesome.
[21:19] <cmaloney> so it could be a learning process and not just abject failure.
[21:20] <_stink_> it's just hazing.
[21:20] <gamerchick02> hazing can be bad.
[21:21] <cmaloney> _stink_: Well, it starts off with good intentions, I'm sure
[21:21] <cmaloney> but it feels a lot like trying to fit through a cookie-cutter
[21:25] <rick_h> cmaloney: :( I have to say I'm not sure how many folks would pass those things after being out of school for a while
[21:31] <cmaloney> Yeah
[21:32] <cmaloney> Even so I was never that good at word problems
[21:32] <cmaloney> if you give me the formula I might have a fighting chance
[21:35] <cmaloney> Maybe there's an opening for being the Dalai Lama or something
[21:39] <cmaloney> https://twitter.com/Chris_Randall/status/841396341964128256
[21:45] <gamerchick02_> cmaloney, isn't the Dalai Lama position passed down by generation?
[21:47] <cmaloney> Well yeah, but maybe they're looking to shake things up
[21:47] <cmaloney> Y'know, have a Dalai Lama-elect or something
[21:48] <cmaloney> or a non-Tibetan
[21:48] <cmaloney> I'm flexible