[00:11] <Raim> hi
[00:11] <Raim> what should I do if bzr instructs me to run 'bzr upgrade' but then it tells me that it is already at the latest format version?
[00:11] <Raim> see http://pbot.rmdir.de/c09c1e95ebc98ddbc7148e2c3a228cc8
[00:13] <Peng_> Raim: It's telling you to upgrade http://code.bitlbee.org/bitlbee/
[00:13] <Peng_> Damn LF.
[00:13] <Peng_> Raim: , not your local repo.
[00:13] <Raim> Peng_: ah!
[00:13] <Peng_> Actually, it's telling you to upgrade http://code.bitlbee.org/.
[00:13] <Raim> yeah, I understand
[00:14] <Raim> and by reading the message again it even said exactly that
[00:15] <Peng_> Unless you actually run code.bitlbee.org, you can't fix it, but it does encourage you to send them an email, and it helps explain why you'll have awful performance pulling from that repo. :"D
[00:16] <Peng_> s/"//
[00:22] <itistoday> hi there, i'm new to bazaar and DVCS in general, was wondering if someone could help explain to me what the difference between 'pull' and 'merge' is?
[00:36] <mzz> that had better be in the manual, it's kinda important
[00:36]  * mzz checks
[00:39] <mzz> itistoday: "pull" either turns the branch you're running it in into a copy of the branch you're pulling from (while keeping any uncomitted changes) or complains if it can't do so because you have committed changes that aren't in the branch you're pulling
[00:39] <flvr8> it isn't explained well in the user guide, but the man page has a good concise summary (i.e. man bzr)
[00:40] <mzz> itistoday: "merge" should only be done on a branch with no uncommitted changes and combines anything you've committed with anything in the branch you merge that you don't have yet, after which you get to review the result and commit it if it makes sense
[00:40] <mzz> weird that this isn't explained properly in the manual, imho it's kinda important to understand the difference
[00:42] <itistoday> thanks, although sorry, i'm still a little confused... so first, for both 'pull' and 'merge' you need to have an existing branch to run the command from?
[00:42] <mzz> itistoday: it is important to realise that merge is normally done in a clean working dir, and you need to commit the result if it makes sense. "merge" always creates a brand new revision nobody else has yet, even if the resulting text is identical to some revision that already exists. pull fast-forwards, you don't add any revisions other than what you're pulling in.
[00:42] <mzz> yes, both pull and merge need two branches
[00:43] <itistoday> so... I'm assuming the answer to this is 'no', but is then 'pulling' simply merging and then committing? if no, then what's the difference?
[00:43] <mzz> itistoday: if in doubt pulling if you can and merging if pull complains will often work, but in some workflows you may want to explicitly commit a merge even though a pull would be possible.
[00:44] <mzz> itistoday: pull does not create any new revisions that aren't already in the branch you're pulling. after merge you always have to commit the result (even if there are no conflicts)
[00:45] <mzz> itistoday: (this also means that you can merge and then revert if you did not like the result. With pull you'd have to remember the previous revision yourself to be able to do that)
[00:46] <itistoday> mzz:  thanks, kinda getting it, still have more questions tough, so then is 'pull' as if you were to remove your entire local branch and use the 'branch' command?
[00:46] <mzz> itistoday: yep
[00:46] <itistoday> ok... that makes a whole lot more sense
[00:46] <mzz> itistoday: but only if you don't have any revisions locally that aren't in what you pull. If you do it'll complain that the branches have diverged.
[00:47] <mzz> itistoday: so other than that you can't easily undo it if you don't quite remember what the previous revision was, and assuming no *uncommitted* local changes, "pull" is quite safe
[00:47] <itistoday> mzz: does that mean: local branch must have a revision number less than the one from where you're pulling?
[00:47] <mzz> itistoday: revision numbers in bzr confuse me. You'll have to read the manual for that one.
[00:48] <itistoday> i guess that was a bad question, but essentially does that mean that you cannot have made any changes to the branch you have that are not in the one you're pulling from?
[00:48] <mzz> itistoday: (what if you committed one extra revision and you're pulling from a branch that has two (unrelated) new revisions?)
[00:49] <mzz> itistoday: no *committed* changes, yes.
[00:49] <mzz> itistoday: "pull" will attempt to keep uncommitted changes (just like "up" does in things like svn and cvs)
[00:50] <itistoday> ok, cool :-) i think i get pull now
[00:50] <itistoday> thanks!
[00:50] <mzz> itistoday: actually so will merge, but using that is usually a bad idea, since it means it's hard to tell which changes are part of the merge and which are yours!
[00:50] <itistoday> that was going to be my next question
[00:50] <itistoday> so you can merge when you have uncommitted changes?
[00:50] <Peng_> By default, merge yells at you if you have uncommitted changes. You have to pass --force to do it.
[00:51] <mzz> ah, I didn't know that.
[00:51] <itistoday> Peng_: thanks! What does the --uncommitted option mean?
[00:51] <mzz> (because I'm pretty good at making sure I have no uncommitted changes before merging myself)
[00:51] <itistoday> --uncommitted: "Apply uncommitted changes from a working copy, instead of branch changes."
[00:52] <itistoday> does that mean only grab the uncommitted files from the place you're merging from?
[00:52] <Peng_> itistoday: Yeah.
[00:52] <Peng_> itistoday: That merges the uncommitted changes in the source branch's working tree into yours, instead of merging the new revisions and ignoring the working tree.
[00:52] <itistoday> that's really weird
[00:53] <Peng_> It's really useful.
[00:53] <mzz> I don't think I've used that, but that's my fault.
[00:53] <itistoday> i'm sure, i'm just new to this entire thing, it's all fascinating to me
[00:53] <Peng_> Say you're making some changes in a branch, but then decide they should be in a new branch. Do "bzr branch", "bzr merge --uncommitted", and then "bzr revert" in the source branch. Bang!
[00:53] <mzz> I think I'd usually end up just committing those uncommitted changes to the other branch, then merging regularly.
[00:53] <mzz> ah, that's actually useful.
[00:54] <itistoday> Peng_: great example! thanks
[00:54] <mzz> although unsurprisingly there are other ways to do that :)
[00:54] <itistoday> so, one other thing regarding pull.. in the user's guide part 6.2.3:
[00:55] <itistoday> 6.2.3   Refreshing a mirror branch
[00:55] <itistoday> "Use the pull command to do this:"
[00:55] <itistoday> cd trunk; bzr pull
[00:55] <itistoday> that seems to be similar to 'update'
[00:55] <itistoday> what's the difference?
[00:55] <Peng_> itistoday: Pull is about branches, while update is about working trees.
[00:56] <itistoday> ok, the terminology still hasn't stuck quite yet, is this right: pull is more granular than update? i.e. update does it for all the branches..?
[00:56] <mzz> "up" becomes important if you have working trees and their corresponding branch in different locations.
[00:57] <Peng_> itistoday: Pull is "copy new revisions from branch X to Y". The pull command also implicitly runs "bzr update". Update is "update my working tree with new changes in branch X".
[00:58] <itistoday> Peng_: does 'new revisions' there mean the 'history' from branch X to Y?
[00:58] <mzz> sounds right to me
[00:58] <itistoday> and then 'update' takes the latest history and makes it visible to the file system for you to work?
[00:58] <Peng_> itistoday: Yeah.
[00:58] <mzz> yep
[00:59] <itistoday> awesome! thank you both very much for helping explain this :-)
[00:59] <mzz> itistoday: if this is just the result of "bzr branch" (aka "get") you'll end up with working tree and branch in the same spot, and won't have much use for "update"
[00:59] <mzz> itistoday: but there are ways to get the branch revision updated that don't automatically update the working tree afterwards, in which case you'll need "update". It'll probably be obvious once it happens.
[01:00] <mzz> err, branch history, not revision
[01:00] <mzz> "bzr help working-trees" mentions a few, I think
[01:01] <itistoday> mzz: thanks, i'll keep that in mind
[01:01] <itistoday> i looked over a quick git tutorial, it seems to take a different approach with where branches are stored, i.e. it seems like the entire folder contains the repository
[01:01] <mzz> does someone know if there's a plugin I overlooked that automates creating a new branch for a lightweight checkout and switching to it?
[01:02] <mzz> itistoday: I haven't used git much, but see 10.2.5 in the manual
[01:03] <mzz> I use a variation of that setup: my lightweight checkout isn't below the repository.
[01:03] <itistoday> mzz: k, reading...
[01:03] <mzz> I'm looking for a more convenient way to do the "bzr branch ...", "bzr switch ..." mentioned there.
[01:03] <mzz> perhaps I should just write a plugin.
[01:05]  * mzz throws together a "relswitch" plugin
[01:06] <flvr8> is there a generalized way to create server aliases, a la "lp"?
[01:06] <mzz> flvr8: I just came across the "bookmark" plugin, which may do what you want
[01:06] <flvr8> thanks, will take a look
[01:08] <Peng_> flvr8: Better than writing Python code, you mean?
[01:09] <flvr8> Peng_: heh, i take it "lp" is hardcoded somewhere? are there other "presets"?
[01:10] <mzz> oh, huh. ":this" partially fixes what was annoying me.
[01:11] <mzz> flvr8: "lp:" is a bit fancier than it looks (deals with logins and some transformations of the path too iirc, it's not just a fixed prefix)
[01:11] <itistoday> mzz: that seems a bit different from how git does it, i think. i think git sortof hides the branches from you, whereas with bzr you have to have the directory structure already laid out (repo/branches), i think git does (folder <- invisible branches)
[01:11] <flvr8> mzz: ah, of course
[01:11] <mzz> itistoday: git does have a directory structure, but it's below .git, iirc.
[01:12] <mzz> itistoday: I suck at git, but afaict it's considered acceptable to peek inside .git. That's *much* less common with .bzr.
[01:12] <itistoday> mzz: ah ok, then it should be possible to do something similar with 'bzr'?
[01:12] <mzz> itistoday: well, I do think the two are pretty similar, but I haven't compared them in any amount of depth :)
[01:14] <mzz> itistoday: I just found out about the magical ":this" location which points at the current branch. I think that can make them more similar
[01:14] <mzz> let's see
[01:15] <itistoday> the idea would be to have a branch with a .bzr folder in it, and to be able to change the working directory of that to another branch, without changing the folder's location
[01:15] <mzz> I don't think you can have a .bzr folder, but you can have a .hidden-repo folder. Give me a minute, experimenting.
[01:15] <itistoday> k
[01:17] <itistoday> the .hidden-repo folder would have to reside within the branch itself... i'm not sure if that's possible with bazaar, which i think expects the repo to be the parent folder
[01:18] <mzz> yay lightweight checkouts
[01:19] <mzz> itistoday: haven't thought this through, but http://paste.pocoo.org/show/125465/
[01:20] <mzz> itistoday: note that putting the checkout inside the repo works just fine (that's how that example in the manual I mentioned does it)
[01:20] <mzz> itistoday: I'm interested in doing it this way because I have my repo on a network mount while I want my checkout to be local.
[01:21] <itistoday> mzz: so initially in that example :this points to .hidden-repo/trunk ?
[01:22] <mzz> itistoday: yeah, because that's what we checked out
[01:22] <itistoday> with the checkout, do you still have access to all the revisions?
[01:22] <mzz> itistoday: as long as the repository is reachable
[01:22] <mzz> err, as long as the branch is reachable is better
[01:23] <mzz> it's a lightweight checkout, which means it has just a working tree. For anything involving history it needs the branch and its repository
[01:23] <itistoday> which it transparently accesses?
[01:24] <mzz> itistoday: might actually want to peek at what ends up in .bzr to understand what's going on here, imho.
[01:24] <mzz> itistoday: the checkout remembers the location of its branch
[01:24] <itistoday> mzz: so the lightweight checkout acts as an alias to the branch?
[01:25] <mzz> see "bzr help checkouts"
[01:26] <itistoday> thanks, yeah, it seems like an alias
[01:26] <mzz> oh, I forgot --no-trees on the init-repo
[01:26] <itistoday> what does that do?
[01:26] <itistoday> er... i'll have a look at the manual
[01:26] <mzz> stop it from putting working directories in .hidden-repo, which is kinda silly here
[01:27] <itistoday> cool, that makes sense, thanks for the example :-)
[01:28] <mzz> notice there's very little to a branch without a working tree: just a revision id, tags, and branch.conf
[01:29] <itistoday> neat
[01:30] <itistoday> but yeah, i think the main difference here between git is that with bzr the repo must be in a different directory than the working tree
[01:30] <mzz> and bzr gives you quite a bit of flexibility in where you put the repo, the branch, and the working tree (in the same place is simplest, but you can spread them out a bit too)
[01:30] <mzz> you might even be able to put the repo inside the checkout and .bzrignore it
[01:31] <itistoday> now that would be cool
[01:31] <mzz> well, I think it'd be confusing.
[01:31] <mzz> if you mess up the .bzrignore you could end up committing the repo to itself, or something equally daft.
[01:31] <mzz> let's see though.
[01:32] <Peng_> flvr8: lp: is provided by the built-in Launchpad plugin (bzrlib.plugins.launchpad), using bzrlib's directory service API. You could totally write a plugin to provide something similar, but you can't just add "foo: = http://bzr.foo.org/" to some config file.
[01:32] <mzz> the bookmark plugin mostly does just that, iiuc
[01:34] <mzz> itistoday: http://paste.pocoo.org/show/125470/ does seem to work, although I still think it's confusing.
[01:35] <flvr8> Peng_: thanks
[01:37] <mzz> itistoday: to improve this setup further you'd want a :repo alias so you don't have to specify those paths relative to the branch
[01:37] <itistoday> mzz: thanks! is there any easy way to set that alias?
[01:37] <flvr8> does anybody have experience with the bzr-emailer-notifier script? it's sending emails ok for two of the repositories, but not the third. (and there are a bunch of 'No handlers could be found for logger "bzr" errors' in the log, which makes me wonder if it's hung up on a lock per #141172 or #172392 -- any way to tell?)
[01:37] <mzz> itistoday: and adding that to bzr is pretty trivial, although it is arguably a misfeature because branches are normally just an optimization, you're not supposed to care about their location
[01:38] <mzz> itistoday: I'm tempted to just write it anyway though.
[01:38] <mzz> lemme grab a snack and do that.
[01:38] <itistoday> mzz: :-)
[01:41] <itistoday> wow this is neat
[01:41] <itistoday> so, i did something very similar to what you did, mzz
[01:42] <itistoday> except i had a branch to start with already
[01:42] <itistoday> so after creating the repo in the branch (.bzr-repo)
[01:42] <itistoday> i branched to it like this: bzr branch . .bzr-repo/trunk
[01:42] <itistoday> then I deleted everything inside the folder *except* for the .bzr-repo folder
[01:43] <itistoday> and did a lightweight checkout from the .bzr-repo/trunk
[01:43] <itistoday> and now it appears i have the same setup
[01:43] <mzz> yep (remember to make that a --no-trees repo, bit faster that way)
[01:44] <itistoday> yeah i did :-)
[01:44] <itistoday> is there a bzr command though to do what i did via rm -rf  and bzr checkout --lightweight?
[01:44] <itistoday> i.e. turning the current branch into a checkout from someplace else?
[01:44] <itistoday> it seems like a dangerous thing to do though so there might not be
[01:45] <itistoday> just want to know if what i did would be the standard way of doing that
[01:45] <mzz> lemme see
[01:48] <mzz> itistoday: bzr reconfigure --lightweight-checkout --bind-to .bzr-repo/trunk .
[01:49] <itistoday> wowww
[01:49] <itistoday> let me see if that works...
[01:52] <itistoday> incredible
[01:52] <itistoday> bazaar is awesome :-)
[01:52] <itistoday> i might write a blog post on this if that's OK? i'll of course be sure to credit you and your examples
[01:52] <mzz> mmm, drat. "lookups" is not an instance variable, so I can't just hack up the existing AliasDirectory so you get the same style of alias. Oh well.
[01:53] <itistoday> i think people would be interesting for the git people to know that this can be done in bazaar
[01:53] <itistoday> *think people = think it
[01:58] <itistoday> how does the autocompletion work in bzr shell?
[01:58] <itistoday> i type 'br[tab]' and it just puts a tab
[02:10] <mzz> itistoday: meh. Try http://paste.pocoo.org/show/125474/ (put in ~/.bazaar/plugins, then turn the ":this/.." in earlier examples into "repo:")
[02:11]  * mzz found various fun locations differing from the one he wanted
[02:12] <mzz> itistoday: tab-completion works for me
[02:12] <itistoday> i'm on OS X
[02:12] <itistoday> oh well, not a big deal
[02:12] <itistoday> re plugin: neat!
[02:12] <itistoday> ill try it right now :-D
[02:13] <mzz> (I was ending up with locations at various spots below .bzr, which wasn't what I wanted)
[02:13] <mzz> (took me a while to realise I had to go through .bzrdir)
[02:13] <itistoday> it might be useful for me to learn python at this point, if only to be able to customize bzr to my liking :-)
[02:14] <itistoday> not sure what what you mean ..?
[02:14] <mzz> can be quite useful to do ad hoc scripts or plugins
[02:14] <mzz> just that I was getting the code wrong initially
[02:15] <itistoday> how do i setup the plugin folder properly with this paste?
[02:15] <itistoday> i've always seen plugins as directories, and they usually have some sort of specific setup with an __init__.py file in it
[02:18] <itistoday> mzz: ping
[02:19] <mzz> itistoday: http://paste.pocoo.org/show/125477/ is slightly cleaner
[02:20] <itistoday> mzz: how do I setup the plugin though?
[02:20] <mzz> itistoday: just store as ~/.bazaar/plugins/repoalias.py, or ~/.bazaar/plugins/repoalias/__init__.py if you prefer
[02:21] <itistoday> doesn't seem to work via the second method...
[02:22] <itistoday> Unable to load plugin 'repoalias' from '/Users/gslepak/.bazaar/plugins'
[02:22] <itistoday> Unable to load plugin 'repoalias' from '/Users/gslepak/.bazaar/plugins'
[02:22] <itistoday> err, sorry for the dup
[02:23] <mzz> no? urgh, now what did I do wrong
[02:23] <itistoday> mzz: have you tried it?
[02:23] <mzz> there should be a message above the failure
[02:23] <mzz> yes, I have
[02:23] <mzz> well, I've tried way one, and I can't think of a reason for way 2 to fail
[02:23] <mzz> (don't do both at the same time though)
[02:23] <itistoday> i tried method 1 too
[02:23] <itistoday> same message
[02:24] <itistoday> wonder if there's any way to get what the reason is?
[02:24] <mzz> no further output? Also check ~/.bzr.log
[02:25] <itistoday> yeah, there is
[02:25] <itistoday> 1 sec
[02:25] <itistoday> http://paste.pocoo.org/show/125478/
[02:26] <itistoday> doesn't seem to like RepositoryDirectory
[02:27] <mzz> that traceback makes no sense to me
[02:27] <mzz> oh wait
[02:28] <mzz> itistoday: how did you paste this code over? Did you accidentally end up with the call to directory_service.directories.register indented?
[02:28] <itistoday> let me check
[02:28] <itistoday> yes
[02:28] <itistoday> sorry, i don't know python
[02:28] <mzz> itistoday: indentation is syntax in python. Using the "download" button of the pastebin is strongly recommended.
[02:29] <mzz> (under "paste details")
[02:29] <mzz> or I guess I could just stuff this thing on launchpad
[02:29] <itistoday> k, will remember that from now on for python code
[02:30] <itistoday> ok that seemed to work :-)
[02:30] <itistoday> although i'm probalby using it incorrectly: bzr branch . :repo/expirmental
[02:30] <itistoday> bzr: ERROR: ":repo/expirmental" is not a valid location alias.
[02:31] <mzz> itistoday: repo:, not :repo. Sorry about that.
[02:31] <itistoday> :-D
[02:31] <itistoday> mzz: thanks! sorry about that
[02:31] <itistoday> i like that syntax a lot actually
[02:31] <mzz> I actually think I like repo: better, so I think I'll keep it
[02:31] <itistoday> yeah
[02:31] <itistoday> definitely
[02:32] <mzz> hmm, what to call the plugin
[02:32] <itistoday> mzz: you might want to consider making this a real plugin?
[02:32] <itistoday> i think lots of people would find this useful
[02:32] <mzz> hardest part: think of a name
[02:32] <itistoday> repoalias is pretty good i think...
[02:32] <mzz> repoalias it is
[02:32] <itistoday> :-)
[02:34] <itistoday> yup, seems like it
[02:36] <mzz> itistoday: just give me a minute, pushing etc
[02:36] <itistoday> mzz: sure :-)
[02:38]  * mzz is figuring out whether lp can host branches without having a whole project for them
[02:38] <wgrant> mzz: Use +junk in place of the project name.
[02:39] <mzz> "bzr push lp:+junk/repoalias" fails
[02:39] <wgrant> mzz: You need your username in there too.
[02:39] <wgrant> bzr push lp:~username/+junk/branch
[02:39] <mzz> yeah, got it. Thanks!
[02:40] <mzz> itistoday: bzr get lp:~marienz/+junk/repoalias
[02:41] <itistoday> mzz: awesome, thanks!
[02:42] <itistoday> if I get time i'll write a blog entry on this plugin and using bazaar like git here: http://taoeffect.com/blog
[02:44] <mzz> notice this is just a hack so far, I don't know if there are any gotchas if you actually use this
[02:45] <itistoday> mzz: k, will be sure to mention that if i post it
[02:48] <mzz> added it to the list on the wiki too
[02:48] <mzz> I guess I'll turn it into a proper lp project if people use it
[02:48] <itistoday> just used it with merge, seems to be working fine :-)
[02:49] <itistoday> mzz: if i find any bugs in it, what would be the best way to report them to you?
[02:51]  * mzz wonders if launchpad has a way to file bugs on a person instead of a project
[02:52] <mzz> itistoday: I'm actually more reachable through irc than through email, I'm weird like that. Just poke me in here.
[02:52] <itistoday> mzz: k, sure thing, yeah, and it would be neat if launchpad could do that, although if you decide to turn it into a project that would solve it
[02:59] <itistoday> already, i'm heading out, thanks again mzz for all your help, and the awesome plugin!
[07:36] <kfogel> If I see this:
[07:36] <kfogel> working tree: Working tree format 4
[07:36] <kfogel>         branch: Branch format 6
[07:36] <kfogel>     repository: Development repository format - rich roots, group compression and chk inventories
[07:36] <kfogel> ... from 'bzr info -v', does that mean I'm using brisbane core?
[07:37] <wgrant> 'chk inventories' == brisbane core
[07:37] <wgrant> Not sure if that's 2a, though.
[07:37] <mwhudson> 2a has branch7 too
[07:38] <mwhudson> kfogel: run bzr upgrade --2a in the *branch* directory
[07:38] <wgrant> Right, my 2a has that repository type but branch7
[07:38] <mwhudson> (it will be very quick)
[07:38] <mwhudson> although
[07:38] <mwhudson> you should probably recreate the working tree too
[07:39] <kfogel> mwhudson: this is the mysql-server branch that I created, using the script you've seen by email.  I ran 'bzr upgrade --2a mysql-server' to get this!
[07:40] <mwhudson> kfogel: it's a standalone branch?
[07:40] <kfogel> mwhudson: yes
[07:40] <wgrant> I though branch7 was only needed for stacking. Does 2a force it just because it's a good opportunity?
[07:41] <kfogel> mwhudson: it is not in a repo other than itself
[07:41] <mwhudson> kfogel: strange!
[07:41] <mwhudson> wgrant: yes, i think so
[07:42] <mwhudson> wgrant: any client that can understand a chk repo can certainly understand branch7
[07:42] <wgrant> mwhudson: That is true.
[07:42] <kfogel> mwhudson: this appears to be bzr 1.16, not 1.16.1, fwiw (it's on devpad).
[07:43] <mwhudson> kfogel: i don't think any of the fixes will have made a difference here
[07:43] <mwhudson> kfogel: you did run reconcile before updgrade, right?
[07:44] <kfogel> mwhudson: yup.  I just ran that script, as per my email.
[07:44] <mwhudson> good
[07:44] <wgrant> What benefit does the reconcile bring?
[07:44] <mwhudson> well, you could try running bzr upgrade --2a again...
[07:44] <wgrant> (apart from making a nice heater)
[07:45] <mwhudson> wgrant: inconsistent revision information in the revision graphs can mess the conversion up
[07:45] <mwhudson> (i don't really know the details tbh)
[07:45]  * mwhudson goes to cook dinner
[07:46] <wgrant> mwhudson: Ah, right.
[07:46] <kfogel> mwhudson: bzr upgrade --2a will take another four days?
[07:46] <mwhudson> kfogel: it really shouldn't
[07:46] <mwhudson> changing the branch format is easier
[07:46] <mwhudson> maybe tar it up first though...
[07:47] <kfogel> time bzr upgrade --2a
[07:47] <kfogel> starting upgrade of file:///home/kfogel/lp-testing/mysql-server/
[07:47] <kfogel> making backup of file:///home/kfogel/lp-testing/mysql-server/.bzr
[07:47] <kfogel>   to file:///home/kfogel/lp-testing/mysql-server/backup.bzr
[07:47] <kfogel> bzr: ERROR: File exists: u'/home/kfogel/lp-testing/mysql-server/backup.bzr/': [\
[07:47] <kfogel> Errno 17] File exists: '/home/kfogel/lp-testing/mysql-server/backup.bzr/'
[07:47] <mwhudson> rm -rf backup.bzr
[07:48] <kfogel> mwhudson: done (well, moved it elsewhere).  now re-running
[07:48] <kfogel> mwhudson: thanks for taking time out from cooking dinner
[07:49] <kfogel> mwhudson: upgrade completed :-)
[07:49] <kfogel> 22 milliseconds
[07:50] <kfogel> bzr info -v now says branch format 7
[08:31] <mwhudson> kfogel: yay
[16:18] <Lo-lan-do> G'day all…
[16:20] <Lo-lan-do> I'm reading http://bazaar-vcs.org/Roadmap/BrisbaneCore/PlusOne and the last feature listed there appeals to me for a client.
[16:20] <Lo-lan-do> Any hint whether we're talking months or years here?
[16:53] <Glenjamin> is there a mirror for bzr downloads somewhere? lp seems to be down
[17:31] <james_w> Glenjamin: should be back up
[17:36] <Glenjamin> mm, got it now
[17:36] <Glenjamin> altho i'm having a problem installing bzrtools on linx
[17:37] <Glenjamin> i;ve installed bzr and bzrtools via easy_install, but they both seem to be eggs, instead of bzrtools going into the plugins folder
[18:54] <SamB> Glenjamin: but does "bzr plugins" list bzrtools?
[23:11] <Glenjamin> SamB: cheers for replying, i figured our that easy_install did an egg, which didnt work - but setup.py install did it properly
[23:58] <dobey> abentley: not around are you?


[02:36] <vibhav> Can anybody tell me whether LP #871739 is worth a sync?
[02:38] <ajmitch> vibhav: are you sure that applies to the version in precise?
[02:39] <vibhav> lemme see that
[02:49] <vibhav> ajmitch: Yes, The bug can be reproduced in precise
[02:53] <ajmitch> vibhav: given that precise has 2.4.0-5, which had the fix to bring back static libraries (-6 was just a rebuild), syncing wouldn't gain much
[02:55] <vibhav> fine, then ill develop a patch
[02:57] <ajmitch> how'd you check it? I just took a look at the package on my local mirror, it seems to have the .a files
[02:58] <vibhav> I installed it on my VM
[02:58] <vibhav> And the .a files were not present
[02:59] <vibhav> ajmitch: My bad
[02:59] <vibhav> I found em
[03:00] <ajmitch> ok
[03:00] <vibhav> So, should I mark this bug as "Fix Released" ?
[03:00] <ajmitch> fwiw, you can use dpkg-deb -c /path/to/package.deb to list the contents, it's a little quicker than installing
[03:00] <vibhav> thanks
[03:00] <ajmitch> yes, it looks to be fixed so mark it as that
[05:47] <vibhav> IS it safe to apply options that speed up building in pbuilder?
[05:52] <RAOF> vibhav: That depends; do they work? :)
[05:59] <vibhav> RAOF: They work
[05:59] <vibhav> Though they might mess up something
[07:18] <geser> vibhav: which options do you want to apply?
[07:27] <vibhav> geser: https://wiki.ubuntu.com/PbuilderHowto , look at the "Speeding up build-dependencies calculation" and "Speeding up the package installation"
[07:29] <RAOF> vibhav: They're safe.
[07:29] <geser> vibhav: I use those for a long time and didn't have any issues with them (as long as the tmpfs is large enough to build the package :) )
[07:29] <vibhav> thanks RAOF geser
[07:47] <dholbach> good morning
[08:10] <Tribaal> Hi folks, I'm currently trying to fix a small packaging bug on opensc, and my launchpad branch is up for review - would anybody have a minute to spare to tell me if my process is correct (it's my very first time fixing something in Ubuntu)?
[08:18] <vibhav> Do I need to change the "other" non-debian changelog while fixing a bug?
[09:05] <arand> vibhav: There should be no need to patch the upstream changelog, if that's what you're asking, make sure to forward the patch upstream as well.
[09:07] <Tribaal> so, I put a packaging fix branch for review in precise - is there anything else I should do? Like ping somebody or tag it with something?
[09:08] <tumbleweed> Tribaal: propose a merge
[09:08] <Tribaal> tumbleweed, that's done
[11:33] <vibhav> How does one join The Sponsors Team?
[11:37] <Laney> vibhav: by being an Ubuntu Developer and then asking an admin nicely
[12:23] <Tribaal> Laney, what/when should one request sponsorship? I submitted a branch for review a few hours ago - is that all I need to do? Is that what sponsorship is for?
[12:23] <Laney> Tribaal: you should check it appears on http://reports.qa.ubuntu.com/reports/sponsoring/ and if so someone will look at it in due course
[12:24] <Tribaal> Laney, it does, and thanks for the clarification!
[12:24] <Laney> np
[12:25] <Tribaal> Laney, is this page basically the "log of stuff to merge from non-ubuntu members"?
[12:27] <Laney> it's stuff which people would like uploaded but can't do themselves
[12:27] <Tribaal> Laney, makes sense, thanks again.
[12:28] <Tribaal> Laney, last question (promise :) ): how does one become a motu? Not that I intend to, but I'm just curious
[12:29] <Laney> Tribaal: Keep contributing fixes and soon enough someone will tell you to apply (to the Developer Membership Board)
[12:29] <Tribaal> Laney, oh, it's a pull process, not a push :) Interesting. Thanks again for your help
[12:29] <Laney> well, it can be either actually
[12:30] <Tribaal> how much is considered "enough" contribution?
[12:30] <Laney> but a good way to know when to apply is when people assume you already are MOTU, or tell you to hurry up and apply already
[12:30] <Tribaal> haha
[12:30] <Tribaal> ok
[12:31] <Laney> there's no fixed "enough", but less than six months would be unusual
[12:31] <Tribaal> Laney, makes sense
[12:31] <ajmitch> unless you got in early on, when 6 weeks was a long time ;)
[12:32]  * ajmitch wants to rant about libraries that claim to be 'open source' but really aren't free to use
[12:32] <Tribaal> so just for my understanding - being an "ubuntu developer" is being allowed to push to universe or "more"?
[12:32] <Tribaal> the titles are confusing :)
[12:32] <ajmitch> pretty much, it implies you have some upload privileges, whether to a limited set of packages or to universe
[12:33] <Tribaal> ahhh
[12:33] <Tribaal> and so a motu has upload privileges to "universe" while an ubuntu developer might have provileges to only a few packages?
[12:33] <Laney> right
[12:34] <Tribaal> gotcha
[12:34] <Laney> ubuntu developer is the umbrella group
[12:34] <Tribaal> got it
[12:34] <Tribaal> thanks for the clarification
[12:42] <dholbach> Tribaal, please keep asking questions :)
[12:43] <Tribaal> sure, but I don't want to be the annoying newbie (tm) today (it's Friday, and I assume most people are hungover or tired or both)
[12:44] <bregma> the hangover doesn't start until tomorrow
[12:44] <Tribaal> oh? good
[12:45] <dholbach> bregma, do you have plans for the WE already? :)
[12:45] <Tribaal> then: I fixed a packaging problem (a one liner), how do I engage debian about it? Should I do it myself? is it automated?
[12:45] <tumbleweed> it's not automated
[12:45] <Tribaal> do people expect me to fix it as upstream as possible?
[12:45] <Tribaal> and let it "ripple down" into ubuntu when the next debian refresh comes?
[12:45] <dholbach> Tribaal, these are all great questions
[12:45] <dholbach> https://wiki.ubuntu.com/Debian/Bugs#Using_submittodebian_to_forward_patches_to_Debian
[12:46] <dholbach> ^ explains how to use a nice tool to submit fixes to Debian
[12:46] <tumbleweed> put it this way, after you make a package in Ubuntu differ from Debian, you are responsible with keeping it up to date
[12:46] <tumbleweed> (the changes from Debian have to be synced into it by hand)
[12:46] <tumbleweed> so it's in your interest to get it as upstream as possible
[12:46] <Tribaal> ok, easy enough for my one liner, but I can see how that can become a problem :)
[12:46] <dholbach> it's also a matter of timeliness - if we are a few days away from release and have an urgent problem to fix or find that upstream or debian won't take an obvious fix for a longer period of time, it's totally fine to get it into Ubuntu - even if it creates delta
[12:47] <tumbleweed> we recommend making non-urgent changes in Debian, and just syncing them to Ubuntu
[12:47] <tumbleweed> but that's easier when you know the debian maintainer of that package or one of its uploaders...
[12:47] <Tribaal> now the killer question: what defines "urgent"?
[12:47] <tumbleweed> urgent enough for you to want to do it in Ubuntu first :)
[12:47] <Tribaal> haha
[12:48] <dholbach> you'll get a sense of it with a bit of experience - and you can always ask
[12:48] <tumbleweed> and different people have different views on this
[12:49] <Tribaal> so, shameless self-promotion and poll: what do you think about this: urgent or not? https://bugs.launchpad.net/ubuntu/+source/opensc/+bug/872019
[12:50] <tumbleweed> that package is already modified in Ubuntu
[12:50] <Tribaal> indeed
[12:50] <tumbleweed> so go for it
[12:50] <Tribaal> so basically that means "wait for a sponsor to pick up your patch and merge it", or is there another step in the process?
[12:51] <tumbleweed> no, that's abotu it
[12:51] <Tribaal> alright
[12:51] <Tribaal> sweet
[12:51] <tumbleweed> do push it upstream too, if applicable to Debian
[12:52] <Tribaal> not sure it is, for the time being
[12:52] <Tribaal> I need to check
[12:54] <Tribaal> oh it's already fixed in debian :)
[12:54] <Tribaal> sweet
[12:55] <Laney> in that case you should investigate taking their fix instead of doing an ubuntu-specific one
[12:55] <Tribaal> hum ok
[12:55] <Laney> makes for less maintenance in the long term
[12:55] <Laney> :-)
[12:56] <Laney> depends on what their fix is, of course
[12:56] <Tribaal> even if the diff will be null after ubuntu pulls the latest debian version?
[12:56] <Laney> makes for less changes to review at that time
[12:56] <Tribaal> yeah, so that is basically already the case
[12:57] <Tribaal> I reimplemented their exact solution (it's a one liner...)
[12:57] <Laney> got to go to a seminar, sorry
[12:57] <Tribaal> sure thing
[12:57] <Tribaal> nice talking to you Laney
[12:58] <tumbleweed> if upullin gin the latest debian version won't bring new features, and will fix bugs, then that's by far the best solution
[12:58] <tumbleweed> (we're in feature freeze, so new features require release-team approval)
[12:59] <Tribaal> there are new features in the debian package (new upstream version)
[13:00] <Tribaal> this specific fix is however purley a packaging issue (the debian/opensc.install file was missing an entry, basically)
[13:00] <Tribaal> quite the trivial diff
[13:01] <tumbleweed> Tribaal: have you seen bug 935348?
[13:02] <Tribaal> FTBFS - fails to build from source?
[13:02] <tumbleweed> correct
[13:02] <Tribaal> whow
[13:03] <Tribaal> how come I can build it locally?
[13:03] <tumbleweed> good question :)
[13:03] <Tribaal> ah
[13:03]  * tumbleweed tries a local build
[13:03] <Tribaal> precise
[13:03] <Tribaal> this machine is oneiric
[13:03]  * Tribaal newbie
[13:03] <tumbleweed> ah. I recommend setting up a pbuilder / sbuild for test-building
[13:03] <Tribaal> oh, I thought I had that
[13:04] <Tribaal> is that what bzr bd uses?
[13:04] <tumbleweed> also, running the development release is a good idea if you want to find problems :P
[13:04] <Tribaal> indeed, but I don't want to find too many of them at once :P
[13:04] <tumbleweed> Tribaal: no, bzr bd just builds on your machine
[13:04] <Tribaal> oh ok
[13:05] <ogra_> tumbleweed makes it sound as if there were no probs in non dev images
[13:05] <ogra_> :)
[13:05] <Tribaal> :)
[13:05] <tumbleweed> ogra_: I generally find dev releases more stable, yes :)
[13:05] <ogra_> haha
[13:06] <Tribaal> well I will have to switch relatively soon, I'm the last guy in my team not using Precise
[13:06] <Tribaal> will you guys be at UDS?
[13:07] <ogra_> sure
[13:07]  * tumbleweed must still book flights
[13:07] <Tribaal> cool
[13:10] <Tribaal>  so is universe feature frozen as well?
[13:11] <ajmitch> tumbleweed: you'd better, you don't have long :)
[13:12] <ajmitch> Tribaal: yes, feature freeze applies to universe as well
[13:13] <Tribaal> the latest debian package would fix the build for that package :)
[13:13] <ajmitch> you can get freeze exceptions
[13:13] <tumbleweed> there are a few reverse dependencies of opensc. If they'll work with the new version, we can probably sync it
[13:13] <ajmitch> also the freeze just applies to new features, new bugfix releases can be uploaded
[13:13] <Tribaal> oh ok
[13:21] <hrw> freeze... I forgot lesson from ogra - 'upload, nevermind how broken. fixes are accepted later' :D
[13:22] <ajmitch> so this is what ogra_ is teaching people these days? :)
[13:25] <hrw> ajmitch: I think he used lighter description ;)
[13:32] <ogra_> lol
[14:07] <lenios> hi there
[14:07] <lenios> does anybody know if mysql-workbench-gpl will be available for precise? https://bugs.launchpad.net/ubuntu/+bug/53062
[14:14] <Adri2000> lenios: no, unless someone asks for a FeatureFreeze exception and syncs it from debian
[14:14] <lenios> then shouldn't the package be removed?
[14:14] <Adri2000> removed from where?
[14:15] <lenios> because mysql-workbench-gpl:i386 is available, but broken because it's asking for non existing dependencies
[14:16] <lenios> it works when linking libzip2 to libzip1 though
[14:16] <Adri2000> where do you see this package available? I don't see it in ubuntu
[14:16] <Adri2000> there is mysql-workbench in debian though
[14:19] <lenios> oops, my bad, i'm talking about local mirror
[15:03] <lazka> What should I do regarding daily build in a PPA with source format 3.0? I used to append ~revision to the version, but now the orig.tar.gz doesn't contain that and lauchpad rejects the upload because a orig.tar.gz with that name is already there
[15:04] <lazka> Do I need to add the revision to the main version, giving me a new orig for each upload?
[15:20] <geser> IIRC recipes only work with "3.0 (native)" and not "3.0 (quilt)", but probably better ask in #launchpad
[15:23] <lazka> geser, ok, thanks
[15:36] <tumbleweed> geser: apparently quilt is supported these days, if upstream releases are appropriately tagged
[15:36] <geser> oh, that news for me, but I don't know much about recipes
[15:38]  * tumbleweed hasn't played with that feature
[16:25] <phiphi> hello. Who's responsible for packaging the nvidia drivers?
[16:25] <phiphi> Nvidia Driver uninstall is incomplete. Open Source 3D Driver Nouveau remains blacklisted. bug 958848
[16:25] <phiphi> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/958848
[16:39] <tumbleweed> phiphi: tseliot
[16:41] <phiphi> tumbleweed: thank you, subscribed him to the bug.
[16:42] <phiphi> Can somebody confirm the bug? Is my view right, that this is a simple bug?
[16:43] <tumbleweed> phiphi: he's presumably already subscribed to all nvidia driver bugs
[16:44] <tumbleweed> phiphi: if you haven't purged the package, it's configuration files will remain
[16:45] <phiphi> its not a config its the blacklisting of the opensource driver that remains. It gets blacklisted twice and one is removed.
[16:45] <tumbleweed> ah
[16:46] <tumbleweed> the best way to get a bug noticed is to provide a patch
[16:48] <phiphi> Of course. But I'm a packager.
[16:48] <phiphi> Can you guide me to the packaging recipe or whatever, perhaps I can find the bug
[16:51] <phiphi> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/nvidia-graphics-drivers/precise/view/head:/debian/nvidia-current.prerm
[17:24] <hakermania> Hi there! I've got a ready backport for Wallch, version 3.0 actually. I was (quite) recently told to take a freeze exception, any change, or anything that I have to keep in mind?
[17:58] <sivapvarma> how to make the screen shot app in ubuntu to make select area for grab as default option
[17:58] <sivapvarma> that will save me a mouse click each time
[18:00] <hakermania> sivapvarma, open a terminal, go to /usr/share/applications
[18:00] <sivapvarma> ok
[18:00] <sivapvarma> then
[18:00] <hakermania> nano gnome-screenshot.desktop
[18:01] <hakermania> and in Exec field
[18:01] <hakermania> instead of gnome-screenshot --interactive
[18:01] <hakermania> place gnome-screenshot -a
[18:01] <hakermania> save with Ctrl+O and then Ctrl+X
[18:01] <hakermania> now, every time you click on the screenshot icon you will be asked to select an area
[18:02] <hakermania> You can also bind the PrtSc button for this with a little trick, if you're interested... Not very difficult...
[18:03] <hakermania> sivapvarma, you have to be root to edit gnome-screenshot.desktop, of course
[18:03] <hakermania> (sudo nano gnome-screenshot.desktop)
[18:04] <sivapvarma> it seems i like sudo vim gnome-screenshot.desktop :-)
[18:04] <hakermania> ok, did you succeed ?
[18:06] <sivapvarma> hakermania: yeah thanks its working
[18:06] <sivapvarma> what about the dirty hack :-)
[18:07] <hakermania> ok, about the 'dirty' hack now, open a terminal and do sudo mkdir /screenshot_app
[18:07] <sivapvarma> ok before I do what you say
[18:07] <hakermania> ?
[18:07] <sivapvarma> let me tell you what i tried before
[18:07] <hakermania> no, let me finish
[18:08] <sivapvarma> I have created a custom shortcut in keyboard application
[18:08] <hakermania> then do sudo mv /usr/bin/gnome-screensaver /screenshot_app/
[18:08] <sivapvarma> ctrl + print scrn -> gnome-screenshot -a
[18:09] <hakermania> gnome-screenshot*
[18:09] <sivapvarma> it worked for two to three times but did not work later on
[18:09] <hakermania> Ok, sivapvarma, let me tell you know
[18:09] <hakermania> Let me start again
[18:09] <sivapvarma> ok
[18:09] <hakermania> 1) sudo mkdir /screenshot_app
[18:09] <sivapvarma> you mean from home folder
[18:09] <hakermania> 2) sudo mv /usr/bin/gnome-screenshot /screenshot_app
[18:10] <hakermania> from wherever, number (1) will do the same thing, regardless where you run it
[18:10] <hakermania> it will create a directory in root ( / ) anmed screenshot_app
[18:10] <hakermania> named*
[18:10] <hakermania> if you do cd /
[18:10] <hakermania> and then ls
[18:10] <hakermania> you will see it
[18:10] <sivapvarma> ok
[18:12] <sivapvarma> done till now what next
[18:13] <hakermania> 3) sudo nano(or vim) /usr/bin/gnome-screenshot and place this inside: http://paste.ubuntu.com/896777/
[18:13] <hakermania> 4) sudo chmod +x /sreenshot_app/gnome-screenshot
[18:13] <hakermania> 5) Done
[18:13] <hakermania> i'm a genius :P
[18:14] <hakermania> Oh, I got step 4 wrong, it is 4) sudo chmod +x /usr/bin/gnome-screenshot
[18:17] <PaoloRotolo> Hi all!
[18:17] <hakermania> Hi Paolo...
[18:20] <hakermania> sivapvarma, just tried it on my machine and it works like a charm btw
[18:20] <sivapvarma> same here too thanks :-)
[18:20] <hakermania> np
[18:20] <sivapvarma> but where did i mess up while creating the keyboard shortcut
[18:22] <hakermania> I don't know, I never trusted those things... For example, now they have placed for minimize/maximize shortcuts in Beta 12.04 -> Windows Key+Down/Up arrow, but this also causes, because of the windows key button to open the Dash -_-
[18:24] <sivapvarma> ok can we share the screen with tranparent white so that we can clearly notice that screenshot app is running
[18:24] <sivapvarma> shade*
[18:25] <sivapvarma> now whenever i run screeshot I have to search for mouse pointer to make sure it is working
[18:25] <sivapvarma> also that feature  is very intuitive and it should be there
[18:25] <sivapvarma> any ideas on how it can be done
[18:27] <sivapvarma> if you have to tried shutter for example it has such a feature when grabbing an area of the screen
[19:37] <Ramiel> hi. What's a reasonable character for separating official package version from the patched one you're uploading to the ppa?
[19:37] <Ramiel> the patched version contains modifications not applied upstream or in the ubuntu version
[19:38] <Ramiel> it's supposed to be up-to-date with original package, but it's not a newer/early-access/nightly-build/whatever
[19:39] <hakermania> Ramiel, i feel you, i have same question...
[19:39] <Ramiel> I think tilde is not suitable as it won't supersede the version it's chnaging
[19:40] <Ramiel> hakermania: I'm sicerely thinking of changing the package names and make them conflict with original ones...
[19:40] <Ramiel> but it's more than one package and I don't know exactly where the patches become packaged into
[19:43] <astraljava> Ramiel: hakermania: Perhaps you're looking for this? https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage
[19:44] <Ramiel> astraljava: I alredy read that before but someone I unfortunately trusted told me I probably wanted tilde instead of dash
[19:45] <Ramiel> astraljava: a counter is a non-go, do you think it's ok 1:2.10.0-0ubuntu2ppa20120323?
[19:46] <Ramiel> also, how about 1:2.10.0-0ubuntu2.P20120323?
[19:49] <micahg> Ramiel: + is what you're looking for I think
[19:50] <micahg> ahead of the current version behind SRUs
[19:51] <Ramiel> SRUs?
[19:52] <Ramiel> service release updates?
[19:52] <broder> !sru
[19:56]  * Ramiel thinks of using '+'
[19:58] <ajmitch> micahg: currently re-merging phpldapadmin for security fixes, I suppose these also need to make it back to previous releases? :)
[19:59] <micahg> ajmitch: would be nice :)
[19:59] <micahg> ajmitch: I think jdstrand is on deck for community tasks next week
[20:00] <ajmitch> ok
[20:01]  * ajmitch will just try & work through a few on the rc bugs list today
[20:05] <ajmitch>  955 files changed, 78554 insertions(+), 36532 deletions(-)
[20:05] <ajmitch> for flumotion...
[20:05]  * ajmitch wonders how he can phrase the FFe :)
[20:07] <vorian> slight mod?  :)
[20:08] <ajmitch> vorian: new version apparantly is needed to work with python 2.7, so I may be able to bribe someone
[20:08] <vorian> i hear beer works very well
[20:09] <ajmitch> that's what I'm afraid of
[20:11] <Ramiel> thanks all
[20:55] <ajmitch> micahg: did you want me to upload the openclipart debdiff, given that I never restarted the test build? :)
[20:56] <micahg> ajmitch: I did and it finished, I added the bug, I just never finished checking if it needed an FFe :)
[20:57] <ajmitch> micahg: given that the source is there for 2.0, the only options would be revert to the old version or fix it?
[20:58] <micahg> ajmitch: ok, I"ll just upload then :), can wave the need for FFe later if need be
[20:58] <ajmitch> don't base it just on my arguments ;)
[20:58] <ajmitch> for me it was just a nice-to-have
[20:59]  * ajmitch just doesn't like seeing packages uploaded that FTBFS, it gets confusing for people grabbing the source
[20:59] <micahg> yeah, it's a nightmare package to begin with as well (at least there's a bug filed and tagged appropriately)
[21:00] <ajmitch> I think I need a laptop with 16GB of RAM like you have
[21:00] <ajmitch> some of those images took awhile to process
[21:03] <micahg> ajmitch: Build needed 08:31:38, 5523908k disc space
[21:03] <ajmitch> hopefully the buildds are quiet
[21:04] <hakermania> Do i have chances to have a backport in ubuntu 12.04?
[21:05] <micahg> hakermania: I'm not sure if -backports is open yet
[21:05] <micahg> hakermania: wallch should be backportable, sure
[21:05] <hakermania> micahg, why wallch, specifically?
[21:06] <micahg> hakermania: oh, I thought that's what you were going to ask about ;)
[21:06] <hakermania> micahg, yes that's what I'm asking about, but initially you was like 'nah, backports are off for now', but then you were 'Wallch should be fine' :P
[21:07] <hakermania> was/were
[21:07] <micahg> hakermania: we discussed opening backports early, not sure if that ever happened
[21:08] <ajmitch> it required an LP change iirc
[21:10] <hakermania> micahg, do I need any special process or what's mentioned here is enough -> https://help.ubuntu.com/community/UbuntuBackports?
[21:11] <hakermania> meant https://wiki.ubuntu.com/UbuntuBackports
[21:11] <micahg> hakermania: that's fine, but 12.04 backports isn't open yet AFAIK
[21:12] <hakermania> micahg, not yet? But I was told to do so prior to beta 2, which comes in 6-7 days
[21:13] <micahg> hakermania: if you're updating the package in 12.04, you'll need a freeze exception at this point as backports isn't open or wait until Q and backport from there
[21:49] <hakermania> micahg, i'm not an expert or something :P What's 'Q'? I understood FFe though :P
[21:51] <micahg> hakermania: the letter after P, an entity in the Star Trek universe, a placeholder for the next Ubuntu release
[21:52] <micahg> *next release after precise
[21:52] <hakermania> micahg, nice one :P But I want it IN precise :O FFe?
[21:56] <hakermania> Afterall, untill Q wallch will have many changes
[22:09] <hakermania> micahg, !
[22:18] <micahg> !ffe| hakermania
[22:19] <hakermania> micahg, I know what it is, the only way to get it in precise is FFe. I just need you to tell me that I'm right B-)
[22:19] <micahg> hakermania: well, -backports is part of precise and enabled by default
[22:20] <micahg> just with a lower pinning so they're not selected by default
[22:21] <hakermania> micahg, so, you mean that a new version of Wallch can be make it in Precise while Precise is out? Through Update manager or something? What do you suggest?
[22:24] <micahg> hakermania: the user has to explicitly choose to upgrade to the version in backports
[22:24] <hakermania> micahg, i see. How can I update the version of wallch on usc?
[22:30] <micahg> hakermania: your choices are FFe or backport (needs to wait until it opens for P or until it gets uploaded to Q)
[22:33] <hakermania> micahg, both of the choices will result in new version of wallch in usc?
[22:34]  * micahg isn't sure how backports in USC works
[22:36]  * hakermania doesn't know what to do
[22:36] <micahg> FFe will upgrade everyone, backport will make it available for everyone, just not sure how that's displayed in USC
[22:38] <hakermania> Oh, then I'll go with a FFe, definitely
[22:53] <hakermania> micahg, many thanks, bye


