[01:14] <spm> looking at bug 726584 and the corresponding RT. we have 2.3b5 on jubany atm. I can find a ppa from max for 2.3.0-1; but it's unclear to me which version matches up to revno? I'm guessing by the dates that we need 2.3.1 or possibly .2?
[01:22] <spiv> spm: let me double check
[01:23] <spm> ta
[01:23] <spiv> spm: yes, 2.3.1
[01:23] <spm> coolio, do we have a ppa of that already I can backport from?
[01:25] <spiv> spm: none that I can see.
[01:26] <spiv> (There's the daily builds from trunk PPA, but I think that's a bit riskier than we want to use)
[01:32] <spm> okidoki. I'll update the RT with a request for a PPA we can backport off. ta spiv
[01:32] <spiv> spm: Thanks!  Glad to have progress :)
[01:32] <spm> heh, nothing quite like being down 1-2 folks in a team of 4. :-)
[01:33] <spiv> Yeah, I bet.
[01:39] <poolie> maxb, hi, could you update the ppas some time?
[01:58] <maxb> poolie: hi
[01:59] <maxb> yes, I promised to do that this evening and have so far failed, due to Rocket Bunnies :-)
[01:59] <maxb> I shall do it before I sleep
[02:04] <poolie> thanks mate :)
[02:04] <poolie> i sympathize about the bunnies
[02:07] <maxb> yikes, there have been 19 revisions in the debian packaging branch since the last PPA release
[02:26]  * maxb is confused
[02:27] <maxb>  How can I be getting conflicts in files when merging 2.3.1 into ppa/natty ?!
[02:27] <maxb> upstream files, that is, not debian/*
[02:48] <Peng> Cherrypicking, maybe?
[03:13] <AfC> Is there a way to force Bazaar back to the original behaviour of not attempting to use empty commit messages and just straight up cancelling a commit if it gets one?
[03:16] <lifeless> that changed?
[03:21] <AfC> lifeless: yeah. It's rather off-putting.   Say there are many changes committed after this reversion.  Later on, I want to bring that undone change back, I can do this: (still in trunk) bzr merge -r old-rev1..old-rev2 && bzr ci -m "Bring that old change back".  I tried and this worked.  But is this the canonical/recommended way?
[07:04] <poolie> yes
[07:04] <poolie> hi jam
[07:04] <echo-area> poolie: Thanks
[07:40] <vila> hi all !
[08:23] <jam> hi po
[08:23] <jam> hi poolie
[08:26] <jam> and vila, too!
[08:26] <vila> _o/
[08:29] <maxb> Does bzr actually use per-file DAGs to assist merging?
[08:30] <maxb> I'm getting all sorts of spurious conflicts in criss-cross situations, even though the specific files conflicting didn't criss-cross
[08:30] <maxb> e.g. the current merge of loggerhead trunk into daily-ppa
[08:35] <maxb> and in fact, 4 files which didn't conflict drastically failed to have their changes merged correctly
[08:35] <vila> maxb: not as well as it should, jam knows the best about this specific point
[08:36] <jam> maxb: merge --weave does
[08:36] <jam> (does what you want)
[08:36] <jam> maxb: thats the main problem with re-landing code :)
[08:36] <jam> but I'm trying to at least make sure that I do the work of merging into experimental
[08:37] <jam> I didn't realize the ppa branch would have that problem, too
[08:37] <maxb> --weave ... did not do what I wanted :-(
[08:37] <maxb> At least for the daily-ppa branch I can just revert all the non-debian bits to the pending merge tip and be done with it
[08:42] <jam> maxb: can you point me to the branches you are merging? I can give it a look over
[08:42] <jam> maxb: I would guess the daily ppa would have tried to build the old trunk tip
[08:42] <jam> which has been removed from history
[08:42] <jam> which is going to confuse the hell out of everything
[08:45] <maxb> Most recently I was trying to merge lp:loggerhead into lp:~bzr/loggerhead/daily-ppa
[08:45] <jam> maxb: right, and you actually need to revert all of the 'experimental' branch back out of the daily-ppa, since it used to be in lp:loggerhead
[08:45] <jam> maxb: so probably the best thing is as you said
[08:46] <maxb> But that had already been done in the past
[08:46] <jam> maxb: but not in the trunk branch, so things get really weird in history
[08:46] <maxb> evidently :-)
[08:46] <jam> daily-ppa basically has a change for almost every file that supersedes what is in trunk
[08:47] <jam> what was in trunk
[08:47] <jam> but then trunk updates == conflicts
[08:47] <maxb> ugh
[08:47] <maxb> bzr really ought to understand "I merged foo and reverted to its version" as "I'm happy to accept foo's changes in future"
[08:47] <jam> maxb: if we had reverted trunks contents using "bzr revert -r OLD; bzr commit", and then rebuilt experimental from there
[08:47] <jam> it would work better for you
[08:48] <maxb> right, I'd better get myself to work now. I'll re-stare at trees
[08:48] <maxb> later
[09:01] <jam> vila, mgz: ping about tarfile exports. "tarfile.extractfile()" seems to hang indefinitely if you give it corrupt data. Which does exercise the test, but means it has a really bad failure mode
[09:02] <vila> weird, what is hanging ?
[09:02] <jam> f = tarfile.extractfile('path'); f.read() the .read() is hanging
[09:03] <vila> O_o
[09:04] <jam> I'll try to trace into it to give better detail
[09:04] <vila> is there a pipe there ?
[09:04] <jam> vila: nope, it is reading from disk
[09:04] <vila> O_O
[09:05] <poolie> hi jam, vila
[09:06] <vila> _o/
[09:08] <jam> vila: ah, maybe it is "assertEqualDiff being unhappy trying to match 800 lines of gobbledy-gook
[09:08] <jam> vila: yeah, stopping the hang shows it in difflib
[09:08] <jam> so better and worse :)
[09:10] <vila> 800 lines ? That's a lot...
[09:10] <jam> yeah, swapping out assertEqualDiff made it happier
[09:10] <jam>     _file_content = ('!\r\n\t\n \r'
[09:10] <jam>                      + '\n'.join([osutils.rand_chars(80) for i in range(800)])
[09:10] <jam>                      + '\n')
[09:10] <jam> doesn't seem very big to mee
[09:10] <poolie> wow, that's a bit bad it would hang
[09:10] <jam> me
[09:10] <vila> hmm, please don't use rand_chars in tests, it is *guaranteed* to fail one day or another
[09:10] <jam> poolie: it might just go O(N^2) and die, or it might have a real bug in the diff code.
[09:10] <jam> vila: it is meant to
[09:11] <jam> how do you expect it to fail?
[09:11] <jam> (I need a way to force '\r' and '\n' in the compressed streams)
[09:11] <jam> which has all sorts of "tar header", etc.
[09:11] <jam> I can hand-craft something today
[09:11] <vila> because you will encounter a combination that while unlikely will break the test ?
[09:11] <jam> or I can throw enough random data at it, that I'm sure it has at least one char
[09:11] <jam> vila: this is file content itself
[09:12] <jam> if we are not managing to preserve exact fidelity
[09:12] <vila> yeah, hand crafting is better, it's stable ;)
[09:12] <jam> we have a problem
[09:12] <jam> vila: except there are timestamps, and mtimes that will vary
[09:12] <jam> which means that the real data may change its compressed form
[09:12] <vila> still deterministic
[09:12] <jam> vila: deterministic in the sense that time.time() is always changing?
[09:13] <vila> yes, in predictable ways (except on vbox slaves but I digress ;)
[09:14] <vila> so modulo restting the system clock, you can run the same twice and get the same result
[09:14] <vila> introducing randomness is the opposite of test isolation :)
[09:14] <jam> vila: still isolated tests
[09:14] <jam> each test does not depend on the other
[09:15] <jam> I can run 'osutils.rand_chars()' manually and hard-code it in the file, but that just bloats the test file (IMO)
[09:15] <vila> and give us data to analyze if the test ever fails whereas rand_chars won't
[09:16] <vila> and of course you're supposed to provide a sample that is not 80*800 chars long...
[09:19] <vila> or said otherwise: if the test fails with 80*800 random chars, how would you debug it ?
[09:19] <poolie> do we have any tests using rand_chars?
[09:22] <vila> hmm, not much but grep rand_chars in bzrlib/tests find 15 matches (not all of them are relevant though)
[09:22] <vila> ./test_lockdir.py:394:            lf1.nonce = osutils.rand_chars(20) seems valid for example
[09:23] <poolie> mm
[09:23] <vila> well, almost, there should probably be an assertion that we don't collide
[09:23] <jam> poolie: indirectly almost all of them via 'gen_file_id()"
[09:23] <poolie> we should probably make them deterministic
[09:23] <poolie> right
[09:30] <maxb> 2.3.1 is up in ~bzr/proposed - testers appreciated
[09:34] <poolie> thanks maxb
[09:34] <poolie> i'll install it
[09:46] <poolie> jelmer, can you help me think of some other options?
[09:53] <jam> vila: I used hard-coded data. Now the test fails intermittently
[09:53] <jam> (explicitly not fixing the bug so that I know I should have a failing test.)
[09:53] <jam> it was failing reliably with 64k data
[09:53] <jam> it seems the timestamps are having a pretty strong effect on the compressed steram
[09:53] <jam> stream
[09:54] <vila> jam: then your data are not good enough ? Or you should isolate the test from the timestamps
[09:54] <jam> vila: I can make it 64k data and be done with it
[09:54] <jam> (which I had)
[09:55] <jam> poolie: other options for? (and shouldn't you be sleeping by now?)
[09:56] <vila> jam: huh ? You said bloating the test wasn't good no ?
[09:57] <jam> vila: osutils.rand_chars(65536) isn't many characters in the file
 or said otherwise: if the test fails with 80*800 random chars, how would you debug it ?
[09:57] <jam> [osutils.rand_chars(80) + '\n' for i in xrange(800)] isn't much bigger
[09:57] <vila> s/80*800/65536/
[09:58] <vila> jam: how will you debug it if it fails ?
[09:58] <jam> vila: if we are corrupting the data stream, it doesn't matter what the content is, IMO
[09:58] <jam> vila: start looking for missing binary streams
[09:58] <jam> if it is 100 random chars, does that help debugging?
[09:58] <jam> same problem
[09:58] <vila> yes the problem is the random part
[09:58] <jam> to trigger it, needs enough random data, that you can't eyeball the corruption
[09:59] <jam> vila: note that we also want to trigger it for raw tar, .tgz and .tbz2, and .tar.xz
[09:59] <jam> and .tar.lzma
[10:00] <vila> if the test is random it's not a reliable reproducing recipe, do we agree on that ?
[10:01] <jam> vila: no
[10:01] <vila> as I mentioned earlier, if the bug is too hard to reliably reproduce, I don't care about having a test for it as long as the diagnosis is 100%: we must use 'wb' and be done with it
[10:01] <jam> vila: if the chance of failing is 1 in 2^256
[10:01] <jam> I'm fine with that
[10:01] <vila> but you're pulling this number out of thin air right ?
[10:02] <jam> 65k bytes, compresses down to about 40kb. If you then have 1-in-256 chance per byte to be a '\r' or '\n', then your total chances are (let me grab a calc)
[10:02] <vila> since you can only prove it to be right by establishing which inputs are valid/invalid
[10:03] <jam> vila: given 10k compressed characters, the odds it not having what we want is  10^-17
[10:03] <jam> vila: what bounds would you be happy with?
[10:03] <vila> 0
[10:03] <jam> vila: note, zlib changes the compressed stream from source from time to time
[10:03] <jam> it is allowed to
[10:03] <jam> for the same compression settings
[10:03] <jam> as long as the actual decompressed content is the same
[10:04] <jam> vila: I can't give you 0
[10:04] <jam> I can give you epsilon
[10:04] <vila> that's my point
[10:04] <jam> vila: it means we can't force the compressed stream, but we can be really darn certain
[10:06] <vila> the options are:
[10:06] <vila>  1) no test
[10:06] <vila> 2) test with a hard-coded reduced length
[10:06] <vila> 3) test with random data
[10:07] <vila> (3) is the worse because, a) it can't be debugged if it fails b) it will fail
[10:07] <jam> vila: I disagree on (b)
[10:08] <jam> if we are failing because of the content of files
[10:08] <jam> then we have *serious* problems internally
[10:08] <vila> do you have a fix for the bug ?
[10:10] <jam> vila: certainly, but I would like to make sure we are testing all of them. Since mgz was kind enough to notice we had the same bug in other exporters
[10:12] <vila> jam: can you seed rand_chars and guarantee you will get the same chars  ?
[10:12] <vila> jam: can you still haven't answer: "How would you debug it ?"
[10:12] <jam> vila: with 800 random characters I had 2 accidental successes in 30 runs
[10:13] <jam> vila: looking at the stream isn't a way to debug it, regardless.
[10:13] <jam> unless you know a way to debug a gzip stream
[10:13] <vila> Is that a way to say it can't be debugged ?
[10:13] <jam> especially a gzip(tar) stream
[10:13] <jam> vila: it can be "oh it isn't getting the data back properly, I must have missed something"
[10:14] <jam> but analyzing the data stream probably isn't the way to debug it
[10:15] <vila> then how about forgetting about the compressed stream and ensures we never corrupt it instead ?
[10:16] <jam> vila: we are corrupting the compressed stream
[10:16] <jam> how do we forget about it?
[10:16] <jam> 'bzr export -' is writing the stream to stdout, and we weren't setting the binary flag
[10:16] <vila> by using a mock compressor ?
[10:17] <jam> 'bzr export foo.tar.gz' was opening the output file without the binary flag
[10:17] <jam> vila: the bug was both in the command
[10:17] <jam> and in the individual code ptahs
[10:17] <jam> paths
[10:17] <vila> right
[10:17] <vila> and the issue is that it was corrupted because somewhere 'w' was used instead of 'wb'
[10:18] <jam> vila: if it was just the 'export -' we could put '\r\n' in the file content and 'plain_tar_export' it.
[10:18] <jam> vila: right
[10:18] <jam> plus the fact that GzipFile(mode='w') automatically sets 'wb'
[10:18] <jam> so we had 'w' before
[10:18] <jam> but we switched to GzipFile(open('w'))
[10:18] <jam> and ooops, it broke
[10:18] <vila> if you can't reliably inject a stream that would be corrupted because you don't control how it's transformed, I'm saying: control it
[10:19] <jam> vila: GzipFile is going to be python-version dependent, and possibly platform dependent
[10:19] <vila> indeed
[10:19] <jam> how do you want to control it, since we want to be testing the specific code path
[10:19] <jam> BzipFile happened to be ok, plain_tar_export was bad, GzipFile was bad
[10:19] <jam> ZipFile I think was ok
[10:20] <jam> I'd like to make sure that transforming the code paths in ways that look fine, still are actually fine
[10:20] <vila> 'make sure' != 1e10-17
[10:20] <jam> vila: osutils.rand_chars(65536)
[10:20] <jam> 10^-17 is sure for me
[10:20] <jam> if you prefer, I can make it
[10:20] <jam> 10^-999
[10:21] <vila> yeah, some japanese may disagree :-/
[10:22] <jam> vila: /me => lunch, bbiab
[10:23] <poolie> i've been feeling sad about that
[10:24] <jam> poolie: ?
[10:24] <jam> I didn't mean to go to lunch and make you sad :)
[10:25] <poolie> :) the Japanese disasters
[10:32] <poolie> hello inada-n, i hope you're doing ok
[10:34] <inada-n> hello, poolie.
[10:34] <inada-n> About earthquake?
[10:34] <poolie> yes
[10:34] <inada-n> I'm OK in Tokyo.
[10:35] <poolie> good
[10:35] <vila> good
[10:35] <inada-n> Thanks, a lot.
[17:12] <jml> goaeruaeos
[17:12] <jml> I have to figure this out every six months
[17:12] <jml> how to get a list of landings I've done on launchpad
[17:14] <vila> jml: some filtering from qlog maybe ?
[17:15] <jml> vila: ahh, never mind.  :-D
[17:18] <jml> vila: yeah, exactly like that
[17:19] <vila> good, I'm not suffering from Alzheimer then ;D
[17:19] <jelmer> hehe
[17:20] <vila> jelmer: I think you miss my msg yesterday about lp:~vila/ubuntu/lucid/bzr/sru-2.1.3
[17:20] <jelmer> vila: I think I might - what was it?
[17:21] <vila> jelmer: can you have a look at it (no urgency), there is a dirty trick in debian/watch but I filed bug #736145 about it
[17:22] <vila> jelmer: 2.1.4 will be released soon so it's just a warm-up to see if I get it right
[17:23] <jelmer> vila: what about https://launchpad.net/bzr/2.3 ?
[17:23] <jelmer> vila: it's only got the latest release, but that should be sufficient in our case
[17:23] <vila> EPARSE, what about 2.3 ?
[17:24] <vila> and what is your last remark about ? 2.1 or 2.3 ?
[17:25] <jelmer> vila: there is https://launchpad.net/bzr/2.1 as well
[17:25] <jelmer> vila: So in the watch file we can just use the series-specific page, which will always contain the latest release in that series. For debian/watch that's sufficient
[17:26] <vila> haaa, for watch file!
[17:26] <jelmer> vila: well, that /is/ what you were asking about.. :)
[17:26] <vila> jelmer: but these pages doesn't mention the tar.gz
[17:26] <vila> jelmer: but these pages don't mention the tar.gz
[17:26] <jelmer> vila: they do
[17:26] <jelmer> just check https://launchpad.net/bzr/2.1 or https://launchpad.net/bzr/2.3
[17:26] <jelmer> there's a link on the right hand side
[17:26] <vila> ooooooh !
[17:27] <vila> right, so for old stable series and as long as we are fast enough to keep track, yeah, far better than my dirty trick
[17:33] <vila> jelmer: otherwise, is this branch a good base for 2.1.4 ? AIUI the first line in changelog should mention lucid instead of UNRELEASED but the rest should be ok ?
[17:35] <vila> jelmer: or will 2.1.4 require a roundtrip via debian  (squeeze provides 2.1.2) ?
[17:35] <jelmer> vila: the version should be 2.3.1-0ubuntu1
[17:36] <vila> 2.1.3-0ubuntu1 you mean ?
[17:36] <jelmer> vila: (your version is not intended to be uploaded to Debian but to Ubuntu, in case of debian it would be 2.3.1-1)
[17:36] <jelmer> vila: sorry, yes
[17:36] <vila> ok
[17:37] <vila> 0 because 2.1.3-1 will come from debian and override it ?
[17:37] <jelmer> yes, exactly
[17:38] <jelmer> vila: it looks good to me otherwise
[17:38] <vila> ok, thanks !
[17:40] <jelmer> vila: one minor nitpick - maybe this is loggerhead's formatting - there should be one extra level of indentation for the + signs under "New upstream release"
[17:40] <vila> oh, not loggerhead
[17:41] <vila> the '+' should below the 'N'ew ?
[17:41] <jelmer> it should have one more space than the *
[17:41] <jelmer> so it should be below the space in the previous line
[17:41] <vila> ha no
[17:41] <vila> sry, was looking at wrong file
[17:42] <vila> yeah, below the sapce
[17:42] <vila> space
[17:44] <g0nzal0> hello #bzr
[17:45] <vila> hello  g0nzal0
[17:46] <g0nzal0> I'm using bzr 2.2.1 with the svn plugin (version 1.0.4)
[17:46] <g0nzal0> I'm trying to branch an svn repository, but said repository has a commit of a file named \
[17:47] <philsf> I forgot to add a part of a message to a commit. is there a simple way to edit a log? This is a simple versioned directory, not a remote branch, fwiw
[17:47] <vila> philsf: uncommit/commit if it's the last commit you did
[17:47] <g0nzal0> the svn plugin conveniently checks for this and raises an exception
[17:48] <g0nzal0> is there a way around that? I can't get a full copy of that svn repo with bzr otherwise :(
[17:49] <maxb> g0nzal0: Actually, I think the forbidding of backslashes in pathnames is done in the core of Bazaar
[17:50] <maxb> this means there's no way you can have such a file in a Bazaar branch, that you can work with using an unmodified copy of Bazaar
[17:51] <g0nzal0> maxb, yes it is (tried commenting out the check on the svn plugin and got an exception from bzr)
[17:51] <g0nzal0> magcius, the file is removed in the svn repo in a later commit
[17:52] <g0nzal0> *removed from
[17:52] <g0nzal0> I mean, maxb
[17:52] <maxb> I'm not sure that will help you
[17:53] <g0nzal0> it doesn't, bzr branch stops when it hits the commit that adds that backslash-named file :(
[17:54] <jelmer> g0nzal0: the best way to work around it is to "svnadmin dump" the repository, eliminate the backslash and reload it
[17:55] <g0nzal0> jelmer, ah, I don't think I have permissions to do that, but I can talk to the sysadmin and try that, thanks!
[17:56] <jelmer> g0nzal0: there is a bug report in bzr about this, but it hasn't seen much activity recently
[17:56]  * jelmer will be back later
[18:28] <cr3> hi folks, someone seems to have merged changes in from a branch and merged into trunk. now, the revno in the trunk is 30 numbers smaller than before, what might've happened?
[18:30] <beuno> cr3, they merged trunk into a branch and pushed that up to trunk
[18:31] <cr3> beuno: that resulted in lots of commits being conflated into one, might there be a way to revert that or do something reasonable about it?
[18:31] <beuno> I guess someone could push --overwrite
[18:31] <beuno> if they have trunk
[18:32] <cr3> beuno: yeah, "if they have trunk" is the problem, I just pulled from trunk so mine is reverted now :(
[18:32] <beuno> hm
[18:33] <beuno> not sure how to revert that easily
[18:33] <cr3> beuno: I'm about to take the last snapshot I had, reproduce the commits that were done previously and then try to push that. I expect that to be a lot of work, so looking for the quick fix
[18:34] <cr3> beuno: would the person that merged trunk into the other branch and pushed had to use --overwrite as well? ie, would bzr have provided somekind of warning to prevent this and required explicit action on the part of the user to proceed?
[18:39] <beuno> cr3, no, no --overwrite
[18:39] <beuno> you can, however, set a flag that won't allow this to happen again
[18:39] <beuno> append_only or something
[18:39] <beuno> I forget where to set it
[18:41] <cr3> beuno: sounds like a good lead, thanks so much!
[18:47] <philsf> vila: it was not the last commit. Can I uncommit/commit and still preserve the original revision number?
[18:53] <cr3> beuno: I found that I can add this line to .bzr/branch/branch.conf: append_revisions_only = True. however, not sure how I can commit that so it applies to everyone branching the project
[18:54] <beuno> cr3, that's a good question
[18:54] <beuno> maybe lifeless knows
[18:55]  * jelmer waves
[18:56] <beuno> heya jelmer
[18:56] <maxb> cr3: "commit" it? It applies to a particular copy of a branch, not a project.
[18:57] <maxb> Usually you would set it on the branches on a server that people share
[18:57] <maxb> Bazaar might copy it to new branches 'bzr branch'-ed from that - I'm not sure, you'd have to test.
[18:58] <maxb> cr3: Before you try to regenerate any commits manually: You really do not need to. No data has been lost. Bazaar has just been instructed to understand it differently?
[18:58] <cr3> maxb: I just tried locally: 1. created file .bzr/branch/branch.conf with append_revisions_only = True; 2. branched project to other directory; 3. looked at .bzr/branch/branch.conf in other directory: branch.conf does not get branched
[18:58] <maxb> cr3: Is this project public? It would be easier to explain with specific examples. If not, I can explain more generically
[18:59] <cr3> maxb: I managed to regenerate the data already and the diff (not bzr diff, just /usr/bin/diff) of my new branch and the one on the server seem the same now
[18:59] <maxb> cr3: However I would still advise you *NOT* to push --overwrite that
[19:00] <cr3> maxb: the project is public and, if you happen to have a moment, I wouldn't mind understanding how to resolve this kind of situation
[19:00] <maxb> We can fix your revnos without forcing everyone else to "pull --overwrite" and potentially have to replay their own local commits
[19:00] <cr3> maxb: really? why not?
[19:00] <maxb> I don't understand the "why not?" question
[19:00] <cr3> maxb: good point. although there are probably not that many people branching the project, I try to do things right when possible
[19:01] <maxb> Ok - give me the URL for the branch concerned, and I'll have a look
[19:01] <cr3> maxb: I meant "why not push --overwrite", but you answered before I hit enter :)
[19:01] <cr3> maxb: lp:checkbox
[19:01] <maxb> fetching..... meanwhile, have you used "bzr qlog" previously?
[19:02] <maxb> I find it an awesome tool for understanding revision graphs
[19:02] <cr3> maxb: the problematic revision is 864 and no, haven't used qlog before
[19:02] <maxb> yikes, that revision merged an awful lot of trunk changes, didn't it :-)
[19:02] <cr3> maxb: totally :)
[19:02] <cr3> maxb: about 30 revisions worth :)
[19:03] <cr3> well, 30 revisions based on difference of current revision in trunk and what it should be
[19:03] <maxb> OK, so here's how we go about restoring the "left hand" or "first parent" ancestry that determines revnos
[19:03] <maxb> First you branch lp:checkbox at 863
[19:04] <maxb> oh, sorry
[19:04] <maxb> I don't mean 863, 1 sec
[19:05] <maxb> hmm. We need to find the revision which was the tip of lp:checkbox which was before that erroneous merge was pushed
[19:07] <maxb> Ah, OK, so I think that was the current 862 "Merged from testsprint-checkbox-base-sru-changes."
[19:07] <maxb> Right, let me start again, and get the numbers right this time
[19:08] <cr3> maxb: I'll follow what you say in qlog
[19:08] <mgz> vila: that was my impression with rand_chars as well, but jam is right. provided that the (teeny) chance of the randomness working against us results in a spurious pass rather than a spurious failure, it's the best way to write that kind of test.
[19:08] <maxb> So, we branch from lp:checkbox 862, because that is the last revision that is part of the old mainline, which is still on the mainline.
[19:09] <cr3> maxb: why not 863?
[19:10] <maxb> Having looked at the history, it looks to me like the "bad" merge was an attempt to land the revision which is currently 863 on trunk
[19:11] <maxb> More importantly, 863 is diverged from the long string of revisions which we want to put back on the mainline
[19:11] <cr3> maxb: exactly, now I understand where you're getting at
[19:11] <maxb> OK, so having done that, for the sake of illustration, you might choose to turn on append_revisions_only = True in the local branch
[19:12] <maxb> then we're going to pull, not merge, r862.2.31 of lp:checkbox
[19:13] <maxb> (and yes, we could just have branched that directly - this was either my mistake or a fortuitous illustration of exploring the history)
[19:13] <maxb> :-)
[19:14] <maxb> After that, we *merge* the formerly "bad" merge commit - i.e. we 'bzr merge -r 864 lp:checkbox'
[19:14] <cr3> maxb: I'm doing bzr branch -r862 lp:checkbox then bzr pull -r862.2.31 lp:checkbox, right? I'm waiting for the first branch to finish, this is taking a while unfortunately
[19:14] <cr3> aha, after that pull, I get: Now on revision 893.
[19:14] <cr3> which is sounding very sane!
[19:15] <maxb> And commit that with a message of something like "Land translation work by Mahyuddin Susanto via Michael Terry."
[19:15] <cr3> maxb: you didn't forget 863, right?
[19:15] <maxb> No, this is intentional - the one merge is going to pull in 863 & 864
[19:16] <cr3> of course, my bad :)
[19:16] <maxb> Once you've done this commit, you are back in the rough "shape" of the tree that you wanted to have kept all along
[19:17] <cr3> maxb: this is amasing, really!
[19:17] <maxb> The remaining thing is to merge (one by one if you want to preserve their mainline revnos in full) the remaining commits. Fortunately in this case there is only one.
[19:17] <cr3> maxb: Thanks so much for taking the time to explain this to me, I'm keeping this irc log and framing it somewhere :)
[19:17] <maxb> So, "bzr merge -r 865 lp:checkbox" (or for that matter just "bzr merge lp:checkbox")
[19:17] <maxb> And commit
[19:18] <maxb> and we're in our final desired state. Only thing remaining is to then push back to lp:checkbox - *without* --overwrite
[19:18] <cr3> makes perfect sense
[19:18] <cr3> excellent, so my contributors will not need to pull --overwrite themselves. win!
[19:19] <maxb> To prevent it happening again, you can enable append_revisions_only on the Launchpad copy of the branch
[19:20] <cr3> maxb: how can I ssh/scp/ftp there again?
[19:20] <cr3> I once accessed the server to rm branches but that was a very long time ago
[19:21] <maxb> If your local bzr is new enough, you can just run "bzr config -d lp:checkbox append_revisions_only=True"
[19:22] <maxb> um
[19:22] <maxb> wait a moment, I think that may not work
[19:23] <maxb> bzr config -d bzr+ssh://bazaar.launchpad.net/+branch/checkbox append_revisions_only=True
[19:23] <maxb> owing to a bug in current bazaar, you need to not use the lp: shortcut here
[21:42] <philsf> I forgot to add a part of a message to a commit. is there a simple way to edit a log? This is a simple versioned directory, not a remote branch, fwiw. it was not the last commit. Can I uncommit/commit and still preserve the original revision number?
[23:22]  * jelmer waves to spiv
[23:26] <poolie> hi all
[23:27] <jelmer> poolie: g'day
[23:27] <poolie> hi jelmer
[23:28] <poolie> jam, still around?
[23:31]  * spiv waves back
[23:33] <jelmer> spiv: Why do we never store directory service URLs but always resolved URLs? Is it since the way a directory service resolves a URL might differ per user?
[23:34] <spiv> jelmer: I think it's just by accident, rather than design
[23:34] <spiv> I'm pretty sure there's a bug or two about how we should store unresolved directory service locations.
[23:35] <jelmer> spiv: I was looking at one of the bugs that the linaro folks were hitting, where we are calling urlutils.normalize_url() on a URL that can contain e.g. "lp:bzr"
[23:35] <spiv> There is a bit of an issue that directory services might resolve differently, or even be not present at all, for different users.
[23:36] <spiv> So I guess if we start storing them we should take care to handle that gracefully
[23:36] <spiv> I wouldn't want my bzr to crash with a traceback just because someone else's branch I access has a parent_location with a custom directory service URL.
[23:37] <jelmer> right, that makes sense
[23:38] <jelmer> spiv: so I guess then a related issue is: is "lp:bzr" something that urlutils should handle gracefully?
[23:38] <spiv> Hmm
[23:38] <spiv> We're really mixing different types of variable
[23:38] <jelmer> On the one hand it would be a nice solution here, but I'm worried about misinterpreting what could be a proper URL with an entirely different meaning
[23:38] <jelmer> yeah
[23:39] <spiv> "URL" and "location" might be good names for those types, if we had statically typed variables.
[23:39] <spiv> Or "URL" and "BRL" ;)
[23:40] <spiv> So in my ideal world, we'd never all normalize_url on something that isn't a proper URL
[23:40] <jelmer> your ideal world has URLs ? :-P
[23:41] <spiv> But we sometimes use them interchangeably, although sometimes not (the CLI isn't consistent about what it accepts)
[23:41] <spiv> s/all/call
[23:43] <spiv> To be pedantic, strictly speaking I didn't imply my ideal world would have to have URLs ;)
 jelmer: I think it's just by accident, rather than design <-- i agree
[23:45] <spiv> Anyway, given we mix URLs and not-quite-URLs quite a bit now, we have two options that I can see:
[23:46] <spiv> 1) make functions like normalize_url that expect URLs also cope with not-quite-URLs
[23:47] <spiv> 2) try to be stricter about not using not-quite-URLs interchangeably with URLs
[23:47] <spiv> Maybe there are other options.
[23:47] <poolie> i think 'lp:' is a proper url
[23:47] <poolie> or 'should be treated the same'
[23:49] <spiv> Or another way to look at it perhaps is: why is linaro calling normalize_url?  Is it because they really want "normalize_location" and that's the closest we have?
[23:49] <jelmer> spiv: This is the stacked-on argument to cmd_push()
[23:49] <spiv> Ah, right.
[23:50] <spiv> So, essentially, yes :)
[23:50] <jelmer> spiv: yes, indeed
[23:50] <spiv> I don't feel strongly about which route we should take, but I do feel strongly that the current situation is a problem :)
[23:50] <jelmer> :)
[23:51] <jelmer> I think in the short term it would probably make sense to do the directory lookup in cmd_push for --stacked-on, as it's consistent with how we treat directory URLs in other places.
[23:52] <lifeless> there is a bug on directory lookups in push :parent as well IIRC
[23:52] <lifeless> so you'dfix more than one bug :>
[23:52] <lifeless> sorry, I mean, while you're there consider doing more ;)
[23:53] <spiv> I was about to say, I'm not sure that's the same bug (although I'm sure it's related)
[23:55] <jelmer> is :parent a directory as well? It seems odd that it breaks in that case, as "bzr push lp:foo" works
[23:58] <lifeless> jelmer: it needs to double dereference
[23:59] <lifeless> jelmer: when :parent returns lp:foo it breaks
[23:59] <jelmer> lifeless: ahh


[12:17] <danilos> gmb, I've been going through emails and only now I noticed gary and others won't be around today :)
[12:17] <danilos> gmb, so, we can go and have some wild partying instead of hanging around here :P
[12:18] <gmb> danilos: Sounds like a plan to me :)
[12:28]  * gmb -> lunch
[17:44]  * danilos -> off, tty tomorrow


[00:00] <LaserJock> and there are a lot of discussions, I usually find it very hard to pick which ones to go to as there are many at the same time
[00:01] <LordMetroid> I've never been to a summit before, I really need to get out and meet people more.
[00:02] <LordMetroid> And I would be going through Denmark, Germany, France having fun and sampling the culture and cuisine once again
[00:02] <LaserJock> yeah, if you can afford to go it's a great experience
[00:31] <mdke> can we upload to karmic?
[00:32] <LaserJock> mdke: I don't think so yet
[00:32] <mdke> will things be held in a queue or just rejected?
[00:32] <mdke> (I see a few things on karmic-changes but maybe those are exceptional
[00:34] <kees> mdke: the toolchain is still being finalized
[00:34] <LaserJock> mdke: I suppose you could give it a shot, but generally we do wait until the toolchain is up and working
[00:36] <mdke> ok, fair enough
[00:36] <mdke> I'll keep my releases in bzr only for a bit :)
[01:53] <cjwatson> mdke: feel free to upload; they'll be held in a queue
[02:14] <cjwatson> infinity: debootstrap 1.0.13 is on its way in now, with karmic support
[02:19] <LordMetroid> karmic support?
[02:20] <cjwatson> yes
[02:20] <LordMetroid> What does that mean...
[02:20] <cjwatson> the next Ubuntu release will be called "Karmic Koala"
[02:20] <cjwatson> its codename, that is
[02:21] <LordMetroid> I know, but for debootstrap to support karmic, what does that mean.
[02:21] <LordMetroid> I don't find anything through google about that...
[02:21] <cjwatson> debootstrap needs to have explicit support for each release it might be asked to install
[02:22] <cjwatson> in this case, it's pretty trivial, just a symlink
[02:22] <LordMetroid> ohh, nice
[02:22] <cjwatson> I'm not sure why google would be helpful here
[02:23] <cjwatson> we have to do a bunch of stuff like this when opening each new release; it's pretty routine
[02:23] <LordMetroid> I've never been all that involved in the development of a release
[02:23] <LordMetroid> I managed to scratch the surface but I have no idea where to go to get really involved
[02:23] <LordMetroid> See what is happening and all
[02:24] <cjwatson> http://wiki.ubuntu.com/NewReleaseCycleProcess is what we have to do to get each new release ready for developers to contribute
[02:24] <LordMetroid> I subscribe to the announcements mailing-list(though an announcement is only made every month or so unless they want to say, please do 5 a day)
[02:28] <cjwatson> LordMetroid: http://launchpadlibrarian.net/25947235/debootstrap_1.0.12_1.0.13.diff.gz has some other changes as well, but the relevant change for this is right at the bottom
[02:28]  * cjwatson -> bed
[02:29] <LordMetroid> nigh cjwatson
[02:29] <LordMetroid> *night
[04:19] <jdong> tjaalton: are you familiar enough with the vmmouse driver to play "crack or not crack" with me? :)
[04:19] <jdong> so the problem is, it seems like modern vmware+vmmouse, when you click down the mouse it sends ButtonDown, MotionEvent(0px or 1px), ButtonUp
[04:20] <jdong> this combination of events causes a drag to be interpreted.
[04:20] <jdong> often times this means right-clicking for a context menu automatically selects the first thing
[04:21] <jdong> (it interprets it as you right-clicked, dragged to the first item, then let go)
[04:21] <jdong> now... how to correctly work around this?
[04:21] <jdong> I tried a simple one-liner that disallows posting both a move and a button change event at the same time, and it's pretty effective but not perfect
[04:22] <jdong> still even a miniscule move of the mouse while clicking gets caught as a drag.
[04:22] <jdong> would implementing a couple millisecs of time awareness into a buttondown in which motion events are discarded be insane?
[04:43] <bryce> jdong, have you tried 12.6.3?
[04:43] <jdong> bryce: I stole a tarball from Debian Sid whatever that version is
[04:43] <jdong> yeah 12.6.3
[04:43] <jdong> same bug persists
[04:44] <jdong> holding the mouse as still I I can, clicking always generates a down, move, up event.
[04:45] <bryce> jdong, hrm
[04:45] <bryce> jdong, have you talked with upstream about this?  I've been exchanging emails with philip langdale the past couple days on vmmouse
[04:45] <jdong> it might be my host (VMware fusion 2.0.2)
[04:45] <jdong> but in any event IMO the guest mouse driver shares some responsibility in filtering out nonsense and making it behave more like a mouse.
[04:46] <jdong> and no, I haven't had contact with upstream
[04:46] <bryce> fwiw I'm considering merging up a backport of vmmouse for jaunty...
[04:46] <jdong> if you're in regular contact with them and want to poke this issue to them too, it'd be well appreciated
[04:46] <bryce> however if it's too buggy
[04:46] <jdong> it'll require a bit of packaging changes (conflicting mdetect), other than that so far it looks good here
[04:46] <bryce> no, I don't really have the time to do a lot of troubleshooting (I never use vmware myself)
[04:47] <bryce> but if you work with them and get a patch, I'd be open to including it in the backport
[04:47] <jdong> ok
[04:47] <bryce> I can put you in contact with philip if you'd like to bypass the usual process
[04:48] <bryce> er, "directly"
[04:48] <jdong> that'd be cool
[04:48] <bryce><EMAIL_ADDRESS>?
[04:48] <jdong> yep
[04:51] <bryce> jdong: ok, start a bug and give me the bug # and I'll include it in the email
[04:59] <jdong> bryce: bug 366521
[05:00] <bryce> awesome, thanks
[05:00] <jdong> sure thing
[05:00] <jdong> yeah interestingly in this xev capture, it raised a completely null MotionNotify event...
[05:00] <jdong> i.e. motion to the exact same coordinate as the buttonpress one.
[05:00] <jdong> that's clearly wacky behavior ;-)
[05:01] <bryce> email sent
[05:01] <jdong> thanks
[05:01] <bryce> hopefully it'll be something simple :-)
[05:02] <bryce> for some reason I have a sinking fear it is due to something busted in xserver
[05:03] <jdong> yeah I'm not sure exactly what the physical mice drivers do
[05:03] <jdong> but it's always nailed the differecne between a click vs click-drag for me
[05:03] <jdong> but vmmouse is kinda ridiculous
[05:03] <jdong> right now EVERY click is a click-drag
[05:03] <jdong> and with my one-liner hack if you even BREATHE on the mouse it turns into a drag.
[05:03] <jdong> I've seen a bit of mailing list banter on QT's list about this
[05:04] <jdong> it in fact is bad enough that their click-to-sort table widgets don't work with vmmouse
[05:04] <bryce> you know, the symptoms you've described I had seen myself, although only with firefox, and it's long since gone away so I'm sure it' sunrelated...
[05:04] <bryce> heya andresmujica
[05:04] <jdong> but QT folks adopted a very novel approach by claiming MotionNotify is for "logical motion"
[05:04] <jdong> (aka it's not our problem fix it elsewhere)
[05:04] <bryce> in any case, if nothing else I sympathize with how irritating it is
[05:04] <jdong> haha thanks :)
[05:05] <jdong> it's crazy I'm the only one who's complained about it so far
[05:05] <jdong> not many people run Ubuntu in VMWare it seems
[05:05] <bryce> I think a lot of people moved from vmware to kvm
[05:05] <jdong> (at least not a GUI)
[05:05] <bryce> I used to get lots of bugs about ubuntu+vmware, pre-kvm
[05:06] <jdong> yeah, if I'm on a Linux host I'll jump to KVM first
[05:06] <jdong> but on this hardware OS X is the best native platform (the one that gives me least grief setting up)
[05:06] <jdong> so it'd be nice if I can run a couple Ubuntu instances
[05:09] <calc> jdong: i use vmware with ubuntu
[05:09] <bryce> heya calc
[05:10] <jdong> calc: do you get the crazy mouse symptoms I see here?
[05:10] <calc> jdong: i haven't noticed any problems with it yet with 6.5.2 other than the keyboard issue (it might be fixed for 6.5.2 i had to fix it in 6.5.0)
[05:10] <jdong> calc:  a quick and dirty test: gnome-terminal, do a dmesg
[05:10] <calc> hmm let me see
[05:10] <jdong> calc: then do a single left click on any leftover blankness of a line of output
[05:10] <jdong> see if the entire blank area gets selected.
[05:10] <jdong> or better yet, xev, click the mouse and see how many events fire
[05:11] <calc> ok
[05:11] <jdong> should just be down then up
[05:11] <jdong> I get down, motion, up.
[05:11] <calc> only one press/release when i hit a button
[05:11] <calc> hmm let me try a few more times
[05:11] <jdong> calc: interesting, perhaps it's VMWare Fusion specifically that is implicated.
[05:12] <jdong> I did mention in my bug report it was on Fusion
[05:12] <calc> i get notify events if i click inside the black square but only press/release for the other area
[05:12] <calc> i am not completely up to date 9.04 in my vm though
[05:13] <jdong> hmm
[05:13]  * calc does an update and sees what it does
[05:13] <calc> also i'm running amd64
[05:13] <jdong> yeah this is 64-bit Ubuntu in my VM too
[05:13] <jdong> it's probably that your parent X server "numbs" motion events while clicking for you.
[05:14] <jdong> I'm betting OS X does use the GUI toolkit abstraction layer to weed out nonsense drags
[05:14] <jdong> I can imagine drag filtering being incredibly annoying to a graphics designer or a leet gamer.
[05:14] <calc> ah maybe so, i'm running 9.04 amd64 -> vmware -> 9.04 amd64
[05:14] <jdong> right, I suspect the parent X server's mouse driver is playing a role
[05:15] <calc> well when i click i'm not making any motion at all
[05:15] <jdong> nor am I attempting to do so
[05:15] <calc> i'm using a laptop so its simply a keypress and that is all
[05:15] <jdong> in my testing above the mouse is off the table (optical)
[05:15] <calc> ah ok
[05:15] <jdong> and the Motion event is for the exact coordinate of the click :)
[05:15] <jdong> which makes it even more idiotic
[05:16] <calc> heh
[05:17] <calc> hmm apparently the servers are so loaded its causing even approx to hang for me, ugh
[05:19] <jdong> oh it's not a fun day at all in archive land :)
[05:21] <andresmujica> hi bryce!
[05:21] <andresmujica> hi all
[05:22] <bryce> andresmujica: o/
[05:33] <infinity> cjwatson: Yay, thanks.
[05:34] <infinity> cjwatson: I'll update the livefs stuff and triple-check that it works sometime early in the weekend, so I can sleep soundly for the rest of the weekend knowing that my "new release" work is more or less done. :)
[09:19] <LordKow> whom/where would i file ubuntu wiki bugs at? https://wiki.ubuntu.com/DebootstrapChroot does not work for jaunty. i believe it has to do with the fact that recommends are now installed by default. if you follow the how to exactly as it describes then you are left with a broken chroot env
[09:21] <mdke> cjwatson: thanks for the info
[10:01] <jpds> LordKow: Well, it's a wiki - so you can do so yourself, but you can look at who did the previous edits for advice.
[10:03] <LordKow> jpds: ah i see. i thought maybe the wiki was a little more controlled than that. im not just going to edit it... maybe there is some sort of commenting feature i can utilize.
[10:04] <joaopinto> LordKow, how is it broken, what problem are you getting ?
[10:06] <jpds> LordKow: Yes, there's a 'Comment for this edit:' field.
[10:06] <LordKow> joaopinto: 'apt-get install wget debconf devscripts gnupg nano  #For package-building' when installing devscripts it wants to install dbus which will most definitely not work in a chroot. apt errors out in the dbus postinst script when it tries to start the service. and then it errors out again when trying to remove it (prerm script)
[10:08] <LordKow> im not really sure why devscripts needs dbus in the first place. im guessing there is a dep that maybe (incorrectly?) depends on dbus... i can't see how any devscript or any of it's deps would need dbus. that is a pretty rich package though so i could be missing something.
[10:10] <joaopinto> LordKow, you will need apt-get install --no-install-recommends ...
[10:11] <joaopinto> LordKow, it does not depend on dbus, it's a "recommends" relation
[10:13] <LordKow> joaopinto: ah okay. so it was between intrepid and jaunty release that ubuntu went with the install recommends by default (following debian guidelines)?
[10:13] <joaopinto> I believe it was during intrepid
[10:16] <LordKow> joaopinto: perfect, --no-install-recommends took care of it. now it should be passed along to the wiki page which im working on figuring out right now
[10:24] <LordKow> joaopinto, jpds: thanks for the help
[15:17] <rjune_> Where can I find some short examples on how to work with libapt-pkg?
[16:29] <PingJocky> Quick one... Is there a different Kernel Between ubuntu and ubuntu NBR in 9.04?
[16:30] <Nafallo> no
[16:30] <PingJocky> thanks!!! i have been looking everywhere for that
[16:31] <PingJocky> something aint right with the ACPI and my eeepc 1000 isnt chrging
[16:32] <PingJocky> Ill submit a bug report and roll it back to 8.10 with the array kernel
[17:48] <larsivi> I have to ask - why is Ubuntu 9.04 released with a dysfunctional intel xorg driver?
[17:49] <LaserJock> larsivi: basically because it was the best we got
[17:50] <larsivi> LaserJock: I understand the complications of package and kernel dependencies, but there has been a constant regression since 8.04 meaning that maybe keeping with some older versions would have been a better compromise
[17:51] <LaserJock> larsivi: except there's problems matching Xorg and driver versions I believe
[17:51] <LaserJock> larsivi: I don't know that the old driver on newer Xorg worked any better
[17:52] <larsivi> LaserJock: so then one could have opted for an older Xorg too
[17:52] <larsivi> Am I wrong in thinking that most users have intel cards?
[17:52] <calc> larsivi: at least as far as 2.4 vs 2.6 goes they both suck in different ways according to the phoronix performance tests anyway
[17:52] <LaserJock> larsivi: which would have caused problems for everybody else
[17:52] <LaserJock> larsivi: yes, you are
[17:52] <LaserJock> larsivi: I think anyway there are more nvidia/ATI out there presently, I could be wrong though
[17:52] <calc> LaserJock: "most" is true but not an overwhelming majority
[17:53] <calc> intel has by far the majority marketwide... not sure about ubuntu users specifically
[17:53] <larsivi> calc: I wasn't suggesting a 2.4 kernel :P
[17:53] <LaserJock> calc: more intel than everything else combined?
[17:53] <calc> larsivi: i'm talking about intel driver version number
[17:53] <larsivi> calc: hehe, ok :)
[17:53] <calc> LaserJock: not to that extent but iirc its over 40% intel (maybe 50%)
[17:54]  * calc looks at the data again
[17:54] <LaserJock> calc: yeah, I could believe that
[17:54] <LaserJock> my point was that holding Xorg back is not an easy decision
[17:54] <calc> http://jonpeddie.com/press-releases/details/computer_graphics_chip_shipments_dive_in_q4_08_according_to_jon_peddie_rese/
[17:54] <LaserJock> especially if you think the -intel drivers are going to be better than they were
[17:54] <calc> intel has 47.8% according to that site for shipments for 2008
[17:55] <LaserJock> calc: well, on new machines sure
[17:55] <calc> 47.8% for Q42008, was 49.4% 2008Q3
[17:55] <LaserJock> calc: I was just thinking of all our users out there, I'm guessing quite a few still have nvidia/ATI
[17:55] <LaserJock> there are quite a few machines still being used form before Intel was even really in the market
[17:56] <LaserJock> *from
[17:56] <calc> LaserJock: yea for Ubuntu users specifically the makeup may be different but Intel has been at ~ 50% for many years
[17:56] <larsivi> anyway, this appears to have been known for quite some time (more than 6 months), so I find it a bit curious that those that can (Canonical?) haven't spent more resources on it
[17:56] <calc> nvidia seems to actually be losing marketshare as time progresses
[17:57] <LaserJock> larsivi: I think pretty much all who could, did what they could
[17:57] <calc> and ! (AMD/Intel/Nvidia) percentage-wise is just noise
[17:57] <LaserJock> larsivi: we had several testings of different options, it just seemed like every change would help some but not others
[17:58] <calc> according to the numbers for laptops (where most Intel IGP is used anyway) the numbers are actually ~ 60% for Intel
[17:58] <LaserJock> larsivi: http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/ might be a good read
[17:59] <larsivi> LaserJock: in 8.10 things were slow for me (couldn't use desktop effects), but now it is close to unusable (although desktop effects are fast enough now) due to graphical glitches and absurd cpu usage
[17:59] <larsivi> LaserJock: I follow the xorg mailing list
[18:00] <LaserJock> larsivi: right, so helping the Ubuntu X team and upstream to figure out why you're having problems is probably worthwhile
[18:00] <LaserJock> larsivi: for me 8.10 was just fine, 9.04 I get GPU lockups when using desktop effects
[18:00] <LaserJock> such is life sometimes :/
[18:01] <calc> LaserJock: i think part of the reason we see more non intel users on Ubuntu is due to them being power-users and thus willingly to pay more for the nvidia binary only drivers :-\
[18:01] <LaserJock> calc: surely there are a lot of people using older machines though too
[18:02] <LaserJock> calc: I only have one machine with an Intel card because most of my machines were built before Intel was commonplace
[18:02] <larsivi> LaserJock: yeah, I have put forth my information in the relevant places
[18:03] <calc> perhaps that is true for very old machines < 8 years old
[18:03] <LaserJock> calc: ?!
[18:03] <calc> intel has dominated the graphics market since probably shortly after i810
[18:03] <calc> er > 8 years old (over i used the wrong symbol)
[18:03] <LaserJock> calc: I only really started to see them ~ 2 years ago
[18:04] <calc> LaserJock: a lot of marketshare is in business desktops which has used integrated intel graphics nearly forever
[18:05] <LaserJock> calc: ah, that'd make sense
[18:06] <calc> in 2005 it appears intel had somewhere ~ 35% market share with ati taking second place at 24%
[18:06] <LaserJock> larsivi: anyway, yeah, -intel suckage is kind of a known thing, but it wasn't for lack of trying to get something better
[18:06] <calc> roughly the same in 2006
[18:07] <LaserJock> calc: good grief, really? I'd never heard of an intel graphics card until probably 2007
[18:08] <LaserJock> or wait, 2006 maybe
[18:08] <LaserJock> darn, had it been *that* long since Dapper?! :/
[18:08] <calc> 2004 mobile market intel had 40% (the 2005/2006 numbers were for desktop above)
[18:09] <larsivi> I have the 965 now, before that the 915 which I bought in a laptop early 2005
[18:09] <highvoltage> hey LaserJock
[18:09] <larsivi> the 915 came a long time after the 810 stuff
[18:10] <larsivi> LaserJock: so assume that 40% of ubuntu users have intel graphics cards, and maybe half of those experience issues, that would mean that 20% of jackalope users would have issues with it that are obvious and easy to notice - that is a blocker in any other software
[18:10] <calc> it looks like 2003 overall share intel had ~ 32%
[18:10] <calc> with ati at 25%
[18:12] <LaserJock> larsivi: yeah, but there wasn't much that could be done unfortunately
[18:12] <LaserJock> larsivi: hopefully 9.10 will be *much* better on that front
[18:13] <larsivi> LaserJock: no offense meant, but that is bullshit - that is a fix to delay a release for
[18:13] <calc> overall we need to do what our users require and using hwdb to track that would be useful :)
[18:13] <LaserJock> larsivi: for how long?
[18:14] <LaserJock> larsivi: the problem isn't even really known as far as I know (I'm not an X expert by any means)
[18:14]  * calc thinks the current ubuntu user breakdown would have lots more ati/nvidia than the overall marketshare numbers would otherwise indicate
[18:14] <larsivi> LaserJock: I would have lost my job 10 times if I had released software that didn't work for 20% of the users
[18:14] <LaserJock> larsivi: I don't think there's any gaurantee that with a delay of even a month or two that things were going to be much better
[18:14] <LaserJock> larsivi: it's not our software, it's Intel's and Xorg's
[18:15] <larsivi> but ubuntu pick it
[18:15] <sistpoty> maybe there'll be updates?
[18:15] <LaserJock> larsivi: we could have decided to not ship an -intel driver, yes
[18:15] <larsivi> now I'm a private user, so I may not switch, but as a commercial user I would have dropped Ubuntu over this issue
[18:16] <LaserJock> sistpoty: hopefully
[18:17] <LaserJock> it'd really be nice to get things better for sure
[18:17] <sistpoty> larsivi: I assume as a commercial user you wouldn't run jaunty right after its release, but maybe go with hardy instead?
[18:18] <larsivi> sistpoty: that is a point, but for the desktop I don't find the LTS that important
[18:18] <sistpoty> *shrug*, was just a guess
[18:20] <larsivi> when that is said, as a proffesional user I actually find it a bit problematic that python haven't been upgraded to 2.6
[18:20] <LaserJock> larsivi: you mean in 8.04?
[18:21] <larsivi> LaserJock: yes - sorry for confusing matters a bit
[18:23] <LaserJock> yeah, adding a whole new python version isn't really -updates territory
[18:26] <larsivi> anyway - will leave you with my bile for now :P
[18:27] <LucidFox> When is karmic development going to start?
[18:42] <calc> LaserJock: i think larsivi didn't get the fact that he would have to drop all Linux shipped ~ 2009 to avoid this intel problem
[18:42] <calc> LaserJock: already has
[18:42] <calc> LaserJock: the toolchain is being worked on now
[18:51] <LaserJock> calc: right, yeah, I guess the perception is that we just picked the wrong version and that's it
[18:52]  * calc read the keithp post, sounds good going forward
[18:52] <calc> hopefully no one decides to rewrite xorg again next month :\
[18:53] <calc> LaserJock: fortunately places like phoronix have made it clear that there wasn't really a choice
[18:59] <LordMetroid> Do the UDS cost anything to attend?
[18:59] <[reed]> no, they are free... of course, travel is yours to pay unless you get sponsored
[19:00] <[reed]> LordMetroid: https://wiki.ubuntu.com/UDSKarmic
[19:00] <LordMetroid> thanks
[19:06] <ScottK> jcastro: Thanks for the link to the Intel video blog post.
[19:07] <ScottK> I'd feel better if he'd mentioned UXA is pretty unstable for a lot of people and they were fixing that.
[19:08] <Nafallo> hmm. UXA is the thing that made compiz eat my memory I think :-)
[19:17] <LucidFox> calc> Ah, I see... https://edge.launchpad.net/ubuntu/karmic
[19:17] <LucidFox> What I meant was, when is it going to be unfrozen?
[19:17] <LucidFox> https://wiki.ubuntu.com/KarmicReleaseSchedule has April 30 as "toolchain uploaded"
[19:19] <LaserJock> LucidFox: the toolchain is being worked on right now
[19:20] <LucidFox> Yes, I realize this :)
[19:23] <ScottK> LucidFox: When it's ready.
[19:23]  * LucidFox nods
[19:23] <ScottK> LucidFox: You can upload stuff now, it'll just get held until the archive opens.
[19:55] <LordMetroid> This is ridiculus
[19:56] <LordMetroid> Ubuntu has only gotten slower and slower, now gedit is even unable to render the characters at the same moment I type them.
[19:57] <LordMetroid> This problem needs to be addressed or is Ubuntu only intended for high end computers...
[19:58] <rendero> hello, what changed since kernel 2.6.28, because i cannot establish a ppp <-> nas interface and connect to internet anymore
[20:00] <LordMetroid> They replaced the kernel with Ms code
[20:05] <mneptok> LordMetroid: do you have Compiz enabled? if so, disable it.
[20:05] <LordMetroid> Nope
[20:05] <mneptok> LordMetroid: what does (h)(a)top say?
[20:07] <LordMetroid> (h)(a)?
[20:07] <mneptok> htop atop
[20:07] <mneptok> choose yer poison
[20:08] <LordMetroid> brb, installing one of them
[20:10] <mneptok> LordMetroid: before you join a developer channel and rant about the lack of quality and performance problems, using basic tools to actually check your own machine is a best practice.
[20:11] <LordMetroid> I have run top
[20:11] <mneptok> and?
[20:12] <mneptok> what process is utilizing the most CPU cycles?
[20:12] <LordMetroid> X.org
[20:12] <mneptok> and what video chipset and grpahic driver are you using?
[20:13] <LordMetroid> An ATI Radeon Mobility 7600
[20:13] <mneptok> and whose driver?
[20:13] <LordMetroid> X is occupying like 40%
[20:13] <LordMetroid> The default from installation
[20:16] <mneptok> alt-F2
[20:16] <mneptok> metacity --replace
[20:16] <mneptok> restart X
[20:24]  * mneptok whistles the "Jeopardy!" theme
[20:33] <mneptok> cr3!
[20:41] <cr3> mneptok: hey dude!
[20:43] <mneptok> cr3: our final weekend in .qc, we leave on Tuesday. got back from the MySQL conf @ 3am last night. :(
[20:43] <cr3> mneptok: sounds painful, where was the conf?
[21:02] <mneptok> cr3: Santa Clara
[21:02] <mneptok> (Silicon Valley)
[21:21] <Julieh_> ipoo
[21:21] <Julieh_> suck my dick
[21:21] <Julieh_> -.-
[21:50] <LordMetroid> I figured it out, subpixel rendering is the demon in this...
[21:51] <mneptok> no, your video driver is
[21:51] <mneptok> subpixel smoothing works just fine on my Intel chipset
[22:00] <LordMetroid> Turning off subpixel rendering on the text solved it though
[22:30] <Amaranth> LordMetroid: VBGR?
[22:31] <LordMetroid> VBGR?
[22:31] <LordMetroid> RGB
[22:31] <Amaranth> Ok then, something is wrong with your driver
[22:32] <Amaranth> Although even a CPU from the time that GPU came out should be able to do subpixel rendering without using 40% CPU
[22:32] <LordMetroid> hm
[22:32] <Amaranth> Unless you have that GPU but a 500Mhz CPU or something :P
[22:32] <LordMetroid> I got a 2.4GHz P5
[22:32] <LordMetroid> *p4
[22:33] <LordMetroid> mobile variant(if there is such)
[22:33] <Amaranth> You should be able to do full software rendering without using 40% CPU then as long as you aren't trying to use compiz :P
[22:34] <Amaranth> LordMetroid: Try with the vesa driver
[22:34] <LordMetroid> how do I change?
[22:34] <Amaranth> LordMetroid: edit your xorg.conf
[22:34] <LordMetroid> xorf.conf is empty
[22:34] <Amaranth> LordMetroid: If it doesn't chew CPU with vesa the bug is in the radeon driver
[22:34] <Amaranth> LordMetroid: dexconf then
[22:35] <Amaranth> LordMetroid: Did you file a bug, btw?
[22:36] <LordMetroid> Yes, I have, https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/366224
[22:36] <Amaranth> yeah, that bug is going to be the driver
[22:39] <LordMetroid> restarting the X server to see if it take effects
[23:25] <afflux> could someone explain why ubuntu does not ship static versions of libgcj? I couldn't find info on that...
[23:27] <dtchen> bug 448789
[23:27] <dtchen> debian 448789
[23:27] <afflux> thanks
[23:33] <directhex> afflux, why is static linking desired? debbuntu generally relies on a "include things only once" rule, which is pretty dynamic-linking-reliant
[23:34] <afflux> directhex: I thought it was common to include .a files in -dev packages. In this case I need them for a work project, so I'll go rebuilding gcj.
[23:37] <directhex> directhex@desire:~$ apt-file search -x \\.a$ | cut -f1 -d':' | sort | uniq | wc -l
[23:37] <directhex> 2354
[23:37] <directhex> some packages do
[23:38] <afflux> I agree


[12:06] <LinDol> hi all
[12:09] <darkxst> hi LinDol
[12:09] <darkxst> did you see my message about translating slideshow to Korean?
[12:09] <darkxst> would be great if you can do it
[12:09] <LinDol> oh. i see your message
[12:10] <LinDol> but, I can not translate it. because I am still learning english.
[12:11] <darkxst> LinDol, ok, bu
[12:11] <LinDol> :)
[12:12] <darkxst> but don't know of any other Korean translators on our teams
[12:12] <LinDol> ah.
[12:12] <darkxst> as always you can get help with english here, except I am off to bed now, some other time
[12:16] <LinDol> ;)
[12:16] <LinDol> what is your time?
[12:17] <darkxst> LinDol, 11pm
[12:17] <LinDol> here is 9 p.m
[12:20] <LinDol> um I check
[12:20] <LinDol> ubiquity-slideshow-ubuntu packed now, so this package is managed by ubuntu korean translator group.
[12:21] <darkxst> LinDol, yes, but they have not translated the ubuntu GNOME version
[12:21] <LinDol> Ah..
[12:21] <darkxst> LinDol, perhaps you can talk with them about it ;)
[12:22] <LinDol> so when should we finish to translate to other language?
[12:23] <LinDol> how many do we have a time?
[12:24] <darkxst> LinDol, I think April 9th is the deadline for translations
[12:31] <darkxst> so you have nearly a month
[12:31] <darkxst> and I o
[12:31] <darkxst> I off to bed now
[12:31] <LinDol> :0
[12:31] <LinDol> :)
[12:31] <LinDol> have a good night :)
[12:36] <darkxst> LinDol, that should be a good sleep !
[19:07] <taharqa> Hi folks
[19:08] <taharqa> I'm using gnome ubuntu 14.04 and I have some weird behaviour when using two screens
[19:08] <taharqa> mouse can not go from primary screen to secondary
[19:09] <taharqa> the cursor is like stopped
[19:09] <taharqa> but from the secondary screen to the primary no problem
[19:10] <taharqa> 2. when the secondary screen is on the top it is impossible to cross the top bar
[19:11] <taharqa> 3. the Settings>Display screen is very very light all options users have on internet is absent
[19:15] <taharqa> may someone help me
[21:05] <darkxst> taharqa, top/botton configuration is probably a bit broken
[21:06] <darkxst> (i.e you can't put the primary on bottom)
[21:06] <darkxst> atleast not in 14.04
[21:09] <taharqa> hi darkxst
[21:10] <taharqa> that sad because I organize my desktop in order my secondary screen on top of my laptop ^^
[21:12] <darkxst> taharqa, I think it is fixed in newer versions though
[21:13] <taharqa> I'm using 14.04 what do you advise me todo ?
[21:13] <darkxst> you could try booting 15.04 live CD and see if it works there
[21:14] <taharqa> is this a lts ?
[21:14] <darkxst> no
[21:14] <taharqa> can't I just upgrade gnome version ?
[21:14] <darkxst> but if there is an existing fix, it might be possible to backport
[21:15] <darkxst> taharqa, no you can try 3.12 from gnome3-staging ppa, but that is basically unsupported now
[21:17] <taharqa> darkxst: ok I'll check the 15.04 in live cd then
[21:19] <taharqa> darkxst: and regarding the Settings>DIsplay dialog that is very very simple
[21:22] <darkxst> https://bugzilla.gnome.org/show_bug.cgi?id=663690
[21:33] <darkxst> that was fixed in GNOME 3.12
[21:33] <taharqa> cool
[21:34] <taharqa> ang ubuntu 15.04 has gnome 3.12
[21:34] <darkxst> 3.14
[21:34] <taharqa> the pi version !
[21:36] <taharqa> #I am developer inmy day life, if I want create gnome application what do you suggest
[21:37] <taharqa> js , vala, go, c# ?
[21:38] <darkxst> taharqa, depends on your experience though js or vala would be best for gnome app
[21:56] <taharqa> darkxst: oh I'm polyglot java, js, golang, shell, etc
[21:57] <taharqa> ok so js could be a good to start
[21:57] <taharqa> can we register shortkey even in js
[21:57] <taharqa> ?
[21:58] <darkxst> what do you mean?
[21:59] <taharqa> oh I mean for instance I want to create a new keyboard shortcut , to launch some tasks in background
[22:00] <darkxst> gnome-shell handles the global keyboard shortcuts
[22:01] <darkxst> you can possibly add settings for those using gsettings (or via g-c-c panel)
[22:24] <b-yeezi> bye all


[05:02] <lotuspsychje> jtreminio: welcome
[05:02] <jtreminio> howdy
[05:02] <lotuspsychje> jtreminio: wich package are you trying to find?
[05:02] <jtreminio> So I'm wondering what PHP version is earmarked for 16.04
[05:03] <lotuspsychje> !info php5 xenial
[05:03] <lotuspsychje> jtreminio: but i assume you heard php7 is out right
[05:03] <jtreminio> Yes :)
[05:04] <lotuspsychje> jtreminio: we will have to wait until april 2016 for xenial official release
[05:04] <jtreminio> It's probably wishful thinking that 7 would make it in, I'm guessing
[05:04] <lotuspsychje> until we know wich php version
[05:04] <lotuspsychje> but i dont think it will be 7
[05:04] <jtreminio> who actually decides? a committee?
[05:04] <lotuspsychje> jtreminio: the community and the canonical team
[05:05] <lotuspsychje> jtreminio: you could try #ubuntu-devel to know more
[05:05] <lotuspsychje> see also this
[05:05] <lotuspsychje> !latest | jtreminio
[05:06] <jtreminio> Thank you.
[07:53] <lordievader> Good morning.
[08:24] <alkisg> Hi, when the pkexec authentication window comes up in Xenial, I can't type my password (no cursor), until I select another user in the combo box, then I select me again, and then the keyboard cursor appears
[08:24] <alkisg> I'm using gnome-flashback, has anyone else seen that, e.g. while using Unity?
[12:42] <BluesKaj> HI folks


[05:36] <pitti> Good morning
[09:01] <seb128> good morning desktopers
[09:05] <Laney> hello!
[09:05] <seb128> Laney, hey, happy friday!
[09:05] <Laney> hey seb128 (& pitti), happy friday to you!
[09:05] <Laney> nice and sunny here
[09:05] <seb128> grey and windy here
[09:06] <seb128> it was nice and sunny yesterday
[09:06] <seb128> give it back!
[09:07] <Laney> http://www.bbc.co.uk/weather/2641170
[09:07] <Laney> i think you can have it in 5-6 hours :P
[09:07] <seb128> lol
[09:08] <seb128> http://www.meteofrance.com/previsions-meteo-france/metz/57000
[09:08] <seb128> seems like we are just getting the rain :/
[09:08] <Laney> mmm, bad weekends for us
[09:10] <seb128> nice, robert_ancell fixed the "can't type password on the greeter" bug in unity-greeter
[09:12] <Laney> great
[09:22] <pitti> hey Laney, bonjour seb128
[09:23] <pitti> nice & sunny here too, already 20 degrees
[09:23] <seb128> pitti, hey, wie gehts? happy friday!
[09:23] <pitti> what a great start of spring :)
[09:23] <pitti> seb128: quite fine, thanks!
[09:23] <Sweetshark> Moin!
[09:24] <pitti> moin Sweetshark, frohen Fruehlingsanfang!
[09:27] <seb128> pitti, lucky you
[09:27] <seb128> pitti, http://www.meteofrance.com/previsions-meteo-france/metz/57000 is what we get :/
[09:28] <pitti> seb128: :(
[09:29] <pitti> seb128: mais il sera mieux la semaine prochaine
[09:30] <seb128> pitti, oui
[11:30] <Saviq> can someone please make bug #1200270 public?
[11:31] <seb128> Saviq, done
[11:32] <Saviq> seb128, thanks
[11:32] <seb128> oh, nice
[11:32] <seb128> I just hit that this morning
[11:32] <seb128> or similar, a compiz segfault in libframe
[11:34] <Saviq> freakin 24° in March...
[11:35] <ogra_> yeah
[11:35] <ogra_> unbelivable
[11:36] <ogra_> Saviq, you guys at least had some winter  over there ...
[11:36] <ogra_> we didnt ... not even below zero
[11:36] <Saviq> ogra_, the New Yorkers stole all the winder
[11:36] <ogra_> europe will get eaten by insects this summer
[11:36] <Saviq> *winter
[11:46] <mdeslaur> seb128: hrm, seems some people are having a regression, but I can't reproduce it..
[11:46] <mdeslaur> seb128: http://askubuntu.com/questions/436385/segmentation-fault-when-installing-librsvg2-common-and-libgdk-pixbuf2-0
[11:46] <mdeslaur> seb128: https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/1174253
[11:46] <ubot2> Launchpad bug 1174253 in gdk-pixbuf (Ubuntu) "Segfault (core dumped) in gdk-pixbuf on upgrade" [Undecided,Confirmed]
[12:02] <seb128> mdeslaur, hum :/
[12:03] <seb128> mdeslaur, nessita has the issue on a precise box some days ago, but she had a glib 2.37 from a ppa (where precise has 2.32) so we though it was due to the ppa, maybe it was not
[12:03] <seb128> mdeslaur, http://pastebin.ubuntu.com/7119828/ was the stacktrace she had
[12:06] <seb128> mdeslaur, looking to the gtk diff it's weird that it leads to those issues :/
[12:08] <mdeslaur> seb128: not sure what gtk+3.0 has to do with that stacktrace...
[12:08] <seb128> mdeslaur, nothing, that's what said
[12:09] <mdeslaur> the only thing I can think of is that the librsvg update triggered gdk-pixbuf in the postinst
[12:09] <seb128> mdeslaur, when you say regression it implies change, but gdk-pixbuf didn't change?
[12:09] <mdeslaur> nope, it didn't
[12:10] <mdeslaur> but librsvg does this:  dpkg-trigger --no-await /usr/lib/#MULTIARCH#/gdk-pixbuf-2.0/*/loaders
[12:12] <mdeslaur> so perhaps their gdk-pixbuf was already broken, and the update just triggered it
[12:12] <seb128> yeah
[12:12] <seb128> did we get many reports?
[12:12] <seb128> I didn't see any out of the one I pointed you at yesterday
[12:12] <mdeslaur> no, just the bug you showed me yesterday, and 3-4 people adding me-toos to the old gdk-pixbuf bug
[12:12] <seb128> k
[12:12] <Laney> actually
[12:12] <mdeslaur> so it doesn't seem widespread
[12:13] <Laney> I can get that if I install librvg2-common in a precise-chroot then upgrade librsvg2-common libglib2.0-0 to raring
[12:13] <Laney> which is what the original reporter of that bug had
[12:13] <seb128> oh, interesting
[12:14] <seb128> the loader is in common
[12:14] <mdeslaur> Laney: hrm, interesting...which resembles what nessita had too, an updated glib
[12:14] <seb128> Laney, does that upgrade the lib with it?
[12:14] <seb128> mdeslaur, can the lib and -common (=loader) get out of sync?
[12:14] <mdeslaur> seb128: ?
[12:15] <seb128> mdeslaur, what happen if you update librsvg2-common (that has the gdk-pixbuf loader)
[12:15] <Laney> yes it updates the library
[12:15] <seb128> mdeslaur, does that pull in the new lib?
[12:16] <seb128> hum, ok, so it's not those getting out of sync :/
[12:16] <seb128> I though maybe we would get the new loader with the old lib
[12:16] <Laney> i can't get it within precise
[12:17] <seb128> do you get it if you upgrade glib and not librsvg2-common?
[12:17] <seb128> glib to raring
[12:17] <seb128> e.g is that old librsvg and new glib which is the issue?
[12:17] <Laney> sec, checking if it happens in a supported upgrade path
[12:18] <mdeslaur> it may be just a side effect of the trigger in the librsvg postinst, and have nothing to actually do with librsvg itself
[12:18] <Laney> I expect that's the case
[12:18] <Laney> you can get it if you run gdk-pixbuf-query-loaders
[12:18] <mdeslaur> yeah
[12:18]  * mdeslaur wait impatiently for real hardware to finish installing
[12:19] <Laney> bah, yeah, it happens on trusty upgrade too
[12:20] <seb128> oh
[12:20] <seb128> Laney, same bt?
[12:20] <Laney> sec
[12:21] <Laney> just upgrading glib is enough
[12:21] <seb128> deeeeesssssrrttt
[12:22] <seb128> Laney, btw on a similar not, https://errors.ubuntu.com/problem/51867c7babfc41c749a4ed34ba54148f534a28c1 is ranked high on trusty issue and is also a segfault on precise->trusty updates
[12:23] <seb128> bug 1272977
[12:23] <ubot2> Launchpad bug 1272977 in gtk+3.0 (Ubuntu) "gtk-update-icon-cache segfaults in gdk_pixbuf_io_init()" [High,Triaged] https://launchpad.net/bugs/1272977
[12:24]  * seb128 hates in session upgrades
[12:26] <Laney> http://paste.ubuntu.com/7130341/
[12:27] <seb128> seems like the dlopen fails?
[12:27] <seb128> _dlerror_run
[12:28] <seb128> errstring = 0x10101010000007c <error: Cannot access memory at address 0x10101010000007c>
[12:30] <mdeslaur> ugh
[12:30] <mdeslaur> https://launchpad.net/~webupd8team/+archive/gvfs-libmtp
[12:30] <mdeslaur> that ppa installs an updated glib on precise
[12:30] <seb128> it's not the only one
[12:31] <mdeslaur> seb128: you're scaring me :)
[12:32] <seb128> lol
[12:32] <seb128> well, nessita has 2.37 from a scope testing ppa (though a private one)
[12:32] <seb128> we can't do a lot to prevent ppa users to run into issues...
[12:32] <seb128> we should look at the precise->trusty upgrade issue though
[12:35] <mdeslaur> seb128, Laney: thanks for your help
[12:35]  * mdeslaur feels better now
[12:35] <seb128> mdeslaur, I didn't do much, but yw!
[12:35] <Laney> at least we found a bug in trusty upgrades
[12:35] <Laney> I wonder how we didn't notice it in raring
[12:36] <seb128> I wonder if it's the same as the gtk-update-icon-cache one
[12:36] <Laney> I don't get that
[12:36] <Laney> not in this partially upgraded state anyway
[12:36] <seb128> well, e.u.c suggest a lot more users get that one that the one you are getting
[12:36] <seb128> it's concerning that a glib update makes gdk-pixbuf segfault though
[12:37] <seb128> glib is supposed to be ABI compatible
[12:37] <seb128> let's see if desrt have a clue what could be going on there
[12:37] <Laney> yeah if you upgrade gdk-pixbuf it goes away
[12:37] <Laney> that probably happens on upgrades
[12:38] <seb128> we can avoid it, but still updating glib should make gdkpixbug segfault
[12:39] <Laney> should *not* :P
[12:40] <seb128> yeah, I need to stop forgetting the not :p
[12:53] <seb128> on the list of frequent trusty issue as well
[12:56] <seb128> software-center hitting
[12:56] <seb128>  The following packages have unmet dependencies:
[12:56] <seb128> steam-launcher: Depends: jockey-common but it is not going to be installed
[12:56] <seb128>                 Depends: libc6 (>= 2.15) but 2.19-0ubuntu2 is to be installed
[12:56] <seb128>
[12:56] <seb128> is steam-launcher something we ship/provide?
[12:57] <seb128> oh
[12:57] <seb128> https://apps.ubuntu.com/cat/applications/steam-launcher/
[12:59] <Laney> it's not in the archive
[12:59] <Laney> s-c wants me to 'Buy' it... where do those come from?
[13:21] <bregma> seb128, I've been testing a bunch of lockscreen fixes in landing-006, and everything is fine on one of my test machines but another one has trouble after switching to the guest session fro the lockscreen: bschaefer could not reproduce, could I get you to also test it for me, in case I just have a messed-up test machine?
[13:23] <seb128> bregma, hey, sure
[13:36] <seb128> bregma, what specific issue do you have? seems to work fine me, I switched forth and back a few time between my user and a guest using the indicator, no problem (out of the "screen lock dialog is displayed for your user when coming from the greeter", which is not a new issue)
[13:37] <bregma> (1) my mouse disappears when switching to the guest (I have a touchscreen, so I'm not completely hosed) and (2) when I switch back to my own session, the lockscreen comes up for the guest account (at which point I am hosed, because there is no password)
[13:37] <bregma> but only on my one machine
[13:38] <bregma> so I do suspect something weird on that machine
[13:38] <seb128> how do you go back your session?
[13:38] <bregma> I touch the menu option in the sesson menu
[13:38] <seb128> but yeah, I can't even imagine how your user-session-process-unity would ask you to unlock for guest
[13:39] <seb128> are you sure are on the right vt?
[13:39] <seb128> tried to ctrl-alt-f7?
[13:45] <bregma> the only graphics vt is vt7, and if I switch to the guest session without the lockscreen on, switching back to my session always gives me the guest session after flashing my session briefly on the screen
[13:46] <seb128> it looks like lightdm or something nuked your user session and put the guest on that vt
[13:46] <seb128> do you play with Mir/system compositor on that box?
[13:46] <bregma> it's possibly I have a messed-up lightdm config
[13:46] <seb128> well anyway, I doubt it's unity's doing
[13:46] <seb128> I fail to see how unity could lead to that
[13:47] <seb128> so +1 from me for publishing the silo to the archive ;-)
[13:47] <bregma> agreed, thanks for conforming the problem is on my end
[13:47] <seb128> yw, always happy to help landing bugfixes ;-)
[14:11] <desrt> seb128, Laney, anyone: does anyone know the gcc bug that means g_return_if_fail() return types are mismatched?
[14:12] <seb128> desrt, is that the one larsu mentioned? no...
[14:12] <desrt> ah.  i thought one of you guys told me about it
[14:12] <desrt> maybe it was larsu :)
[14:14] <seb128> desrt, https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1234218
[14:14] <ubot2> Launchpad bug 1234218 in gcc-4.8 (Ubuntu) "4.8 doesn't throw -Wreturn-type anymore for wrong returns in macros" [Undecided,New]
[14:14] <seb128> desrt, that one?
[14:15] <desrt> yes.  thanks.
[14:15] <desrt> erm
[14:15] <desrt> no upstream link
[14:15] <desrt> is it possible that nobody has actually reported this issue to gcc? :)
[14:17] <seb128> desrt, could be
[14:18] <seb128> desrt, larsu is off today
[14:35] <ritz> chrisccoulson, hi, is it possible to update to tb 24.4.0 on precise , or do I need to file an sru on this ?
[14:35] <ritz> wrt https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1281887
[14:35] <ubot2> Launchpad bug 1281887 in thunderbird (Ubuntu) "upgrade thunderbird to 24.4.0" [Undecided,New]
[15:00] <ritz> seb128, could we mark this as wont fix against precise ? https://bugs.launchpad.net/ubuntu/precise/+source/vino/+bug/1027086
[15:00] <ubot2> Launchpad bug 1027086 in vino (Ubuntu Precise) "incorrect schema setting used for authentication-methods in vino server" [Medium,In progress]
[15:02] <ritz> Sweetshark, hi, wrt http://bugs.launchpad.net/bugs/1200277 . is there an ETA ?
[15:02] <ubot2> Launchpad bug 1200277 in libreoffice (Ubuntu) "[LibreOffice] - libreoffice-writer.desktop when drag/drop to desktop, 100% broken. " [Medium,Fix committed]
[15:02] <ritz> for precise and trusty
[15:04] <Guest19431> can i install gnome3.10 in ubuntu12.04 by any means?
[15:04] <seb128> ritz, why? I put it triaged/low in case somebody wants to come with a proper solution
[15:05] <seb128> Guest19431, try #ubuntu for user questions, and probably not
[15:05] <Guest19431> seb128, sorry i m new here
[15:06] <ritz> seb128, upstream believe, the correct fix is as posted
[15:06] <ritz> and to for bad inputs to generates warning.
[15:06] <seb128> ritz, so why wontfix?
[15:07] <ritz> seb128, difference of opinion between what is supposed to be the correct fix, and what the upstream believes is the correct fix
[15:08] <seb128> ritz, k, it's not important enough for me to try to argue more over it, let's keep it as triaged/low
[15:08] <ritz> seb128, fair point. this has been fixed in raring and above ( with upstream)
[15:08] <ritz> leaving precise as it is
[15:09] <seb128> k
[15:23] <Sweetshark> ritz: for the archive: trusty in the next days. precise: if needed we can make an SRU extra for that, otherwise: when something else shows up ...
[15:23] <ritz> Sweetshark, thank you :)
[15:24] <Sweetshark> ritz: Do we need a precise SRU?
[15:24] <ritz> Sweetshark++ seb128++
[15:31] <chrisccoulson> ritz, no need to report a bug, it will get updated when i have time. it's not particularly urgent
[15:32] <ritz> chrisccoulson, thanks , I will remove the ubuntu-sponsor from the subscriber
[15:39] <Trevinho> seb128: hey, for unity scaling changes have you got some time to check https://code.launchpad.net/~3v1n0/unity-control-center/applications-scaling-selector/+merge/212114 ?
[15:40] <Trevinho> seb128: there are probably some strings to improve
[15:45] <seb128> Trevinho, hey, not really, maybe in some hours, I've like 10 things on my todo for the day
[15:45] <Trevinho> seb128: ok, np
[15:46] <seb128> Trevinho, do you have a screenshot? ;-)
[15:46] <Trevinho> seb128: in a sec
[15:47] <seb128> Laney, ^ do you have spare cycle/want to help with that maybe? (not sure what you got on your plate to end this friday ;-)
[15:47] <Trevinho> seb128: http://imgur.com/brK7lQN
[15:48] <Laney> I think you should ask mpt to review the approach and strings
[15:48] <Laney> Applications Scale target is surely going to need work :P
[15:48] <Laney> but yeah, can look at the code in a bit
[15:49] <Trevinho> Laney: yeah, consider the strings a stub
[15:49]  * Trevinho can't word things .P
[15:49] <Trevinho> seb128, Laney and http://i.imgur.com/X7ob0sC.png
[15:49] <Trevinho> also for Use {max,min}...
[15:50] <seb128> Trevinho, I don't understand what those options mean :p
[15:50] <Trevinho> it's probably better to just to add Use Max available scale and... "Never scale apps"...
[15:50] <Trevinho> seb128: that's why I said strings need work :D
[15:50] <Laney> do you think those ones are required?
[15:50] <Laney> I just imagined listing the monitors and a never one
[15:50] <seb128> Trevinho, in the UI still fitting on a netbook vertical resolution?
[15:51] <Trevinho> seb128: eheh, btw well. they means to use the min or max scale values acrosso monitors
[15:51] <Trevinho> seb128: mh, the window is 661px...
[15:52] <Trevinho> height
[15:52] <seb128> Trevinho, so doesn't fit on 1024x600 which netbooks use
[15:52] <Trevinho> seb128: i would loved to remove some padding above the UI scale, but I wasn't able :P
[15:52] <seb128> we have lot of space on the right :p
[15:53] <Trevinho> seb128: mh, I would have used that as well... but I didn't want to beak the actual way to dispose things
[15:53] <Trevinho> let me see what I can do
[15:59] <mpt> “UI scale” and “Applications Scale target”? Yer what?
[16:00] <mpt> I don’t know what “Use maximum monitor scale” means either :-(
[16:00] <Laney> I'm not sure those are necessary
[16:00] <Trevinho> mpt: well, wording must be improved absolutely.. I just left the first "dev stinrgs" there...
[16:01] <Trevinho> mpt: max,min: means use for all the applications the {max,min} ui sale set per monitor
[16:01] <Laney> the monitor with the largest scaling factor
[16:02] <Trevinho> mpt: btw actually we should instead just add: "Use the monitor with largest scaling factor" or... "Never scale applications".
[16:02] <Trevinho> don't caring about the minimum value....
[16:02] <mpt> What do you mean by “Use the monitor”? Would that move all windows to that display?
[16:03] <Laney> for the "Application scaling"
[16:03] <Laney> vs UI scaling
[16:03] <Trevinho> mpt: no, the fact is that the UI scale, when it comes to toolkits, is not per monitor basis
[16:03] <Trevinho> mpt: but a global value
[16:03] <mpt> Trevinho, sure, I wrote <https://wiki.ubuntu.com/BrightnessAndDisplays#Scaling>
[16:03] <mpt> so I understand that part at least :-)
[16:04] <Trevinho> so, to we need the user to define what scaling to use at global level
[16:04] <Trevinho> ok...
[16:04] <Trevinho> :)
[16:04] <mpt> So which of the three settings would “Use maximum monitor scale” change, and to what?
[16:04] <Trevinho> ah, I didn't see the new diesngs
[16:04] <Laney> that even has a two column layout
[16:05] <mpt> Trevinho, I understand that this menu is a quick placeholder for 14.04
[16:06] <mpt> I guess “UI scale” maps to ui-scale, that much is obvious :)
[16:08] <Trevinho> mpt: yeah, but let me see because probably I can adjust the things to match design more...
[16:09] <mpt> Laney, yeah, that was to solve the issue where we currently have three rows of stuff for the current display, followed by two rows of display-independent stuff, followed by one row of stuff for the current display, followed by one more row of display-independent stuff
[16:11] <Laney> mpt: yeah, but it also solves another problem in that the UI becomes too tall for netbook-like screens if we keep growing downwards
[16:11] <Laney> I'm all in favour of implementing more of that design if it's reasonable to do so in fairly short order
[16:12] <Trevinho> Laney: good
[16:12] <Trevinho> mpt: there's just one thing the "Scale of r menu and title bars" can't be called in that way, since it will only apply to Shell elements
[16:13] <Trevinho> so to panel, decorations, launcher... but no menu
[16:13] <mpt> Trevinho, the menu bar isn’t a shell element??
[16:14] <Trevinho> mpt: menu bar yes... but no menu content.. I mean, I know you're talking of "bars", but I don't want it to might be considered as it includes also the menu themselves
[16:14] <mpt> Trevinho, I understand that it will change the size of menus that come down from the menu bar, but not context menus or popup menus etc
[16:14] <mpt> Is that right?
[16:14] <Trevinho> mpt: no :(
[16:15] <Trevinho> mpt: the menus won't scale,
[16:15] <mpt> oh crikey
[16:15] <mpt> So the menu contents will be smaller/larger than the menu titles?
[16:15] <Trevinho> mpt: at least, it *might* be possible to achieve... but not done yet
[16:15] <Trevinho> it can happen now yes
[16:15] <mpt> haha
[16:15] <mpt> ok
[16:15] <Trevinho> let me think...
[16:17] <mpt> It’s okay for those labels not to be exhaustive, they have what lawyers call a “penumbra” where you can guess what other sorts of things will be affected
[16:17] <Trevinho> mpt: mh, I don't think that the gtk-text-scale factor can be applied to only one widget... Laney?
[16:17] <mpt> …from the examples given. For example, I think the Windows equivalent of this setting refers to “menus and dialogs”, not needing to mention that it affects lots of other things too.
[16:18] <mpt> And I left out the Launcher because I wanted to avoid confusion with the Launcher’s separate size control (though this setting does affect the Launcher too).
[16:18] <Trevinho> yeah, right
[16:19] <Trevinho> why not just "scale for panels"?
[16:19] <mpt> Trevinho, would you be happy with “Size for menu bar and title bars”? That doesn’t claim that menu bar *menus* will change size too (though it would be nice if they did).
[16:20] <Trevinho> mpt: ok, that's fine... :)
[16:20] <mpt> cool
[16:21] <mpt> (We don’t use the term “panels” anywhere in the UI or help, afaik, but we do use “menu bar” in several areas of System Settings)
[16:21] <Trevinho> mpt: btw the settings I added where considering also another fact: how to handle things when new monitors are attached...
[16:21] <Trevinho> mpt: I mean, what to do: resize the APPS to default scale, or no?
[16:21] <mpt> Trevinho, you mean resize apps on all displays to match the ui-scale of the newly-detected display?
[16:22] <Trevinho> mpt: yes
[16:22] <Trevinho> mpt: or keep things big as in the "current" dpy?
[16:22] <Trevinho> (let's imagine we're on an hidpi laptop)
[16:22] <mpt> Trevinho, would that also mean changing them back automatically when the display is disconnected?
[16:23] <Trevinho> mpt: yes
[16:23] <Trevinho> mpt: that's happening right now..
[16:24] <Trevinho> mpt: err, for now the option in unity is to always apply the maximum scaling factor available in monitors to apps... But that can be falsified easily
[16:24] <mpt> Trevinho, what do you mean by “falsified”?
[16:25] <seb128> desrt, do you have any idea why old gdk-pixbuf would hit http://paste.ubuntu.com/7130341/ when running with a new glib (e.g precise gdk-pixbuf running with glib > 2.36 (instead of 2.32))
[16:25] <Trevinho> mpt: that there's an option that can be set to false to globally use the normal scale factor instead
[16:26] <mpt> Trevinho, by “normal” do you mean 1? Or something else?
[16:26] <Trevinho> mpt: 1, or just the minimum value available across monitors
[16:27] <desrt> seb128: yes.
[16:27] <desrt> the old loader query program didn't use gobject
[16:27] <desrt> but many of the loaders themselves did
[16:28] <desrt> so gobject would get loaded and unloaded repeatedly, each time a loader was queried
[16:28] <desrt> even if the query function didn't use it
[16:28] <desrt> upstream gdkpixbuf links -lgobject explicitly to avoid this
[16:28] <desrt> but as-needed linker flags circumvent that
[16:28] <desrt> so we added an explicit g_type_ensure(G_TYPE_OBJECT) to circumvent the circumvention
[16:28] <seb128> Laney, mdeslaur: ^ fyi
[16:29] <mpt> https://wiki.ubuntu.com/BrightnessAndDisplays?action=diff&rev2=11&rev1=10
[16:30] <desrt> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=686822
[16:30] <ubot2> Gnome bug 686822 in gobject "possible dlopen()/dlclose() issue with automatic g_type_init()" [Normal,Resolved: fixed]
[16:31] <seb128> desrt, I'm unsure to understand why updating glib leads to a segfault there?
[16:31] <desrt> fixed since late 2012... must be some very old gdk-pixbuf you have there
[16:31] <mpt> Trevinho, so when it’s false, you have *scale-factor = 1. When it’s true, you have *scale-factor automatically matching the ui-scale of … what? Whichever remaining display was connected last?
[16:31] <seb128> desrt, it's 12.04 dude
[16:31] <desrt> seb128: the difference is that new glib does g_type_init() automatically on module load
[16:31] <desrt> the module was always being improperly loaded/unloaded before
[16:31] <desrt> but it did no harm
[16:31] <seb128> so we should backport https://bug686822.bugzilla-attachments.gnome.org/attachment.cgi?id=227203
[16:31] <seb128> ?
[16:32] <desrt> yes
[16:32] <desrt> or stop using as-needed
[16:32] <seb128> thanks
[16:32] <seb128> desrt, I'm glad you replied, would have taken ages to figure out what was happening there
[16:32] <desrt> seb128: it took me ages to figure it out the first time ;)
[16:32] <seb128> mdeslaur, do you want to security update that, or should I just SRU it?
[16:33] <seb128> Laney, or maybe you want to do the SRU? you had a chroot/test setup to reproduce it
[16:33] <mdeslaur> seb128: sru it please
[16:33] <Laney> yeah I can cherry-pick that easily
[16:33] <Laney> do you have the bug report to hand?
[16:34] <seb128> Laney, bug #1174253
[16:34] <ubot2> Launchpad bug 1174253 in gdk-pixbuf (Ubuntu) "Segfault (core dumped) in gdk-pixbuf on upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/1174253
[16:34] <Laney> ty
[16:36] <desrt> i love g_type_ensure
[16:36] <desrt> it's such a tricky function
[16:36] <desrt> such a devious implementation
[16:38] <Trevinho> mpt: oh I missed the msg, sorry. But when false it uses the scale-factor that matches the lower value across all available monitors (probably to revert and just use always 1). When true it uses the scale factor that matches the UI scale of the connected monitor that has the maximum UI scale value
[16:39] <Laney> could you use the slider as per the design?
[16:40] <mpt> Trevinho, but that would mean there is no setting for “never touch the scale factor automatically”, right?
[16:41] <mpt> (evidence for the “boolean parameters considered harmful” theory)
[16:41] <Laney> boolean parameters considered harmful [x]
[16:42] <mpt> [_[ ON ]]
[16:57] <Laney> desrt: of course we don't have g_type_ensure in precise
[17:23] <Trevinho> mpt: no, but I might consider to just ignore the minimum thing, and use the default 1.0 instead
[17:35] <seb128> dobey, hey, is https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1244493 still on your list? trusty beta freeze is on monday
[17:35] <ubot2> Launchpad bug 1244493 in software-center (Ubuntu) "Software Center doesn't save settings on Saucy" [High,Confirmed]
[17:36] <jose> hey mterry, around?
[17:36] <mterry> jose, yes
[17:36] <jose> mterry: mind a quick PM?
[17:37] <mterry> jose, go crazy :)
[17:37] <dobey> seb128: ah, sorry. been dealing with click scope issues
[17:41] <seb128> dobey, no worry, I was just remind you in case you forgot about it ;-)
[17:47] <jose> hey guys! anyone from the desktop team has a minute? I'd like to make an invitation on behalf of the Classroom team
[18:10] <Laney> seb128: could you please do queue -Q unapproved -s precise-proposed reject 7198759 for me?
[18:11] <Laney> might make you give a reason too
[18:11] <Laney> which is 'laney sucks'
[18:12] <seb128> is that the oldest upload?
[18:12] <Laney> ya
[18:12] <seb128> I prefer https://launchpad.net/ubuntu/precise/+queue?queue_state=1 to the command line
[18:12] <Laney> do you use the web UI? ;-)
[18:12] <seb128> yeah
[18:12] <Laney> I see
[18:13] <seb128> so you went for LDFLAGS += -Wl,--no-as-needed
[18:13] <seb128> lgtm
[18:14] <seb128> Laney, rejected, thanks for the SRU!
[18:15] <Laney> yeah g_type_ensure doesn't exist in precise sadly
[18:17] <Laney> ok, time to go away
[18:17] <Laney> have a good weekend :-)
[18:21] <seb128> Laney, thanks, you too!
[19:20] <kenvandine> seb128, can you check my uss branch?
[19:20] <kenvandine> bill and i have tested it in the silo
[19:38] <seb128> kenvandine, yeah, -1 for it, please delete the silo
[19:39] <seb128> kenvandine, (that's the penalty for trying to do a friday upload)
[19:39] <seb128> kenvandine, ;-)
[19:39] <kenvandine> :)
[19:40] <seb128> kenvandine, ok, looks fine, I trust your testing so approved, enjoy ;-)
[19:42] <kenvandine> thx seb128
[19:42] <seb128> kenvandine, yw!
[19:42] <seb128> kenvandine, how is the testing going? getting it green for landing?
[19:42] <kenvandine> seb128, enjoy your weekend :)
[19:42] <kenvandine> yeah
[19:42] <seb128> kenvandine, thanks, you too
[19:42] <kenvandine> only complication is coordinating landing of gallery
[19:42] <kenvandine> since it's a click
[19:44] <chrisccoulson> good evening!
[19:49] <seb128> chrisccoulson, hey, how are you? are you still working?
[19:49] <chrisccoulson> seb128, yep, i'm always still working ;)
[19:49] <chrisccoulson> how are you?
[19:50] <seb128> chrisccoulson, or did you IRC from your phone drinking a beer at the pub? ;-)
[19:50] <chrisccoulson> lol
[19:50] <seb128> chrisccoulson, I'm good thanks ;-)
[19:51] <seb128> just back from dinner, drinking a glass of wine and chatting a bit on IRC before closing it and calling it a week ;-)
[19:51] <seb128> chrisccoulson, are you going to be in Malta?
[19:52] <chrisccoulson> seb128, i am, although i was going to join the apps week, but i'm on holiday the week prior to that so i'll be there in the second week ;)
[19:52] <seb128> chrisccoulson, that's great, you can hang out with us again ;-)
[19:53] <chrisccoulson> heh
[19:53] <seb128> we didn't see you for a while
[19:53] <chrisccoulson> i'm looking forward to having a non-US trip :)
[19:53] <seb128> you should come the first week and take holidays with some of us ;-)
[19:54] <chrisccoulson> heh, i've got a family holiday the week before that :)
[20:14] <chrisccoulson> oh, nice, i wanted to create a https server in python, and this blog post from pitti was the first hit in google: http://www.piware.de/2011/01/creating-an-https-server-in-python/ \o/
[20:14]  * chrisccoulson hugs pitti
[20:29] <JanC> chrisccoulson: just remember that it's not really a _full_ SSL/TLS server  :)
[20:30] <chrisccoulson> JanC, that's fine, I don't need one ;)
[20:30] <JanC> as long as you're aware of that it's fine :)
[20:32] <JanC> well, you and everybody else involved
[21:01] <sarnold> JanC: what's missing from this cute little simple server? :)
[21:02] <sarnold> I mean, I wouldn't expect e.g. SNI to work, but otherwise I'm curious where it could go wrong :)
[21:38] <Trevinho> mterry: hey, do you have some time to check https://code.launchpad.net/~3v1n0/unity-control-center/use-unity-text-scale-factor/+merge/212249 ?
[21:39] <mterry> Trevinho, uh sure
[21:39] <Trevinho> mterry: thanks
[21:43] <mterry> Trevinho, so what's the difference between the unity key and the other?  Like, why do we have our own key?
[21:43]  * mterry doesn't know history here
[21:45] <Trevinho> mterry: the fact is that when we have UI scale set in unity, it will scale (if set) the user applications mixing the text-scaling factor and the ui-scale factor from gtk (see https://wiki.ubuntu.com/BrightnessAndDisplays#Scaling), then at that point the gnome text scale factor might be changed....
[21:46] <Trevinho> then we need a place to store the actual text scale factor that we multiply to our scaling. Also in order to get a11y settings to work.
[21:47] <Trevinho> So we have our own setting now, that will be applied to the gnome text-scaling factor parameter by unity
[21:48] <mterry> Trevinho, so both the GNOME text-scaling-factor and the Unity text-scale-factor are both applied?
[21:50] <Trevinho> mterry: well, yes... I mean the gnome text-scaling-factor is used when scaling the UI in interrim values (i.e. you scale your UI at 1.5 or 1.75...), then if you set also the unity text-scaling-factor the gnome scaling factor will bump to the previous value * unity-text-scaling-factor
[21:51] <mterry> Trevinho, this is not making it clearer to me.  Maybe I'm too Friday'd
[21:51] <Trevinho> mterry: or more likely I'm explaing it not that well :)
[21:51] <Trevinho> mterry: so.... In UCC we now have a UI scale parameter... This parameter right now applies only to the shell; but we're changing it to apply also to system (if user wants).
[21:52] <Trevinho> mterry: to achieve that, since Gtk ui-scale-factor is only an integer, we play mixing it with the text-scaling-factor
[21:53] <mterry> Trevinho, So GNOME text-scaling-factor is an integer?  But Unity text-scale-factor is a double?
[21:53] <Trevinho> so if you've a UI scale set at 1.5, the gnome ui scale is 1, and the text-scale-factor 1.5... If the ui scale is 2.5, the gnome ui scsale is 2, and the text scale factor is 1.25
[21:53] <Trevinho> mterry: no, gnome text-scaling-factor is a double, but gnome UI.scaling-factor is an int
[21:54] <mterry> Trevinho, I'm just trying to figure out why we have our own version of GNOME's text-scaling-factor instead of using theirs
[21:55] <Trevinho> mterry: we use that, but we also use that for scaling the UI in general. But if an user changed the option to see "Big text" in a11y options, then that won't work... so here's why the new setting
[21:55] <Trevinho> that's also because in unity we scale things using cairo, and technically this saves us a lot of rewriting...
[21:56] <mterry> Trevinho, do I need another package to test this?  One with the scheme used?  I don't see that schema on my desktop (com.canonical.Unity.Interface)
[21:56] <Trevinho> mterry: yeah, I've linked the unity branch on the review
[21:56] <mterry> Trevinho, I still don't fully understand, but I'll trust that you folks do  :)
[21:56] <mterry> Trevinho, oh!  didn't see that
[21:57] <mterry> Trevinho, I don't believe you did link it?
[21:57] <Trevinho> mterry: I added it just after pinging you, so maybe you have been faster on loading the page
[21:57] <mterry> Oh, I refreshed
[21:57] <Trevinho> mterry: https://code.launchpad.net/+branch/~3v1n0/unity/scale-factor-binding
[21:58] <mterry> Trevinho, also, why does UCC cater to non-unity environments?  I figured we forked so we didn't have to  :)
[22:00] <Trevinho> mterry: yeah, in fact i wanted to ask about it... my initial commit was without checking unity env... Then I noticed that all the rest of the unity code was sitll doing it, so I was wondering it still had to be done
[22:00] <Trevinho> mterry: but if i can revert the change in a sec
[22:01] <Trevinho> err, ucc code I mean
[22:01] <mterry> Trevinho, I don't know myself, might want to check with seb128 about that.  But if rest of code does, I'd say go along with that and a purge merge could be made later
[22:01] <Trevinho> althuogh I was pretty sure it wasn't used in other envs, but... just to check
[22:05] <mterry> Trevinho, OK, code looks fine, but I just want to play with it myself.  Which means building unity.  So it'll take me a while, but I'll get there
[22:05] <mterry> Trevinho, unless there's urgency?
[22:05] <Trevinho> mterry: well we'd like to push unity now, with that in a silo... so if you want you can just wait the silo and then trying from the ppa
[22:06] <Trevinho> mterry: unity doesn't depend strictly on it, but I preferred to push them together not to break the user settings
[22:06] <Trevinho> mterry: also if that would happen only for people with HIdpi scale values
[22:06] <Trevinho> (i mean, the u-c-c- big text option wouldn't be considered)
[22:07] <mterry> Trevinho, ok, then I'll just approve.  Looks reasonable
[22:08] <Trevinho> mterry: thanks... I'll let you know when the ppa is ready
[22:09] <Trevinho> or bregma ^
[22:09] <mterry> Trevinho, done
[22:10] <Trevinho> mterry: ta