[00:00] <luke-jr> mwhudson: I mean when I 'rm a', 'bzr status' lists it as deleted and 'bzr commit' removes it from the repository
[00:00] <luke-jr> I don't want that.
[00:00] <luke-jr> rather, I want bzr to leave it alone like svn does
[00:03] <lifeless> luke-jr: there isn't a global option for this at the moment. I wanted to make it be like svn but got shot down on the mailing list
[00:03] <luke-jr> wtf ☹
[00:03] <luke-jr> is there a not-so-global option?
[00:03] <lifeless> luke-jr: you can supply --strict to commit, and it will cause missing files to be considered an error
[00:04] <luke-jr> no way to automatically use --strict?
[00:04] <luke-jr> wait, an error? ☹
[00:04] <luke-jr> why can't it just ignore it⁇
[00:04] <ScottK> Is there a bzr command that just pushes back where the code was pulled from?
[00:04] <lifeless> ScottK: bzr push :parent
[00:04] <ScottK> lifeless: Thanks.
[00:06] <lifeless> luke-jr: well its code, anything is possible. I'm just describing what the current code does, and that I wanted to make new files and missing files be treated symmetrically, but didn't manage to get consensus on the list for this
[00:06] <lifeless> luke-jr: you're welcome to dig up that thread and post referring to it. Support from users would be good :P
[00:08] <fullermd> You could automatically use strict by just setting up an alias.
[00:09] <luke-jr> fullermd: an error blocks commits, I presume-
[00:09] <luke-jr> I just want the files not present in my WC
[00:09] <luke-jr> yet not delete them from the repo
[00:09] <luke-jr> and still be able to commit changes
[00:10] <mwhudson> oh well, that's less likely to win favour
[00:10] <mwhudson> the idea of commit is that it records what's on disk
[00:11] <luke-jr> it doesn't go trying to add my temp note files]
[00:11] <luke-jr> -.-
[00:11] <mwhudson> true, that's why i have commit --strict on by default...
[00:11] <luke-jr> …
[00:12] <luke-jr> so how do I get that?
[00:12] <luke-jr> better an error than remove I suppose
[00:14] <lifeless> luke-jr: there is a plan, for 'views' which will be a WT setting that says what files to have present on disk; when that is implemented you could use it to get rid of some files from disk without having commit remove them from the branch
[00:14] <lifeless> luke-jr: its not implemented yet, I'm just letting you know that its planned
[00:46] <delaney> is there anyway to make local commits the default with TortoiseBzr?
[01:07] <lifeless> http://paste.ubuntu.com/108059/ - currnet knit vs gc with 1G corpus
[01:09] <mwhudson> seems a bit better :)
[01:09] <mwhudson> is the "how do we make gc stream" question addressed yet?
[01:10] <NfNitLoop> are there known issues with bzr blame?
[01:10] <NfNitLoop> I ran blame on a repo that I've branched from svn.
[01:10] <NfNitLoop> bzr blame says a line was last changed in r1
[01:10] <NfNitLoop> but when I svn blame the repo, I find otherwise.
[01:11] <NfNitLoop> (yes, I know svn rev#s are different from bzr rev#s)
[01:12] <NfNitLoop> What I seen in svn is that the line has been changed since it was created.   bzr blame leads me to believe that it has been the same since its initial revision.
[01:12] <spiv> NfNitLoop: no issues like that.
[01:13] <spiv> NfNitLoop: but bzr-svn will have recalculated all the diffs between revisions.
[01:13] <lifeless> mwhudson: well, just compress on the fly
[01:13] <spiv> NfNitLoop: and so it's possible that it's calculated a different (but equivalent) diff to svn for the same change to a file
[01:13] <lifeless> mwhudson: (as one possible answer)
[01:14] <NfNitLoop> OOOoooh.
[01:14] <NfNitLoop> Yes, I see, spiv.  Thanks.
[01:14] <NfNitLoop> The file was copied in svn.
[01:15] <spiv> NfNitLoop: e.g. consider four lines "aabb" becoming "bbaa"
[01:15] <NfNitLoop> and svn keeps the history through copies.
[01:15] <NfNitLoop> and, IIRC, bzr doesn't?
[01:15] <spiv> NfNitLoop: did "aa" get deleted and re-added, or did the "bb" lines get deleted and re-added :)
[01:15] <spiv> NfNitLoop: oh, yes, that too.
[01:15] <NfNitLoop> yeah, that's it.
[01:17] <NfNitLoop> the diff is pretty simple.   one line's boolean is getting switched between "true" and "false".
[01:17] <NfNitLoop> with no justification in comments or commit messages.
[01:18] <NfNitLoop> Anyway, thanks for the help!
[01:35] <luke-jr> does 'bzr mv' work with bzr-svn right, or does it just add?
[02:17] <enkrates794> I filed a bug about a week ago and got a response asking for more info. I provided the info, but I'm not sure if I should do something else in launchpad to get a further response. Could someone take a look at the bug and let me know if I've missed something? https://bugs.launchpad.net/bzr/+bug/316196
[02:19] <alevine> what's the easiest way to make a personal bzr repo that can be shared (preferably over http)?
[02:19] <alevine> with subversion I used the apache module
[02:22] <tecan> i have problems with bzr
[02:23] <nDuff> alevine, just push your repository to somewhere some web server is sharing
[02:23] <nDuff> alevine, no special web server module needed.
[02:23] <nDuff> alevine, (though if you want more performance, a "smart server" is available).
[02:23] <tecan> suse came with bzr 1.8 but i installed 1.6 and now everything is more complicated
[02:23] <alevine> nDuff, push it over...ssh?
[02:24] <tecan> its probably python 2.6 issues
[02:24] <alevine> thats very cool
[02:24] <nDuff> alevine, ...it's fairly common to use SFTP for uploads (yes, pushes or bound commits) and let third parties use HTTP to download.
[02:24] <asabil> alevine: you must know that http is way way slower than the smart protocols
[02:25] <nDuff> tecan, could you be more specific about the issues you're seeing? "everything is more complicated" isn't very actionable. :)
[02:25] <mwhudson> tecan: new bzr's work with 2.6, but 1.6 isn't very new
[02:25] <alevine> nDuff, asabil: thanks, performance is not an issue, mostly just for myself and for sharing code every once in a while
[02:28] <tecan> there is no where to download the latest tarballs ?
[02:28] <tecan> 1.6 is the latest i can get the source to
[02:31] <luke-jr> …
[02:32] <nDuff> tecan, http://bazaar-vcs.org/
[02:32] <nDuff> erk
[02:35] <luke-jr> so what's the deal with file copies anyhow?
[02:35] <luke-jr> such a simple feature has no progress for years?
[02:37] <nDuff> luke-jr, merge semantics become *much* complicated when one supports copies -- such that one pretty much *has* to do unintuitive things some of the time.
[02:37] <nDuff> luke-jr, there's a pretty good argument to be made that supporting features that require you to do unintuitive things is bad.
[02:37] <nDuff> s/features/"features"/
[02:42]  * igc lunch
[02:42] <nDuff> luke-jr, ...I can see supporting copies inasmuch as "create a new file which looks at this old one for purposes of blame and log operations", and that's probably a pretty reasonable feature request...
[02:43] <thumper> where can I find the default ignore list?
[02:43] <thumper> as in the files that are ignored by default
[02:43] <nDuff> luke-jr, ...but having merges not change the new version under any circumstances probably isn't end-user-intuitive behavior either.
[02:46] <nDuff> thumper, ~/.bazaar/ignore
[02:50] <thumper> nDuff: ta
[02:56] <thumper> anyone know where the bzr svg icon lives?
[02:56] <thumper> I want it for a presentation
[02:59] <jam> http://bazaar-vcs.org/Icons I think
[02:59] <jam> thumper: http://bazaar-vcs.org/LogoOptions
[02:59] <thumper> jam: fantastic, ta
[03:01] <thumper> jam: is there an svg without the text?
[03:01] <jam> thumper along the bottom
[03:01] <jam> bazaar192.svg?
[03:02] <jam> or you can look here: http://bazaar-vcs.org/LogoOptions?action=AttachFile
[03:02] <jam> there seem to be quite a few .svg files
[03:30] <luke-jr> nDuff: screw merge stuff, that's secondary to actually recording a copy
[03:33] <nDuff> luke-jr, ...if you tell users you'll record a copy but don't then give them the behavior they expect when merging between a branch where a copy happened and a branch where the file was changed (whatever that "behavior they expect" may be), that's just asking for surprised/unhappy users. Heck, there'd be likely folks who'd expect copy+rm to behave the same way as a mv -- lots of other SCMs do it that way, after all.
[03:34] <nDuff> ...but anyhow, it's been discussed on list; see the thread [RFC] Tracking file copies
[03:34] <luke-jr> cp+rm = mv
[03:36] <nDuff> ...so are changes in the original going to impact copies on merge or not? (And, more to the point, will changes in the *copies* impact the *original* on cherrypick? If so, which copy?) "Only if the original has since been deleted" means you've got a new set of corner cases.
[03:38] <nDuff> converting cp+rm to mv *only if the original was deleted within the same commit* is a reasonable behavior, but it's not quite the same thing as the generalization cp+rm=mv.
[03:38] <luke-jr> changes to both copies could be merged
[03:39] <luke-jr> creating conflicts if necessary
[03:39] <nDuff> whether that's appropriate depends on why you did the copy. If you're copying a template out to create a new file you're going to modify, merging changes from the new versions back to the template is absolutely wrong behavior.
[03:40] <luke-jr> yes, ok
[03:40] <luke-jr> so cp+rm might not always be = mv
[03:40] <luke-jr> so keep cp+rm separate from mv
[03:40] <nDuff> anyhow, see the mailing list thread
[03:41] <luke-jr> how about just having changes to a copied file depend on the copy changeset?
[03:43] <luke-jr> IMO, cherry picking is a less needed feature than copying
[03:50] <nDuff> luke-jr, well, you might ask jelmer how the spec is coming along sometime.
[03:52] <thumper> is there a nice page explaining how to get bzr working with eclipse?
[03:52] <thumper> I have some pug people asking
[03:52] <thumper> and I don't use eclipse
[03:55] <luke-jr> thumper: open a terminal and Alt-Tab
[03:55] <luke-jr> (why anyone would use eclipse is beyond me, it sucks)
[03:55]  * thumper looks strangly at luke-jr
[03:55] <nDuff> there's a bzr plugin for Eclipse
[03:55] <thumper> nDuff: yes there is
[03:56] <thumper> nDuff: is it packaged for ubuntu?
[03:56] <nDuff> ...though I haven't used it recently; last time I tried, it didn't support linked resources. (They've fixed that since, but not early enough for my purposes)
[03:56] <thumper> is bzr-xmloutput?
[03:58]  * thumper wishes for bzr-eclipse and bzr-xmloutput to live in the ~bzr PPA
[07:12] <vila> hi all
[07:38] <tecan>  ERROR: The user tecan has not registered any SSH keys with Launchpad.
[07:38] <tecan> how do i fix this ?
[07:40] <bob2> login via the web interface and add an ssh key
[07:41] <tecan> where
[07:41] <tecan> i dont see ssh anywhere
[07:43] <tecan> oh o found it
[07:48] <kiko-zzz> morning
[07:52] <tecan> morneng
[08:34] <awilkins> Where is the keyserver where Launchpad keeps it's PPA signing keys? The latest bzr packages are signed with keys I can't find and apt is refusing to associate with them :-)
[08:38] <igc> ping vila
[08:38] <vila> igc: pong
[08:38] <igc> vila: any thoughts on jam's comments re log --include-merges option naming?
[08:39] <igc> he voted tweak but I think we should get the name right first
[08:39] <igc> in particular, how useful would depth control be?
[08:39] <igc> e.g. ..
[08:39] <igc> log -n1 => flat
[08:39] <vila> which thread ? I'm a bit out of loop on log for the last few days :-/
[08:40] <igc> log -n0 => fully nested
[08:40]  * igc looks
[08:40] <vila> I read that I think, I'd prefer --merge_depth to be: 0: flat, -1 fully nested or something like that
[08:40] <fullermd> You mean depth like how many levels deep to show merges?
[08:41] <vila> i.e. matching our internal merge_depth so that it can be used more broadly
[08:41] <vila> fullermd: yes
[08:41] <fullermd> That strikes me as way too fiddly.  It seems like you'd need really contrived cases for a user to actually know what to do with it other than "none" or "all".
[08:42] <vila> I encounter the use case yesterday in a loom where I wanted mainline but at depth 1
[08:42] <igc> vila:https://lists.ubuntu.com/archives/bazaar/2009q1/051802.html
[08:43] <igc> fullermd: it a shame we don't have optional parameter values to options
[08:43] <igc> then log --nested could mean all
[08:43] <vila> and depending on the workflow you use I'm sure there are other such use cases *other* than mainline of full
[08:43] <vila> s/mainline of full/mainline or full/
[08:43] <fullermd> Well, you could add a --nest-level to supplement it.  That's not a major objection.
[08:44] <igc> and log --nested=2 could mean show just 2 levels (total or beyond the mainline depending on one's thought pattern)
[08:44] <fullermd> Yah, but it seems like it would have to be a very specific workflow, AND you'd have to know that it was universally followed.
[08:45] <vila> igc: Ha ! That thread ! Exactly the one I wanted to comment in priority
[08:45] <igc> fullermd: with PQM not showing the real author, I think was suggesting looking down just one level would be nice
[08:45] <fullermd> IMO, by the time you have the need and environment to be able to do that level of control, you're in a position to also want much more control over the rest of the output too.
[08:45] <vila> So, first of all, I still think we should refactor log to be able to pass parameters to log formatters *before* adding generic parameters to log
[08:46] <vila> i.e. not all parameters all relevant for all log formatters
[08:47] <igc> vila: I'm still not sure about that
[08:47] <vila> Second: I think there are more ways to select and present the revisions than just mainline and full, in the broader perspective, any sub-graph may be interesting
[08:47] <igc> vila: I think it ought to be simple for a plugin to define a new LogFormatter like "email" or "xml"
[08:47] <vila> oops, forget Second for a moment then, let's discuss first first
[08:48] <igc> and making every log-formatter see most parameters seems to be introducing complexity to the "create a new LogFormatter" process
[08:48] <vila> IMHO LogFormatter deals mainly with formatting *one* revision and everybody tends to think about them only in that context
[08:49] <vila> That's no the entire truth
[08:49] <igc> vila: also, I think the immediate priorities need to be:
[08:49] <vila> LogFormatter also deals wiht the graph of revisions they are presenting
[08:49] <igc> * make it fast so people can use it on large projects
[08:49] <igc> * provide the blatantly missing functionality (like log DIR)
[08:50] <vila> igc: I understand your priorities, that's one reason I stepped back on refactoring log (the other main one being that I had an already full plate with other issues and my changes to log can stay private for the time being)
[08:51] <vila> Regarding your priorities, "fast" can be done without refactoring, "DIR" I don't think so
[08:51] <igc> vila: I'm not rejecting your idea, I just don't want to hold up improvements than are arguably orthogonal
[08:52] <vila> igc: full agreement
[08:52] <igc> vila: so returning to my UI question, I think fullermd's suggestion has merit: namely ...
[08:52] <vila> but I think *some* of them are not that orthogonal :)
[08:53] <igc> leave the option called --include-merges (and add --nest_level later)
[08:53] <jelmer> luke-jr, That's a known bug in that rc, should be fixed in the 0.5 branch
[08:54] <vila> My main concern is that IMHO we're introducing options that we may deprecate later or force some log formatters to handle things they don't want to care about
[08:54] <igc> vila: but perhaps the LogFormatter constructor should take a nest_level now.
[08:54] <igc> understood
[08:55] <igc> but it's pretty damn easy given depth is a field in every record passed to a LOgFormatter to format
[08:55] <vila> igc: nest_level to constructor sounds good to me
[08:56] <igc> checking if n <= m isn't more complex than if prefer_merge_revisions IMO
[08:56] <fullermd> Can't the formatters just eat whatever args you give them and only bother looking at the ones they care about?
[08:57] <fullermd> It seems insane to have to explicitly add each possible arg, even if they'll never care about it...
[08:57] <vila> if it's under log formatter control I'm happy enough, it means they can decide to handle the option or not, or even reject the option
[08:57] <igc> but it implies lots of common filtering code repeated in each log formatter
[08:58] <vila> fullermd: we are not there yet, but the idea is to pass unprocessed option to log formatter which in turn can pass back unprocessed option for error handling
[08:58] <igc> rather than a log formatter having a clear responsibility, i.e. "format this record"
[08:58] <vila> igc: that's why we want a base class with all the utilities !
[08:59] <vila> You're back to reducing log formatter to "format this record" that's not their only responsibility IMHO
[08:59] <igc> it is currently
[08:59] <igc> they don't really so a graph ...
[08:59] <vila> no it isn't : look at begin_log end_log
[08:59] <igc> just a sequence of tuples (including a depth field)
[09:00] <igc> begin_log and end_log are hooks as I understand them for opening/closing headers/footers, yes?
[09:00] <vila> of course the LogRevision are called in sequence but that's also a part that could/should go under the lf responsability
[09:00] <igc> and/or opening/closing resources perhaps
[09:01] <vila> That's why I say the lf responsability is currently unclear, parts of it being implemented by the log module, I think that's wrong and blurry things
[09:02] <vila> igc: Have a look at the xnloutput Log Formatter for example
[09:03]  * igc looks
[09:04] <vila> It's a lf that consider itself responsible for the whole log display, not only each individual revision display, because it must balance the xml flags for each level
[09:04] <vila> so it must understand the whole graph (or tree if you prefer)
[09:05] <vila> You can argue that it could just use depth as an attribute and just format the whole as just a sequence...
[09:06] <vila> ...but that's not the point I'm trying to make :-)
[09:06] <igc> right
[09:06] <igc> so begin_log & end_log put out the <log> and </log> markers
[09:06] <igc> the rest looks like the usual HTML formatting dance :-)
[09:07] <igc> i.e. balancing of tags while outputting nested lists
[09:08] <vila> i.e. taking care of the whole formatting not only of the "format this record"
[09:08] <vila> that's my point
[09:10] <vila> end-log do a bit more than just putting out the </logs>  (not <log>) marker, there is a stack to purge to
[09:10] <igc> it's format-this-record-in-the-context-of-what-I've-seen-already and ...
[09:10] <igc> unwind levels as we step outwards
[09:10] <vila> you can stop there, you said context
[09:11] <igc> vila: I guess I'm asking ...
[09:11] <igc> why would passing more to the log formatter help it?
[09:11] <igc> we don't pass through end-of-merge for example
[09:12] <igc> vila: would that make things easier say?
[09:12] <vila> what is end-of-merge ?
[09:13] <igc> a True/False field generated by tsort.merge_sort (along with rev-id, depth & revno)
[09:13] <igc> I suspect having it would help much
[09:13] <igc> it's not until you see the *next* depth that xmlformat will know the amount of levels to unwind
[09:14] <igc> s/would/wouldn't/
[09:14] <vila> I think that giving more responbilities to lf, will make it easier them to access the data they need instead of relying on the log module to format them in a generic way
[09:16] <vila> Being able to decide at the lf level what 'revision' parameter is valid or not sounds like a solution to several problems you tried to address recently
[09:17] <vila> igc: Won't you be happier with get_view_revisions being specific to a log formatter ?
[09:18] <igc> I'll be happier when get_view_revision goes!
[09:18] <igc> it's a crap API!
[09:18] <vila> I think that will make the include_merges parameter useless for example
[09:18] <vila> igc: great, delegate to lf will make it less crap
[09:19] <igc> true, but so will fixing it :-)
[09:20] <igc> the mainline rev, revnos and include_merge parameters are all unnecessary IMO
[09:20] <igc> Branch.iter_merge_revisions is the way forward I feel
[09:21] <vila> except for the fact you need them to be reasonably fast, I entirely agree :)
[09:21] <vila> i.e. they are implementation details
[09:22] <vila> Branch.iter_merge_revisions ? IS there where you use a reverse parameter ?
[09:22] <igc> jam wanted a reverse parameter to it and I've submitted a patch along those lines but ...
[09:22] <igc> I'm not sold yet on reverse being meaningful at that level
[09:22] <vila> Can we please, please, stop using 'reverse', 'forward' and 'backward' have a meaning by themselves 'reverse'... always makes me wonders
[09:23] <igc> true
[09:23] <igc> so currently, reverse in log & missing calls sort_by_depth
[09:24] <vila> hmm, more than just that I think
[09:24] <igc> That feels a bit too fancy for Branch.iter_merge_revisions where forward/backwards makes a lot more sense
[09:25] <vila> off-topic forward without 's' and backwards with 's' always /
[09:25] <vila> s!/!?!
[09:25] <vila> lol, perl is noise :)
[09:25] <igc> no, I meant forward/backward
[09:26] <vila> ooh, you mean 'reverse' as used at UI level, I was meaning internally also
[09:26] <igc> vlia: anyhow, I need to have dinner now
[09:26] <igc> vila:^^
[09:26] <vila> Enjoy your dinner :)
[09:27] <igc> so you're ok with --include-merges at the UI level & preferred_depth at the LogFormatter API level?
[09:27] <igc> vila:^
[09:28] <vila> why preferred  instead of just depth ?
[09:28] <vila> I'm ok for --include-merges
[09:28] <igc> you're right, just depth is good
[09:29] <igc> or levels
[09:29] <vila> Overall: I'm globally ok with your modifications anyway, it's just that I think some of them may be simpler *after* refactoring and some of them may make refactoring *harder*
[09:29] <vila> But since you'r the one spending the time on it, you get to choose :)
[09:29] <igc> :-)
[09:30] <vila> igc: And I'm perfectly fine that
[09:30] <vila> igc: And I'm perfectly fine with that
[09:30] <igc> cool - time to go. Thanks for the chat
[09:30] <vila> You're welcome
[09:45] <vila> jam: Ha ! Look who is blocking pqm now ! Welcome to the club :-)
[09:51] <NET||abuse> hi guys.. basic usage question, i've a little project on my laptop, i'm concerned for the hardware, how do i clone up to my server for backup? can i just sftp copy the whole versioned directory(working copy i guess) straight up to the server?
[09:51] <NET||abuse> or do i need to use a bzr instruction to do so?
[09:52] <pygi> NET||abuse, either bzr branch whateva on server works, or you can sftp things
[09:52] <pygi> or bzr push from local to server
[09:52] <NET||abuse> hmm, ok
[09:52] <NET||abuse> i'll have a look at it.
[09:59] <NET||abuse> hmm, missing page in the bzr docs,, http://bazaar-vcs.org/Scenarios/NewProject
[09:59] <pygi> NET||abuse, that Scenarios page is new :)
[09:59] <pygi> we're yet to work on it ;)
[10:02] <NET||abuse> so i can push to my server where it has no bzr repo setup, initi'd yet
[10:06] <vila> herb: It looks like you're the only losa around, can you have a look at PQM please ?
[10:06] <vila> herb: I meant when you come online...
[10:08] <NET||abuse> hmm, ok so branch from my local to remote doesn't work,, i did bzr branch ./ svn+ssh://me@host/path/to/new/bzr/dir    and it throws error "bzr: ERROR: No repository present:"
[10:10] <NET||abuse> What i'm looking to do is move my current standalone branch on my local laptop, up to a dir on my webserver, and then have that act as the main branch for my work, i will be opening it up to someone else next week, so need it up there, and also worried my laptop is about to croak
[10:11] <NET||abuse> it's gotta a discreet nvidia NVS135M card in it, they're known to have issues, this is my 1st replacement from dell, the first one died and 5 engineer visits didn't fix it, so they just gave me whole new model, now last night during 10,000 bc :) the screen glitched like the last one had started to before it died...
[10:11] <NET||abuse> not good.
[10:18] <fullermd> I don't think you can branch into SVN...
[10:20] <fullermd> I don't even know if branch CAN target somewhere remote.  Used to definitely not; can't remember if that was changed or not.
[10:20] <fullermd> Generally you just push anyway.
[10:28] <NET||abuse> umm, you see this is why i need to ask,, yeh, svn+ssh,, oops,, i'm not looking to push to svn, was looking to make a new bzr repo... so i just tried bzr ./ bzr+ssh://me@host/path/to/repo/to/create   and it didn't like it,, error unkown command 'server' connection closed: please check connectivity and permissions
[10:29] <NET||abuse> unknown command wasn't 'server' just 'serve'   still the error stands...
[10:30] <NET||abuse> so last effort,, i just tar.gz up the bzr repo directory,, then upload it.
[10:30] <NET||abuse> extract it on the remote server then try to point my local to it.
[10:30] <NET||abuse> or will they conflict? would i have to re clone/branch from the server back down to my local machine?
[10:34] <fullermd> Unknown command serve?  That sounds like a *REALLY* old bzr on the far side...
[10:35] <fullermd> Taring it up should work just fine for backing it up.
[10:39] <NET||abuse> fullermd: yeh, the far side is the old LTS ubuntu, dapper i think?
[10:39] <spm> vila: what seems to be the problem? One of your submissions appears to have succeeded about 20 minutes ago?
[10:40] <vila> spm: thanks for looking in to it, it looked like last *jam* submission was blocking the pqm, mine was just waiting
[10:40] <vila> spm: things seems fine now
[10:40] <vila> spm: did you do anything ?
[10:41] <spm> vila: cool. apart from looking? no. :-) Easiest fix I've done in ages :-)
[10:41] <vila> spm: pqm is just afraid by you then :)
[10:41] <spm> heh
[10:42] <vila> Or may be *I* just misread or read too soon...
[10:43] <spm> shrug - is no matter. when it gets stuck it's pretty easy to unstick - better to keep things flowing
[10:48] <dr_barnowl> fullermd: You can branch into SVN
[10:49] <dr_barnowl> fullermd: I had to "svn-versionize" a list of dated archive folders recently, which I did by committing them to bzr branches and pushing them to svn
[10:54] <fullermd> Well, I know you can push them in.  I mean I don't think you can use _branch_ to do it.
[10:54] <fullermd> (actually, I thought you couldn't use push either, and there was some other command to create one ab ovo)
[10:57] <wgrant> You have to use bzr svn-push to create a new branch.
[11:00] <clemente> In latest bzr.dev:  File "/home/w/bzr/oficial/bzrlib/ui/__init__.py", line 237, in make_ui_for_terminal:  UnboundLocalError: local variable 'cls' referenced before assignment
[11:19] <vila> clemente: thanks, fix is on its way
[11:37] <nua> hi I'm having real trouble starting the bzr server, it breaks and I get a traceback: http://pastebin.com/m66382410
[11:37] <nua> I'm using the standard install for ubuntu 8.10
[11:38] <nua> which reports to be bzr 1.6.1
[11:42] <lifeless> thats a bug in bzr-dbus which has been fixed since that release
[11:42] <lifeless> either uninstall bzr-dbus, or upgrade it, or have dbus running
[11:48] <ScottK> Sounds like a good SRU candidate then.
[11:52] <nua> hmm, now I'm just getting address already in use, I think that other attempt is still using it
[12:02] <frk2> hello all
[12:02] <frk2> had a question regarding the use of hooks in bazaar
[12:06] <frk2> Im using a shared repository arch
[12:06] <frk2> so basically everyone commits to a singular server
[12:07] <frk2> to send commit notifications out do i have to configure bzr-email on every single desktop?
[12:07] <frk2> configuring on the remote repo in .bzr/branch/branch.conf does not seem to work, configuring locally does
[12:13] <lifeless> bzr-email on te server, and push via bzr+ssh should work just fine
[12:13] <lifeless> gnight all
[12:13] <frk2> but a bound commit does not
[12:14] <frk2> lifeless,  i can try to push and see if that works. But I have the branch bound to the server- a commit does not help
[12:14] <frk2> guess you have gone off to bed :) gnite
[12:22] <Jc2k> frk2: you could try bzr-hookless-email as a workaround in the mean time
[12:22] <frk2> Jc2k, whats that?
[12:23] <Jc2k> frk2: it uses inotify (or just run it very frequently in cron) and looks at what changed and generates emails
[12:24] <frk2> is it part of bzr tools now?
[12:24] <Jc2k> no
[12:24] <frk2> so get it from lp directly?
[12:25] <Jc2k> bzr branch lp:bzr-hookless-email
[12:25] <Jc2k> its not a plugin, so no need to put it in .bazaar/plugins or anything
[12:25] <Jc2k> i've not used it myself, but i think debian are using it for their commit emails
[12:31] <frk2> Jc2k, got it running- am guessing it uses sendmail or something to actually send the email
[12:32] <Jc2k> frk2: its based on bzr-email, so imagine its the same kind of thing as that
[12:33] <mtaylor> lifeless: coupla quick things about stacked branches... --stacked-on=lp:~mordred/wafflegrid/5.1-upstream doesn't work - doesn't recognize lp: syntax ... and also, that fails, so the push aborts, but not before it creates _something_ on launchpad
[12:55] <nua> I add the bzr PPA and got the latest version, all working fine now
[12:56] <nua> I was wondering how I require log-in to access the repositories if I'm using bzr serve? it seems like anyone can checkout the code
[12:58] <frk2> nua, you do not, i think
[12:58] <frk2> thats why its read obly
[12:58] <frk2> only
[12:58] <frk2> unless explicitly enabled
[12:58] <frk2> i use bzr+ssh
[12:59] <nua> ok, so I basically have to use bzr+ssh if I want authentication?
[12:59] <nua> that's ok, but it means I get really ugly urls
[13:00] <frk2> AFAIK, yes
[13:00] <nua> would I create an ssh account for each collaborator (I'd rather not) or could I force them to use a single bzr user and authenticate on their ssh keys?
[13:07] <nua> frk2: what about https?
[13:12] <awilkins> nua: You can use http and your http server will take care of auth for you if you configure it
[13:13] <nua> awilkins: ok thanks, I think I'll give that a go
[13:13] <awilkins> nua: ssh also works with a single ssh user as long as you put each users public key on your authorized_keys file
[13:14] <nua> awilkins: I think http sounds like the most sensible route
[13:15] <awilkins> nua: It's very easy for read-only access
[13:15] <awilkins> nua: It'll work out of a dumb http server ; write-access takes a little more work
[13:15] <nua> awilkins: I can run a smart http server by using bzr+http:// right?
[13:16] <awilkins> nua: You can _access_ a smart server by specifying bzr+http://
[13:16] <awilkins> nua: To run one you need to configure the server to pass requests to bazaar through WSGI
[13:17] <nua> awilkins: ok, but I can write to the sever over http/https?
[13:17] <awilkins> nua: Yes, as long as the smart server is configured
[13:18] <awilkins> Which web server are you using?
[13:18] <nua> awilkins: I usually use apache or lighttpd... just looking at which to set up now
[13:19] <nua> awilkins: do you know of any guides on how to set up bzr smart server and http?
[13:19] <awilkins> I wrote the page at http://bazaar-vcs.org/ServerGuide/IIS
[13:19] <awilkins> I think there are hints for apache in the docus somewhere
[13:20] <awilkins> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id80
[13:20] <nua> awilkins: yeah, just found that :)
[13:21] <awilkins> I had to fix the code to make it work with IIS :-)
[13:21] <awilkins> Half IIS's fault though
[13:26] <vila> haaa, just finish talking with igc, saw lifeless less than an hour ago, now poolie is joining... Did I enter the TZ ? (Twilight Zone :)
[13:26] <vila> Hi poolie :-)
[13:29] <poolie1> hello vila
[13:33] <igc> hi poolie
[13:33] <igc> jam: thanks for the review re the dotted_revno_to_revision_id patch. Much appreciated
[13:33] <poolie> hello igc, you're up late
[13:33] <poolie> i think
[13:34] <igc> poolie: my hours are all the place right now
[13:34] <igc> 7am start yesterday, 6am finish, hospital visit in between
[13:35] <igc> I sleep when I tired currently
[13:36] <igc> jam: I'd also love a review of the iter_merge_sorted_revision patch if you have time/interest
[14:09] <igc> poolie: re log --include-merges, I think I'd prefer log --levels N to control how many levels are displayed
[14:10] <igc> N=0 would be "all of them"; N=1 would be a flat list
[14:10] <igc> together with a shorthand of -n, I think it would work well ...
[14:11] <igc> e.g. log -n1 seems better than log --no-include-merges
[14:11] <igc> likewise log --short -n0 is easier than log --short --include-merges
[14:12] <igc> also, when logging from a merge revision, it's the number of levels down that matters, not mainline vs merge revision display
[14:12] <igc> poolie, jam: thoughts?
[14:13] <igc> fullermd suggested having both --include-merges and nest_levels
[14:13] <igc> once we have the latter though, the former seem redundant
[14:13] <aquarius> I had a conflict in my branch when I merged another branch into it, on a file foo/bar/baz. I've done "bzr rm foo" (it doesn't need to be there any more), but bzr still says the conflict is present
[14:14] <aquarius> how do I unconfuse it (and me)?
[14:14] <poolie> poolie: that sounds nice, um
[14:14] <poolie> i would have thought -n0 means "no" :-)
[14:14] <poolie> actually seriously 0 means "none"
[14:15] <poolie> also, being indented one level does not precisely correspond to "one step away" in the actions the user took
[14:15] <poolie> though arguably it does when you pull the dag around a bit
[14:15] <poolie> shorter options == better
[14:19] <poolie> does that help at all?
[14:28] <igc> poolie: I think 0 meaning all is ok; asking for zero levels isn't very useful :-)
[14:28] <poolie> ah
[14:28] <poolie> if you're counting from kind of column zero on the screen
[14:28] <poolie> then yes
[14:28] <igc> well, for log at least!
[14:29] <igc> so I guess we can have n mean either total number of levels or number of nested levels
[14:29] <igc> do you have a preference?
[14:30] <igc> if # of nested levels, then -n0 means flat & we need a # or symbol for all
[14:31] <igc> log -n all is actually ok btw
[14:31] <igc> we don't have int options, just strings we parse into ints it turns out
[14:31] <igc> poolie: ^^
[14:32] <igc> n fact, -n all would work regardless of what exact semantics we gave the numbers
[14:33] <poolie> igc, that makes sense, i think -n0 is nice and short to type to mean everything
[14:33] <igc> me too
[14:33] <poolie> so -n0 would be the default?
[14:33] <igc> it's format specific
[14:34] <igc> the -n just overrides the default
[14:34] <igc> that way we keep c ompatibility for existing users
[14:35] <poolie> ok
[14:35] <poolie> sounds good
[14:35] <igc> internally, -1 will mean "let the format decide" and it will be the default
[14:41] <luke-jr> jelmer: which bug?
[14:42] <bakunin> I'm trying out bzr on my Windows box towards our Subversion repository, but I haven't been able to find out how you specify username and password towards the subversion repository. Any pointers to documentation about this?
[14:46] <luke-jr> jelmer: isn't the difference between "Fix Committed" and "Fix Released" that the latter is actually in a release?
[14:50] <luke-jr> jelmer: BTW, any chance we can get a 'bzr svn-cp' or such that pushes a 'svn cp' upstream? >_<
[14:51] <luke-jr> maybe represent it in bzr through a 'copied from' property or such
[14:51] <luke-jr> (until it has proper copy support)
[15:04] <vila> igc: catching up ! +1 +1 +1 for -n !! Including 0 for all
[15:04] <igc> vila: thanks. I think it will work well
[15:04] <vila> I also prefer that to having several options
[15:08] <vila> igc: "internally, -1 will mean "let the format decide" and it will be the default" :-)
[15:08] <vila> Let the format decide ftw ! :-)
[15:08] <igc> and for backwards compatibility :-)
[15:09] <vila> same boat ! More room to improve other lfs :-)
[16:26] <nua> does this mean I need to edit the bzrlib source?? http://pastebin.com/m533f12af
[16:36] <tro> bakunin: use the HTTP method of specifying username/password. ie<EMAIL_ADDRESS>[16:40] <awilkins> nua: I think the WSGI handler that is posted is a bit out of date
[16:40] <awilkins> nua: When I upgraded on Windows I had to change the logging parameters
[16:43] <bakunin> @tro Will the same work for a http URL?
[17:09] <tro> bakunin: yes
[17:13] <pickscrape> Given a revision ID, what is the quickest way in bzrlib to determine the number of parents that the revision has? (i.e. whether or not it is a merge)
[17:22] <garyvdm> pickscrape: http://pastebin.com/d2ec223ca
[17:23] <pickscrape> garyvdm: thanks for that
[17:46] <poolie> vila: hello
[18:00] <bakunin> tro: Thanks a lot. It worked. I guess this is how basic authentication is handled
[18:23] <luke-jr> how do I get teh 'svn revno' with bzr?
[18:26] <james_w> luke-jr: recent bzr-svn will put it in the output of "bzr log"
[18:27] <luke-jr> james_w: programmically
[18:28] <james_w> luke-jr: dunno
[18:28] <james_w> luke-jr: take a look at bzr-svn's source for how it implements that
[18:29] <luke-jr> :/
[18:29] <james_w> show_foreign_revid perhaps
[18:30] <luke-jr> s/programmically/from a shell script/
[18:45]  * garyvdm wishes he could use python 3.0's nonlocal statement...
[18:58] <lorph> is tortoisebzr usable yet
[19:03] <garyvdm> lorph - I use it.
[19:04] <garyvdm> Heh - He left allready :-(
[19:24] <mrooney> I am using bzr-svn to attempt to branch a rather large svn repository, but it doesn't seem robust enough to ever make it the whole way through. Is there a way to continue/resume this process?
[19:25] <mrooney> It seems to get a few thousand revisions in and then die and I have to start all over.
[19:25] <james_w> hey mrooney
[19:25] <mrooney> james_w: hey!
[19:25] <james_w> you can "bzr branch -r 1000"
[19:25] <james_w> then "bzr pull" 1000 revisions at a time
[19:26] <mrooney> james_w: ahh that sounds perfect, so if I branch 1000 and then the next pull fails, what state is it left in, the original before that pull? or is it still broken?
[19:26] <james_w> it should be left as it was before the pull
[19:26] <james_w> bzr pull -r 2000
[19:26] <james_w> bzr pull -r 3000
[19:26] <james_w> etc.
[19:27] <james_w> should stop it doing too much in one go
[19:30] <mrooney> james_w: thanks so much, this seems good
[19:30] <james_w> cool
[19:30] <mrooney> I figured an easy way to back up our SVN repositories incrementally was just to branch once from another machine via bzr-svn, and then pull every night
[19:30] <mrooney> james_w: does that sound sane?
[19:30] <james_w> seems reasonable
[19:31] <mrooney> excellent
[19:31] <mrooney> It would also probably help if I wasn't doing this over wifi :)
[20:00] <asabil> btw, does bzr have a way to see the diff/log of changes that where retrieved using a pull ?
[20:03] <garyvdm> asabil: There is before you pull. You can use missing to see what revisions, and diff pull_branch for diff
[20:04] <garyvdm> asabil: bzr does not remember what the tip revid was before the pull
[20:05] <asabil> it would be really very useful if it did
[20:28] <amanica_> asabil: you can tag it before you pull
[20:28] <amanica_> or maybe we can do an implicit tag before pulling
[20:29] <amanica_> eg BEFORE_LAST_PULL
[20:29] <amanica_> maybe this would be possible to do with a plugin...
[20:35] <lifeless> mtaylor: file a bug on the stacking-on failure please
[20:36] <garyvdm> Is there a way to specify the bound branch?
[20:37] <garyvdm> e.g. bzry push -d --bound_branch--
[20:37] <lifeless> garyvdm: bzr bind <url>
[20:37] <lifeless> garyvdm: oh; :master I think
[20:38] <garyvdm> lifeless: re:bind Then I would need to bind every time I switch - which is often
[20:38] <garyvdm> I'll check out :master
[20:39] <garyvdm> :bound works - thats very cool
[20:45] <knittl> hi! is there a way to stash commits like in git?
[20:45] <bob2> shelve
[20:46] <knittl> bzr shelve? i can't find it in the manpage
[20:47] <knittl> and it doesn't work … (binary files)
[20:51] <lifeless> knittl: in used to be in a plugin, it recently got moved to core and fixed for binary files
[20:52] <LarstiQ> knittl: which shelve is this with btw, shelf1 or `shelve` from 1.10 and up?
[20:52] <lifeless> knittl: what bzr version do you have?
[20:52] <LarstiQ> knittl: hi, btw :)
[20:52] <knittl> hi LarstiQ :)
[20:52] <knittl> 1.6.1 i got on my machine
[20:52] <knittl> LarstiQ: i checked out blender (took hours)
[20:53] <LarstiQ> knittl: got everything though?
[20:53] <knittl> yup, i'm not missing a thing (till yet)
[20:54] <knittl> -yet +now … sounds better xD
[20:54] <knittl> ok, i just bzr rm --keep the files, committed my changes and pulled
[20:55] <knittl> weirdly enough it told me there was nothing to pull/merge, but before committing it told me there was a pending merge
[20:58] <lifeless> knittl: that means you had done a merge
[20:58] <knittl> lifeless: well, i didn't tell it to do a merge. but nevermind … i'm only doing a little branch for a sideproject xD
[20:59] <lifeless> knittl: check your bash history, I can pretty much guaranteed that 'bzr merge' is in there somewhere :)
[20:59] <knittl> yes, but it aborted and told it couldn't merge because of uncommitted changes
[21:00] <lifeless> knittl: it would do that after you'd made changes; such changes could have included an earlier attempt to merge
[21:00] <knittl> ok, i see :)
[21:00] <lifeless> one of the most obvious differences to git is that 'bzr merge' always waits for the user to commit the result - we don't autocommit
[21:02] <lifeless> -> breakfast
[21:29] <lifeless> Peng: btw, you should find bzr search lower on memory but not too much slower on indexing
[21:30] <Peng_> lifeless: The new group_size stuff? Cool, how much lower?
[21:31]  * Peng_ fires up "bzr -Dmemory index".
[21:31] <lifeless> a lot lower for mysql trees :P
[21:32] <lifeless> also loggerhead suggestions should be faster in format 2 search indices
[21:32] <Peng_> Oh, cool.
[21:32] <Peng_> Should suggestions in general be faster, or is it specific to LH?
[21:33] <lifeless> faster in general
[21:35] <Peng_> Bah, the progress bar is already off the side of the screen.
[21:35] <lifeless> ugh
[21:41] <Peng_> 9 minutes 14 seconds for bzr.dev. "VmPeak:   121356 kB"
[21:41] <Peng_> That's awesome memory usage. It used to take decreasing the group_size to ~80 to do that.
[21:45] <jelmer> luke-jr, you can get the svn revno with "bzr log -r -1"
[21:45] <jelmer> luke-jr, "Fix released" means it's part of the main branch in the bzr world
[21:46] <jelmer> luke-jr, wrt svn-cp, there is no way to make that work while bzr can't represent that internally
[21:49] <Peng_> Nice, "bzr search aye" returns an excerpt from doc/en/user-guide/images/workflows_pqm.png. At least it didn't confuse my shell.
[21:51] <jelmer> hi Peng_
[21:51] <jelmer> Peng_, Did you get anywhere further with that bzr-svn+bzr-search issue you were seeing?
[21:52] <Peng_> jelmer: I didn't try to.
[21:54] <luke-jr> jelmer: bzr doesn't have arbitrary metadata?
[21:54] <Peng_> Haha, "bzr search branch" on bzr.dev sure has a lot of results. :)
[21:54] <luke-jr> jelmer: I'd rather not have to grep/sed on log -r -1
[21:55] <jelmer> luke-jr: only revision properties, but they are set at commit time
[21:56] <jelmer> luke-jr, and the amount of work to work around the fact that bzr doesn't have copies makes me think we should really just implement copy support in bzr first
[21:57] <jelmer> luke-jr, sorry :-/
[21:58] <Peng_> "bzr search branch" had 5311 results. FYI. :P
[21:59]  * jelmer notices bzr-search is Peng_'s latest toy
[22:03] <Peng_> jelmer: Well, I go through a lot of toys. :P
[22:28] <luke-jr> jelmer: so implement copy support already :/
[22:28] <luke-jr> jelmer: honestly, I'd benefit greatly from moving a number of my projects to bzr, but without copy support I can't :/
[22:28] <knittl> is there a bzr move?
[22:28] <luke-jr> yes
[22:28] <jelmer> knittl, yes
[22:28] <knittl> it's not bzr mv … what is it?
[22:29] <luke-jr> knittl: it is
[22:29] <knittl> oh … i must've mistyped it then …
[22:30] <luke-jr> jelmer: supposedly the problem w/ copying is cherry-picking, but IMO copying is more important than cherry picking, so that problem should be deferred :/
[22:31] <jelmer> luke-jr, fwiw, I agree with that (some copy is better than no copy)
[22:31] <jelmer> and just having the history stored now means we can use it later when there is proper merge support (if ever, as that's a very hard problem to solve)
[22:32] <knittl> can somebody help me with a concrete repo? (+branch)
[22:33] <knittl> i'm still more used to git … after all i'm a programmer and like it complicated xD
[22:33] <jelmer> knittl, what's the problem?
[22:33] <knittl> i can't get two directories pulled into b
[22:33] <knittl> * -b +my branch
[22:34] <Peng_> jelmer: Hg supports merging across copies.
[22:35] <jelmer> Peng_: So what do they do when you copy a file and then merge in another branch that changes that file?
[22:35] <jelmer> Do you merge it into both copies ? Or just into one?
[22:35] <jelmer> If you base one source file on the other, you don't necessarily want the changes
[22:35] <Peng_> jelmer: The other branch changed the original or the copy?
[22:35] <jelmer> The other branch changed the original
[22:36] <Peng_> jelmer: The changes are merged into both.
[22:36] <Peng_> Cue Peng_ being proved wrong.
[22:40] <lifeless> Peng_: 9 minutes is slower than usual to index though?
[22:42] <Peng_> lifeless: I dunno. The group_size is 2000, and I'm not sure if I have numbers for that (and if I did, it would be for format 1).
[22:42] <Peng_> lifeless: For group_size = 1000 from a couple months ago, it was 9m56s, so it's faster.
[22:42] <Peng_> lifeless: So, I figure that if it is slower, it's not significant.
[22:45] <knittl> hm, how do i get those folders into my branch? :-/
[22:46]  * Peng_ /aways
[22:46] <lifeless> Peng_: thanks,c ool
[22:48] <jelmer> knittl, I'm not I understand completely what you're trying to do
[22:49] <jelmer> knittl, if you're trying to import folders, just "bzr add" followed by "bzr commit" should be sufficinet
[22:49] <knittl> jelmer: the folders already exist in the master branch
[22:49] <knittl> but they are 'unknown' in my branch
[22:49] <jelmer> knittl, so you want to do a cherry pick merge of those folders?
[22:50] <knittl> i just want to have them in my branch :D
[22:50] <lifeless> knittl: normaly you would just 'bzr merge master && bzr commit' to get something into your branch
[22:51] <knittl> i only tried bzr merge till now
[22:51] <knittl> it tells me there's »nothing to do«
[22:53] <lifeless> knittl: what is the *exact* command line you are running
[22:53] <ivazquez|laptop> Given a bzrlib.branch.BzrBranch6, how do I get the revision of a file within?
[22:53] <knittl> lifeless: bzr merge (master)
[22:54] <knittl> master or not, the output is the same
[22:54] <lifeless> ivazquez|laptop: you need a revision tree - so tree = branch.repository.revision_tree(branch.last_revision()); tree[tree.path2id('path')].revision
[22:55] <ivazquez|laptop> Excellent, thanks.
[22:55] <lifeless> knittl: the literal word master, or the URL ?
[22:56] <knittl> lifeless: ok, i tried "master" after your advice. but i tried the url before and it doesn't change anything
[22:56] <lifeless> knittl: does 'bzr missing URL' report anything?
[22:58] <knittl> »you have 4 extra revisions« + the logs
[22:58] <lifeless> knittl: ok, you have everything from that branch already; so either the folders you are talking about aren't versioned, or you've deleted them locally :)
[22:58] <lifeless> knittl: are you able to give us some more data? Is it an open source project that we could go peek at the url ?
[22:58] <knittl> i don't think i deleted them …
[22:59] <knittl> sure … lp:dnd or lp:~knittl/+junk/dnd
[23:01] <lifeless> I'm on a terrible wifi network at the moment, one second while I wait for my packets to get through :)
[23:01] <knittl> no problem … i'm glad you help me understand bzr a little
[23:01] <lifeless> https://code.edge.launchpad.net/~knittl/+junk/mtd ?
[23:02] <lifeless> I can't see a dnd branch of yours
[23:02] <ivazquez|laptop> Hrm. I'm getting "TypeError: unsubscriptable object" from tree[...].
[23:02] <lifeless> ivazquez|laptop: oh sorry, tree.inventory[...
[23:02] <ivazquez|laptop> Ah, thanks.
[23:02] <knittl> lifeless: yes
[23:03] <lifeless> knittl: so is this your branch without the folders, or the branch with the folders that you want to get into your current copy?
[23:03] <knittl> it's my branch without the folders from dnd
[23:03] <knittl> they got added in r12, my r12 differs …
[23:04] <lifeless> ok
[23:04] <lifeless> and where is the dnd branch?
[23:04] <knittl> the dnd branch is just lp:dnd
[23:04] <knittl> or what do you mean?
[23:07] <lifeless> ok, got it. Now what are the folders you want?
[23:08] <knittl> Data/{Models,Sounds}
[23:09] <knittl> and i didn't remove them … i looked at my history
[23:10] <lifeless> your rev 15 merged his rev 12 that added the files, but your merge backed out his changes
[23:10] <lifeless> I imagine you did something like 'bzr revert .' and then committed something
[23:10] <lifeless> which will have kept the merge record but reverted all the code changes
[23:11] <lifeless> this is easy to fix
[23:11] <lifeless> are you still on rev 15?
[23:11] <knittl> iirc i did bzr rm --keep because they were changed (oh damnit …)
[23:11] <knittl> yup, i'm still on 15
[23:11] <lifeless> ok, do  a 'bzr st' and make sure there are no pending changes - no pending merges or changed files
[23:11] <knittl> no output—good  :)
[23:12] <lifeless> now, 'bzr uncommit' and say yes when prompted.
[23:12] <lifeless> then do 'bzr shelve --all'
[23:13] <lifeless> you should now be on rev 14
[23:13] <lifeless> do 'bzr st' again - is there any output
[23:14] <Peng_> lifeless: Should "bzr search" use more memory when it finds tons of results?
[23:14] <knittl> ok, output after uncommit is added [my files] and 1 pending merge
[23:14] <knittl> bzr shelve --all
[23:14] <Peng_> (Well, "more" = 88 MB, and "tons" = "5300")
[23:14] <luke-jr> jelmer: when multiple possibilities are valid, Conflict
[23:15] <lifeless> Peng_: probably, though that does seem excessive
[23:15] <lifeless> knittl: 'bzr st' output after doing the shelve ?
[23:15] <knittl> wops, that bzr shelve shoulda go into my shell xD
[23:15] <knittl> shelve won't complete
[23:15] <knittl> $ bzr shelve --all
[23:15] <knittl> bzr: ERROR: Changes involve binary files.
[23:15] <lifeless> odd
[23:15] <lifeless> what bzr version do you have?
[23:16] <knittl> 1.6.something
[23:16] <knittl> 1.6.1
[23:16] <lifeless> ok, when you get a chance upgrade, cause that is fixed
[23:16] <knittl> that's the latest bazaar i get from the ubuntu repos
[23:16] <lifeless> for now though, just take a copy of your new files somewhere
[23:16] <Peng_> https://launchpad.net/~bzr/+archive
[23:17] <knittl> okay
[23:17] <lifeless> knittl: when you've taken that copy, run 'bzr revert'
[23:18] <lifeless> knittl: and then 'bzr merge lp:dnd', if it merges without conflicts then do 'bzr commit'
[23:18] <knittl> ok, i'll try
[23:18] <knittl> ok, did that, worked fine :)
[23:19] <lifeless> put your files back, run 'bzr add' then 'bzr commit'
[23:19] <knittl> my files are still there … now just the regular bzr add?
[23:19] <knittl> great :)
[23:19] <knittl> why is this so complicated? :p
[23:20] <lifeless> well, its not normall :)
[23:20] <lifeless> knittl: also, you may like to know that you can push to lp:~knittl/dnd/mtd
[23:20] <knittl> :)
[23:20] <knittl> lifeless: yes, i know that …?
[23:21] <lifeless> cool (I just found it odd your branch was in +junk)
[23:21] <knittl> oh yes, i just wanted to test … maybe i'll move it to ~knittl/dnd later on
[23:22] <lifeless> you can do that in the web ui I think
[23:22] <lifeless> anyhow, http://bazaar-vcs.org/Download/ has newer versions of bzr for Ubuntu - just follow the link to the ppa
[23:22] <knittl> yes, but that's not important atm. is long as i can pull/push and have all data xD
[23:24] <knittl> $ bzr push
[23:24] <knittl> Using saved location<EMAIL_ADDRESS>[23:24] <knittl> bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
[23:24] <knittl> :-$
[23:25] <lifeless> add --overwrite
[23:26] <lifeless> that error is just a protection against mmistakes, but we redid that commit deliberately
[23:26] <knittl> ok, i really need to get a newer version
[23:26] <knittl> but that will hopefully be available in jaunty
[23:27] <knittl> lifeless: got it all back to normal. thanks!
[23:27] <knittl> i can always count on irc :)
[23:30] <Peng_> "bzr search a" on bzr.dev takes 84 seconds (user time; realtime fluctuated), VmPeaks at 96 MB, and returns 12,429 results. :D
[23:37] <wgrant> jelmer: Is that add_records() fix in bzr.dev the one to stop it complaining about knit corruption?
[23:38] <jelmer> wgrant, it will stop a complaint if you run "bzr merge"
[23:38] <jelmer> wgrant, it won't affects "bzr check"
[23:38] <wgrant> jelmer: Right. Thanks for handling the bug quickly.
[23:39] <enigma1> Hm...I just got an assert error with bzr-svn 0.5
[23:39] <enigma1> I was pushing a tag back up to SVN.
[23:39] <wgrant> jelmer: Is 0.5 stable now?
[23:39] <wgrant> I thought it was still unreleased.
[23:40] <enigma1> AssertionError: Unable to find direct lhs parent for <RevisionMetadata for revision 9707, path cpp-common/tags/0.11 in repository 'daff2dd8-1c3d-0410-9cd2-f6297dd8f964'>
[23:40] <jelmer> wgrant: Yeah, it's not yet released (there's one rc out, another to follow soon)
[23:40] <enigma1> No...this is off 0.5-trunk
[23:40] <jelmer> enigma42, Any chance you can try after removing the local cache?
[23:40] <jelmer> s/try/try again/
[23:40] <jelmer> there was a bug similar to this fixed some days ago
[23:41] <enigma42> jelmer: I'm a little nervous to clear the cache.
[23:41] <jelmer> enigma42: Why?
[23:41] <enigma42> Last time I cleared the cache, my svn branches got out of sync with the SVN server.
[23:41] <enigma42> So, the latest revisions in bzr were in svn, but they weren't correlated.
[23:41] <jelmer> enigma42: alternatively, you could just move it out of the way for now
[23:42] <enigma42> True.
[23:42] <jelmer> just to see if it helps
[23:42] <enigma42> OK...let me try.
[23:42] <enigma42> Um...I think my 0.5-trunk my be a little of of date, do you know when the bug was fixed?
[23:42] <wgrant> jelmer: Is 0.5 in a PPA somewhere yet?
[23:43] <jelmer> wgrant, there's a month old package in debian experimental
[23:43] <jelmer> enigma42, I think about a week
[23:43]  * wgrant shall update that and PPA it.
[23:43] <jelmer> enigma42, if removing your cache causes issues, that would be a sign there's a lot more wrong..
[23:44] <enigma42> jelmer: OK. So you think I should update to the latest 0.5-trunk, remove the cache, and try again?
[23:44] <jelmer> enigma42: Please do - that should tell us if those problems are still there, and allow us to fix them
[23:45] <enigma42> OK. Let me give that a go.
[23:47] <enigma42> Oh...on a different note, why is the bzrtools in the PPA *way* out of date?
[23:48] <enigma42> Is that hard to build?
[23:48] <enigma42> Is that something I could build and email to someone?
[23:49] <lifeless> Peng_: yes, thats not that useful :P - searching for multiple terms might be more useful :P
[23:52] <lifeless> jelmer: where is bzr-git up to?
[23:52] <lifeless> jelmer: [should the help be improved, is there meant to be a git:// urlspec?]
[23:53] <jelmer> lifeless: I'm making sure dulwich is ready for a release
[23:54] <jelmer> I blessed the current mapping as stable yesterday and renamed it appriopriately
[23:54] <jelmer> The idea is to release a simple bzr-git in a couple of days
[23:54] <jelmer> meanwhile I'm still working on optimization
[23:55] <enigma42> jelmer: The most recent revision I'm seeing for the 0.5 tree is from Saturday, Dec 27. Does that sound right to you?
[23:55] <jelmer> lifeless, I was hoping to receive comments about my local branches spec, that's the main thing important about URLs
[23:55] <enigma42> jelmer: I'm pulling from: http://people.samba.org/bzr/jelmer/bzr-svn/0.5/
[23:55] <jelmer> enigma42, no, the most recent one is from a couple of hours ago
[23:55] <enigma42> Ack...nevermind.
[23:56] <spiv> "[###################/] determining changes:analyzing repository layout:determining changes:copying revision:determining revisions to fetch:discovering revisions -2349/68866
[23:56] <enigma42> Looked at the wrong end of the log. :-P
[23:56] <lifeless> jelmer: I glanced at it
[23:56] <spiv> "
[23:56] <spiv> jelmer: that's an amusing progress line :)
[23:56] <jelmer> spiv: bug in the new progress code :-(
[23:57] <jelmer> spiv, btw, did you see my comments to your import patch?
[23:57] <spiv> jelmer: yeah, I did.
[23:58] <ivazquez|laptop> Taking a look at https://fedorahosted.org/packagedb/browser/0.3.x , how do I get 182 from the InventoryFile for AUTHORS?
[23:59] <jelmer> hmm, ohloh seems to've released the sourcecode related to their vcs analysis
[23:59] <lifeless> ivazquez|laptop: you map the revision back via the branch
[23:59] <jelmer> and added hg support
[23:59] <jelmer> unfortunately it's all ruby :-(


[02:07] <arraybolt3[m]> lotuspsychje: Alright, added the IRC channels to that bug reporting page you linked to. https://help.ubuntu.com/community/ReportingBugs
[02:24] <Bashing-om> arraybolt3[m]: ^ Well done :D
[02:25] <arraybolt3[m]> Thanks!


[06:01] <oSoMoN> good morning desktoppers
[06:04] <ricotz> hey oSoMoN
[06:04] <oSoMoN> hey ricotz
[06:10] <duflu> Morning oSoMoN, ricotz, seb128
[06:17] <oSoMoN> hey duflu
[06:25] <seb128> hey duflu, ricotz, oSoMoN, how are you? did you have a nice Easter weekend?
[06:25] <duflu> seb128, I'm good but it was a busy weekend as expected.  How are you?
[06:26] <seb128> I'm alright, still not fully over the cold and a bit exhausted from the weekend, hopefully it's a bit quieter today ;-)
[06:27] <seb128> we did skip monday for most but reminder about the discourse weekly summary post for those who didn't do it yet (and yes that is including me, I'm working on it atm :-)
[06:30] <oSoMoN> Salut seb128! will do the weekly summary when I get back from school. Week-end was nice, I spent lots of time in the garden planting stuff and playing with my daughters.
[06:35] <didrocks> good morning
[06:36] <ricotz> hello duflu seb128 didrocks
[06:37] <oSoMoN> salut didrocks
[06:40] <didrocks> hey ricotz, salut oSoMoN
[07:05] <duflu> Hi didrocks
[07:08] <didrocks> hey duflu
[07:11] <luna> morning
[07:11] <didrocks> hey luna
[07:13] <marcustomlinson> morning oSoMoN ricotz duflu seb128 didrocks luna
[07:13] <didrocks> hey hey marcustomlinson
[07:13] <duflu> Hi luna, marcustomlinson
[07:15] <jibel> Good morning
[07:15] <marcustomlinson> hey jibel
[07:16] <jibel> Hi marcustomlinson
[07:20] <seb128> oSoMoN, sounds a nice weekend you had ;-)
[07:20] <seb128> hey marcustomlinson, jibel, didrocks
[07:20] <jamesh> hi all
[07:21] <marcustomlinson> hi jamesh
[07:21] <didrocks> salut jibel, seb128, jamesh
[07:27] <seb128> duflu, I don't think that gtk assert is specific to themes, it's just happens if you try to do something in gtk that requires an icon where the pixbuf loaders are not available
[07:27] <duflu> seb128, I was going by the comment in the GTK source code from the upstream bug
[07:27] <duflu> I don't really mind what the cause is. Just want anyone affected to talk to each other
[07:29] <seb128> duflu, see comment #11 and #12 on launchpad, they have more details
[07:29] <seb128> but from an upstream perspective it's a broken setup
[07:29] <seb128> that's what we get by doing in-session-upgrades
[07:29] <duflu> Yep
[07:33] <Nafallo> morning desktopers
[07:33] <marcustomlinson> morning Nafallo
[07:40] <duflu> Hi Nafallo
[07:51] <oSoMoN> good morning/afternoon luna, marcustomlinson, jibel, jamesh, Nafallo
[08:02] <Awayney> this thing on?
[08:03] <luna> Laney: yeah
[08:03] <didrocks> wb Laney
[08:16] <Laney> hey luna and didrocks
[08:28] <duflu> Hi Laney
[08:33] <marcustomlinson> hey Laney
[08:37] <Laney> yo duflu yo marcustomlinson
[08:37] <seb128> Laney, hey, welcome back! did you have a nice time off?
[08:40] <duflu> 🪀
[08:47] <Laney> hey seb128
[08:47] <Laney> yeah was nice, I got lucky with the weather last week
[08:47] <Laney> how's it going there?
[08:48] <Laney> & did much happen here?
[08:49] <seb128> quite busy as usual! beta happened, otherwise not much worth mentioning afaik
[08:50] <Laney> mmm
[08:50] <Laney> I did think about the slideshow at one point
[08:51] <Laney> hey looks like we got a new iso age graph on the dashboard, that looks worth mentioning to me
[09:01] <luna> New test daily images out 06 to test
[09:17] <didrocks> any idea on how to use a local polkit daemon (to read policies on a local directory for tests) on our own separated system bus?
[09:41] <GunnarHj> seb128, Laney, sil2100: Thanks again for your endorsements of my core-dev appl.!
[09:41] <GunnarHj> As you may have seen I passed the DMB grilling yesterday.
[09:46] <seb128> GunnarHj, hey, congrats on finally getting those upload rights ;-)
[09:47] <GunnarHj> seb128: Thx. So finally you'll get rid of quite a few sponsorship requests from me. :)
[09:47] <seb128> Laney, ah right thanks again for helping there! I did set up a basic KPI graph for the ISO but we should get one for the flavors as well, I was unsure how to properly regroup or present. It could be worth a different category
[09:47] <seb128> GunnarHj, :-)
[09:48] <Laney> GunnarHj: well done!
[09:48] <Laney> review requests still appreciated ;-)
[09:48] <Laney> hoho, now you can review us though
[09:48] <GunnarHj> Thanks, Laney. Yeah, they will still come once in a while, no worries.
[09:49] <seb128> Laney, also I need to check how to change the refresh interval, the iso are built once a day it doesn't make sense to pull data every 10min
[09:49] <Laney> seb128: there's a variable you can set, I think one of the other ones uses that
[09:50] <Laney> and a different dashboard might be nice, you could have a selector at the top for flavour and release or something
[09:50] <seb128> ah, thanks for the hint, I will check
[11:25] <GunnarHj> seb128: Trying to improve translations of desktop-icons-ng (bug #1922383). There is a no-change rebuild in the hirsute queue to get the template into the translation import queue. As a next step I plan to patch the latest upstream translations. Does that make sense? Is there any other commit which we should take the opportunity to cherry pick?
[11:25] <GunnarHj> https://gitlab.com/rastersoft/desktop-icons-ng/-/commits/master
[12:18] <seb128> GunnarHj, I would cherry pick the fixes duflu mentioned on his weekly summary on discourse
[12:20] <GunnarHj> seb128: Ok, will do.
[12:21] <seb128> GunnarHj, thanks :-)
[12:31] <luna> congrats GunnarHj to get accepted as an uploader
[12:32] <GunnarHj> Thanks luna!
[14:13] <luna> meeting in a couple of minutes, 3 meetings left before they change format
[14:32] <luna> any meeting today?
[14:40] <luna> Anyone know how to mount ZFS the easiest way from an Ubuntu Live USB ?
[14:43] <jibel> luna, zpool import -a -R <root>
[14:43] <jibel> man zpool-import for details
[14:50] <luna> jibel: thanks, moving all my dotfiles to make a reinstall of my desktop now
[14:58] <Nafallo> hmm. to echo luna. where's the meeting? :-D
[14:58] <Nafallo> I was planning to check the status of https://bugs.launchpad.net/ubuntu/+source/gnome-weather/+bug/1918044 now that it got fixed upstream ;-)
[15:14] <hellsworth> good morning desktopers
[15:14] <oSoMoN> hello hellsworth
[15:14] <marcustomlinson> morning hellsworth
[15:14] <hellsworth> o/ guys!
[15:15] <hellsworth> i hope yall had a nice long weekend :)
[15:15] <oSoMoN> Nafallo, https://discourse.ubuntu.com/t/announcing-the-ubuntu-desktop-team-indaba-ama-april-23-2021/21591
[15:16] <marcustomlinson> hellsworth: was good thanks. hope you have a nice regular weekend :)
[15:18] <hellsworth> haha yeah it was extra good though :)
[15:18] <marcustomlinson> /s/have/had
[15:21] <jibel> Good morning hellsworth
[15:22] <hellsworth> hi there jibel
[16:12] <Nafallo> oSoMoN: thanks. I'll deprecate it in my calendar as well then ;-)
[16:13] <oSoMoN> luna, you were offline when I answered your question about the weekly meeting, see https://discourse.ubuntu.com/t/announcing-the-ubuntu-desktop-team-indaba-ama-april-23-2021/21591
[17:56] <KGB-0> gobject-introspection debian/master Janitor * [close] merge request !8: Apply hints suggested by the multi-arch hinter * https://deb.li/fhGs
[17:56] <KGB-0> gobject-introspection Janitor 234901 * commented merge request !8 * https://deb.li/iOXRz
[18:04] <KGB-0> gobject-introspection debian/master Janitor * [close] merge request !7: Apply hints suggested by the multi-arch hinter * https://deb.li/3yxUR
[18:04] <KGB-0> gobject-introspection Janitor 234904 * commented merge request !7 * https://deb.li/UFB1
[19:46] <luna> Reinstalled my desktop with todays Hirsute beta today :)
[19:46] <luna> so if anyone special needs testing i have time to test
[19:47] <seb128> luna, nothing special but any report of issue you find is welcome!
[19:49] <luna> alright so far i found out this https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1922293 also affects me
[19:51] <seb128> I saw that discussed earlier indeed
[19:52] <seb128> hellsworth, hey, something is weird with glimpse-editor, the stable channel has  0+git<...> version which doesn't seem to come from https://launchpad.net/~hellsworth/+snap/glimpse-editor-stable ? is that expected? also did you say you would remove the i386 binary?
[19:53] <hellsworth> interesting, i closed the channels and then reopened them and promoted a recent build to just amd64 but the i386 binary is there?
[19:53] <luna> seb128: hopefully it will fix itself without a reinstall, but just in case i guess i am not gonna install back all software before release :p
[19:53] <hellsworth> yes let me look into the glimpse build..
[19:56] <hellsworth> ok NOW the i386 binary should be gone (well once the store page updates, i think every 10 min)
[19:58] <seb128> it is indeed, {'amd64': {'stable': 194}}
[19:58] <seb128> thanks!
[19:59] <seb128> and the version what's up there? where isn't it 0.2<something> anymore and not built from glimpse-editor-stable ?
[20:24] <hellsworth> seb128: looking into the glimpse builds now


