[02:04] <jml> $ bzr push sftp://<hostname>/<path>
[02:04] <jml> No revisions to pull.
[02:04] <jml> wtf?
[02:06] <Spaz_> did you specify trunk/ perhaps?
[02:06] <Spaz_> :)
[02:07] <jml> It's the "pull" bit that weirds me out.
[02:14] <lifeless> jml: using  loom?
[02:14] <jml> yeah.
[02:14] <lifeless> bug xxxxx
[02:15] <lifeless> (its open)
[02:15] <jml> it took me a while to figure out it was a loomified branch
[02:15] <jml> export-loom ftw
[02:24] <libwilliam> I'm working on parsing the bzr error messages in my program. I can't seem to find if there is a standard way of doing error messages in bzr. Do all error messages start with "bzr: ERROR: "?
[02:25] <jml> lifeless: can you merge my testresources branch please?
[02:28] <spiv> libwilliam: pretty much.  See bzrlib.trace.report_exception
[02:28] <libwilliam> spiv: thanks
[03:22]  * emmajane waves.
[03:22] <emmajane> I wanted to give the bzr_upload plugin a try, but it doesn't seem to want to load.
[03:23] <emmajane> I've downloaded it from launchpad and run the setup.py script, but I'm still getting:
[03:23] <emmajane> Unable to load plugin 'bzr_upload' from '/home/emmajane/.bazaar/plugins'
[03:57] <alecwh> Hello, can bazaar commit to a repository through the FTP protocol?
[03:57] <alecwh> push*
[04:00] <alecwh> And is it possible to grab the latest working version of a repository - not the entire history?
[04:00] <emmajane> alecwh: yes you can use FTP.
[04:00] <alecwh> emmajane: how would the command look, with a username and password, and can I get bzr to save the location, so I don't need to type it each time I want to push?
[04:01] <emmajane> I believe it's just: bzr push ftp://username@ftpserver
[04:01] <alecwh> emmajane: yes, but I have a password too.
[04:01] <emmajane> does it not prompt you for a password?
[04:02] <alecwh> emmajane: I haven't tried yet, I just assumed there was another variable to set.
[04:02] <alecwh> thanks!
[04:04] <emmajane> I think it should just work.
[04:15] <emmajane> alecwh: try also: bzr help
[04:15] <emmajane> and bzr help <command name>
[04:16] <emmajane> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html
[04:21] <alecwh> emmajane: thanks
[04:21] <emmajane> did it work?
[04:31] <alecwh> emmajane: really sorry, haven't tried yet (not at my computer), I'll get back to you later though
[04:31] <emmajane> np
[07:49] <Kamping_Kaiser> can someone suggest a tool to keep track of bzr branches? (other then LP...)
[07:54] <mwhudson> Kamping_Kaiser: keeping track in what sense?
[07:55] <Kamping_Kaiser> mwhudson, via a web interface, as i recall (sorry, i wasnt clear)
[07:56] <mwhudson> Kamping_Kaiser: there's loggerhead
[07:56] <nosklo> I am having trouble using bzr-svn plugin. Tried both ubuntu hardy package and trunk version. Ubuntu hardy package segfaults on bzr selftest svn.
[07:56] <mwhudson> it can browse directories now, so you can just point it at the directory containing all your repos, for example
[07:56] <Kamping_Kaiser> mwhudson, thanks, i'll go and check it out
[09:00] <fdv> nosklo: have you tried installing the most recent bzr-svn locally (in ~/.bazaar/plugins)?
[09:00] <fdv> that bit me yesterday
[09:01] <nosklo> fdv, using ubuntu package bzr + recent bzr-svn?
[09:01] <fdv> nosklo: what was the question?
[09:01] <nosklo> fdv, getting bzr-svn to work somehow
[09:02] <fdv> nosklo: yes, but what did you just ask me?
[09:02] <fdv> whether I use "ubuntu's" bzr and not ubuntu bzr-svn?
[09:02] <nosklo> fdv, I can't make it work. I have tried: installing bzr and bzr-svn packages, and installing bzr.dev and bzr-svn trunks
[09:03] <fdv> ok..
[09:03] <nosklo> fdv, I am asking if maybe combining the package with the trunk
[09:03] <fdv> which bzr version?
[09:09] <fdv> nosklo: if you get your packages from http://ppa.launchpad.net/bzr/ubuntu it seems to me you _should_ be fine
[09:10] <nosklo> fdv, I will try.
[09:11] <fdv> nosklo: otherwise, check which bzr version you have and compare to http://bazaar-vcs.org/BzrForeignBranches/Subversion#releases
[09:12] <fdv> I have bzr 1.6.1 and bzr-svn 0.4.12, which at least to me seems to be a combination that works
[09:39] <fdv> uhm.. pqm depends on config-manager, which in turn depends on pybaz. the latter is no longer in use, is it?
[13:47] <Leonidas> hi
[13:47] <Leonidas> could someone take a look at the changes between<EMAIL_ADDRESS>and<EMAIL_ADDRESS>[13:48] <Odd_Bloke> Leonidas: Umm, in what context?
[13:50] <Leonidas> Odd_Bloke: there is a change with the fileid TREE_ROOT and I'd like to ask someone what that means.
[13:51] <Odd_Bloke> Leonidas: In what branch?
[13:51] <Leonidas> Odd_Bloke: bzr.dev
[13:51] <Odd_Bloke> Right, that's all I was looking for. :)
[13:52] <Leonidas> iter_changes gives me ('TREE_ROOT', (None, u''), True, (False, True), (None, None), (None, u''), (None, 'directory'), (None, False))
[13:52] <Odd_Bloke> Leonidas: It'd be more normal to use revnos for a branch like bzr.dev.
[13:53] <Leonidas> Odd_Bloke: right, but I don't have the revno.
[13:54] <Leonidas> when working with bzrlib, one almost never gets any revnos
[13:57] <Leonidas> abentley: do you have a moment and can take a look on that changeset?
[13:59] <abentley> Leonidas: That looks like it's creating the root directory.
[14:00] <Leonidas> abentley: how is this possible? The root directory must have existed earlier.
[14:00] <abentley> There may have been a different root directory
[14:01] <abentley> Yes, the root directory for<EMAIL_ADDRESS>was "tree_root-20070410133226-3795pjcs6oz73ncz-1"
[14:02] <Leonidas> abentley: how can something like this be reproduced? TREE_ROOT looks like it is something special, whereas tree_root-2007... is not.
[14:03] <abentley> Leonidas: Using bzrlib, you should be able to set whatever tree root you want.
[14:07] <Leonidas> abentley: how? By modifiying a revision tree's inventory?
[14:08] <abentley> Leonidas: By calling set_root_id on a WorkingTree.
[14:08] <Leonidas> ah!
[14:09] <abentley> I should point out that released versions of bzr will always select TREE_ROOT if the repo format isn't a rich root format.
[14:11] <Leonidas> but, erm, what use does it have to be able to change the TREE_ROOT? I'm trying to understand this, but somehow a the root directory cannot track any changes like setting it +x or something.
[14:12] <abentley> The root directory can do anything any other directory can do.  Especially, it can be moved and renamed.
[14:14] <abentley> Or deleted, even.  This tends to happen when splitting one tree into two.
[14:14] <Leonidas> I see, didn't know that. I always thought about the root directory to be just a container for the content.
[14:16] <Leonidas> abentley: ok, thanks a lot. Now that I can reproduce this in simple repositories, I can figure out that to do.
[14:16] <abentley> you're welcome.
[15:34] <Leonidas> abentley: I suppose there needs to be a file/directory with that fileid already created to set_root_id, right? But the ``bzr`` program seems not to have any problems with nonexistent root_ids
[15:41] <Zelgadis> Hi! Does bzr supports nested trees?
[15:58] <Teddy> Zelgadis: Apparently, yes.
[15:59] <Zelgadis> Teddy: how?
[15:59] <Teddy> Zelgadis: http://bazaar-vcs.org/NestedTrees
[16:00] <LarstiQ> I might need to update that soon
[16:00] <LarstiQ> Zelgadis: I guess the answer is: it's not where we want it yet, but you can do a number of things already
[16:01] <Zelgadis> wow, thank you
[16:01] <LarstiQ> Zelgadis: if you can desribe your use case more clearly I can give more detailed directions.
[16:03] <Zelgadis> ok. I have a directory with a lib, doc, layouts and episodes
[16:04] <Zelgadis> every person, who works on particular episode will need lib folder
[16:04] <Zelgadis> but some person don't need lib folder, he just wants the doc folder
[16:06] <Zelgadis> that's the complex case. But I can simplify it.
[16:08] <LarstiQ> Zelgadis: I see, nested trees would ease working like that
[16:09] <Zelgadis> yep. The main purpose is to reduce bandwidth usage
[16:09] <Zelgadis> every episode is extremely huge
[16:09] <LarstiQ> Zelgadis: right, I would recommend keeping each episode in its own branch.
[16:10] <LarstiQ> Zelgadis: but you can work with multiple branches like that without having nested-trees, it will be more manual work that way
[16:11] <Zelgadis> LarstiQ: If I'll do it without ConfigManager then everytime user do a checkout a whole repository history will be retrieved, right?
[16:13] <LarstiQ> Zelgadis: cm doesn't impact that aspect, it just takes away some of the manual aspect of checking out different trees into a hierarchy
[16:13] <LarstiQ> Zelgadis: so, you have a couple of seperate problems to be solved
[16:14] <LarstiQ> Zelgadis: one thing you mentioned is breaking up into multiple branches because each individual episode is very big
[16:14] <LarstiQ> Zelgadis: another thing might be that you don't want all history for one specific episode when you're working on it
[16:15] <LarstiQ> Zelgadis: options to help there are stacked branches or lightweight checkouts
[16:15] <Zelgadis> LarstiQ: yes, lightweight checkouts - is a option because I've choosed the bazaar among others VCS
[16:15] <LarstiQ> Zelgadis: what is the workflow like on an episode? Do people need to work against the history often?
[16:16] <Zelgadis> LarstiQ: what is a stacked branches?
[16:16] <Zelgadis> Yes we doing commits often
[16:17] <LarstiQ> Zelgadis: stacked branches allow you to have only some of the historical data yourself, and for older revisions to talk to the branch they are stacked upon
[16:17] <LarstiQ> Zelgadis: it's a feature introduced in 1.6, see --stacked in `bzr help branch` for instance
[16:18] <LarstiQ> Zelgadis: for committing you don't need to access history, diff and log are cases where you need older revisions
[16:20] <Zelgadis> LarstiQ: But if I want to commit locally?
[16:20] <Zelgadis> (with a lightweight checkout that's seems impossible)
[16:20] <Zelgadis> But that's not a big problem.
[16:21] <LarstiQ> Zelgadis: correct, a lightweight checkout needs to contact it's master for everything
[16:21] <LarstiQ> Zelgadis: a stacked branch doesn't need to, it can operate locally
[16:21] <Zelgadis> nice
[16:22] <LarstiQ> Zelgadis: http://doc.bazaar-vcs.org/bzr.1.6/en/user-guide/index.html#using-stacked-branches
[16:23] <LarstiQ> Zelgadis: out of curiousity, what is an episode?
[16:23] <Zelgadis> cartoon episode - source files (.blend, .sif, .xcf, .kra)
[16:24] <LarstiQ> ooh, cool
[16:25] <Zelgadis> LarstiQ: You may find more at http://morevnaproject.org/
[16:25] <Zelgadis> althrough, not much there yet
[16:27] <Zelgadis> LarstiQ: So, back to the NestedTrees problem - all I need, is just organize folders in branches
[16:28] <LarstiQ> Zelgadis: yeah
[16:29] <LarstiQ> Zelgadis: it sounds to me like most people will only have one or two branches (lib/episodeX or doc) at a time
[16:30] <Zelgadis> yep
[16:31] <LarstiQ> Zelgadis: in that case it isn't too much overhead to just get them by hand
[16:33] <Zelgadis> the problem is what I need some files (like Makefile and README) at the root of branches
[16:33] <Zelgadis> outside the branches
[16:34] <LarstiQ> Zelgadis: you could do something like: cd morevna; bzr branch http://host/environment; cd environment; bzr branch http://host/episodeX
[16:35] <Zelgadis> LarstiQ: ...and tell to .bzrignore in environment to ignore the subdirectories?
[16:35] <LarstiQ> where environment has the Makefile, README and all other things you need for all of them
[16:35] <LarstiQ> Zelgadis: bzr will do that automatically
[16:36] <LarstiQ> or well, I should rephrase that
[16:37] <LarstiQ> Zelgadis: if you have a bzr branch in another bzr branch, bzr status will not list all the files in that inner branch as unknown
[16:37] <Zelgadis> cool!
[16:37] <LarstiQ> Zelgadis: it will see that the directory is a bzr branch, and not recurse into it
[16:37] <Zelgadis> didn't know that - that simplifies things!
[16:37] <LarstiQ> Zelgadis: it will show up only once as an unknown dir
[16:38] <Zelgadis> but we could still add that unknown dir?
[16:38] <Zelgadis> LarstiQ: it will help people to figure out what branches they could need
[16:39] <LarstiQ> Zelgadis: not `bzr add`
[16:39] <LarstiQ> Zelgadis: what do you mean, figure out what branches they need?
[16:40] <Zelgadis> LarstiQ: so, they appear as unknown, but 'bzr add' won't add them?
[16:40] <LarstiQ> (and not recursing into unknown directories is something bzr does for all unknown dirs btw)
[16:40] <LarstiQ> Zelgadis: correct
[16:41] <LarstiQ> Zelgadis: try: cd /tmp; bzr init foo; cd foo; bzr init bar; bzr st; bzr add bar; bzr st;
[16:42] <Zelgadis> LarstiQ: Ah, understand. That's ok.
[16:43] <Zelgadis> LarstiQ: Thanks alot!
[16:44] <LarstiQ> Zelgadis: np :)
[16:44] <Zelgadis> back to work ^___^
[16:55] <Leonidas> bzrlib.errors.InconsistentDelta: An inconsistent delta was supplied involving 'newdir/secondfile', 'secondfile-20080921155404-xxpouw03i8s29crx-3'
[16:55] <Leonidas> reason: This was marked as a real delete, but the WT state claims that it still exists and is versioned.
[16:56] <Leonidas> hmm, this is strange.
[16:56] <Leonidas> I just tried to change the root_id to the id of the subdirectory newdir, but that does not seem to work.
[16:57] <LarstiQ> Leonidas: that would give two paths with the same file_id, no?
[17:12] <stewart> lifeless: ping?
[17:12] <ronny> hi
[17:13] <ronny> how can i convert a branch with rich root support into one without rich root support?
[17:13] <stewart> ronny: bzr upgrade (has parameters)
[17:14] <stewart> anybody know if you can combine two bzr trees for separate projects (i.e. no common history) into one?
[17:14] <LarstiQ> stewart: bzr merge -r 0..-1 otherbranch
[17:14] <ronny> stewart: it goes only in one direction
[17:15] <LarstiQ> stewart: you may want to move the contents of one of them into a subdir to reduce conflicts
[17:15] <ronny> stewart: i can convert from non-rich to rich, but not back
[17:15] <stewart> ronny: okay - not 100% of that.
[17:15] <stewart> LarstiQ: that's what we'd do. it's adding a storage engine into the mysql tree that's been maintained externally.
[17:15] <LarstiQ> ronny: that would be because a non-rich root format can not represent all of the information in a rich root format
[17:16] <LarstiQ> ronny: so by default that isn't possible. May I ask why you'd want to do so?
[17:16] <LarstiQ> stewart: ah, I see.
[17:16] <ronny> cause the remote is not a rich repo
[17:16] <ronny> and i want to push
[17:17] <ronny> however bzr doesnt let me to
[17:18] <LarstiQ> right, for the reason I just mentioned.
[17:18] <LarstiQ> ronny: upgrading remote isn't feasible?
[17:19] <ronny> i could do that, but its just my branch of another project, i dont want to enforce anything and i dont want to redo the cahnges i did
[17:19] <LarstiQ> ronny: right.
[17:19] <ronny> what kind of metadata does the rich-root hold, cause im pretty sure i dont use any of it
[17:19] <stewart> LarstiQ: just tested the merge command above, worked great. thanks!
[17:21] <LarstiQ> ronny: the root path gets to have a real file_id, which enables you to move it and such.
[17:22] <LarstiQ> ronny: I'm looking for ways to help you deal with this, without having to exercise bzrib directly.
[17:23] <LarstiQ> next up, rebase
[17:24] <ronny> hu?
[17:24] <LarstiQ> ronny: I looked at creating a bundle and applying that, didn't work. Now I'm looking at rebase.
[17:25] <ronny> hmm, the __dozenz__ of partially incompatible repo formats are a pain :/
[17:25] <LarstiQ> __dozenz__?
[17:26] <ronny> well, i count at least 6 of them
[17:26] <ronny> well, more like 13
[17:27] <LarstiQ> ah, dozens, not a python __attribute
[17:31] <Leonidas> LarstiQ: no, not really, since the newdir has a different fileid than '' which has the fileid TREE_ROOT.
[17:32] <LarstiQ> Leonidas: but you said you dit set_root_id(newdir_id)?
[17:33] <LarstiQ> ronny: I can't really think straight right now
[17:34] <LarstiQ> ronny: but I'd try the list next
[18:30] <Leonidas> LarstiQ: yeah, I had a working tree with the root id set to TREE_ROOT and then I tried changing it to the file-id of my subdirectory
[18:58] <fdv> anybody around who might have a hint or two on how to get pqm working?
[18:58] <fdv> or are there alternatives?
[19:42] <Odd_Bloke> fdv: What are you struggling with?
[19:54] <fdv> Odd_Bloke: pqm requires config-manager, which requires pybaz
[19:55] <Odd_Bloke> fdv: Yes.
[19:55] <fdv> afaik, baz, and therefore pybaz, is discontinued
[19:55] <Odd_Bloke> Yes.
[19:55] <Odd_Bloke> It's a bug in CM, rather than PQM.
[19:55] <fdv> yes, I presumed as much
[19:56] <fdv> but I don't really know neither pybaz, nor bzrlib very well, so migrating is a rather tough option :)
[19:56] <Odd_Bloke> fdv: PQM doesn't require you to use baz.
[19:57] <Odd_Bloke> It just required libraries for using baz to be installed.
[19:57] <Odd_Bloke> Which is why it's such an irritating bug.
[19:57] <fdv> right, so pybaz is enough?
[19:57] <Odd_Bloke> fdv: Enough for what?
[19:58] <Odd_Bloke> If you want to use PQM for bzr, you only need what's in PQM.  Unfortunately, PQM currently requires config-manager which requires pybaz, but that's orthogonal to what you really need.
[19:58] <Odd_Bloke> fdv: What platform are you on?
[19:59] <fdv> Odd_Bloke: ubuntu
[19:59] <fdv> sorry, was distracted a moment
[20:00] <Odd_Bloke> fdv: 'apt-get install config-manager' should be enough for PQM to not complain about it. :)
[20:00] <fdv> the config-manager package is broken, as it depends on pybaz, but that one doesn't exist
[20:00] <fdv> ...anymore
[20:01] <Odd_Bloke> *shakes fist at Ubuntu*
[20:01] <fdv> still, when trying to use config-manager from source, there are lots of 'import pybaz' statements in there
[20:01] <fdv> so I can't really see how it'd work
[20:01] <fdv> oh, right
[20:01] <Odd_Bloke> Try using https://code.launchpad.net/~daniel-thewatkins/pqm/config-manager
[20:02] <fdv> maybe that code is only called when one uses baz
[20:02] <Odd_Bloke> fdv: That code _should_ only be called when one uses baz.
[20:02] <fdv> right, I see
[20:02] <Odd_Bloke> Unfortunately, it is not.
[20:02] <fdv> oh
[20:02] <fdv> bummer
[20:02] <Odd_Bloke> Hence the whole issue. :p
[20:02] <fdv> sounds like it should be fairly easy to fix
[20:03] <fdv> I see
[20:03] <Odd_Bloke> fdv: Patches welcome. ;)
[20:03] <fdv> hehe :)
[20:03] <Odd_Bloke> I've spent a little while looking at it (I worked on PQM over the summer), but didn't get very far.
[20:03] <fdv> so config-manager is only needed by pqm when used with baz, is it so?
[20:03] <Odd_Bloke> fdv: Nope, CM isn't _needed_ even then.
[20:03] <fdv> ok, but it _can_ be used
[20:04] <Odd_Bloke> Yeah, but it also _can_ be used when you're using PQM with bzr.
[20:04] <fdv> but it might also be nice to have with bzr?
[20:04] <fdv> right
[20:04] <Odd_Bloke> It should be completely independent of baz.
[20:04] <Odd_Bloke> But it's not.
[20:04] <fdv> I see
[20:05] <Odd_Bloke> fdv: Actually, that's not the branch you should use.
[20:05] <fdv> oh
[20:05] <Odd_Bloke> fdv: It depends on a lot of other unmerged work.
[20:06] <fdv> right
[20:06] <Odd_Bloke> fdv: If you don't want to use config-manager, ISTR that just removing the imports works.
[20:06] <Odd_Bloke> Which is nasty, but will let you get on with things.
[20:07] <fdv> ok
[20:07] <fdv> (another issue, btw, is that config-manager won't build without the dir ./libgetopt, which is not there, but I nicked it from the .deb)
[20:07] <fdv> Odd_Bloke: what would I need config-manager for anoway?
[20:08] <Odd_Bloke> fdv: If your build required you to pull in a few branches.
[20:08] <Odd_Bloke> It's _kinda_ like svn:externals.
[20:08] <fdv> aha
[20:08] <fdv> makes sense
[20:08] <fdv> kind of hard to put the pieces together without prior knowledge :)
[20:09] <fdv> (this channel, of course, is _very_ helpful in that respect :))
[20:09] <Odd_Bloke> fdv: Yeah, PQM is still fairly obtuse.
[20:11] <fdv> config-manager seems to be a bit out of date, actually
[20:11] <fdv> though maybe I just don't understand it
[20:11] <Odd_Bloke> Well, it depends on pybaz, which is a reasonable indicator. :p
[20:12] <fdv> under implementations, there is only arch_vcs.py and fake_vcs.py
[20:12] <Odd_Bloke> Yeah, that's where the baz and bzr stuff should be.
[20:13] <fdv> only baz, afaics
[20:13] <Odd_Bloke> Whereas currently it's intermingled with the core code.
[20:13] <fdv> aha
[20:13] <fdv> I see
[20:14] <fdv> doesn't sound like a very pleasing place to start :)
[20:14] <fdv> Odd_Bloke: thanks a lot, at least I know part of the rationale now and I might be able to get it together
[20:14] <Odd_Bloke> fdv: No worries. :)
[21:34] <fdv> Odd_Bloke: wouldn't it make sense in pqm to import config_manager only inside the two methods using it?
[21:34] <fdv> I'm not sure if I see why that is ugly
[22:01] <Odd_Bloke> fdv: It would make sense, I think.
[22:14] <lifeless> stewart: yo
[22:37] <libwilliam> I was doing some messing around with the different commands to see what they did and now my tag revnos are listed as ?.. My guess is because I uncommitted the revisions that had tags. So if this is the case I was wondering if those tags should even exist?
[22:40] <Odd_Bloke> libwilliam: Those tags will point at the old revisions.  The '?' just means that those revisions don't have a revision number in this branch (as they are not part of the history).
[22:42] <libwilliam> Alright, well I am trying to do a bzr log -r tag:<tag with ?> and I am getting a crash
[22:42] <libwilliam> Is this worthy of a bug report?
[22:43] <jelmer> libwilliam, please
[22:43] <libwilliam> jelmer, k
[22:44] <rsc-> Is there a way for me to use "meld" to resolve conflicts when merging?
[22:48] <beuno> jml, hi
[22:48] <beuno> I've given your lp stacked branch experiment a spin
[22:48] <beuno> and I get this: http://paste.ubuntu.com/49082/
[22:49] <beuno> I have a shared repo
[22:52] <jml> beuno: oh, the branch called 'experiment' is broken.
[22:53] <jml> beuno: but even if it was ok, if you branch it locally, it should work, and won't be stacked unless you say --stacked
[22:56] <rsc--> Is there a way for me to use "meld" to resolve conflicts when merging?
[23:00] <beuno> jml, that explais it, thanks


 Lock on sleep. Sleep locks immediately.