[14:26] <veger> Could someone set importance of bug #392496 to wishlist?
[14:26] <ubot2`> Launchpad bug 392496 in plasma-widget-networkmanagement "Network interfaces starting with rndis should be named 'Mobile Interface' rather than 'Networking Interface'" [Undecided,New] https://launchpad.net/bugs/392496
[14:45] <s9iper1> veger:done
[14:46] <veger> s9iper1: thank you
[14:46] <s9iper1> yw
[15:48] <G__81> Hi everyone
[15:49] <s9iper1> G__81: hi
[15:50] <s9iper1> ask your question G__81
[15:51] <G__81> s9iper1: interested in Ubuntu development. just wanted to start off with something and wanted to know if this is the right place
[15:53] <brendand> G__81, it's certainly the right place if you want to help with finding, reporting and analysing Ubuntu bugs
[15:56] <G__81> analysing bugs in the sense ?
[15:56] <s9iper1> for the development as i suggest the channel is Ubuntu-desktop
[15:57] <s9iper1> like bug triaging techniques
[17:00] <tbruff13> how can i join the bug squad
[17:01] <tbruff13> I read the wiki but i cannot find a specific link or article that explains how to join
[17:01] <tbruff13> do i have to do anythign special or will my launchpad accoutn be enough
[17:03] <bkerensa> =/
[17:04] <bkerensa> missed him by a few seconds
[17:37] <hggdh> hasty people ;-)
[17:44] <tbruff13> can anyone tell me how to join the bug squad
[17:46] <tbruff13> hello
[17:49] <tbruff13> can someone tell me how to join the Ubuntu bug squad
[17:56] <tbruff13> can someone tell me how to join the ubuntu bug squad so I can work on aiding with bugs for Kubuntu 12.04
[17:57] <ikonia> tbruff13: did you read the url that was given to you
[17:58] <tbruff13> http://wiki.ubuntu.com/BugSquad
[17:58] <tbruff13> yes
[17:58] <ikonia> ok, so does that not guide you ?
[17:58] <tbruff13> found it
[17:59] <tbruff13> i messed up typing in the link
[17:59] <tbruff13> oops
[17:59] <tbruff13> sorry
[17:59] <ikonia> what ?
[17:59] <ikonia> how can you have read the page if you messed up the link
[17:59] <ikonia> time wasting lies
[18:10] <bcurtiswx> bugs against the messaging menu are reported for which package?
[18:11] <bcurtiswx> ah, google was my friend, nvm
[18:21] <cyphermox> om26er: poke.
[18:22] <cyphermox> om26er: if you're comfortable enough with rebuilding nm-applet; I'd have a patch I'd like to have tested for the leak in cdma/gsm --> http://paste.ubuntu.com/891023/
[18:31] <om26er> cyphermox, sure I'll report to you tomorrow if that's fine ?
[18:42] <cyphermox> om26er: sure.
[18:48] <cyphermox> om26er: seems like there's a different patch from dcbw after all, and it's likely just going to get committed upstream directly; so I'll try to get this uploaded ASAP, so tomorrow just update and let me know :)
[18:49] <om26er> cyphermox, sure thing :)
[21:10] <Nafallo> hrm. is there a bug about the bluetooth regression in precise yet?


[14:06] <ranguli> Is there any information available about porting apps to Ubuntu Touch? I'd like to try and port some linux apps over and contribute but I need a starting point for reference.
[14:08] <ranguli> GUI apps, I should add.
[14:48] <faenil> mmm he left already :/
[14:57] <om26er> t1mp, hey! can you visually tell, which UI component this app is using for switching between tabs ?
[14:57] <om26er> http://i.imgur.com/t5R0I48.png
[15:09] <dobey> om26er: music/calendar do some complicated stuff to do that, with uitk 1.3; best to read the source
[15:09] <ahayzen> om26er, that is the leadingActionBar of the PageHeader component
[15:10] <mzanetti> kenvandine, https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1589547
[15:10] <kenvandine> mzanetti, thx!
[15:11] <ahayzen> om26er, which is set here http://bazaar.launchpad.net/~music-app-dev/music-app/trunk/view/head:/app/components/MusicPage.qml#L46 ... and comes from here ..http://bazaar.launchpad.net/~music-app-dev/music-app/trunk/view/head:/app/music-app.qml#L640
[15:11] <om26er> hey ahayzen, I am actually trying to fix autopilot tests for the music app, seems the App started using the new header and now switch_to_tab() helper does not work
[15:11] <ahayzen> uhoh
[15:12] <ahayzen> om26er, there should be a leadingAction helper for the header, if there is try using that
[15:14] <ahayzen> those AP tests must have been broken for a while as that was changed ages ago ... *sigh* we need Jenkins back at full strength :-) or just migrate more test to QML Unit tests :-)
[15:16] <ahayzen> om26er, will probably be this you want https://developer.ubuntu.com/api/autopilot/python/1.5.0/ubuntuuitoolkit/#ubuntuuitoolkit.AppHeader.click_action_button
[15:17] <om26er> ahayzen, yes, I am already there.
[15:19] <om26er> ahayzen, we need to add object names for the action buttons to change tabs
[15:20] <ahayzen> om26er, yup, i don't mind looking at it if you want
[15:20] <om26er> ahayzen, I can do that, but need to know how long does it normally take for a new release of the music app ?
[15:21] <ahayzen> om26er, usually once per otaish ... but both me and victor have been busy recently so it has stagnated...but i'm hoping for something in this next cycle
[15:21] <ahayzen> got a long list of stuff todo
[15:22] <om26er> ahayzen, hmm, ok, I will push something temporary to lp:ubuntu-system-tests for now. And if you could add the object names that'd be great.
[15:22] <ahayzen> om26er, yeah, i don't mind create an MP to fix it in lp:music-app ... have you got a bug tracking this ?
[15:23] <om26er> ahayzen, not yet.
[15:23] <om26er> ahayzen, I peeked through the code and there is still reference to Tabs in lp:music-app is that needed ?
[15:23] <ahayzen> om26er, in which the autopilot or QML ?
[15:23] <om26er> ahayzen, qml
[15:24] <om26er> in music.qml
[15:24] <ahayzen> hmmm potentially not, but it manages the show/hiding of tabs for us ... the problem we had is we migrated to the new PageHeader for the convergence stuff but are still using the old style Tabs
[15:25] <ahayzen> so this was the solution we came up with until the Tabs are standalone
[15:25] <ahayzen> as using the Tabs normal header... it will fill the width of the app
[15:26] <ahayzen> but for convergence we needed the tab header to only be half width, so hence the solution
[15:26] <ahayzen> until there is a new Tab component, which i need to catch up with the sdk folks and see if it exists yet
[15:26] <kenvandine> mzanetti, branch proposed, but it probably won't land terribly soon
[15:39] <t1mp> om26er: hi. Sorry I didn't reply, I did not realize that my irc client disconnected..
[15:39] <t1mp> let me read the backlog
[15:41] <t1mp> ahayzen, om26er: AppHeader.click_action_button is not the correct autopilot proxy to use for PageHeader.leadingActionBar
[15:41] <t1mp> there is an ActionBar CPO, just select the PageHeader.leadingActionBar
[15:41] <ahayzen> t1mp, ah cool thanks
[15:41] <t1mp> it has a click_action_button(action_objectName) function
[15:42] <t1mp> that should do it. Also works for the actions in the right side of the header (but with trailingActionBar). It automatically clicks the action, or opens the overflow and then clicks the action.
[15:42] <ahayzen> yeah that's perfect
[15:43] <ahayzen> thanks t1mp :-)
[15:44] <ahayzen> t1mp, also are there plans to change the Tabs to have a separate header component (so it doesn't span the width), or has it already been done, or is what we are doing the 'correct' way?
[15:44] <t1mp> ahayzen: we don't plan a new Tabs component
[15:44] <t1mp> what do you need exactly? Maybe Sections is what you need?
[15:45] <ahayzen> t1mp, for the music app in convergence... it has tabs on the main left side...and then a page header on the right
[15:45] <ahayzen> IIRC the tab's header filled the width
[15:45] <ahayzen> and yeah now sections scroll, i'd vote for that in converged mode anyway
[15:45] <t1mp> if the mainPage has a PageHeader with leadingActions, that should work fine
[15:45] <ahayzen> this was just done a while back before those bugs were fixed
[15:46] <ahayzen> t1mp, yup that is what we have done
[15:46] <t1mp> ok. That is the recommended way if you want the overflow menu
[15:46] <ahayzen> cool thanks, just wanted to check it hadn't changed :-)
[15:46] <t1mp> I think that's one of 3 options. 1) Overflow menu (with leadingActionBar), 2) Sections, 3) a ListView with ListItems on the main page to navigate
[15:47] <ahayzen> yeah if you had a *really* wide screen... a listview on the left could be fun
[15:47] <ahayzen> something to play about with in the next iteration of convergence stuff anyway :-)
[15:47] <t1mp> yeah
[15:48] <t1mp> if you would implement the listview now with AdaptivePageLayout, that means in a 1-column view (on a phone in portrait mode) you only see the list when you are on the main page
[15:49] <ahayzen> yeah, but currently we don't use APL :-/
[15:49] <ahayzen> mainly due to when you push to the left side it resets the right
[15:50] <ahayzen> so then you can't have a static sidebar on the right side
[15:50] <ahayzen> but in the future i expect we'll make the left side into APL or alike so we'll have three columns
[16:01] <t1mp> ahayzen: yeah, the assumption is that the left side controls the right
[16:02] <t1mp> but you could have APL on the left and a separate right-side column next to it
[16:03] <t1mp> I don't know if that would be handier than what you have now though :)
[16:06] <ahayzen> t1mp, yeah that was what i was thinking, APL on left and then our right sidebar along side...but depends what we do