[00:10] <shadeslayer> lilstevie: ok, just a small question, SBKv2 means that the security key changed and we don't know the new key, right?
[00:16] <lilstevie> correct
[00:16] <lilstevie> well, more to the point, we have the key, but have been asked not to release it this time
[00:16] <lilstevie> but there is a little compatibility issue
[02:43] <jkfangTW> Does anyone know how to install omap4-extras-multimedia for ubuntu(Oneiric) ?
[02:43] <jkfangTW> This multimedia addons looks imcomplete.
[02:44] <jkfangTW> I cannot install it via synaptic by adding tiomap PPA on Oneiric.
[02:50] <jkfangTW> Names
[03:05] <davidm> jkfangTW, I'm not sure that TI has put everything into the PPA yet
[03:05] <davidm> I hope they will do it soonish
[04:30] <Netham46> Three things: 1) I have a USB headset that has drivers for x86(-64) but none for ARM. Know where I would look to get the sources, and how to build/use 'em? 2) I'm running on an android tablet. Is there any way I could run my Android apps natively on ubuntu? 3) Know of an onlive client for ARM?
[04:31] <Netham46> Other than the audio meter being a bit wonky, my onboard audio is working great, btw. Also, the controls for my headset (vol+/vol-/mute) all work as expected.
[04:32] <Netham46> Also, is Kubuntu Mobile a real thing? o.O
[04:33] <twb> Netham46: that kinda depends on the headset
[04:33] <Netham46> Microsoft LifeChat LX-3000
[04:34] <twb> Netham46: if you're talking about out-of-kernel (third-party) drivers, you should probably write to the vendor and ask for the source.
[04:34] <Netham46> Something tells me that MS didn't make Linux drivers for it
[04:34] <twb> How do you have drivers for x86-64 then
[04:35] <Netham46> THey came w/ the distro.
[04:35] <Netham46> and, tbh, I'm not 100% sure how the driver thing works on *nix. I've only ever messed with network stuff.
[04:36] <twb> Well, unlike e.g. Windows, most drivers ship with the kernel itself -- they're available everywhere, unless the distro decides to remove them
[04:36] <twb> If that's the case for your device, it should work just as well on ARM
[04:37] <twb> If you're using something like Ubuntu on x86-64, though, they do include a handful of third-party drivers, and the state of those varies wildly
[04:37] <Netham46> Well, it worked as expected on x86-64 out-of-box
[04:43] <twb> As to your second question, I don't know anything about android but I guess it would depend on someone porting dalvik to ubuntu
[04:44] <Netham46> Kk.
[04:45] <Netham46> I've pretty much given up on OnLive on it for now, too, heh. I was just seeing if someone might know something I've missed.
[04:52] <Netham46> Oh yea, one last question, is there any solution to get flash?
[04:53] <twb> I have no idea; I don't use GUIs
[04:53] <twb> I suppose you could use an open-source implementation like gnash
[04:54] <twb> And obviously e.g. mplayer supports the FLV codec, so you don't need flash for youtube or whatever
[04:55] <Netham46> I'd like to get Hulu and Pandora to run. Right now, I'm using a dedicated Pandora app.
[04:56] <twb> This would be pandora the America-only music thing, not Pandora the hand-held ARM-based game console?
[04:56] <Netham46> pandora the americal-only music thing
[04:56] <Netham46> Didn't realize it was region-locked, though
[04:56] <twb> I don't know anything about that, sorry.
[04:57] <Netham46> The web client is flash-based
[05:07] <Amaranth> hrm, oneiric feels likes it's at least twice as slow as natty on panda
[05:07] <Amaranth> Netham46: The web client is HTML5
[05:08] <Netham46> Amaranth, in both FF and Chromium it asks me to install Flash
[05:08] <twb> Can GCC build thumbee binaries?
[05:09] <Netham46> also, KDE is much better in oneiric for me, I'm not getting random crashes anymore
[05:09] <Netham46> now if only nvidia could release drivers that aren't complete garbage for the tegra 2
[05:10] <jkfangTW> Amranth, have you done some bechmarks ? I'm also  testing oneiric and Natty on my pandaboard .
[05:10] <Amaranth> If nvidia could release drivers that aren't complete garbage for anything other than Windows I'd be shocked
[05:10] <Amaranth> jkfangTW: No, just going in feeling
[05:10] <Netham46> Their PC drivers are pretty decent
[05:10] <Netham46> far better than ATIs
[05:10] <twb> Netham46: you're only saying that because you haven't seen the source
[05:11] <Netham46> Fair enough
[05:11] <Netham46> That and I only tend to use Linux on platforms where Windows isn't available
[05:18] <GrueMaster> Netham46: For Pandora, you can install pithos from the ubuntu universe repository on any system that will run 11.10.  I am running it now on a TI omap4 pandaboard.
[05:19] <netham45_tab> yea, that's what I'm using rightn ow.
[05:19] <GrueMaster> Flash is a whole nother ball game.  It requires either a fast processor (x86) or hardware decoding (arm).  On the arm side, there are ways of getting a version to run on Ubuntu, but I am not sure how.  Need Google search.
[05:21] <netham45_tab> kk.
[05:22] <netham45_tab> bah, I went to do a search for libflashplayer.so and apparantly that's a valid domain. has a placer on it.
[05:25] <GrueMaster> Try this version for arm.  http://kotelett.no/ac100/phh/Android2.2/libflashplayer.so
[10:09] <ndec> ogra_: are you doing something 'somewhere' to configure the audio on panda on first boot?
[10:10] <ogra_> ndec, nopw
[10:10] <ogra_> i dont think so
[10:10] <ndec> we don't have audio on Blaze by default...
[10:10] <ndec> so i was thinking that something is done for Panda somewhere...
[13:25] <ndec> ogra_: i think you lied to me ;-) see /lib/udev/rules.d/90-alsa-ucm.rules
[13:25] <ogra_> ndec, thats on all ubuntu images
[13:25] <ndec> grep Panda ;-)
[13:25] <ogra_> not special by any means
[13:26] <ogra_> grep SDP
[13:26] <ogra_> ;)
[13:28] <ogra_> ndec, that file comes with alsa and as long as the blaze still uses proper device naming it should be fine
[13:28] <ndec> yeah... but it does not ;-)
[13:28] <ndec> we are debugging why!
[13:28] <ogra_> is the devce still called SDP4430 ?
[13:28] <ndec> yes
[13:28] <ogra_> weird
[13:29] <ndec> we will need to look in the udev log
[13:30] <ogra_> i think you can also monitor udev somehow
[13:30] <ogra_> beyond the log ... i.e. the daemon
[13:32] <ndec> yes. that's what i meant indeed.
[14:44] <dabukalam> is the beagleboard xM omap3 or omap4?
[14:45] <ogra_> 3
[14:45] <dabukalam> ogra_, thx
[14:47] <prpplague> techincally its DM3xxx , but that is splitting hairs
[16:01] <dabukalam> just installed oneiric server on a beagleboard
[16:01] <dabukalam> but did all the installation through serial
[16:02] <dabukalam> why doesn't it output to a monitor?
[16:04] <ogra_> because its a server image ?
[16:04] <ogra_> it shoudl offer a tty for login after install on the monotor though
[16:04] <dabukalam> that's what I mean
[16:05] <dabukalam> aha
[16:05] <dabukalam> got it
[16:30] <dabukalam> ogra_, I dunno if you remember, but I was trying to put core on an i.MX53.
[16:30] <ogra_> yep
[16:30] <dabukalam> ogra_, now I'm trying to the same thing with a beagleboard xM
[16:30] <ogra_> ah
[16:30] <ogra_> should work the same way, module kernel/bootloader
[16:30] <dabukalam> yeah
[16:30] <ogra_> *modulo
[16:30] <dabukalam> that's what I assumed
[16:31] <dabukalam> but oneiric server images
[16:31] <dabukalam> are only two partitins
[16:31] <dabukalam> *partitions
[16:31] <dabukalam> not 3
[16:31] <dabukalam> same with the desktop ones
[16:31] <dabukalam> (for omap as opposed to mx)
[16:32] <ogra_> as i said, modulo the bootloader/kernel bits :)
[16:37] <dabukalam> where would the kernel be located?
[16:42] <dabukalam> ogra_, just the image in /boot?
[16:42] <ogra_> for the beagle ?
[16:43] <dabukalam> ogra_,
[16:43] <dabukalam> ya
[16:44] <ogra_> well, in different places
[16:44] <ogra_> there is vmlinuz in /boot
[16:44] <ogra_> and there is the boot partition that carries a uImage
[16:48] <dabukalam> yeah yeah ofc
[16:48] <dabukalam> i just leave that partition the way it is
[16:50] <GrueMaster> dabukalam: If you are just setting up a beagle to boot from sd with root on usb or network, it may be easier to just run the netinstall.
[16:50] <GrueMaster> That is supported for omap.
[17:03] <ogra_> GrueMaster, he is supposed to set up core on several differnnt arches
[17:04] <GrueMaster> Ah.  Well, it should work.  Just takes a little tweaking.  I have used it as a chroot and as a nfs-root.
[17:04] <ogra_> yep, me too, i have never natively booted it though, good to see it works :)
[19:52] <dabukalam> ogra_, you here?