[16:59] <mpt> Sleep when idle.
[16:59] <mpt> This is like "/!\ The display will turn off before the screensaver activates." all over again.
[17:06] <snwh> you forgot sleep on idle
[17:06] <mpt> What's the difference between "sleep on idle" and "Sleep when idle"? :-)
[17:08] <snwh> I was kidding :P
[17:11] <mpt> A shame English doesn't have a common simple word for "inhibit"
[17:12] <xnox> mpt: do you mean suspend or hybernate? big difference between the two inhibit methods on UNIX......
[17:13] <mpt> xnox, neither
[17:13] <mpt> well
[17:13] <xnox> *sigh*
[17:14] <mpt> xnox, the equivalent of "Lock Screen"
[17:15] <xnox> mpt: on the technical side of things it's actually same as switching to a different user account. Since just like a logged in user it has indicators/launcher/apps/"live wallpaper with information".
[17:15] <mpt> "Shorter times are more secure. Phone won’t lock during calls or video playback.”
[17:15] <xnox> why not.
[17:16] <mpt> xnox, yeah, the equivalent of "Lock Screen", not the equivalent of "Switch User Account…"
[17:16] <xnox> you can totally keep the phone call / video playback active, yet require to unlock after one exits.
[17:16] <mpt> E.g. if you're playing music and you lock the phone, the music should keep playing.
[17:16] <xnox> similarly one shouldn't require to unlock the phone to play public youtube video or to answer a call.
[17:16] <mpt> That's a separate problem. :-)
[17:17] <xnox> thus after exiting the phone call, you may see the lock screen =)
[17:17] <mpt> Yes.
[17:17] <mpt> "during"
[17:18]  * xnox likes screen turning off during the call though.
[17:18]  * snwh doesn't like screen *locking* during a call
[17:18] <mpt> Yes, but that isn't the same as locking either...
[17:18] <xnox> and when the screen is off it's hard to tell if it's "locked or off or something else"
[17:19] <mpt> To find out, just take it away from your ear
[17:19] <snwh> presumably the screen turns off during a call due to the proximity sensor
[17:19] <xnox> snwh: sure but turning off screen based on the proximity/ambience sensor during the call saves piles of battery.
[17:19] <snwh> not debating that
[17:20] <xnox> mpt: you clearly don't talk on the phone in nightclubs / at night =) it didn't always work on iPhone 3gs requiring me to press the lock button to "wake it up"
[17:20] <snwh> sometimes i've made a call via the speaker and still used the phone for other things, so the screen isnt off in that case
[17:20] <xnox> snwh: hmm... yeah and not locked either....
[17:20] <xnox> hmm....
[17:21] <snwh> it could go off if idle+during call
[17:23] <snwh> should implement a "slam-to-end-call" so you can hang up your phone like the old days –using the proximity/accelerometer– "Smack your phone face-down on the table to end a call." :P
[17:23] <snwh> cause hanging up violently has been lost
[17:24] <xnox> yeah, some phone did go silent if you flip it (accelerometor or something)
[17:25]  * snwh isn't serious :)
[17:25]  * xnox is MUAHAHAH
[17:25]  * xnox off to code that feature
[17:25] <xnox> snwh: the problem with open source is feature creep, but worse off working implementations of feature creep =)
[17:26] <snwh> it wouldn't be a feature that would be popular, as slamming your $600 phone isn't ideal :)
[17:26] <mpt> https://twitter.com/rohdesign/status/324548858430500865
[17:26] <snwh> that would be hard on the colon
[18:02] <mpt> Just posted "Security & Privacy" wireframes (no spec text yet): https://wiki.ubuntu.com/SecurityAndPrivacySettings#Phone
[18:04] <snwh> in terms of lock, I've always liked a pattern lock akin to Android
[20:00] <xnox> snwh: used to be useless as it used to auto-unlock upon completing the sequence without requiring one to lift the finger, thus one could brute-force by only trying all the 9 spots combinations sans jumps which was less than 4 digit pin.
[20:00] <xnox> and smudges on the screen give it away even quicker =)
[20:01] <xnox> iphone is more annoying, even with lock it pushes private sms & email on to the lock screen =(
[20:04] <xnox> idealy i'd like to pin protect OTP generator
[21:03] <snwh> xnox, what? the combinations for a non-jump 9 point pattern are far higher than range of possibilities for a 4 digit pin
[21:03] <snwh> well for a lock screen I'm talking, not the sim lock pin
[21:32] <xnox> snwh: i'll have to calculate again..... you are quite right.


[04:31] <Unit193> cjwatson: Re: https://people.canonical.com/~ubuntu-archive/transitions/html/fuse3.html, you could always just nab https://github.com/OpenMandrivaAssociation/grub2/blob/master/grub-2.02-fuse3.patch
[04:34] <Unit193> (Obviously not for impish.)
[08:06] <alexghiti> Hi, it seems pyopencl tests are a bit flaky and are used to segfault: could someone try to launch the tests again here https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=pyopencl&trigger=pocl/1.6-5build1 ? Thanks
[08:24] <ginggs> alexghiti: clicked three times for luck :)
[08:31] <alexghiti> ginggs: Thanks!
[09:15] <paride> ddstreet, hi! I read the backlog of yesterday's backports meeting and issues with updating https://wiki.ubuntu.com/UbuntuBackports were mentioned
[09:15] <paride> AIUI you updated it, but now it still shows the last edit to be in 2012
[09:15] <paride> did the changes got lost or something?
[10:55] <Mirv> love the smell of massive archive rebuild in my inbox
[16:30] <GunnarHj> doko: The rebuild of gdk-pixbuf fails on some archs which in turn blocks other builds (mutter in my case).
[16:34] <RikMills> circular build deps for gdk-pixbuf. not the 1st time that has been seen IIRC
[16:36] <GunnarHj> RikMills: Suboptimal timing for such a problem. :/
[16:38] <RikMills> I think last time locutusofborg solved it by doing a rebuild against the release pocket in a landing ppa?
[16:38] <RikMills> https://launchpad.net/ubuntu/+source/gdk-pixbuf/2.42.6+dfsg-1build2
[16:41] <GunnarHj> So it seems.. Is that anything you could do, RikMills? I have to be AFK for a few hours.
[16:41] <RikMills> needs a core dev, which I am not
[16:42] <locutusofborg> yes
[16:42] <locutusofborg> let me take care of it
[16:42] <GunnarHj> Great!
[16:42] <RikMills> thanks :)
[16:48] <locutusofborg> https://bileto.ubuntu.com/#/ticket/4679
[22:38] <Unit193> tsimonq2: Any update on the very simple pastebinit patches?  There's a new deprecation, fixed that too and staged them all at https://git.unit193.net/cgit/users/unit193/pastebinit.git/