[01:30] <FernandoMiguel> nite
[05:59] <broder> bah - sorry, did i miss a response?
[06:01] <Sarvatt> broder: ya didnt ask anything in this channel
[06:02] <broder> oh, ok. irc client must have flaked worse than it looked
[06:02] <broder> on a standard desktop, is there something other than g-p-m (or g-s-d now) that will blank the screen? the kernel or something?
[06:03] <Sarvatt> not that i'm aware of, should only be g-s-d now
[06:04] <broder> did the kernel used to?
[06:05] <broder> i have a (2-4 yr old intel chip, running natty) machine in front of me that blanks the screen after 5-10 minutes in spite of /apps/gnome-power-manager/timeout/sleep_display_ac being 0
[06:07] <Sarvatt> whats the gnome-screensaver timeout?
[06:07] <broder> ooh, look at that
[06:08] <broder> i uninstalled gnome-ss uninstalled, but xset q tells me there's still a screensaver timeout set
[06:10] <broder> Sarvatt: cool, i can chase this from here. thanks for that :)
[15:53] <FernandoMiguel> oias
[20:14] <Prf_Jakob> Sarvatt, RAOF: It looks like the new 12.04 installer requires a larger screen then 800x600.
[20:14] <Prf_Jakob> Which happens to be the default screen size for VM's
[20:18] <bryceh> Prf_Jakob, you mean for the webcam picture taker thingee?
[20:18] <Prf_Jakob> bryceh: no just the installer, got a bug report saying that some controlls ended up outside the screen.
[20:19] <Prf_Jakob> That is I don't know if it is that.
[20:19] <bryceh> it probably is, there's a bug filed about it against ubiquity already
[20:20] <bryceh> I ran into that myself doing an install on a netbook
[20:20] <Prf_Jakob> ok
[20:20] <Prf_Jakob> We can up the default the screen size in the driver, but that would lead to uncomfritables for netbooks.
[20:23] <Prf_Jakob> bryceh: do you happen to have the bug number available?
[20:23] <bryceh> Prf_Jakob, I think it really should be fixed in ubiquity.  It looks to me like they just need to scale the pictures being displayed when the screen resolution is below 800x600
[20:24] <Prf_Jakob> yeah that would be better.
[20:24] <bryceh> Prf_Jakob, not offhand
[20:24] <Prf_Jakob> ok
[20:24] <bryceh> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/869239
[20:24] <ubot4> Launchpad bug 869239 in ubiquity (Ubuntu) "webcam screen should be resized for netbooks (Eee PC, 10") (affects: 8) (dups: 3) (heat: 48)" [High,Triaged]
[20:24] <Prf_Jakob> thanks!
[20:24] <bryceh> thank firefox url autocomplete :-)
[20:25] <Prf_Jakob> haha :)
[20:25] <bryceh> Prf_Jakob, if you can add your case to that bug report, I'll bump up the importance on it a notch
[20:25] <bryceh> maybe it'll get some attention
[20:38] <Prf_Jakob> Okay, which email/pass combo did I use..
[20:44] <Prf_Jakob> bryceh: ok done.
[20:59] <bryceh> alrighty
[21:00] <bryceh> it should show up on the release manager's list for alpha-2 now, which should ensure it gets some attention
[21:18] <Prf_Jakob> bryceh: thanks, are you guys shipping 12.04 with mesa 8.0/7.12?
[21:33] <bryceh> Prf_Jakob, yep
[21:34] <Prf_Jakob> right, I'm guessing you are not using the xa_branch of xf86-video-vmware repo tho.
[21:36] <bryceh> not sure, I haven't looked at the -vmware package in some time
[21:37] <Prf_Jakob> http://packages.ubuntu.com/precise/x11/xserver-xorg-video-vmware <-- doesn't mention it in the package log.
[21:43] <Sarvatt> Prf_Jakob: speaking of that, is that branch not going to get pushed to master or something?
[21:44] <bryceh> Prf_Jakob, looks like we're just pulling from debian, so probably would be best if any branch changes be coordinated through them
[21:47] <Sarvatt> its probably going to be another month or so at least, need a 8.0 mesa branch to enable xatracker for it and all but was just assuming vmwgfx_branch would go to master at some point
[21:51] <Prf_Jakob> Yeah that branch is going to be merged soon.
[21:52] <Prf_Jakob> Sarvatt: Okay, good to know.