[02:34] <bac> good <localtimeofday> everyone
[02:36] <mwhudson> hi bac
[02:36] <bac> hey mwhudson
[05:46] <StevenK> bac: Hai, are you still reviewing, or is the topic a bit stale?
[05:50] <lifeless> StevenK: what do you need reviewed
[05:53] <StevenK> lifeless: Small 42 line branch: https://code.edge.launchpad.net/~stevenk/launchpad/reject-mail-ppa-name/+merge/39119
[05:56] <lifeless> done
[06:00] <bac> StevenK: i am reviewing
[06:01] <bac> StevenK: but i am about to be lunching
[06:01] <bac> oops, didn't read far enough.
[10:57] <bac> adeuring: i leave the reviewing to your capable hands
[10:57] <bac> i did clear out +activereviews for you
[10:57] <adeuring> bac: ok, have a nice weekend!
[10:58] <bac> you too
[16:17] <EdwinGrubbs> sinzui: besides the losas, who should review a change to qastaging-penid-config? https://code.edge.launchpad.net/~edwin-grubbs/lp-production-configs/qastaging-openid-config/+merge/39153
[16:18] <sinzui> I do not think anyone else needs to
[16:21] <sinzui> EdwinGrubbs, why use staging's login? It is a test server. If we use the production one, it will be more reliable. And new users can also login
[16:23] <EdwinGrubbs> sinzui: No good reason.
[16:25] <sinzui> gary_poster, can you foresee cases where qastaging has to use ISD's staging SSO server
[16:26] <gary_poster> qastaging is not something I've had any involvement with other than the original discussions, but thinking...
[16:27] <gary_poster> ...yes...
[16:27] <gary_poster> maybe
[16:27] <gary_poster> description:
[16:28] <gary_poster> we want a system (staging or qastaging, not sure for this brave new world) that people can use to QA/test their webservice scripts
[16:29] <gary_poster> the one thing that we can possibly enable in the future on staging-type machines that is not OK on production machines is creating users with escalated privileges
[16:29] <gary_poster> for tests
[16:29] <gary_poster> we would want those users to be discarded
[16:29] <gary_poster> If we implemented it that way
[16:29] <gary_poster> So, that's scifi
[16:30] <gary_poster> In the abstract, I'd use the staging openid
[16:30] <gary_poster> because of that use case and maybe others like it
[16:30] <gary_poster> but if the staging openid server has been problematic that's a fair argument
[16:30] <gary_poster> sinzui ^^^
[16:31] <sinzui> gary_poster, I think that system is staging. qastaging is fast. SSO staging is not. if SSO staging is broken for a week, Launchpads QA is also broken
[16:32] <gary_poster> sinzui: I'm good with that as an initial setting
[16:32] <sinzui> oh, I guess I really do want to use production SSO with QA staging. We need to ensure our changes work in production
[16:32] <gary_poster> I thought that's what you were sating anyway
[16:33] <gary_poster> saying
[16:33] <sinzui> gary_poster, I often have to write and speak to understand myself
[16:34] <gary_poster> ah ok, understood.  I sometimes need the same
[16:42] <EdwinGrubbs> sinzui: ok, I'll change it to use login.launchpad.net.
[16:42] <sinzui> thanks
[16:43] <gmb> adeuring: Do you have time to take a look at https://code.edge.launchpad.net/~gmb/launchpad/make-bnl-descriptions-readable-bug-664566/+merge/39158 for me?
[16:43] <gmb> It's not a huge branch.
[16:43] <adeuring> gmb: sure
[16:43] <gmb> adeuring: Thanks.
[16:53] <adeuring> gmb: what about letting the display text for BugNotificationLevel.COMMENTS start with  "Any change..." too? (instead of "a change")
[16:55] <EdwinGrubbs> sinzui: can you approve this branch? https://code.edge.launchpad.net/~edwin-grubbs/lp-production-configs/qastaging-openid-config/+merge/39153
[16:56] <sinzui> Edwin, I cannot. I guess only a losa can.
[16:57] <EdwinGrubbs> sinzui: I added you as a reviewer just now. I will also get a losa to review it. It seems like all the other changes on that project had two reviews like that.
[16:57] <sinzui> There is a bug!
[16:57] <sinzui> I was able to give an approval via a comment, but I could not claim a  review an comment
[16:58] <adeuring> gmb: I think @cachedproperty would be better for _bug_notification_level_field. I understand that it is used just once, but just in case it is used later somewhere else, we can/should use the same Choice instance
[16:58] <gmb> adeuring: Okay, sure.
[16:59] <adeuring> gmb: thanks, r=me.
[17:00] <gmb> adeuring: Thanks!