[03:57] <persia> Just FYI, I've created #ubuntu-packaging to handle support with packaging stuff for Ubuntu.  Someone should complain if they don't like the current ACCESS.
[05:21] <SpaceGhostC2C> Flannel: can we figure it out here?
[05:21] <Flannel> SpaceGhostC2C: Don't invite people to troll other channels.  There's nothing to figure out.
[05:22] <SpaceGhostC2C> Flannel: I invited them there. I didn't say, "Hey let's go laugh at these tards." I said there was a #jesus channel.
[05:22] <SpaceGhostC2C> If they wanted to chat about religion
[05:22] <SpaceGhostC2C> Which is the subject.
[05:22] <SpaceGhostC2C> Maybe it needs to be updated that you can't invite anyone to another channel.
[05:22] <Flannel> Your comment, "It's a lawl and a half", is sort of damning
[05:23] <SpaceGhostC2C> May be. You can't find humor in religion? I find a lot of my beliefs rather odd and even comical.
[05:24] <SpaceGhostC2C> Currently they said I didn't troll.
[05:24] <SpaceGhostC2C> Whether other users were trolling isn't my fault. I found the channel really funny after about 5 minutes when three other users joined and tried fault-finding in the bible.
[05:25] <Flannel> SpaceGhostC2C: What are we discussing anyway?  Would you like me to ban you from #ubuntu-offtopic so that you have a reason to come here and plead your case?
[05:25] <Flannel> I told you from the get go: You don't want to walk this line-- You will lose.
[05:25] <SpaceGhostC2C> I'm saying I didn't break rules. I didn't troll there.
[05:26] <Flannel> All I'm saying is if you troll places, or invite others to do so, you will find yourself banned.
[05:26] <persia> May I mediate?
[05:27] <SpaceGhostC2C> I think it would e fair.
[05:27] <Flannel> persia: I don't think there's anything to mediate, two statements of fact.
[05:27] <SpaceGhostC2C> I didn't troll, and I invited others. I said it was a lawl and a half because other people were trolling.
[05:27] <persia> Flannel: I see statements from both sides.  I don't see communication yet.  I'll happily stand back.
[05:28] <SpaceGhostC2C> I found it rather funny to watch people grep'ing through the bible trying to find contradictions.
[05:28] <SpaceGhostC2C> I think it all hinges whether I was trolling, and my stand and #jesus' is that I wasn't.
[05:29] <Flannel> SpaceGhostC2C: You actively trolling in that channel isn't important.  Your comment in -ot was one of encouraging people to join that channel for the purpose of amusement, not for the given purpose of that channel.
[05:30] <SpaceGhostC2C> I'm sorry I found people trying to troll amusing. I said that if they want to chat about religion that #jesus is a place they could go, and I added my synopsis of the current state of the channel.
[05:31] <Flannel> SpaceGhostC2C: Perhaps it'd be best if you simply refrained from doing so in the future then.
[05:31] <SpaceGhostC2C> Like currently Shaddowwolf is trolling. I'm asking the op his opinion.
[05:31] <SpaceGhostC2C> Sounds great. Thanks Flannel.
[06:29] <dholbach> good morning
[08:11] <SpaceGhostC2C> Hey, I was just wondering something, I asked Flannel if it was cool to say I enjoyed my time at the #jesus channel, and he said it wasn't.
[08:12] <SpaceGhostC2C> I didn't want to talk about it, but I had a good debate and we all ended happily, no hurt feelings, we even discussed VPS hosts for a while.
[08:13] <SpaceGhostC2C> I just wanted to tell the channel that the people in #jesus were pretty cool, but wanted to know first if it was okay and Flannel said it wasn't.
[08:15] <SpaceGhostC2C> Commentarios?
[08:16] <persia> Discussions related to religion are tricky, and it's easy to end up being misinterpreted.
[08:16] <SpaceGhostC2C> Earlier there was some issue dealing with trolling, which I wasn't taking part in, but mentioned when I said to a user who was talking about religion that he should come to #jesus and I mentioned that it was a lawl and a half because some -ot members were trolling.
[08:17] <jussi01> I think !o4o explains it pretty well
[08:17] <SpaceGhostC2C> persia: what I wanted to say had nothing to do with religion, just that the occupants of the channel were pretty cool.
[08:17] <persia> There's nothing wrong with saying that one enjoys another channel, or that the people in another channel are cool, but one has to be careful to not imply that people should be in that channel or that one's experience is related to a religious issue.
[08:18] <SpaceGhostC2C> I wanted to say this, "I had a pretty good time with the guys in #jesus."
[08:18] <jussi01> SpaceGhostC2C: use common sense. if it seems to create an issue, then just leave it. However, that said, any advertising or perceived advertising of other channels with out the channel owners consent is spam.
[08:19] <SpaceGhostC2C> It wasn't advertising, it was my thoughts on the people in it, and it didn't break rules. It wasn't about the content or topic of the channel, so I think that means that it is okay to say.
[08:19] <topyli> advertising channels is not often a good idea, unless asked. did someone ask you for jesus-related channels?
[08:19] <SpaceGhostC2C> topyli: at this time, I just wanted to say I had fun there. Nothing else.
[08:19] <SpaceGhostC2C> Not that anyone should go there.
[08:20] <persia> SpaceGhostC2C: The trick is that it's hard to find an audience to which it is safe to express that.  Do consider that the recipients of your message may have all sorts of interpretations to your words.
[08:20] <SpaceGhostC2C> Earlier, someone was interested in religion as a topic and I mentioned they could go to #jesus. I also lawled a bit at the -ot people who were trolling them, and then confirmed that the ops and other members of #jesus didn't think I was trolling.
[08:21] <SpaceGhostC2C> If I said, "I had a pretty good time with  the guys in #jesus."
[08:21] <SpaceGhostC2C> I might get the usual guff, but I doubt anyone would be offended.
[08:24] <SpaceGhostC2C> So, It'd be okay if I said just what I quoted?  It's not !o4o.
[08:26] <SpaceGhostC2C> But op wishes are my command.
[08:26] <SpaceGhostC2C> Whether rules are broken or not, ops are God.
[08:26] <SpaceGhostC2C> Later.
[09:08] <Flannel> What's up with +es?  there haven't been any recently
[09:09] <Flannel> (that'd be exceptions for proxy users)
[09:10] <elky> that'd be why we just got abused in -proxy-users then
[09:11] <elky> maybe floodbot4 can't do them?
[09:11] <Flannel> status is normal, I'm not sure if the FBs are supposed to be opped anymore or not
[09:19] <elky> [20:19] == FloodBot4 invites you to join #ubuntu
[09:19] <elky> [20:19] == #ubuntu Cannot join channel (+b) - you are banned
[09:22] <elky> that would be why
[09:22] <elky> !ops | O HAI GUISE! guess what!
[09:23] <elky> someone please hook floodbot4 in to ubottu for next time too, plxkthx
[09:25] <elky> Myrtti, can i borrow some scripty goodness when you wake plz?
[09:25] <elky> holy crap, it hasn't been /removing/ exempts.....
[09:26] <elky> I think i'll remove the ones that have been going since mid-february, what do you think, flannel?
[09:27] <elky> anything for feb to go?
[09:39] <Myrtti> http://ubuntu.pastebin.com
[09:39] <Myrtti> meh
[09:40] <elky> it's the bots that need fixing more
[09:40] <elky> there's exempts dating back to mid-feb
[09:40] <jpds> We have paste.u.c for a reason. ;)
[09:41] <Myrtti> jpds: the problem isn't with pastebin, it's my script. If you've got issues with how it works, you're free to make your own - I don't have time right now to debug mine.
[09:44] <Myrtti> http://ubuntu.pastebin.com
[09:44] <Myrtti> yeah, doesn't work.
[09:44]  * Myrtti goes back to work.
[09:52] <elky> yeah, im doing 1 at a time so it's not as invasive -- there's a crapton of floodbot exempts from february still
[09:56] <jpds> We should so have a /cs clear exempts
[09:58] <elky> except many of them will still be in use
[09:58] <elky> you'd have to be able to give it a date range imho
[10:05] <elky> indus, can we help?
[10:05] <indus> no
[10:07] <indus> wondering if there exists a #ubuntu+1 , there should be a #ubuntu -2 for hardy :)
[10:08] <Myrtti> why?
[10:08] <indus> anyways, when does the #ubuntu room get > 2000 users
[10:08] <elky> +1 is to separate out questions related to a system in active development, not because it's lts.
[10:08] <Myrtti> it's hardy is still supported just like karmic is
[10:08] <indus> ah never mind my questions, some problem with my head today
[10:08] <indus> bye
[10:09] <elky> The only fair reponse to that is "only today", I suspect.
[10:09] <elky> err, "only today?"
[10:10] <Myrtti> coffee consumed, back to work
[10:12] <elky> floodbot1 and floodbot2 done. floodbot3 and floodbot4 still need doing
[11:58] <elky> keep a watch on vishal. just tried to dcc a 0 byte file to me and then asked where to get software for ubuntu.
[11:58] <elky> he's quit now, but i've seen the nick floating around...
[12:44] <tomaw> anyone around?
[12:47] <persia> many folk.  Who do you need?
[12:47] <tomaw> #ubuntu is being botted but you've not noticed yet
[12:48] <tomaw> we've a utility that can automatically kill them but there's a chance of false positives
[12:48]  * persia can't do anything about Ubuntu, but with that context, maybe someone else can.
[12:48] <persia> s/Ubuntu/#ubuntu/
[12:51] <tomaw> I joined the bot as that's far too intensive to control manually
[12:53] <tomaw> and doing so has scared them somewhere else anyway
[12:59] <tomaw> or not.  I'm quite confident it's not hitting anything it shouldn't now but I'll remove it later in case that changes.
[13:00] <jussi01> tomaw: thanks for that.
[13:02] <elky> tomaw, thanks. usual suspects?
[13:03] <tomaw> I'm not sure.  We've not let them get enough bots in a channel to do whatever it is they intend to.
[13:04] <elky> I think I can cope with that answer :)
[13:05] <bazhang> thanks tomaw
[13:05] <tomaw> they're all listed in the efnet rbl but we don't use that for anything more than alerts as it contains some stuff we don't want to ban on automatically
[13:06] <tomaw> well, alerts and the occasional onjoin kill with idoru ;)
[17:45] <jussi01> SWAT: lol at the sudo crem :D
[18:37] <SWAT> jussi01: I also found it hilarious. We had quite the laugh about it
[18:43] <switchgirl> hi i have spotted behaviour  that is TOTALLY inappropriate and un ubuntu like - on launchpad - more like a-ban-too https://answers.launchpad.net/ubuntu/+source/apt/+question/103579 << the comment from terminate
[18:43] <switchgirl> what can i do
[18:47] <switchgirl> ignore me i misread it
[18:47] <switchgirl> sorry
[18:47] <mneptok> the unobfusctaed lamnguage is bad, but he's quoting others.
[18:47] <mneptok> bah.
[18:47] <genii> Weird
[18:48] <mneptok> indeed
[19:04] <jussi01> Ranakah: good evening! How may we help you today?
[19:04] <Ranakah> i am banned on #ubuntu because unstabble connection
[19:05] <Ranakah> i upgrade my router and there are some problems.. i fix this :)
[19:05] <Ranakah> sorry... good evening :)
[19:06] <mneptok> @login
[19:07] <ikonia> I see the ban
[19:07] <ikonia> I'll remove it if you like ?
[19:07] <Ranakah> please :)
[19:07] <ikonia> I assume you're connections stable looking at the scroll back now
[19:07] <Ranakah> i see.. now i use other tunnel :)
[19:08] <Ranakah> tnx for unban
[19:08] <Ranakah> have a nice day
[19:08] <ikonia> well I've removed the ban, I see you're connection is much better
[20:00] <topyli> again, can we please disable @lart?
[20:31] <erUSUL> anyone (half)awake ??
[20:32]  * mneptok is, as is Myrtti
[20:34] <erUSUL> ok; tyvm
[21:20] <guntbert> hi, can someone have a look at bullgard ? he insists on asking people to "test video chat" with him. Or is my meter way off?
[21:21] <knome> just make sure the one who tests it is a hairy male
[21:21] <knome> :|
[21:21] <knome> (just kidding)
[21:21] <guntbert> knome: no - I'm being serious - is that something you'd let just pass?
[21:22] <knome> i'm not sure. did he actually try to set up his video, or just popped id?
[21:22] <knome> *in
[21:23] <guntbert> knome: oh - I didn't mention it was in #ubuntu - I told him it was off topic and he insists it is not...
[21:24] <knome> well, i can't do anything about #ubuntu...
[21:24] <knome> maybe just ignore him
[21:24] <knome> if he doesn't keep on insisting
[21:25] <guntbert> knome: thought so - from your nick :-) - well I'm gonna leave anyway - have a nice time
[21:25] <knome> hehe, i'm not a kde guy either ;)
[21:25] <knome> enjoy yourself as well
[21:26] <guntbert> knome: btw - if you omit my nick My client doesn't alert me when you address me :-)
[21:26] <knome> guntbert, heh, i know ;)
[21:27] <guntbert> knome: is much easier for me - gnight
[21:27] <knome> guntbert, night!
[21:38] <mneptok> IMO, asking for help in testing an app's functionality in #ubuntu is kosher.
[21:39] <knome> right
[21:40] <mneptok> of course, it depends on how you're asked.
[21:41] <mneptok> "I HOT MALE U MAKE HOT SEXY CHATS TO ME, AMERICAN BOOBLADY!!!!!1!!!!111!!" != kosher
[21:41] <knome> ;))
[21:56] <Jordan_U> remczas in #ubuntu is a bot.
[21:56] <Jordan_U> Maybe not.
[21:59] <Jordan_U> From talking to remczas in a PM it seems I was wrong. He just had a very bot like response to me triggering ubottu with "!google | theZagnut"