[06:34] <didrocks> thomi: hey, still around by any chance?
[08:22] <didrocks> sil2100: hey, how are you?
[08:26] <sil2100> didrocks: hi! Sleepy, but alright - how about you?
[08:26] <didrocks> sil2100: I'm good thanks!
[08:26] <sil2100> didrocks: I'm looking at builds 76 and 77 now :)
[08:26] <didrocks> sil2100: yeah, I wanted to update you that 77 is showing the same
[08:27] <didrocks> sil2100: maybe the new autopilot is too fast for the intel machine :p
[08:33] <sil2100> ;)
[09:11] <didrocks> sil2100: does it seem to be time-related/easily fixable?
[09:18] <rye> Hi, https://bugs.launchpad.net/unity/+bug/1102410 - should I reopen the bug? I don't see how the blur became faster. It is quite the same speed as the old one before the nux fix
[09:19]  * rye curses every time he hits the "Super" key now because of that and https://bugs.launchpad.net/unity/+bug/1099787
[09:30] <smspillaz> rye: there are a number of things which could cause blur to be slow
[09:30] <smspillaz> rye: it would be better if we changed the description of that bug to "reduce the number of samples taken for the dash blur"
[09:32] <smspillaz> rye: the best approach to making blurs faster IMO would be to use a cache to reduce re-blurring so many fragments on each frame
[09:32] <smspillaz> That would require nux to be able to do geometry clipping, which appears to be a challenge in itself
[09:35] <sil2100> didrocks: it should be feasible, just give me a few more moments to finish up some things :)
[09:35] <didrocks> sil2100: sweet! :)
[09:38] <rye> smspillaz: aha, it reblurs everything on every frame draw? This is consistent with what I am seeing for the dash previews, even the unaffected regions take time to draw
[09:38] <smspillaz> rye: yes. Nux doesn't have a concept of partial texture redraws
[09:39] <smspillaz> I had a look into what it would take to add partial texture redraws like we have in compiz, but it would be very complicated and I suspect we'd have to repeat ourselves a lot in the code
[09:39] <smspillaz> because there's no central "draw a texture" function in nux
[09:40] <smspillaz> rye: to clarify: it reblurs the background of any window intersected by any new damage events
[09:40] <smspillaz> for the dash, this happens to be full-screen (for uninteresting reasons)
[09:41] <smspillaz> for the switcher this happens to be parts of the screen
[09:42] <rye> smspillaz: originally there was blur_passes = 1, then it was removed (default is 1 anyway, hm). But I don't see how that would affect the speed drastically. I am actually thinking we are using the wrong blur now, not the faster one
[10:01] <luv> Trevinho: good morning, would you have a sec to see the new diff here https://bugs.launchpad.net/unity/+bug/1107866 ?
[10:02] <luv> i mean here https://code.launchpad.net/~lukas-vacek/unity/bamficon_windowlist-raring/+merge/145676
[10:02] <luv> oh
[10:02] <luv> you already did! :-)
[10:12] <luv> Trevinho: great, i appreciated your comments; btw the fact that I copy WwindowPtr and not the id is because Windows() used to return the id back in unity-5.0
[10:14] <luv> oh and i dont think MAXIMUM_LABEL_WIDTH_PROPERTY is an integer ... because I indeed used an integer originally but it wouldn't compile so I checked the type in the src code and it requires const char * so i changed that and it works fine
[10:15] <luv> yeah and thanks for your superfast answer! Those are all small changes and I will get tham sorted tonight.
[10:55] <smspillaz> rye: we should be using the faster one
[10:55] <smspillaz> rye: it would be called QRP_GLSL_LSBlur or something
[11:22] <yaraju> hi all!
[11:22] <yaraju> Though I've tried following the forums online, i find that when I add a new launcher using "Alacarte" it won't show up on my Unity Dash search. Can anyone help me figure out what's going on?
[12:03] <MCR1> JohnLea: Hi :) Please comment on bug 1116538.
[12:06] <didrocks> MCR1: hey, did you check to finish the work on the minimize/maximize?
[12:06] <didrocks> like exposing to g-c-c
[12:07] <didrocks> as we are in a middle ground right now, some part are not yet reviewed by smspillaz
[12:07] <JohnLea> MCR1; re that bug, does "Strg" = "Ctrl"?
[12:07] <MCR1> didrocks: I am still waiting for smspillaz' input.
[12:07] <didrocks> smspillaz: ^
[12:07] <didrocks> MCR1: otherwise, I'll revert the change for coherence
[12:08] <MCR1> didrocks: Why revert domething that works ? The only problem remaining is that you just can change shortcut via CCSM now...
[12:08] <didrocks> MCR1: it doesn't work
[12:08] <didrocks> it doesn't migrate the right keys
[12:08] <didrocks> and there is no way to change the shortcut as we did
[12:08] <MCR1> didrocks: I do think reverting is counterproductive -> ofc it works
[12:08] <didrocks> so the "having something working everyday" rule is broken
[12:09] <didrocks> MCR1: right, but we have half changes
[12:09] <didrocks> so it doesn't work for the reasons above ^
[12:09] <didrocks> MCR1: and CCSM isn't an official tool
[12:09] <MCR1> as I said, I am commited to fixing it fully
[12:09] <didrocks> yep, please get in sync with smspillaz ASAP
[12:09] <MCR1> sure - I have not forgotten it ;)
[12:10] <smspillaz> JohnLea: the only modifier I can think of as equavilent to Control is Primary
[12:10] <MCR1> JohnLea: No, that bug is about having 2 restore window functions instead of one, so for grid-resized windows we currently use another shortcut to restore than for all the other windows
[12:11] <MCR1> smspillaz: Hi
[12:11] <smspillaz> yeah I saw
[12:11] <smspillaz> hang on
[12:11] <MCR1> smspillaz: Cool, thanx
[12:12] <smspillaz> MCR1: you've reminded me that we really should autogenerate the keybindings glue code
[12:12] <MCR1> JohnLea: IMHO we need just Ctrl+Alt+Down and it should work for all windows (first restore, then minimize), no ?
[12:12] <MCR1> smspillaz: Oh, that would be great
[12:12] <smspillaz> its a pain to get right though
[12:13] <MCR1> smspillaz: Because currently changing shortcuts is like visiting hell ;)
[12:13] <smspillaz> MCR1: only if you want to expose them in gnome-control-center
[12:13] <JohnLea> MCR1; agreed we should standardise, also agree with getting rid of the "Ctrl + Alt+ R" shortcut and replacing it with "Ctrl + Alt + Down".  I was just wondering why the bug didn't mention Ctrl and was talking about Strg instead, but never mind, I'll update the bug description
[12:13] <smspillaz> the current code is actually partially autogenerated
[12:13] <smspillaz> though I don't know where the script I used to do it was
[12:14] <MCR1> JohnLea: Because the reporter is from Germany
[12:14] <MCR1> JohnLea: And there Strg==Ctrl
[12:14] <MCR1> Steuerung
[12:14] <JohnLea> MCR1; anyhow, it's a good change, I'm just updating the bug now
[12:14] <MCR1> JohnLea: Thx
[12:15] <JohnLea> MCR1; done
[12:19] <MCR1> JohnLea: Thx
[12:20] <smspillaz> hmm
[12:20] <smspillaz> MCR1: this:
[12:20] <smspillaz> 21	-    { "unmaximize_window_key", "unmaximize" },
[12:20] <smspillaz> 22	+    { "unmaximize_or_minimize_window_key", "unmaximize or minimize" },
[12:20] <smspillaz> will probably cause some trouble
[12:20] <MCR1> smspillaz: The big question is-> if I added a new function + new shortcut, what do we exactly need to adjust to make g-c-c work with the new shortcut
[12:20] <smspillaz> you probably wanted unmaximize_or_minimize
[12:20] <yaraju> Any help with why my launcher added using "alacarte" won't showup on a Unity Dash search?
[12:21] <MCR1> smspillaz: ok
[12:21] <smspillaz> (the current version won't work with gconf, and changes won't get propogated back to compiz from gsettings if it changes directly in gsettings)
[12:21] <MCR1> smspillaz: Isn't that the description only ? So the spaces do not matter ?
[12:22] <smspillaz> MCR1: no, its the name of the foreign gnome key with underscore separated identifiers (instead of dashes)
[12:22] <MCR1> ok
[12:22] <smspillaz> (we just translate _ to - for the gsettings case)
[12:22] <MCR1> yep, I understood that
[12:23] <smspillaz> MCR1: if you want unmaximize_or_minimize_window_key to integrate with the existing org.gnome.desktop.wm.keybindings:unmaximize key
[12:23] <smspillaz> then you should leave that declaration as
[12:23] <smspillaz>     { "unmaximize_or_minimize_window_key", "unmaximize" },
[12:24] <MCR1> well, that is what didrocks suggested (I think), but imho this would be confusing, no ? Wouldn't it be better to name the key correctly ?
[12:25] <MCR1> ofc if you also say that it should be done that way. I'll do it that way
[12:26] <smspillaz> MCR1: creating a new key would be a pain
[12:26] <MCR1> ok, then let's go with this version...
[12:26] <smspillaz> you'd then have unmaximize and "unmaximize_or_minimize" next to each other, and then you'd have to update org.compiz.integrated and then also .convert files and .keybindings files and blah blah blah
[12:26] <smspillaz> not all that fun
[12:27] <MCR1> ok, let's do it the more easy way
[12:27] <smspillaz> almost more painful than I'm finding rails development at the moment
[12:27] <MCR1> hehe
[12:28] <smspillaz> "you wanted to add a new page? oh, I guess you'll have to update routes.rb, the controller, the seed.rb, pages_model.rb" blah blah blah
[12:28] <MCR1> urgh
[12:28] <smspillaz> "oh its not working - run rake db:seed you tard"
[12:29] <smspillaz> I don't understand how a framework that embodies DRY as a core value doesn't encourage the use of constants
[12:31] <smspillaz> how much longer until feature freeze
[12:31]  * smspillaz wonders if its worth even trying to get people to look at the gesture test refactoring code
[12:32] <smspillaz> or if the plan is just "ignore until it goes away"
[12:34] <MCR1> smspillaz: Oh, thanks 4 the other review, btw. :)
[12:34] <MCR1> smspillaz: Probably this will also eliminate some of the Coverity static analyzer bugs...
[12:35] <smspillaz> maybe, although coverity checks for different kinds of things
[12:36] <MCR1> smspillaz: I am having slight problems to implement the damaging from scratch in workspacenames and at the same time workspacenames gets featured everywhere and still has this nasty flickering bug, which I've already fixed...
[12:36] <MCR1> smspillaz: Would it be okay to get this fix in first and implement the damagerect in a subsequent MP ?
[12:37] <MCR1> smspillaz: I am confident I can get it done until FF (hopefully)
[12:37] <MCR1> smspillaz: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix-1075578-workspacenames-flickering-during-display/+merge/133124
[12:38] <MCR1> ^^ this just fixes the flickering for now :-[
[12:38] <MCR1> smspillaz: Example for feature: http://www.iloveubuntu.net/how-easily-add-names-workspaces-ubuntu-1210
[12:38] <smspillaz> yeah doing that is not such a great idea
[12:39] <smspillaz> full-screen redraws all the time == dead batteries
[12:39] <MCR1> smspillaz: Could you help me implement it then ?
[12:39] <smspillaz> MCR1: was the "timer" variable a bool? or what
[12:39] <MCR1> smspillaz: Yes, I know - it is not ideal
[12:39] <smspillaz> CompTimer ?
[12:39] <smspillaz> CompTimer *?
[12:40] <MCR1> smspillaz: unos momentos
[12:41] <MCR1> smspillaz: No, it is a simple int
[12:41] <MCR1> int		timer;
[12:42] <smspillaz> MCR1: ... what is it supposed to represent? Where else is it used ?
[12:45] <MCR1> well, it is used for different things in workspacenames, but in the case I've corrected it is timer = optionGetFadeTime () * 1000;
[12:46] <smspillaz> MCR1: is it decremented anywhere ?
[12:46] <MCR1> timer -= msSinceLastPaint;
[12:46] <MCR1> WSNamesScreen::preparePaint (int msSinceLastPaint)
[12:47] <MCR1> It means it will only damage the screen during fade, but not during display anymore
[12:48] <MCR1> as far as I understand... and as the flickering fix shows
[12:48] <smspillaz> MCR1: hmm
[12:49] <smspillaz> MCR1: in any case, your best bet is to find the condition in which the text is actually meant to be displayed, and then call cScreen->damageRegion (textRectangle); in donePaint on the same condition
[12:49] <MCR1> smspillaz: I just saw that I have to remove the dependency on mousepoll as well, it is still there...
[12:50] <MCR1> smspillaz: Ok, I'll try to fully fix it, before I'll ping you again ;) I have to understand how damageRegion works exactly anyway...
[12:51] <smspillaz> MCR1: damageRegion means "this area of the screen will be redrawn"
[12:51] <MCR1> yes, I understand the theory ;)
[12:52] <smspillaz> you need to do it because core uses that information to copy from the scene framebuffer to the backbuffer
[12:54] <MCR1> smspillaz: First I'll have to fix the shortcut-thingy or else didrocks will kill me ;)
[12:54] <smspillaz> didrocks doesn't kill people
[12:54] <smspillaz> he hugs them to death
[12:54] <MCR1> phew
[12:54] <smspillaz> which is slightly different
[12:54] <didrocks> different approach :-)
[12:55] <MCR1> hehe
[12:56] <MCR1> smspillaz: I also have a fix for the cylinder rendering of the Cube Gears: http://imagebin.org/245474
[12:57] <smspillaz> great
[12:57] <MCR1> smspillaz: Here you can see that they are rendered wrongly ^^
[13:07] <MCR1> smspillaz, didrocks: *Should* be okay now, hopefully: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1115128-expose-unmaximize_or_minimize_key-in-g-c-c/+merge/146384
[13:11] <smspillaz> MCR1: have you tried it to make sure it works ?
[13:11] <smspillaz> I haven't got time to manually test merge proposals atm
[13:12] <MCR1> smspillaz: No, and I am not sure how as g-c-c integration here is a bit broken atm...
[13:17] <luv> Trevinho: ping ;-)
[13:17] <luv> Trevinho: what the hell^W^W is the deal with the AP/unit tests?
[13:17] <Trevinho> luv: 1 sec I'll be back to you
[13:23] <Trevinho> luv: ok, I'm here...
[13:23] <luv> great  ..
[13:23] <Trevinho> luv: so, I'd prefer an unit test as it's less prone to failures
[13:23] <Trevinho> and should also be quite easy here...
[13:23] <luv> alright, well ... got to hear ... almost feel like giving up :-/
[13:24] <luv> good to hear
[13:24] <smspillaz> MCR1: describe 'broken'
[13:24] <Trevinho> luv: what you need is adding a new tet case to test_application_launcher_icon.cpp
[13:25] <luv> alright what should the test case do ... how do i simulate what Windows() return ?
[13:25] <Trevinho> It should be enough to: do ...
[13:25] <Trevinho> auto win = std::make_shared<MockApplicationWindow>(g_random_int());
[13:25] <Trevinho>   mock_app->windows_ = { win };
[13:25] <smspillaz> MCR1: it should 'just work' when you change WM realted options in gsettings
[13:25] <MCR1> smspillaz: I have flat-file CCSM config here and g-c-c does not seem to recognize it
[13:26] <smspillaz> MCR1: you need to use gsettings
[13:26] <luv> and then I compare the values from win with what my function returns ... ok
[13:26] <MCR1> smspillaz: then CCSM crashes on me/ does not like gsettings
[13:26] <luv> still not super excited about that though :-)
[13:26] <Trevinho> luv: then you only have to do mock_icon->GetMenus()... that will return a list of dubsmenu items...
[13:26] <smspillaz> MCR1: COMPIZ_CONFIG_PROFILE=ubuntu ccsm
[13:26] <Trevinho> luv: you've to ensure that there's one matching your window name
[13:27] <luv> um, ok, im lost again :-)
[13:27] <Trevinho> luv: err.. actually if you add one window you should ensure that no item is there, while if there are two windows (add one more), it has the menus
[13:28] <MCR1> smspillaz: It does not work here -> once I change (in CCSM) from flat-file to gsettings, CCSM simply closes
[13:28] <luv> um so how many tests should i write?
[13:28] <luv> is it enough to write a test for each ...  0,1,2 windows?
[13:28] <MCR1> smspillaz: Once I reopen it, it uses flat-file again
[13:28] <smspillaz> luv: test for code coverage
[13:29] <smspillaz> luv: so, you should ensure that every possible path in your change is covered by some kind of test
[13:29] <smspillaz> MCR1: I guess you can force it, by editing ~/.compiz-1/compizconfig/config
[13:29]  * MCR1 is not sure if he wants that...
[13:31] <luv> well, i haven't done any unit test _for unity_ yet so please bear with me
[13:32] <MCR1> smspillaz: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1117311-gears-cylinders-not-rendered-correctly/+merge/146853
[13:33] <smspillaz> MCR1: yeah I saw
[13:33] <smspillaz> MCR1: in any case, please find a way to switch to using gsettings and test the integration code
[13:33] <luv> do I want to test GetMenus or EnsureMenuItemsWindowsReady ? In case I want to test GetMenus - should I check all created dbusmenuitems have all properties set exactly as they should or is it enough to see that they are not/available?
[13:33] <MCR1> smspillaz: Ok, I'll try
[13:34] <luv> im trying to shorten this endless merge review ping-pong, that's all ....
[13:37] <luv> smspillaz: kinda not enough, because cases like bunch of windows with same titles, bunch of windows with different titles but same shorten titles are not covered in the code (explicitly)
[13:37] <smspillaz> bregma: get in touch when you can :)
[13:38] <luv> s/covered/expressed/
[13:38] <Trevinho> luv: sorry, I missed your messages
[13:39] <Trevinho> luv: so, two tests are enough in your case
[13:39] <Trevinho> luv: one that checks that there are no window items, another one that checks that there are
[13:40] <luv> great, i will add an extra one which tests for windows with same title as well - that should be handy too
[13:40] <luv> Trevinho: thanks
[13:40] <luv> I will do that tonight and we can go through next round of the ping pong tomorrow ;-)
[13:43] <MCR1> smspillaz: Could you please comment on bug 1101198 - I would like to know how you want that fixed...
[13:44] <smspillaz> MCR1: I don't really know "how" it should be done, as I don't know the ccsm codebase
[13:44] <MCR1> smspillaz: Well, there are cases for everything there, but not for a soft dependency...
[13:45] <MCR1> smspillaz: So we could a) extend CCSM to understand a recommend in the xml
[13:45] <smspillaz> it sounds like a good idea but I don't really know exactly how to do it
[13:45] <MCR1> smspillaz: Or b) scratch that and make (in this case text) a hard dependency
[13:46] <smspillaz> MCR1: of workspacenames ?
[13:47] <MCR1> smspillaz: Currently it will just say "plugin x needs feature textrendering, which is provided by plugins a and b, Do you want to activate a or b or deactivate plugin x ?"
[13:48] <MCR1> smspillaz: No, it is about: scaleaddon, stackswitch, shift, scalefilter, thumbnail, ring
[13:48] <smspillaz> better to make it optional *shrug*
[13:48] <MCR1> smspillaz: They all need text, but will also work without
[13:49] <smspillaz> yeah, just leave it optional
[13:49] <MCR1> smspillaz: Yeah, the best thing would be a soft dependency. I will have to learn some Python ;)
[13:49] <MCR1> smspillaz: Currently nothing happens and the user is not informed about text...
[13:49] <MCR1> smspillaz: So all text-related options silently fail
[13:50] <MCR1> smspillaz: if text plugin is disabled
[13:50] <MCR1> smspillaz: Then something like this happens to users: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1099100-thumbnail-title-text-issues/+merge/143042/comments/310279
[13:52] <MCR1> smspillaz: Seems CCSM coders have thought about everything, just not that ;)
[13:53] <smspillaz> MCR1: there had been talk of that for a long time in compiz
[13:53] <smspillaz> many years back
[13:53] <smspillaz> eg cube should "suggest" rotate
[13:54] <MCR1> smspillaz: yeah, exactly -> soft dependencies with the user deciding
[13:55] <MCR1> recommends feature x which is provided by plugin y, should we enable plugin y or do you want the feature x to stay disabled ?
[13:59] <MCR1> smspillaz: I will implement that in the next weeks...
[13:59] <MCR1> smspillaz: Let's make CCSM perfect :)
[14:00] <smspillaz> MCR1: have a look at how some of the other tags are handled in libcompizconfig and the xml
[14:01] <MCR1> yes, I already did that :)
[14:01] <smspillaz> I think if you want to add a new tag, you need to update the .proto, compiz.cpp (in compizconfig), compizconfig.pyc, and Settings.py
[14:01] <MCR1> that is why I am confident about implementing it
[14:01] <MCR1> thx 4 the info :)
[14:02] <mterry> sil2100, so enough unity tests failed last night to stop the daily build
[14:03] <MCR1> smspillaz: I do not want to nerve, just FYI: There is another related problem -> for example water plugin needs FBO to be enabled to work, but we cannot check for a special setting via CCSM <- I am still thinking about how to fix that best
[14:03] <smspillaz> MCR1: TBH we should remove that setting
[14:03] <MCR1> nooooooooooo
[14:04] <smspillaz> MCR1: it makes sense to - and here is why
[14:04] <MCR1> Here Compiz is fast with FBO turned off and slow like sh*t when turned on
[14:04] <MCR1> with fglrx or gallium-radeon
[14:04] <smspillaz> "always swap buffers" is basically the option that 99% of users would care about
[14:05] <MCR1> but FBO turned on (which is default) makes stuff really slow here
[14:05] <MCR1> and that is with a fast system and very fast gfx card
[14:05] <smspillaz> MCR1: it doesn't have any impact if core or plugin code is not using it
[14:05] <smspillaz> if "always swap buffers" is off, there's no reason to use framebuffer objects for rendering
[14:05] <smspillaz> (at least in the basic case)
[14:06] <MCR1> IMHO FBO should be off by default, but that is just my 2 cents from testing on ATI
[14:07] <smspillaz> MCR1: I think what you meant to say was "always use glXSwapBuffers, even if it means backing up the previous frame" should be off by default
[14:07] <smspillaz> and that would be a bad idea regardless, because it tears like crazy
[14:07] <didrocks> MCR1: tbh, I would prefer you ensure it's working on a fresh account if needed :)
[14:07] <didrocks> MCR1: the g-c-c integration should work there ;)
[14:07] <MCR1> didrocks: ok
[14:07] <didrocks> thanks!
[14:08] <MCR1> didrocks: please give me a little bit of time...
[14:09] <didrocks> sure
[14:09] <smspillaz> MCR1: Iunno if we can do it for this release, but it might be worth looking into how hard it would be to implement GLX_EXT_buffer_age for the root-window-only case on the mesa drivers
[14:09] <MCR1> didrocks: it is high up on the priority list
[14:09] <didrocks> thanks MCR1 ;)
[14:10] <smspillaz> krh said he wouldn't support it on X because compositing + reparenting makes it hard to support, but I know that logic makes no sense for the root window, because there's no reparenting or compositing involved there
[14:10] <MCR1> didrocks, yw ;)
[14:11] <MCR1> smspillaz: It would be great to support additional OpenGL features, I agree 100%
[14:12] <smspillaz> well, buffer_age in particular means we don't need to resort to crazyness in order to support glXSwapBuffers/glXSwapControlEXT
[14:14] <MCR1> is buffer_age working on all main drivers ?
[14:14] <smspillaz> only nvidia at the moment
[14:14] <MCR1> hmm
[14:14] <smspillaz> its trivial to support in a driver though
[14:15] <MCR1> Well, you know that I am still missing OpenGL knowledge to make judgements here...
[14:15] <smspillaz> the graphics system has to give you a new backbuffer on glXSwapBuffers, its not hard for the driver to tell you when it was last displayed
[14:15] <didrocks> hey fginther, around?
[14:15] <fginther> didrocks, morning!
[14:16] <didrocks> how are you?
[14:16] <fginther> sleepy, need some coffee :)
[14:16] <didrocks> ahah ;)
[14:16] <didrocks> fginther: once, you are awaken, did you see https://code.launchpad.net/~ps-jenkins/bamf/latestsnapshot/+merge/146765? It seems that it didn't go with the fastrack (in addition to failing
[14:16] <MCR1> smspillaz: But we had excellent OpenGL feature detection in UFO:AI. It might make sense to look at that code and see what we could use...
[14:17] <smspillaz> MCR1: feature detection doesn't really matter in this case
[14:17] <fginther> didrocks, I'll get it going.
[14:17] <didrocks> sil2100: hey hey! did you get any progress or the failures look ugly?
[14:17] <smspillaz> MCR1: the fact is that if you have tearing in a compositor, you're kinda doing it wrong
[14:17] <MCR1> smspillaz: yep - the good ol' tearing problem...
[14:17] <didrocks> fginther: thanks, then, all projects will have the fasttrack (in unity, webapps, webcreds, oif, indicators… ?)
[14:18] <smspillaz> bregma: you around ? .....
[14:19] <MCR1> afk, bbl
[14:20] <fginther> didrocks, I'm still waiting on a review for the fasttrack changes. keep your fingers crossed :)
[14:20] <didrocks> fginther: heh, ok :)
[14:46] <ritz> hi Mirv, busy ? looking for assistance with  https://launchpad.net/bugs/1096954
[15:12] <kenvandine> mhr3, did you see my valgrind log from yesterday?
[15:13] <kenvandine> mhr3, http://ubuntuone.com/0AQvy3yDmcQCLz3Ejxn6pE
[15:13] <mhr3> nope
[15:13] <mhr3> will check out
[15:17] <kenvandine> mhr3, thanks
[15:19] <ritz> ping didrocks
[15:20] <sil2100> didrocks: will give you an update in a moment, been on lunch and didn't see your ping :)
[15:21] <didrocks> sil2100: no worry
[15:21] <didrocks> hey ritz
[15:21] <ritz> hi didrocks, busy ? looking for assistance with  https://launchpad.net/bugs/1096954
[15:21] <ritz> unity 2d
[15:22] <ritz> forcing  compositing as off seems to fix the issue
[15:22] <ritz> in code
[15:22] <ritz> any clue on how I could proceed further in this ?
[15:25] <didrocks> ritz: kind of busy TBH ;) you should retarget the package from unity to unity-2d btw ;)
[15:25] <didrocks> ritz: not really sure, does it happens with other QML apps?
[15:25] <ritz> hmm, have not tested this with other qml apps
[15:27] <didrocks> maybe that will give an hint
[15:27] <ritz> thanks, will try this
[15:31] <sil2100> didrocks: I think I have a hint what might be wrong, since those failures I can reproduce locally - so they're not 'hopeless' ;)
[15:31] <didrocks> sil2100: sweet, I hope that we can have an unity daily release tomorrow passing tests at least :)
[15:31] <didrocks> ritz: yw ;)
[15:53] <sil2100> Ha!
[16:03] <sil2100> didrocks: I know how to fix some of those failures, so I'll submit some fixes and get them merged till EOD
[16:05] <sil2100> mterry: hi! If anything, I have a fix for the preview-related AP failures in the unity release task
[16:05] <sil2100> So that we don't step on eachother's toes
[16:23] <jibel> didrocks, would it be possible to land the introspection modules of autopilot daily into raring or is it not done on purpose?
[16:35] <didrocks> jibel: introspection modules? sorry out of context
[16:35] <didrocks> you mean the -gtk and -qt ones?
[16:35] <jibel> didrocks, yes autopilot-(gtk|qt)
[16:35] <didrocks> IIRC, some work were needed (like the qt one is dep on qt 5), I think some tests or something on the -gtk ones were not working, cyphermox would know more? ^
[16:36] <cyphermox> well there were issues initially with the -qt one
[16:37] <cyphermox> and further work on -gtk to make sure the module would be installable properly, I'll check again to see how ready that is
[16:37] <cyphermox> I think it can land today
[16:38] <jibel> cyphermox, what do you mean by "installable properly"?
[16:38] <cyphermox> there were issues with how the package was built, now it was updated to make it a proper gtk module IIRC and just clean up the packaging
[16:39] <jibel> k
[16:39] <mpt> Cimi, yo, could you join #ubuntu-design?
[16:40] <cyphermox> jibel let me run it through sbuild now and I'll be able to tell you exactly how ready I think it is to land
[16:41] <jibel> cyphermox, thanks
[16:41] <cyphermox> there's a minor copyright issue I'll fix now
[16:42] <cyphermox> didrocks: I can sponsor the first upload and we'll make it autoland after?
[16:43] <didrocks> cyphermox: well, let's do autolanding right away :)
[16:43] <cyphermox> ok, I thought it was better to have the first-ever upload manually ;)
[16:45] <didrocks> no no :)
[17:26] <MCR1> hrmpf, didrocks is gone...
[19:07] <andyrock> mpt, the panel-tray branch should land in trunk soon ;)
[22:24] <luv> hey, how can i executed tests/test_application_launcher_icon.cpp ?
[22:25] <luv> oh and how was the trick to add pseudo windows to mock_app ??
[22:34] <luv> hmm and how can i get dbusmenuitems off it anyway?