[06:28] <alex-weej> "- there is no point in having a "monochrome" rendering mode, like we  do currently, it just looks ugly unless you have activated native  TrueType hints, so make this explicit in the interface." i disagree with that
[06:28] <ScottK> Agree with that.  It just hasn't always happened that way.
[06:28] <alex-weej> high DPI
[06:29] <mdz> ScottK: it was not my intention to make a decision on the request; I was confused by the terminology
[06:29] <milli> ScottK: fwiw, _I_ vehemently care about _non_-anti-aliased fonts.
[06:29] <mdz> ScottK: which I think needs a lot of cleanup (hence my discussion with pitti about it)
[06:29] <Hobbsee> mdz: would have thought you'd give it 24+ hours and such.  but OK.
[06:29] <ScottK> mdz: Agreed on the fact that the current situation is confusing.
[06:30] <pitti> still waiting for some answers on the ML before I actually change it
[06:30] <Hobbsee> pitti: the freeze stuff?
[06:30] <Hobbsee> yes, i need to reply to that.
[06:30] <Hobbsee> (as the head of universe sponsorship queue
[06:30] <Hobbsee> )
[06:31] <ScottK> pitti: I also think that we need a documented spot for all of the distro release specific exceptions.
[06:31] <pitti> ScottK: agreed, and that's the plan already
[06:32] <pitti> ScottK: once we agree to the set of freezes, the links behind them will give details
[06:32] <ScottK> OK.
[06:32] <pitti> ScottK: and FreezeExceptionProcess, of course
[06:32] <ScottK> In particular, there is a set of packages for UME that has a standing exception.  Which packages those are won't be clear to people not involved in UME.
[06:37] <mathiaz> keescook: do you have testcases for avahi-daemon in your automatic testing suite ?
[06:38] <keescook> mathiaz: nope :(
[06:38] <keescook> wait
[06:38] <keescook> yes, minimal.
[06:39] <mathiaz> pitti: regarding the dhclient apparmor profile, I've got a minimal one but I still to test it more.
[06:39] <keescook> it tests registration.  so, really it's an mdns test, not a link-local test.
[06:39] <pitti> mathiaz: hm, I'm afraid it gets pretty late for that kind of change
[06:39] <mathiaz> pitti: yeah. So I think we should defer the change for hardy.
[06:40] <milli> alex-weej: fwiw, I have Feisty and use Monochrome, Smoothing = None, Hinting = Full, to get fonts to look _decent_
[06:40] <alex-weej> milli: and you have truetype fonts with hints designed for bilevel rasterisation
[06:40] <milli> I'll be very upset if monochrome disappears, or at least it's meaning, which is "don't anti-alias"
[06:40] <alex-weej> milli: i assume Tahoma or something
[06:40] <pitti> mathiaz: agreed
[06:41] <milli> alex-weej: yes
[06:41] <mathiaz> pitti: I've investigated the reason why the profile doesn't get applied on boot.
[06:41] <mathiaz> pitti: it seems that it's due to start-stop-daemon.
[06:41] <alex-weej> milli: i don't think it should disappear.
[06:41] <milli> alex-weej: there has always been a disconnect between what FontConfig has for options and what's in the Gnome properties sheet
[06:41] <alex-weej> totally
[06:42] <milli> alex-weej: ah, you were quoting someone else?  (just noticed the "'s)
[06:42] <alex-weej> hehe
[06:42] <alex-weej> i disagree because on a hypothetical 500dpi screen, you probably don't want AA at all
[06:42] <milli> Arial is the font I use pretty much everywhere
[06:42] <alex-weej> like printers
[06:43] <alex-weej> Arial's hinting is /aggressive/
[06:43] <alex-weej> totally different font for every point size
[06:44] <milli> I must say, and I've heard comments to this effect, if you can't render fonts _BEAUTIFULLY_, or at least up to par with Windows and OS X out of the box, it's an in-your-face kind of thing and a turn off.  It _will_ slow adoption of Linux on the desktop.  That has been the case for a long time.
[06:45] <milli> That's my rant about fonts.  I was so disappointed with Edgy because no combination of fonts or settings looked good in OpenOffice and I couldn't believe it got released like that.
[06:46] <alex-weej> OpenOffice does its own thing
[06:46] <milli> But only a handful of people screamed about it.
[06:46] <alex-weej> as does Gecko
[06:46] <milli> yes, I have since found out.
[06:46] <milli> and stopped screaming
[06:48] <milli> alex-weej: w.r.t. AA, I find that all is does is make fonts look blurry, which gives me a headache.  It works for print media, not for screen IMHO.
[06:48] <alex-weej> print doesn't AA...
[06:48] <alex-weej> print draws at 720dpi :P
[06:48] <Keybuk> at 600dpi, you kinda don't need too :p
[06:50] <alex-weej> the real solution to all of this mess is to 1) stop doing hinting, 2) stop doing any form of anti-aliasing whatsoever, 3) render the entire desktop scene at 3nn oversampling, 4) filter the whole scene
[06:50] <milli> what I mean then, is brochure ware stuff, etc, created with Photoshop (or GIMP) where the fonts are blended / anti-aliased on the page..
[06:50] <alex-weej> fonts shouldn't be the only thing that get the benefit of subpixel positioning
[06:51] <alex-weej> milli: if you're doing print media in photoshop then you suck
[06:51] <milli> alex-weej: I'm not ;-)
[06:51] <alex-weej> :P
[06:51] <IntuitiveNipple> alex-weej: I think someone's doing that - couple of bug reports today about 'fuzzy' icons in Clearlooks that I see as sharp as a knife :p
[06:52] <milli> That should be ....  "GIMP (or Photoshop)"
[06:52] <alex-weej> IntuitiveNipple: no that's because 24px icons are being sized at 22px
[06:52] <IntuitiveNipple> alex-weej: I don't see the fuzzy ones and I've not changed anything - why would that be?
[06:52] <alex-weej> IntuitiveNipple: icon theme
[06:52] <alex-weej> Clearlooks mandates 22px toolbar icons
[06:53] <alex-weej> including the stuff in the main menu
[06:54] <IntuitiveNipple> I checked the theme based on what the bug-reporter said, and Clearview is using GNOME, and they are crisp and sharp with all today's updates.
[06:54] <alex-weej> mjg59: i just read your email -- the positioning of stems is the same with both filters
[06:55] <alex-weej> IntuitiveNipple: because GNOME Icon Theme is a tango-theme
[06:56] <alex-weej> i.e. it has 22px icons
[06:56] <alex-weej> Human, for example, has 24px
[06:57] <IntuitiveNipple> alex-weej: ok, maybe I'm confused, but I understood from the bug-reporter that is icons in use there, and he/she is seeing them fuzzy.
[06:57] <alex-weej> yes that's because they are being resampled, and 24 does not divide by 22
[06:58] <IntuitiveNipple> alex-weej: I understand that; what I'm not clear on is why, if I've seemingly selected the same theme/Icons, why I appear to get a different result.
[06:58] <cromo> hi. I dist-upgraded from perfectly working feisty to gutsy and now experience weird hang ups. It will hang up after about 10 minutes after logging in from gdm, but it can't work for hours under console (like now) without problems.
[06:58] <alex-weej> maybe we're barking up the wrong tree, then.
[06:59] <cromo> sys-rq keys seems to work sometimes, sometimes they don't
[06:59] <alex-weej> cromo: graphics card overheating?
[06:59] <cromo> doubt so
[06:59] <cromo> it's radeon 9200
[06:59] <IntuitiveNipple> alex-weej: I don't play with theme customisations at all so my system is whatever the default installs are, which is why I thought to compare when I saw the bug-report
[06:59] <alex-weej> cromo: have you checked your kernel logs?
[06:59] <cromo> and the mouse pointer works fine
[06:59] <cromo> yes, nothing there
[06:59] <cromo> for me it looks like scheduler problem
[06:59] <alex-weej> tried a different driver?
[06:59] <cromo> but the mouse works? I guess it's not the graphics then
[06:59] <alex-weej> no
[07:00] <cromo> I mean, I can move it, but can't click on anything
[07:00] <alex-weej> have you tried vesa?
[07:00] <cromo> also, it alwyas hangs when the cpu is at 100% usage
[07:00] <cromo> I will
[07:00] <cromo> but I doubt that it will help
[07:02] <alex-weej> bbl simpsons
[07:02] <alex-weej> +food
[07:03] <cromo> ok, I run X with vesa driver
[07:03] <cromo> let's see...
[07:05] <mathiaz> pitti: what about adding the dhcp client profile to the apparmor-profile package (which is in universe) ?
[07:05] <cromo> btw, these lockups happened for bopt .192 and .193 radeon driver
[07:05] <pitti> mathiaz: that's fine for me
[07:05] <pitti> mathiaz: if the profile works for the derooted client, too?
[07:05] <pitti> mathiaz: e. g. the derooted one needs cap_setuid
[07:06] <towolf> mjg59: whoa, just read your email. your whole argument hinges on an example that would rarely occur in real life. go up 4pt and the story looks entirely different.
[07:06] <mathiaz> pitti: that'S right.
[07:06] <mathiaz> pitti: the profile is a little bit different (wrt the capabilities).
[07:06] <towolf> mjg59:  8pt has always been a corner case in displaying fonts.
[07:07] <mathiaz> pitti: but at least we can ship something and get it tested.
[07:07] <towolf> mjg59: there's always xterm at your disposal. or MGT if you prefer tabs.
[07:09] <mjg59> towolf: "Your use case doesn't matter" is a poor argument
[07:09] <mjg59> Since it pretty clearly matters to me :)
[07:10] <mjg59> The aim should be to find ways of introducing changes like this /without/ upsetting people
[07:11] <mjg59> Which I believe to be achievable, just not in the amount of time we have
[07:11] <towolf> mjg59: so you sit 30cm away from the creen because your fonts are at 8pt?
[07:12] <towolf> mjg59: now i see ...
[07:12] <towolf> *screen
[07:12] <mjg59> towolf: No, I sit 30cm away from the screen because I use a laptop and work from bed
[07:13] <unggnu> mjg59, hi, could you please say something to wrong sonybright.sh value range? https://bugs.launchpad.net/bugs/136380
[07:13] <ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New]
[07:14] <mjg59> unggnu: I haven't had time to test it
[07:14] <unggnu> Ok, thanks.
[07:16] <towolf> mjg59: my position would be: let's defer until a better GUI is available. freetype still ships with lcd_legacy in the code, and enabling it would better a matter of a drop-down combined with the proper fontconfig magic.
[07:16] <towolf> mjg59: it's not either or, both styles are possible. (at the cost of confusion potential)
[07:16] <mjg59> towolf: Right. Once we can handle these cases automatically, I've got no objection
[07:17] <mjg59> But we're not going to be able to do that in time for release
[07:18] <towolf> mjg59: i agree, but Keybuk's scheduling point had merit.
[07:18] <mjg59> towolf: No, if we push it into the beta then it looks bad if we remove it again
[07:18] <towolf> mjg59: and i can assure you that the patches would be a selling point of ubuntu. not a detractor.
[07:18] <mjg59> Because people will write stories about how it's going to be in the release
[07:18] <towolf> i see.
[07:19] <mjg59> Whereas if we get it working at the start of a cycle, there's a much lower probability of us having to remove it
[07:20] <mjg59> Is restarting NetworkManager on upgrade really necessary?
[07:26] <Ng> mjg59: ooi, is your gnome DPI set to your real DPI? If I set mine to roughly what the real DPI of the screen is, the colour hints on vertical parts of glyphs are much harder to see (which I kinda get the feeling should be obvious, and that anything sub-pixel should depend on really knowing where the pixels are)
[07:27] <mjg59> Ng: No, for an LCD running at native resolution the software knows where the pixels are regardless of what the DPI is
[07:27] <mjg59> Altering the DPI is effectively just altering the physical size of your screen while keeping the resolution the same
[07:27] <Ng> mjg59: but the gnome dpi setting demonstrably changes how freetype is rendering the fonts
[07:28] <mjg59> Ng: Because it tries to keep the fonts the same physical size, regardless of the size of the screen
[07:28] <towolf> Ng: could you demonstate that?
[07:28] <mjg59> Which will alter the width of the strokes, and hence also the way the font is rendered
[07:28] <mjg59> It's equivalent to just changing all your font sizes
[07:29] <cromo> alex-weej: ok, it was the radeon driver it seems. vesa works fine.
[07:30] <Ng> towolf: I'll see what I can knock up when I get home :)
[07:30] <cjwatson> mjg59: how about coupling it with an announcement to u-d-a that this is an experimental change, we are soliciting feedback, and may well revert it before release?
[07:30] <mjg59> cjwatson: I don't think that would help. People will review the beta without reading uda.
[07:30] <cjwatson> or even a note in the fonts dialog
[07:31] <Ng> either way my musings about DPI are irrelevant if we're going to hardcode everything to 96dpi :)
[07:31] <cjwatson> though I have to say I'm not sure I care about reviews of beta which assume it's final
[07:31] <mjg59> cjwatson: I don't think we should be putting anything in the beta unless we have no reason to think anything bad is going to happen
[07:32] <towolf> Ng: i don't think freetype cares about anything but target size. this dpi has to be this and that is a myth. unless proven.
[07:32] <mjg59> In this case, I think we have reason to feel that some users will be very unhappy with the change (and some users very happy)
[07:33] <mjg59> Given that we know what the concerns are already, we should introduce the change at a point when we have time to address those concerns - rather than either dismissing them or removing the feature
[07:33] <cjwatson> while I can see your point, I'm worried that it's the-perfect-is-the-enemy-of-the-good
[07:33] <cjwatson> i.e. we never introduce any change until it's perfect
[07:34] <mjg59> I'm happy introducing changes without them being perfect, as long as we think that they'll either be perfect or a decent approximation of it by the time we release the final product
[07:34] <cjwatson> the thing that seems unclear here is whether this change is "the good"
[07:34] <mjg59> We know that this change can't be perfect by release time
[07:34] <cjwatson> we do? I didn't think we had enough information
[07:34] <mjg59> There's nothing we can do to help the people it makes unhappy
[07:35] <cjwatson> somebody suggested an extra fonts-dialog option
[07:35] <cjwatson> modulo naming, would that work?
[07:35] <mjg59> cjwatson: No, not really
[07:35] <cjwatson> why not?
[07:35] <mjg59> That would just give the choice of enabling it or disabling it at a system-wide level
[07:35] <cjwatson> I think that's good enough
[07:35] <mjg59> And would require code changes to freetype, cairo and xft
[07:36] <Mithrandir> I think we are too trigger-happy about adding preferences at the moment, though that's slightly tangential.
[07:36] <mjg59> Which haven't been written yet
[07:36] <cjwatson> so does introducing or reverting the change
[07:36] <cjwatson> (require code changes, albeit written)
[07:36] <cjwatson> I would like to know how complicated those changes would be
[07:37] <mjg59> The UI would be fairly easy, though working out a way of making it make sense to users would be much harder
[07:37] <Keybuk> cjwatson: code easy, UI harder but possible
[07:37] <mjg59> Our existing font configuration is over-complicated already
[07:37] <Keybuk> though since this would appear under Advanced, that's less of an issue
[07:38] <cjwatson> AIUI this change only negatively affects users who have already gone into that dialog
[07:38] <cjwatson> is that true?
[07:38] <mjg59> cjwatson: No
[07:38] <cjwatson> doesn't it chiefly affect a mode which is not switched on by default?
[07:38] <Keybuk> s/chiefly/only/
[07:38] <mjg59> cjwatson: It affects anyone who's enabled sub-pixel anti-aliasing, which is not in the advanced dialog
[07:39] <mjg59> And the fact that we're not enabling sub-pixel anti-aliasing by default on TFTs is a bug anyway, but still
[07:40] <cjwatson> so why would this have to appear in Advanced?
[07:40] <towolf> my experience is, touch anything font-related /anytime/, and a very vocal group will stand up and protest. loudly. this is not contingent on the time of release.
[07:40] <cjwatson> there are already four options there
[07:40] <cjwatson> five doesn't seem a big deal
[07:40] <towolf> only options will appease linux font zelots.
[07:41] <mjg59> cjwatson: Philosophically, because it's an option that shouldn't exist
[07:41] <Mithrandir> if so, we should replace the monochrome one, I'd say.  *hides*
[07:41] <mjg59> Realistically, because it's an option that nobody would understand
[07:41] <cjwatson> huh? I don't understand the four different options there right now
[07:41] <cjwatson> because I am not a font expert
[07:41] <cjwatson> I can see that they look different
[07:41] <cjwatson> and your precise concern is that they look different
[07:41] <mjg59> Oh, right
[07:42] <cjwatson> so I do not believe that that is a problem
[07:42] <towolf> cjwatson: because it doens't make sense, nor reflect reality namingwise.
[07:42] <mjg59> This option would be orthogonal to those four
[07:42] <Mithrandir> cjwatson: but they don't look different at that font size anyway?  Or not very much so, at least?
[07:42] <cjwatson> Mithrandir: different enough to see
[07:42] <iwj> pitti: New dpkg and libc for your delectation, delight and disaster.
[07:42] <towolf> mjg59: not orthogonal at all
[07:42] <cjwatson> and also it's instant-applyu
[07:42] <cjwatson> so you can simply see the effect on your desktop
[07:43] <mjg59> towolf: Subpixel positioning is orthogonal to the anti-aliasing method
[07:43] <cjwatson> so I entirely disagree that this would be incomprehensible
[07:43] <Mithrandir> cjwatson: can you see the difference between "best contrast", "best shapes" and subpixel?
[07:43] <towolf> mjg59: that sentence doesnt make sense to me.
[07:43] <iwj> elmo: that rfc3484 rule 9 disablement ought to be in the beta at this rate; my libc built and tested fine and it's currently awaiting archive admin approval.
[07:43] <cjwatson> Mithrandir: when it instant-applies to my desktop, yes
[07:43] <towolf> mjg59: we do not have subpixel positioning at all, yet
[07:44] <elmo> iwj: super, thanks
[07:44] <slangasek> iwj: default gai.conf that disables it, or patched the code?
[07:44] <iwj> slangasek: (b)
[07:44] <slangasek> spiff
[07:44] <iwj> slangasek: It's trivial; you just changed `no' to `yes' (or v.v) in the default config, and 0 to 1 (or was it v.v) in the code.
[07:44] <mjg59> towolf: I thought the entire point of this code was that it altered the smoothing code to be more willing to align things to subpixel boundaries?
[07:44] <iwj> s/changed/change/
[07:44] <towolf> mjg59: no, yft and cairo don't allow that.
[07:45] <towolf> that's futuristic stuff.
[07:45] <towolf> *xft
[07:45] <mjg59> Ok, so I've misunderstood what changes it actually makes. In that case, why does it reduce the level of pixel alignment?
[07:45] <towolf> they just puzzle rectangles together
[07:45] <towolf> because the rectangles change. but at 1px distances.
[07:46] <towolf> turner has an algorithm in the pipeline that calculates better side bearings, but that's neither subpixel.
[07:46] <towolf> the whole point of the patch is to improve shape while maintaining contrast.
[07:47] <mjg59> towolf: But it improves shape without maintaining contrast
[07:47] <towolf> the fun part of lcd filtering is that it tricks your visual apparatus, into veliving that.
[07:47] <towolf> (or not, in your case)
[07:47] <mjg59> It's turning what used to be white into grey - there's no way that that can improve contrast
[07:48] <towolf> not improve, retain some/much of it.
[07:48] <mjg59> Right. But it's a tradeoff - improved shapes at the cost of contrast
[07:49] <towolf> with a good enough ratio
[07:49] <mjg59> (and increased blurriness, but I'll admit that people make the same accusation against sub-pixel AA in general, so I'm not going to argue that one)
[07:49] <mjg59> towolf: That's purely subjective
[07:49] <towolf> see with increasing font sizes, the trongly hinted way can just flip from on pixel unit to the next
[07:49] <towolf> it's so ugly.
[07:49] <towolf> and 1995
[07:49] <mjg59> With the reduced hinting example you showed, the contast is massively reduced
[07:50] <towolf> at 8pt. no fair.
[07:50] <mjg59> But we have people using 8 point fonts
[07:50] <towolf> let them use xterm
[07:50] <mjg59> No. That's not an option.
[07:50] <mjg59> We don't break existing configurations.
[07:50] <slangasek> the discussion seems to be backsliding, we're back to arguing the subjective merits of the options which isn't going to get us anywhere
[07:51] <towolf> multi-gnome-terminal? my lab post-doc uses that
[07:51] <mjg59> What we should be focusing on is providing a solution that works for a wider range of cases, even if it's somewhat heuristic
[07:51] <Ng> towolf: that's gnome1 though, afaik :(
[07:51] <slangasek> mjg59: but you don't think there's time to craft such a solution before release?
[07:51] <towolf> you're right, we cannot change it just like that.
[07:52] <towolf> they will come with pitchforks.
[07:52] <mjg59> I agree that the new code is almost certainly a win at larger font sizes
[07:52] <towolf> and torches.
[07:52] <mjg59> slangasek: I suspect not
[07:52] <towolf> say browsing the web. (most important task at a pc). it's ahuge improvement.
[07:52] <mjg59> slangasek: I think it'd probably end up requiring quite a lot of tuning
[07:52] <slangasek> right
[07:53] <mjg59> Naively, we could just add fontconfig support to automatically disable this at low font sizes or for monospace fonts
[07:53] <mjg59> I suspect that would deal with most of the issues, but we'd need someone to step forwards and commit to writing that code *now*
[07:53] <Trewas> towolf: there are still very many low-dpi screens (like all 19" 1280x1024 lcds) where 8 pixel fonts are fine and needed to fit enough stuff to screen
[07:54] <towolf> Trewas: it's not the issue, we have options for that case. it's jut that out of a hunch mjg59 prefers one combination that is achievable otherwise.
[07:55] <mjg59> towolf: At the moment, we don't have options for that case
[07:55] <towolf> in the shot you posted, in my eyes the left option was largely compatible with the right side.
[07:55] <Trewas> towolf: anyway, shouldn't the new filtering method still retain sharpness (i.e. not be blurry) in fully hinted case?
[07:55] <pkern> vorlon is called differently here... that feels strange. :)
[07:56] <towolf> Trewas: yes, but there are some interactions that turn out not so great in the end.
[07:56] <towolf> Trewas: it just works best with the autohinter.
[07:57] <towolf> Trewas: the perception is the autohinter is inferior. that's not true.
[07:57] <towolf> Trewas: apple is the holder of the truetype hinting patent. guess what, they abandoned the technology completely.
[07:58] <towolf> there was a blog post by some luminary about safari on windows recently.
[07:58] <towolf> it spawned a sizeable flame-war.
[07:58] <towolf> this will happen with us, too.
[07:59] <mjg59> towolf: The issue is that we're trying to apply a "one size fits all" mentality to this. This isn't going to work.
[08:00] <Trewas> towolf: I read http://antigrain.com/research/font_rasterization/index.html and it seems that hinting is still a benefit with low-dpi screens, even if it is fine for high-dpi screens and scaling is easier
[08:00] <towolf> mjg59: i agree ;-)
[08:00] <mjg59> The requirements of a terminal application are very different to the requirements of a web browser. In one, precise definition of characters is more important than accurately depicting the character shapes. In the other, that's less true/
[08:00] <towolf> Trewas: i agree.
[08:01] <mjg59> My objection at the moment is that the change increases the aesthetics of the common case, but reduces the functionality of the corner case. I'm happy with one, but not the other
[08:01] <towolf> Trewas: i propose some amount of hinting too.
[08:02] <towolf> mjg59: i've been happily using the patch in my terminal usage since 2006. But my res is 129 dpi. and i use at least 12pt.
[08:02] <towolf> mjg59: what you call aesthetics is readability for me.
[08:03] <towolf> mjg59: for me it is significantly improved.
[08:03] <seb128> siretart: the sync tool is confused because the orig already exists in your ppa archive, could you do a fake sync using http://people.ubuntu.com/~pitti/scripts/syncpackage?
[08:03] <towolf> mjg59: if it weren't taseless i would cite a published study proving that (SR vs. monochrome)
[08:04] <towolf> (hint: it's a microsoft typography study)
[08:05] <slangasek> towolf: you don't appear to be arguing anything new or disputed though, you admit that you're using fonts >= 12pt which isn't the problem case?
[08:05] <mjg59> towolf: I'm not using monochrome, and nor have I argued that doing so improves readability
[08:05] <jwendell> seb128, a doubt: was the sound when we log in dropped along with splash screen too?
[08:06] <towolf> strong hinting ~ monochrome (for sufficiently fuzzy values of ~)
[08:06] <seb128> jwendell: no, splash screen is a gconf key change, the sound is due to upstream code changes
[08:06] <jwendell> seb128, ok, i just wanted to know if this is a new 'feature' for gutsy or a bug :)
[08:07] <towolf> slangasek: you can achieve readable fonts at 6pt with the new method. a size where all other methods are not readable at all)
[08:07] <seb128> jwendell: a bug and upstream is on it I think
[08:07] <towolf> slangasek: the issue is habituation.
[08:07] <jwendell> seb128, btw did you understand that question about vino-session?
[08:07] <seb128> jwendell: I don't really understand the vino session thing, why doesn't it register to the session the "normal" way?
[08:07] <towolf> slangasek: and the dishabituation will take some time.
[08:07] <seb128> jwendell: no
[08:07] <slangasek> "doctor, I'm getting a headache from my computer screen" "must be your habituation" :)
[08:08] <jwendell> seb128, indeed, there should be some way to run a executable by watching a gconf key
[08:08] <towolf> slangasek: doctor: here have a transferral receipt to the therapeut, ...
[08:09] <jwendell> seb128, d-bus is the right thing for 2.22
[08:09] <towolf> slangasek: for your phantom pain.
[08:09] <Trewas> towolf: in feisty full hinting with subpixel rendering seems very sharp (more so than non-antialiased case because curves are not blocky), with the new stuff in gutsy the same is quite blurry
[08:09] <slangasek> towolf: um, except it's not phantom pain
[08:09] <slangasek> actually, it's totally valid that one's expectations regarding the text appearance could contribute to greater eye strain
[08:10] <ogra1> a bit gto visible for being a phantom :)
[08:10] <ogra1> s/gto/to/
[08:10] <towolf> Trewas: a result of Vera family with suboptimal settings. it's not enough to just patch the libs.
[08:10] <Trewas> towolf: I am using verdana/tahoma (never liked how vera fonts look)
[08:10] <elmo> hey, all this talk about fonts is giving me a headache, who do I see about that?
[08:10] <elmo> \o/
[08:11] <ogra1> lol
[08:11] <Nafallo> :-)
[08:12] <towolf> the glyphologist
[08:12] <slangasek> towolf: anyway, I don't see that much weight should be given to a claim that "this is the only option that makes 6pt fonts readable" from someone who isn't /using/ 6pt fonts
[08:12] <towolf> slangasek: err, i tested this
[08:12] <slangasek> towolf: but you're not /using/ them
[08:12] <slangasek> which implies you don't actually find them desirable
[08:13] <ogra1> or are forced to use them
[08:13] <seb128> jwendell: well, there is this autostart spec, you just have to add a .desktop
[08:13] <slangasek> so if it makes 6pt fonts legible, but at the same time makes it so no one /wants/ to use anything smaller than 10pt...
[08:14] <seb128> jwendell: and you could make the vino server exit if the key is set
[08:14] <Keybuk> slangasek: it doesn't just make 6pt fonts legible, it changes the appearance of fonts at all sizes
[08:14] <Keybuk> (as is obvious from the fact people noticed the change <g>)
[08:14] <jwendell> seb128, sure, but i mean, some executable must be running in order to watch that key
[08:14] <jwendell> seb128, and who will run vino-server again?
[08:15] <slangasek> Keybuk: yes, I'm aware.  But towolf is trying to assert that the new behavior is better even for smaller fonts -- fonts smaller than anything he actually uses
[08:15] <Keybuk> the discussion should really just be about whether Beta is an appropriate time to test this on our users, or not
[08:15] <towolf> slangasek: screenshots coming up.
[08:16] <slangasek> towolf: then you're missing my point
[08:16] <Keybuk> since we'll just descend into an argument of biblical proportions otherwise :p
[08:17] <ogra1> towolf: screenshots totally dont matter, its a 100% subjective view if you lkike the change or not and if it bothers your eyes or not ... no paper or screenshots will change personal impression here
[08:17] <towolf> slangasek: i don't use small fonts because i like to sit at my computer with a relaxed posture, and not squit.
[08:17] <Keybuk> ogra1: it's also worth noting that people's views appear to change after a night's sleep
[08:18] <Keybuk> (mine certainly did)
[08:18] <cromo> alex-weej: disabling dri makes the ati driver work fine, too.
[08:18] <ogra1> Keybuk: yes, mine didnt yet but i noticed the comments
[08:18] <alex-weej> cromo: i'm sorry i didn't see what (if anything) you wrote before
[08:18] <alex-weej> cromo: ah, vesa works
[08:18] <alex-weej> cromo: ok, so have you filed a report on this?
[08:19] <alex-weej> and are you using Compiz?
[08:19] <seb128> jwendell: again? you have a .desktop it's run at every login
[08:19] <towolf> ogra1: wasn't the point that the new way doesn't work with small type, and i wanted to disprove that FUD?
[08:19] <seb128> jwendell: and you make vino-server exit on startup if the key is set
[08:20] <seb128> jwendell: that's not starting vino-server, looking the key value and returning that will load your box
[08:20] <mjg59> towolf: It depends what you mean by "work". It reduces contrast and definition, but improves the shaping.
[08:20] <seb128> jwendell: I'm away for dinner, be back later
[08:21] <ogra1> towolf: my personal as that my eyes start to tear after a while with these fonts ... no matter how big they are on my 1024x768 screen
[08:21] <ogra1> s/personas as/personal concern was/
[08:22] <Trewas> towolf: I think the new way makes smaller-than-usable fonts look legible (say 6 pixels) but actually hurts for small-but-still-usable case (say 8 pixels)
[08:22] <towolf> ogra1: but you are seasoned unix users, you have been using those fonts since decades. a change will unequivocally be wrong to you.
[08:23] <mjg59> towolf: No, that doesn't fit with me preferring the new code for the desktop applications
[08:23] <ogra1> towolf: i even used fonts when there wqas no antialiasing ... that doesnt make them appear less blurry to me though
[08:23] <towolf> ogra1: thanks for proving the point.
[08:24] <towolf> anyhow, after two nautilus crashes: ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot4.png
[08:24] <towolf> ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot5.png
[08:24] <mjg59> towolf: None of those are readable at my screen resolution
[08:24] <towolf> for sufficiently small values of readable.
[08:24] <mjg59> Expanding them, the middle one is more legible
[08:24] <towolf> decipherable.
[08:25] <mjg59> But that's not the setting we were proposing to ship
[08:25] <slangasek> towolf: no, the point is that you, as someone who isn't using 8pt fonts, should not have more weight given to your opinion than the folks who are actually using fonts of that size, no matter how you try to bolster your opinion with screenshots or studies
[08:27] <towolf> slangasek: but that's why Keybuk proposed to throw the stuff into the wild, to have /all/ ubuntu users have a go at it, right?
[08:27] <slangasek> yes
[08:27] <slangasek> but that's not the discussion you're continuing to have here :)
[08:27] <towolf> slangasek: all includes my mom and dad, and of course ubuntu devs running terminals at 8pt.
[08:28] <mjg59> Anyway. I suspect strongly that it would be helpful for someone to work on an implementation for ensuring that the choice of method can be chosen at runtime, and then adding fontconfig support for changing it based on font families or size
[08:28] <mjg59> Is anyone going to volunteer to do that?
[08:28] <towolf> slangasek: no, you guys dragged me into the "it doesn't work at 8pt" discussion
[08:28] <ogra1> towolf: you shouldnt let your mom and dad run gutsy ;)
[08:28] <alex-weej> cromo: did you answer my q? sorry, i crashed
[08:29] <Keybuk> mjg59: if the guidelines of what people want are clear, I have no problem doing that
[08:29] <towolf> mjg59: let's hope someone with a good sense of HIG and humanity.
[08:29] <alex-weej> crashed loading towolf's links
[08:29] <Keybuk> having reviewed the code quite heavily already, I know where the bits need to go
[08:29] <mjg59> towolf: I suspect that it can be done without appearing in the user interface at all
[08:29] <towolf> mjg59: whoa, be careful with one-size fits all.
[08:30] <towolf> mjg59: the proposal by david turner on the cairo list i cited earlier seemed very reasonable.
[08:30] <mjg59> towolf: I agree that it's impossible to make everyone happy. The aim is to make enough people happy that a sufficiently small number of people want to change the option that there's no need to put it in the UI
[08:30] <towolf> mjg59: it explicitely contained a truetype optimized option.
[08:30] <towolf> mjg59: and a deactivate aa below x-pt.
[08:31] <towolf> don't assume a point size to do that.
[08:31] <mjg59> Keybuk: My handwavy assertion is that, by default, we should automatically use the old method on monospace fonts below 9 points
[08:32] <mjg59> This is assuming that we stick to the current defaults, ie sub-pixel defaults to full hinting
[08:32] <Keybuk> 9pt at which dpi?  9pt at 200dpi is a somewhat larger glyph than at 96?
[08:32] <mjg59> 9pt is 9pt
[08:32] <Keybuk> the existing fontconfig checks seem to be based on pixel size
[08:33] <mjg59> Ok. If it's pixel-sized, then that's easier
[08:33] <Keybuk> 9pt is 0.125" on the screen :)
[08:33] <mjg59> A quick play suggests 12 pixels would leave me happy
[08:35] <mjg59> Keybuk: Just to clarify - by "old method" I mean "the old sub-pixel colour filtering" and not "monochrome"
[08:35] <Keybuk> this would appear to mean setting the filter to "legacy" correct?
[08:36] <mjg59> Yes
[08:36] <mjg59> At least, that's my understanding
[08:36] <towolf> mjg59: we should not stick to full hinting. (saying this seems futile)
[08:36] <towolf> Keybuk: correct
[08:36] <mjg59> towolf: There's a sufficient decrease in contrast that reducing hinting for terminals is not a good idea
[08:37] <Keybuk> mjg59: depending on terminal colour?
[08:37] <mjg59> Keybuk: My /impression/ is that the new filter is perfectly reasonable at 10 pixels on non-monospace
[08:38] <towolf> i realized that you never posted a screenshot of your terminal, without magnification.
[08:38] <mjg59> towolf: It looked pretty much identical to the one you posted
[08:38] <towolf> okay
[08:38] <mjg59> towolf: Am I right in thinking that that used full hinting?
[08:38] <towolf> the one in your email?
[08:38] <mjg59> No
[08:39] <towolf> the white-on-black one?
[08:39] <mjg59> screenshot3
[08:39] <mjg59> Yes
[08:39] <towolf> no, didn't use full hinting.
[08:40] <towolf> would have entailed killing my x
[08:40] <mjg59> Ok, interesting. My fully hinted one looked almsot identical.
[08:40] <towolf> mjg59: see? you're getting there. ..
[08:41] <mjg59> towolf: ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot1.png clearly has reduced contrast on the unhinted version
[08:41] <towolf> smaller font.
[08:42] <towolf> smaller to a degree where the stems used a thickness of < 1px. below that the becvome gray.
[08:42] <towolf> because there's no hinting involved to flip them back to 1px.
[08:42] <mjg59> towolf: Right, exactly
[08:42] <mjg59> For small fonts we probably want hinting in order to keep the contrast high
[08:43] <mjg59> For larger fonts, the contrast will be good enough anyway and we can concentrate on shapes
[08:43] <towolf> mjg59: 1. yes, that should be possible, 2. we is not defined here
[08:43] <towolf> we as in "we"
[08:44] <mjg59> For certain applications, contrast is more important than shaping
[08:44] <towolf> because i am a lot more comfortable with reading the center in screenshot1.png
[08:45] <Keybuk> mjg59: ok, that patch seems possible
[08:45] <mjg59> Keybuk: Ok, I think that makes me massively happier
[08:45] <Keybuk> it would be in the form of a fontconfig option to set the lcd filter
[08:45] <mjg59> Yeah
[08:45] <Keybuk> you'd drop something in conf.d to set hinting=legacy when pixelsize <= 8
[08:45] <Keybuk> for example
[08:45] <mjg59> Right
[08:45] <Keybuk> (or 12 or whatever you like)
[08:45] <mjg59> I think we want to ship one of those by default
[08:46] <Keybuk> then cairo, xft, etc. would call FT_Library_SetLcdFilter with what fontconfig says, not FT_LCD_FILTER_DEFAULT
[08:46] <mjg59> Yes, that sounds appropriate
[08:46] <Keybuk> as you say, we can ship that by default maybe with a debconf option or something
[08:47] <mjg59> As I said, I /think/ it's primarily an issue with monospace
[08:47] <mjg59> So we could just default it there and leave the others
[08:47] <mjg59> I suspect that will avoid upsetting console-oriented people, and make desktop-oriented people happy at the same time
[08:47] <mjg59> Anyway -> shops
[08:47] <mjg59> Back in 10
[08:47] <Keybuk> mjg59: with that patch, you'd remove your objection to it being in beta?
[08:48] <Keybuk> slangasek: would release team be happy with the patches going in for beta (including the patch proposed by mjg59?)
[08:48] <towolf> mjg59: it's a problem with web browsers and all other apps too, actually.
[08:48] <lamont> slangasek: expect_5.43.0-13.1 uploaded to debian, you want the sync request now, or once it is in the archive?
[08:48] <towolf> mjg59: you're just more used to the terminal.
[08:48] <lamont> and I missed today's dinstall run
[08:49] <slangasek> Keybuk: as this resolves the main objection where we know ahead of time that some people are unhappy with the behavior change, yes
[08:51] <slangasek> lamont: no preference
[08:53] <Mithrandir> lamont: it won't be acted on until it's in the archive anyway. :-P
[08:57] <mjg59> Keybuk: I think so, yes
[09:00] <jamiemcc> seb128: any chance o3read could be promoted to main as its small and is needed by tracker to index openoffice files?
[09:02] <Mithrandir> jamiemcc: it needs a main inclusion report.
[09:02] <Mithrandir> https://wiki.ubuntu.com/MainInclusionProcess
[09:03] <pkern> slangasek: So you joined Canonical very recently?
[09:03] <jamiemcc> mithrandir: I know - but such decisions are discussed here?
[09:04] <towolf> i was able to get through the pay wall to get the readability paper. it looks not really exciting apart from the difference when italics are used.
[09:04] <towolf> did anyone mention that italics are a *lot* better with the new method?
[09:04] <Mithrandir> jamiemcc: they're quite often not really discussed, just carried out
[09:05] <jamiemcc> mithrandir: who does the inclusion reports?
[09:05] <seb128> jamiemcc: pitti usually
[09:05] <Mithrandir> whoever has an interest in getting the package into main writes it
[09:05] <seb128> jamiemcc: the easier is to file the wiki page
[09:05] <Mithrandir> it's reviewed by pitti and iwj
[09:05] <seb128> jamiemcc: the wiki page has the informations required to make a decision
[09:05] <evand> yay, the new nvidia driver potentially fixes the compiz black windows bug, finally.
[09:06] <pochu> jamiemcc: I could help a bit with the report
[09:06] <jamiemcc> seb128: ok should I write the report then?
[09:06] <seb128> jamiemcc: either do it or convince somebody to do it for you ;)
[09:06] <jamiemcc> thx - pochu are you familiar with the process?
[09:06] <pochu> jamiemcc: tracker's report looks good to take as an example: https://wiki.ubuntu.com/MainInclusionReportTracker :)
[09:07] <pochu> jamiemcc: I know how to do it, although I have never done it
[09:07] <pochu> jamiemcc: but there's always a first time, isn't there? ;)
[09:07] <jamiemcc> pochu: yeah - can you make a start on it? (im still fixing tracker bugs atm(
[09:08] <pochu> jamiemcc: sure thing!
[09:08] <jamiemcc> pochu: thx very much
[09:08] <pochu> np
[09:17] <slangasek> pkern: this week, yes
[09:18] <pkern> slangasek: As Ubuntu RM?
[09:21] <Keybuk> GTK+ font rendering is done through Cairo now, right?
[09:32] <seb128> mjg59: could you look at bug #140485 some people still have gnome-settings-daemon crashing, might be due to the synaptic changes
[09:32] <ubotu> Launchpad bug 140485 in xserver-xorg-input-synaptics "gnome-settings-daemon not starting with 1:2.19.92-0ubuntu3" [Medium,In progress]  https://launchpad.net/bugs/140485
[09:33] <mjg59> seb128: Checking
[09:33] <seb128> mjg59: I think there is not enough information to have a good idea of the issue but maybe you know what to ask
[09:35] <mjg59> seb128: Hm, interesting. I have a suspicion.
[09:35] <alex-weej> pitti: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/120957/
[09:35] <ubotu> Launchpad bug 120957 in update-manager "UpdateManager fails to fetch dist-upgrade tarball" [High,Confirmed]
[09:36] <mjg59> seb128: It's possible that they're machines with a synaptics driver entry but no synaptics pad
[09:36] <seb128> ok, if you could deal with it that would be nice ;)
[09:36] <mjg59> I'll see if I can reproduce
[09:37] <pochu> jamiemcc: could you check, specially point 5? I haven't touched that point (copy&paste from tracker report for it hehe) https://wiki.ubuntu.com/MainInclusionReportO3Read
[09:39] <jamiemcc> pochu: I think the deb for o3read compies with debian policy (the rest looks irrelevant)
[09:39] <bryce> where are the release notes for gutsy beta being compiled?  I've got an entry or two to add.
[09:39] <alex-weej> pitti: oops sorry on the phone and that was a bit rude
[09:39] <alex-weej> pitti: any ideas what's happening with that bug?
[09:39] <pochu> jamiemcc: ok, editing
[09:41] <MacSlow> hi Gman, bryce
[09:41] <bryce> hi MacSlow
[09:41] <Gman> hey MacSlow
[09:42] <pochu> jamiemcc: the binary is lintian-clean, and the source has just a couple minor warnings, so I'd say it is
[09:42] <pochu> jamiemcc: updated, what do you think?
[09:42] <jamiemcc> pochu: looks good - thanks
[09:42] <slangasek> pkern: yep
[09:44] <pochu> jamiemcc: cool, adding to the queue now
[09:44] <jamiemcc> pochu: thx
[09:44] <pitti> iwj: dpkg> thanks, I'll have a look; how bad was the libc patch in the end?
[09:44] <tepsipakki> Keybuk: I thought that cleartype is not used because of the MS patent?
[09:44] <pitti> alex-weej: no problem, looking
[09:45] <pitti> alex-weej: well, it says so in the bug, there are more imports needed
[09:45] <mjg59> Hrm. Ok, doesn't /seem/ to be that
[09:46] <Keybuk> tepsipakki: it wasn't used because we didn't know about it :)
[09:46] <pitti> jamiemcc: MIR> I'll have a look if it is urgent/important, but I prefer to not have too many changes any more
[09:46] <tepsipakki> Keybuk: right, ok :) I'm looking forward to that
[09:47] <mjg59> Is there anyone here who's suffering from #140485 ?
[09:47] <pochu> pitti: well, if it's ok to promote it, it isn't such a big change... :)
[09:47] <jamiemcc> pitti: yeah although some people are compalining tracker does not index Openoffice files - I guess it improves the user experience and o3read is tiny
[09:47] <pitti> jamiemcc: right
[09:48] <pochu> pitti: see bug 117307
[09:48] <ubotu> Launchpad bug 117307 in tracker "Tracker doesn't index openoffice.org files" [Undecided,Invalid]  https://launchpad.net/bugs/117307
[09:48] <pitti> jamiemcc: well, just assume it would crash for some reason, then we would have this crash installed for every tester of beta, and so on
[09:48] <pitti> pochu: that doesn't sound like 'invalid'
[09:49] <jamiemcc> pitti: if it crashed it would be out of process so would not harm trackerd
[09:49] <pochu> pitti: well, it's a recommends, and we install recommends by default... that's why I closed it
[09:49] <pochu> pitti: when tracker wasn't in main yet
[09:50] <pitti> pochu: ah, I see; but we don't install it as part of -desktop
[09:50] <pochu> pitti: o3read? right, I guess the bug is valid now...
[09:52] <stgraber> iwj: You may have received two e-mails from the Ubuntu QA Tracker, you can ignore them. That was just test e-mails that shouldn't have left my server :)
[09:53] <towolf> mjg59: i have the persistent gsd crasher with synaptics here.
[09:54] <towolf> mjg59: i could test something
[09:54] <mjg59> towolf: Could you do gdb /usr/bin/gnome-settings-daemon
[09:54] <mjg59> break gdk_x_error
[09:54] <mjg59> run --sync
[09:55] <mjg59> and then, when it stops, do bt and give me the backtrace?
[09:55] <towolf> mjg59: do i need something like -dbg?
[09:56] <mjg59> towolf: We don't build a debug package for it sadly, so no
[09:56] <mjg59> With luck there'll be enough information for me to get an idea about what's going on
[09:56] <towolf> mjg59: at the start it spews: Function "gdk_x_error" not defined.
[09:57] <mjg59> Yeah, that's fine
[09:57] <towolf> mjg59: then: (no debugging symbols found)
[09:57] <towolf> mjg59: (gdb) bt
[09:57] <towolf> No stack.
[09:57] <mjg59> Did it spit out the error?
[09:57] <towolf> mjg59: the stderr is not interesting, is it?
[09:57] <towolf> mjg59: no?
[09:58] <towolf> mjg59: yes, the output of the program, yes.
[09:58] <mjg59> towolf: You told it to make the breakpoint pending on future shared library load?
[09:58] <towolf> mjg59: hold on
[09:59] <towolf> mjg59: no stack, with y earlier.
[09:59] <mjg59> What caused it to break?
[10:00] <towolf> mjg59: and a couple times, "hit return to"
[10:00] <mjg59> Hit return to what?
[10:00] <towolf> mjg59: This?: Program exited with code 01.
[10:00] <towolf> (no debugging symbols found)
[10:00] <towolf> ---Type <return> to continue, or q <return> to quit---
[10:00] <mjg59> Ok. In that case the breakpoint didn't work
[10:01] <towolf> let's paste the entire thing somewhere
[10:02] <seb128> mjg59: we do build dbgsym for everything no?
[10:03] <mjg59> seb128: There doesn't seem to be a -dbg package for control-center
[10:03] <seb128> mjg59: you don't know about https://wiki.ubuntu.com/DebuggingProgramCrash ?
[10:03] <seb128> mjg59: deb http://people.ubuntu.com/~ubuntu-archive/ddebs gutsy main universe
[10:04] <mjg59> Oh, yes.
[10:04] <seb128> mjg59: that source should have -dbgsym for every binary built
[10:04] <mjg59> Well, let's see if we can actually get a breakpoint first :)
[10:04] <Keybuk> http://people.ubuntu.com/~scott/fontconfig.patch
[10:04] <Keybuk>   (and libcairo.patch and xft.patch alongside)
[10:05] <towolf> mjg59: http://en.pastebin.ca/705069
[10:05] <towolf> mjg59: the Warnings are because i used to use evdev for my keyboard, but disabled it, just in case.
[10:06] <mjg59> towolf: Hrm.
[10:06] <mjg59> Try break gdk_x_error() ?
[10:06] <mjg59> Though I don't /think/ that makes any difference
[10:07] <pitti> iwj: your glibc upload doesn't mention the bug# in the changelog; you'll close it manually, I take it?
[10:08] <towolf> nope
[10:08] <mjg59> Sigh.
[10:09] <towolf> reminds me of the old evdev mouse driver gsd crash.
[10:09] <towolf> that was a pain to debug too
[10:09] <Keybuk> mjg59: is that the kind of patch you were after?
[10:09] <ScottK> pitti: I have a question about fixing the current FTBFS in sdl-mixer1.2.  There's a new Debian revision that solves the FTBFS plus other stuff.  At this point assuming both build (we're still testing), would you rather a sync or just the one patch: http://packages.debian.org/changelogs/pool/main/s/sdl-mixer1.2/sdl-mixer1.2_1.2.6-3/changelog
[10:11] <mjg59> Keybuk: Looks promising, yup
[10:11] <pitti> ScottK: judging by that changelog, I'd rather sync
[10:11] <Keybuk> mjg59: my only concern is that this adds a fair amount of new API to several libraries
[10:11] <ScottK> pitti: Thanks.  Assuming it tests out OK, we'll ask for a sync.
[10:12] <mjg59> Keybuk: Several? Surely it's one API addition to Fontconfig?
[10:12] <Keybuk> fontconfig gains the new lcdfilter option, yes
[10:12] <Keybuk> xft just needs to use that, so no biggy
[10:12] <Keybuk> though it does add an entry to an internal struct
[10:12] <seb128> mjg59: you might need the dbgsym to break on a symbol, not sure if it can resolve with a stripped version
[10:12] <Keybuk> cairo is the annoying one, since it has to grow cairo_lcd_filter_*
[10:13] <Keybuk> yay for every library wrapping the functions of the libraries they use which are functions wrapping other wrapper functions
[10:13] <towolf> seb128: installing dbgsym ...
[10:14] <mjg59> towolf: You might need the gdk ones as well, in that case
[10:14] <towolf> mjg59: package?
[10:14] <seb128> towolf: iinstall libglib2.0-0-dbgsym libgtk2.0-0-dbgsym gnome-control-center-dbgsym
[10:14] <mjg59> Keybuk: These are internal libraries?
[10:15] <towolf> ok, broke(sic?) at gdk_x_error
[10:15] <towolf> #0  gdk_x_error (display=0x808f100, error=0xbfb01608)
[10:15] <towolf>     at /build/buildd/gtk+2.0-2.12.0/gdk/x11/gdkmain-x11.c:614
[10:15] <towolf> #1  0xb714d655 in ?? () from /usr/lib/libbonoboui-2.so.0
[10:15] <towolf> #2  0x0808f100 in ?? ()
[10:15] <towolf> #3  0xbfb01608 in ?? ()
[10:15] <towolf> #4  0x00000000 in ?? ()
[10:16] <seb128> towolf: libbonoboui2-0-dbgsym
[10:17] <towolf> #0  gdk_x_error (display=0x808f100, error=0xbfe6b178)
[10:17] <towolf>     at /build/buildd/gtk+2.0-2.12.0/gdk/x11/gdkmain-x11.c:614
[10:17] <towolf> #1  0xb7156655 in bonobo_x_error_handler (display=0x808f100, error=0xbfe6b178)
[10:17] <towolf>     at bonobo-ui-main.c:58
[10:17] <towolf> #2  0xb7f47f50 in xkl_process_error () from /usr/lib/libxklavier.so.11
[10:17] <towolf> #3  0xb7837c4a in _XError () from /usr/lib/libX11.so.6
[10:17] <towolf> #4  0xb7839714 in _XReply () from /usr/lib/libX11.so.6
[10:17] <towolf> #5  0xb78f0b32 in XOpenDevice () from /usr/lib/libXi.so.6
[10:17] <towolf> #6  0x0805dcbb in ?? ()
[10:17] <towolf> #7  0x0808f100 in ?? ()
[10:17] <towolf> #8  0x00000001 in ?? ()
[10:17] <towolf> #9  0xbfe6b2c8 in ?? ()
[10:17] <towolf> #10 0xb7e2d337 in gconf_client_get_bool () from /usr/lib/libgconf-2.so.4
[10:17] <towolf> #11 0x0805ddb8 in ?? ()
[10:17] <towolf> #12 0x080a4758 in ?? ()
[10:17] <towolf> #13 0x0806ebdc in ?? ()
[10:17] <mjg59> Keybuk: Hm. I may be misunderstanding this. libcairo doesn't seem to actually use those functions you've added?
[10:17] <towolf> #14 0x00000000 in ?? ()
[10:17] <mjg59> towolf: Are you sure you have gnome-control-center-dbgsym ?
[10:18] <slangasek> Keybuk: so if it's an API addition to fontconfig, do you feel we should get buy-in from keithp before committing to that path?
[10:18] <towolf> mjg59:  *** 1:2.20.0-0ubuntu1 0 from people.ubuntu.com
[10:19] <seb128> towolf: you can use http://pastebin.ubuntu.com/ rather than the chan to copy backtraces
[10:19] <mjg59> seb128: Hm. Any idea why those symbols aren't resolving?
[10:19] <towolf> seb128: alright, what now?
[10:19] <seb128> towolf: you might want to install libxi6-dbgsym libxklavier11-dbgsym
[10:19] <towolf> seb128: on it.
[10:19] <seb128> and libx11-6-dbgsym
[10:19] <Keybuk> mjg59: it uses the set_lcd_filter one
[10:20] <mjg59> Sorry, you're right
[10:20] <seb128> mjg59: lacking dbgsym for some libraries like libx11, libxi, etc
[10:20] <mjg59> seb128: Ah, ok
[10:20] <mjg59> Keybuk: Hm. __ it?
[10:20] <Keybuk> mjg59: :)
[10:20] <slangasek> twitch
[10:20] <Keybuk> it shows up in a size change to cairo_font_options_t
[10:20] <mjg59> Oh, of course
[10:21] <Keybuk> but the contents of that struct are hidden
[10:21] <mjg59> Hmph.
[10:21] <mjg59> Yeah, less of a problem then
[10:21] <Keybuk> the headers only include a typedef for it
[10:21] <mjg59> And that's only used internally?
[10:21] <Keybuk> yeah
[10:22] <towolf> seb128: http://en.pastebin.ca/705091
[10:22] <mjg59> Still seem to be missing most of the symbols
[10:22] <slangasek> well, part of the backtrace looks wonky too
[10:23] <slangasek> #8  0x00000001 in ?? ()
[10:23] <mjg59> Hm. Yeah.
[10:23] <mjg59> All the symbols that /do/ turn up are plausible
[10:23] <mjg59> I've got a pretty good idea of where it's falling over, I've just got no idea why
[10:25] <Keybuk> mjg59: yup, works even if I make the function private
[10:25] <mjg59> Ok. I suspect we can work around this by surrounding the entire block in gdk_error_trap_push()/gdk_error_trap_pop(), but I'd prefer to know /why/ it's happening
[10:26] <josephpiche> sorry, i got disconnected. Is there a process for reviewing a spec/blueprint for decline?
[10:26] <pitti> good night everyone
[10:27] <seb128> towolf: can you "sudo apt-get install --reinstall gnome-control-center/gutsy"?
[10:27] <seb128> towolf: did you do a local build or something?
[10:27] <towolf> seb128: no
[10:28] <towolf> seb128:  do i have to quit gdb everytime?
[10:28] <seb128> yes
[10:28] <towolf> or can i just .. ok
[10:29] <seb128> "#6  0x0805dcbb in ?? ()" looks like something that should come from gnome-settings-daemon
[10:29] <towolf> seb128: ah...
[10:29] <seb128> I'm not sure why it has no debug information
[10:29] <seb128> usually that's because the package and the dbgsym don't come from the same build
[10:29] <towolf> seb128: whats this? You can only run one xsettings manager at a time; exiting
[10:30] <seb128> like a local build against a buildd one
[10:30] <towolf> seb128: shit, my bad
[10:31] <towolf> seb128: nah, same thing
[10:32] <towolf> seb128: only the numbers differ
[10:33] <seb128> towolf: if you do
[10:33] <seb128> $ gdb /usr/bin/gnome-settings-daemon
[10:33] <seb128> symbol-file /usr/lib/debug/usr/lib/gnome-control-center/gnome-settings-daemon
[10:33] <seb128>
[10:33] <seb128> does it work?
[10:34] <towolf> seb128: oh.
[10:34] <seb128> ?
[10:35] <towolf> seb128: all this pasting takes a while. but there's more now. http://en.pastebin.ca/705105
[10:35] <seb128> mjg59: ^
[10:35] <seb128> here you go
[10:35] <seb128> ;)
[10:36] <mjg59> towolf: Can you type "up" until you're at the frame for set_tap_to_click ?
[10:37] <seb128> weird that gdb didn't get the debug symbols automatically, gnome-settings-daemon seems to have a .gnu_debuglink
[10:38] <towolf> mjg59: ang "bt"?
[10:38] <towolf> *and
[10:38] <mjg59> towolf: print devicelist[i] .name
[10:39] <towolf> mjg59: lokks like this: (gdb) print devicelist[i] .name
[10:39] <towolf> $1 = 0xb7fc8e73 "\203\024\211e\f"
[10:39] <towolf> mjg59: gibberish?
[10:39] <mjg59> Hm. That doesn't look right.
[10:40] <mjg59> How many times does the phrase "Synaptics Touchpad" appear in your /etc/X11/xorg.conf ?
[10:40] <seb128> towolf: you can try to "thread apply all bt full" to list also local variables in the backtrace
[10:40] <towolf> seb128: restart first?
[10:40] <seb128> yes
[10:40] <seb128> hum
[10:40] <seb128> no
[10:40] <seb128> no need in fact for that ;)
[10:41] <seb128> also maybe copy your xorg.conf somewhere
[10:42] <towolf> a'ight: new bt: http://en.pastebin.ca/705114
[10:43] <towolf> and xorg.conf: http://en.pastebin.ca/705115
[10:43] <ant30> Hi, I has reported a bug to update-notifier with the solution . It is for upgrade from feisty to Gutsy
[10:46] <towolf> mjg59: twice
[10:57] <towolf> seb128: i'll be having a visitor in 10min, anything else i can do?
[10:59] <towolf> mjg59:
[10:59] <mjg59> towolf: Looking at it, but not having much joy so far
[11:00] <towolf> mjg59: i'm sorry for that ...
[11:00] <mjg59> No problem
[11:01] <seb128> towolf: maybe copy the backtrace and the xorg.conf on the bug
[11:01] <seb128> towolf: thanks for the work on it
[11:03] <ScottK> seb128: Do you ahve time to look at a sync that will fix a Main FTFBS?
[11:03] <seb128> ScottK: yes
[11:03] <ScottK> It's Bug #141351
[11:03] <ubotu> Launchpad bug 141351 in sdl-mixer1.2 "Please sync sdl-mixer1.2_1.2.6-3 from debian unstable main" [Medium,New]  https://launchpad.net/bugs/141351
[11:03] <ScottK> Thanks
[11:03] <seb128> you're welcome
[11:04] <YokoZar_> Do the package.install and package.dirs files respect architecture flags?  ie, can I have usr/lib32 [amd64]  in debian/package.dirs ?
[11:04] <seb128> ScottK: I use your id for the sync, ok?
[11:05] <ScottK> seb128: If you want
[11:05] <ScottK> They guy that filed the bug did all the work.  I'm good either way.
[11:05] <seb128> ScottK: do you know him?
[11:05] <towolf> seb128:  done. signing off.
[11:05] <seb128> ScottK: I just want to get somebody responsive notified if the build fails
[11:05] <seb128> towolf: thanks
[11:05] <ScottK> I'll do for that then.
[11:06] <Keybuk> mjg59: \o/
[11:07] <mjg59> Keybuk: ?
[11:07] <seb128> ScottK: the guy is member of some teams already, I've used his account for the sync
[11:07] <ScottK> seb128: Fine by me
[11:07] <seb128> ScottK: bug closed ;)
[11:07] <ScottK> seb128: Thanks
[11:08] <YokoZar_> Do the package.install and package.dirs files respect architecture flags?  ie, can I have usr/lib32 [amd64]  in debian/package.dirs ?
[11:08] <YokoZar_> oops sorry for repost
[11:08] <ScottK> seb128: Do packages that were dep waiting on that one automatically get queued to build or do they need a manual shove?
[11:08] <seb128> ScottK: dep wait works automatically
[11:09] <ScottK> seb128: Cool.  Thanks.
[11:09] <seb128> YokoZar_: I don't think so
[11:09] <seb128> I'm not totally sure though
[11:09] <seb128> I didn't have to use that myself yet
[11:10] <Keybuk> mjg59: lcdfilter gets passed all the way from fontconfig up to gnome-terminal
[11:10] <Keybuk> now I just have to figure out how to get fontconfig to match the monospace font
[11:10] <Keybuk> for some reason, test name=family never works on monospace
[11:10] <YokoZar_> seb128: I'm just worried about my package making an empty /usr/lib32 directory on a 32 bit machine
[11:11] <seb128> YokoZar_: maybe that's the upstream makefile doing it?
[11:11] <seb128> YokoZar_: empty dirs usually don't hurt though
[11:11] <YokoZar_> no it's nothing upstream yet
[11:12] <slangasek> seb128: well, it's not supported by upstream debhelper anyway
[11:13] <slangasek> YokoZar_: I would suggest conditionally setting a variable in debian/rules based on the host architecture, containing the list of "extra" directories you're adding, and then pass that as an argument to dh_installdirs
[11:14] <slangasek> (n.b., if this source package builds more than one binary package, you'll also want to use -p and -N options to make sure you don't add the dir to packages that don't need it)
[11:14] <slangasek> oh... also, if this is a /non/-empty dir in the package, you normally don't need to list it in .dirs at all...
[11:14] <YokoZar_> slangasek: it builds two binaries, one of which is dependent on the other (wine and wine-dev)
[11:15] <YokoZar_> slangasek: I'm also thinking about the install file
[11:15] <slangasek> yes, for the install file I have no good answers
[11:16] <YokoZar_> slangasek: if the install file points to something not there (say, usr/lib32/*.so.* on i386), will bad things happen?
[11:16] <slangasek> yes, you'll get a build failure
[11:16] <slangasek> one option: create two separate .install files, symlink to the right one during the build
[11:16] <YokoZar_> Something like wine.install.i386 and wine.install.amd64 ?
[11:17] <slangasek> yes
[11:17] <Keybuk> heh
[11:17] <Keybuk> because I'm not using Vera, but DejaVu
[11:18] <YokoZar_> slangasek: for some reason I think that which .install.arch file to use should be handled automagically, but it's probably just bad memory
[11:18] <Keybuk> mjg59: 12px?
[11:20] <mjg59> Keybuk: Sounds reasonable.
[11:20] <slangasek> YokoZar_: oh, actually it does
[11:20] <slangasek> right, I had a vague memory of that
[11:20] <YokoZar_> slangasek: oh, cool.  So all I should have to do is just have those files then, and no wine.install file
[11:20] <slangasek> YokoZar_: seems so, yes
[11:22] <YokoZar_> slangasek: actually, I bet (hope) that the way it works is it calls the arch one first and then the general one.  So I'm supposed to put ones common to both in wine.install, and then amd64 specific ones (usr/lib32) into wine.install.amd64
[11:22] <slangasek> YokoZar_: nope, if it finds an arch one it ignores the general one
[11:22] <YokoZar_> slangasek: ahh ok
[11:29] <YokoZar_> slangasek: thank you so much, hopefully I'll have a good Wine package by beta time :)
[11:29] <rawler_> hey.. does anyone know anything about whether nvidia 100.14.19 will make it to Gutsy?
[11:35] <ajmitch> good morning
[11:36] <Keybuk> mjg59: 12px is perfect, my fonts are 13px high <g>
[11:36] <seb128> hey ajmitch
[11:36] <mjg59> Keybuk: Ha
[11:36] <Keybuk> (and since I've been using the new filter for the last few days, I've gotten used to it and now prefer it)
[11:36] <Keybuk> anyhoo
[11:36] <Keybuk> http://people.ubuntu.com/~scott/lcdfilter
[11:37] <Keybuk> source packages and debdiffs for your testing pleasure
[11:37] <Keybuk> works for me (tm)
[11:39] <bryce> rawler_: it's too late; we've been in Upstream Version Freeze for a while
[11:39] <mjg59> Keybuk: What's the change to gnome-control-center?
[11:39] <Keybuk> mjg59: changes the top "subpixel" option to use hinting=Slight
[11:39] <Keybuk> which every single thing says is the right option
[11:39] <Keybuk> (with turner's patches)
[11:40] <rawler_> bryce: I kindof figured.. it's too bad.. it fixes a buttload of bugs..
[11:40] <bryce> rawler_: I'll probably make backport debs of it available at some point though once the dust has settled on gutsy
[11:40] <mjg59> Keybuk: Uh. No, I suspect not for the monospace case
[11:40] <Keybuk> mjg59: indeed, which is why the conf.d for the monospace case sets the hinting level :p
[11:40] <Keybuk> (as well as the lcd filter)
[11:40] <mjg59> Keybuk: Ah, ok :)
[11:41] <rawler_> bryce: sounds reasonable.. :) personally I'll resort to envy for now, but it just sucks having to do that for every nvidia-user i persuade into Ubuntu.. :)
[11:41] <mjg59> Slight hinting absolutely kills monospace at low font sizes
[11:42] <alex-weej> Keybuk: PPA? :)
[11:42] <Keybuk> mjg59: hinting gets disabled completely for monospace at low font sizes
[11:42] <mjg59> Now, or previously?
[11:42] <bryce> rawler_: would you be interested in helping with this driver?  A large reason we're not up to date is just manpower
[11:42] <Keybuk> previously and now
[11:42] <mjg59> Hm.
[11:42] <Keybuk> conf.d/20-unhint-small-vera.conf
[11:42] <mjg59> That doesn't fit what I see - altering the hinting settings changes my terminal
[11:42] <Keybuk> mjg59: you might be using DejaVu Mono instead?
[11:43] <bryce> rawler_: pop over to #ubuntu-x if you're interested
[11:43] <alex-weej> mjg59: /etc/fonts seems to change every distro upgrade
[11:43] <mjg59> I'm using whatever a default install gives you
[11:43] <Keybuk> (though they should include the instructions)
[11:43] <Keybuk> not really relevant anyway
[11:44] <mjg59> Ok, let me see how this turns out in a minute
[11:44] <Keybuk> funny: I was sure I'd got the patch wrong, since the fonts looked ... weird
[11:44] <Keybuk> but it turned out I was just so used to the new filter
[11:45] <rawler_> bryce: thanks for the invite, and yes I'd love NOTHING more than help developing Ubuntu, but until that pays my rent, I'm afraid I have to go to sleep to bear another mindless day at work tomorrow.. :)
[11:45] <ajmitch> bryce: what do you need with it? I tend to use nvidia on my gutsy desktop
[11:46] <rawler_> bryce: so, I'll drop by, go to bed and if I get some time I'll see what I can do for the weekend.. :)
[11:46] <bryce> ajmitch: aside from making new packaging (which I hope to automate away for Hardy), it involves just testing out new versions, riding herd on bugs, etc.
[11:46] <bryce> rawler_: cool
[11:47] <ajmitch> right
[11:47] <bryce> we've been using this approach for -fglrx in the forums, and have had some really nice successes there for gutsy
[11:48] <bryce> (not just -fglrx but also -ati and -radeonhd)
[11:52] <mjg59> Keybuk: Ok, playing with hinting seems to suggest that stuff Just Works
[12:00] <Keybuk> mjg59: your monospace appears with legacy lcd filtering?
[12:00] <mjg59> Keybuk: Yup
[12:01] <Keybuk> ok, seems that we're both happy now? :)
[12:01] <Keybuk> slangasek: are you happy for me to upload?
[12:04] <mjg59> Keybuk: Hm. No, I've got some very ugly rendering here with slight hinting
[12:04] <mjg59> Hang on, let me try to figure this out
[12:05] <mjg59> Ok. I'd say at the moment that this change plus full hinting seems to work fine
[12:05] <mjg59> Slight hinting is generating severe colour blurring
[12:05] <shaya> anyone suffer from a bug w/ clearlooks theme in gutsy?
[12:05] <Keybuk> mjg59: yeah, I've alternated between Full and Slight for a while ...
[12:05] <shaya> in pidgin, the tooltip info pop up doesn't always correspond to the right buddy
[12:05] <shaya> but if I switch to human, it works fine
[12:05] <Keybuk> I think the upload should not include the gnome-control-center change, and instead the mail should ask people to compare both and see which they like
[12:06] <mjg59> Keybuk: Yeah, I'd go with that for now
[12:08] <cjwatson> OK, tomorrow morning's CDs are going to be bust I'm afraid, despite my best efforts
[12:08] <cjwatson> I need to fall asleep and I don't have time to finish the last debian-installer change that needs to land for beta
[12:08] <Keybuk> cjwatson: :-(
[12:08] <pkern> ):
[12:08] <cjwatson> but I'll do it first thing tomorrow morning and rebuild CDs
[12:08] <pkern> cjwatson: Well, have a good night anyway. (:
[12:09] <Keybuk> cjwatson: g'night
[12:11] <mjg59> Keybuk: I wonder if the hinting setting interacts badly with the bytecode interpreter
[12:11] <Keybuk> mjg59: in theory, light hinting uses the autohinter
[12:11] <Keybuk> (so I'm told)
[12:11] <mjg59> Ok
[12:12] <cjwatson> actually, I can upload, because there are no udebs for the last thing I wanted - argh
[12:13] <Keybuk>         if ( mode == FT_RENDER_MODE_LIGHT             ||
[12:13] <Keybuk>              face->internal->ignore_unpatented_hinter )
[12:13] <Keybuk>           autohint = 1;
[12:14] <Keybuk> (though I'm not convinced :p)
[12:15] <Keybuk> ah, no, I see; the transition from FC_HINT_SLIGHT -> FT_RENDER_MODE_LIGHT is done by pango
[12:15] <cjwatson> Keybuk: uploading debian-installer; could you take care of accepting it when it's done *AND* libdebian-installer and hw-detect are in the accepted queue
[12:15] <cjwatson> ?
[12:15] <Keybuk> cjwatson: sure
[12:15] <cjwatson> Keybuk: the source needs to not be accepted before the latter happens or we all get to go round again :)
[12:15] <cjwatson> thanks
[12:16] <Keybuk> all three need to be accepted at once?
[12:16] <Keybuk> (as source)
[12:16] <cjwatson> ah, actually, they're in the accepted queue already, so that's not a problem
[12:16] <cjwatson> Keybuk: no, I meant the binaries
[12:16] <Keybuk> right
[12:16] <Keybuk> it should auto-accept now, no?
[12:16] <cjwatson> d-i needs the new binaries of its bits to be published <= its source
[12:17] <cjwatson> the binaries will, but the source will land in unapproved
[12:17] <cjwatson> sorry
[12:17] <cjwatson> the libd-i and hw-detect binaries will auto-accept
[12:17] <Keybuk> :)
[12:17] <cjwatson> the d-i source will land in unapproved
[12:17] <Keybuk> ok
[12:17] <Keybuk> so d-i just needs to be accepted once the upload is done
[12:17] <cjwatson> right, three minutes to process-upload
[12:18] <cjwatson> but Kirsten is going to kill me if I don't get moving now :)
[12:18] <cjwatson> (somewhat rightly so, I got four hours sleep last night)
[12:18] <cjwatson> Keybuk: the kernel's going to need some more NEW love; I did it for some architectures
[12:19] <cjwatson> i386 is still building
[12:19] <Keybuk> there are *some* advantages to your partner living and working in another city :p
[12:19] <cjwatson> hah
[12:19] <cjwatson> night
[12:19] <bryce> cya cjwatson
[12:31] <slangasek> Keybuk: if you and mjg59 are both happy, knock yourself out :)


[07:12] <knightwise> good morning peepz
[09:05] <brobostigon> morning boys and girls.
[09:20] <zmoylan-pi> o/
[09:21] <brobostigon> o/
[15:18] <kashem> is it possible to know if anyone pinging me?plz...Help
[23:08] <diddledan> zmoylan-pi: daftykins: I've resurrected my server bios


[06:51] <YoBoY> good morning
[07:50] <olive> third day of the paris ubuntu party begins in 2 hours
[07:51] <olive> I try to mount a second video stream with ogg theora in addition of flash/rtmp
[07:52] <valorie> very cool, olive!
[14:19] <daker> hi
[14:19] <Joeb454> hi daker
[19:13] <YoBoY> The ubuntu party in paris os over. I'm exausted
[19:13] <YoBoY> is
[19:21] <jpds> YoBoY: Clearly not enough, if you can make it onto IRC.
[19:22] <YoBoY> LOL
[19:24] <YoBoY> We are at a restaurant, 42 persons
[23:18] <cjohnston> mhall119: ping
[23:27] <cjohnston> mhall119: when you come around... I'd like feedback on bug 625288 and bug 644427... Daviey and loco-councils thoughts would be nice also
[23:27] <ubot4> Launchpad bug 625288 in loco-directory "add social network links to the events (affects: 1) (heat: 3)" [Wishlist,New] https://launchpad.net/bugs/625288
[23:27] <ubot4> Launchpad bug 644427 in loco-directory "Map with pins on the front page (affects: 1) (heat: 4)" [Wishlist,New] https://launchpad.net/bugs/644427


[00:58] <up_oa``> https://www.youtube.com/watch?v=sqSA-SY5Hro
[00:58] <up_oa``> I wish politicians would look out for miners
[00:58] <up_oa``> And not just minors on an island somewhere
[00:58] <up_oa``> Lord, we got folks in the street, ain’t got nothin’ to eat
[00:58] <up_oa``> And the obese milkin’ welfare
[00:58] <up_oa``> irc.supernets.org #superbowl
[00:58] <up_oa``> up_oa`` ebonheart kc2bez lubot ubuntulog3 ChanServ


[01:52] <Dzeg_-> Hi to everyone somebody here who speak and read spanish... I need help with my class but im bad in english and I dont know how to explain my problem in english; or someone who translate my issue commented in  http://pastebin.com/sFNQQeiE


[01:07] <Trevinho> RAOF: hey! You remember that buffer corruption? It happened because I forgot to filter out a surface buffer swap when using egl.... :/....
[01:08] <Trevinho> RAOF: but.... after doing that, I don't get anything draw at all
[01:08] <RAOF> Trevinho: So you were swapping twice?
[01:08] <Trevinho> when using egl swap with damage (eglBufferSwap stul works)
[01:08] <Trevinho> still^
[01:09] <Trevinho> RAOF: yeh, i was...
[01:09] <RAOF> Behind the back of EGL! Naughty!
[01:09] <Trevinho> RAOF: but now I presume is something more driver related at this point...
[01:09] <Trevinho> RAOF: like it says it supports swap with damage, while is not the case
[01:09] <RAOF> Yeah, I'll just have a second look at what our WithDamage implementation does.
[01:51] <RAOF> Trevinho: Ahem. We lie through our teeth about supporting SwapBuffersWithDamage
[01:51] <Trevinho> RAOF: ah! :)
[01:51] <RAOF> Likewise, buffer_age
[01:52] <RAOF> But at least in that case we always return 0.
[01:52] <RAOF> So it's harmless.
[01:52] <RAOF> Our SwapBuffersWithDamage returns EGL_FALSE
[01:52] <RAOF> And nothing else :)
[01:52] <Trevinho> Ah, in fact I was getting an EGL_FALSE but then eglERrror didn't say anything about that, so I was wondering if I was wrong about it
[01:53] <Trevinho> fair enough btw... RAOF any plan for supporting them?
[01:53] <RAOF> Yes.
[01:54] <RAOF> I could trivially fix the buffer_age now.
[01:54] <RAOF> In fact, I shall.
[01:54] <Trevinho> cool
[01:54] <RAOF> But WithDamage requires that we actually implement some form of damage :)
[01:54] <RAOF> I can fix that we say we support it, though :)
[01:55] <Trevinho> RAOF: that's enough for us I think
[01:55] <Trevinho> robert_ancell: ^^ so... it looks like that the at gdk level all is fine for supporting gl... .)
[01:55] <Trevinho> robert_ancell: got any chance to check that branch?
[01:56] <robert_ancell> Trevinho, I'll have a look now
[01:57] <Trevinho> robert_ancell: thanks, as RAOF will fix the fact that egl says we've extensions we actually don't support, I guess I can also remove the hardcoded "return FALSE" on about supporting the buffer damage swap
[01:58] <Trevinho> robert_ancell: and... Once you've done with that, give a look if doing this makes sense to you: https://git.gnome.org/browse/gtk+/commit/?h=wip/mir-async-swaps&id=4073caf3b47a9c847b30d9238860e9f16118337c
[02:03] <robert_ancell> Trevinho, can you convert it into a patch and put it in bugzilla? It will be easier to review like that
[02:03] <Trevinho> robert_ancell: sure
[02:03] <robert_ancell> I immediately notice you've added gdk_mir_window_get_mir_surface which doesn't seem related or necessarily something we should be exposing
[02:04] <Trevinho> robert_ancell: you meant the whole branch or this last patch
[02:04] <robert_ancell> I'm looking at the wip/mir-gdkgl branch
[02:04] <Trevinho> robert_ancell: yes, I added that because also other toolkits expose such stuff (x11 the xid, wayland the surface) and... we'd need it for clutter
[02:05] <robert_ancell> Trevinho, right, but you need to just propose one change at a time
[02:05] <Trevinho> robert_ancell: that was my plan, i just forgot to remove that patch from the branch :(
[02:05] <robert_ancell> OK, I'll have a look when you have a cleaned up patch in bz
[02:25] <Trevinho> robert_ancell: it's at https://bugzilla.gnome.org/review?bug=740346
[02:27] <Trevinho> ops, no it seems I've squashed one patch that was out
[02:30] <robert_ancell> RAOF, mir surfaces can change types?
[02:31] <RAOF> robert_ancell: I believe so; I think we've got a design requirement for morphing windows.
[02:32] <duflu_> Not clear if that ever changes parenthood. I think sabdfl was driving that idea
[02:33] <RAOF> I believe it might unset parenthood; dialog → normal would.
[02:33] <duflu> RAOF: Yeah that's one.
[02:34]  * duflu likes the idea of morphing because it's beautiful and computationally really simple to implement
[02:34] <RAOF> I don't think any morph would reassign parent, though.
[02:35] <Trevinho> robert_ancell: I've removed the extra commit, patch updated at https://bugzilla.gnome.org/review?bug=740346&attachment=291049
[02:35] <robert_ancell> yep
[02:35] <robert_ancell> reading it now
[02:35] <duflu> RAOF: Although to do it properly I think we might end up with separate src and dest surfaces
[02:35] <duflu> Not sure
[02:36] <RAOF> robert_ancell: Oh, by the way: http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/2074
[02:36] <robert_ancell> RAOF, nice!
[02:37]  * Trevinho seconds that!
[02:47] <Trevinho> robert_ancell: about moving these functions to gdk_mir_window or gdk_mir_display... I wanted to do the same since the beginning but then I avoided to  do that not to expose privately the definition of GdkMirGLContext...
[02:47] <Trevinho> robert_ancell: so I just followed what gdk was doing in other toolkits
[02:48] <Trevinho> robert_ancell: but... I agree that it would be better to keep these functions in the place where they override.... Not sure if it's better for reading the whole gl code btw... (I mean, having all these inside gtkmirglcontext makes easy to see the whole gl engine in the same place)
[02:49] <Trevinho> robert_ancell: let me know what you prefer... whether adding a gdkmirglcontex-private.h with the struct definition or the way it is
[02:51] <robert_ancell> Trevinho, I'd prefer the private header
[02:52] <Trevinho> robert_ancell: ok, doing it
[02:52] <robert_ancell> Trevinho, note the other backends do it that way but I changed that for the Mir backend
[02:53] <Trevinho> robert_ancell: yes, I noticed...
[02:53] <Trevinho> robert_ancell: want a new private header, or should I use gdkmir-private?
[02:53] <robert_ancell> Trevinho, just commit the gdk_mir_display_get_mir_connection change directly if it's just a trivial change
[02:53] <Trevinho> k
[02:54] <robert_ancell> Trevinho, use gdkmir-private
[03:16] <Trevinho> robert_ancell: updated
[03:16] <robert_ancell> Trevinho, ack
[03:17] <robert_ancell> Trevinho, #include "gdkglcontextprivate.h"
[03:17] <robert_ancell> Doesn't exist in patch
[03:17] <robert_ancell> (in gdkmir-private.h)
[03:18] <Trevinho> robert_ancell: it's provided by gdk..
[03:18] <Trevinho> that's the genric
[03:18] <robert_ancell> oh, duh
[03:31] <Trevinho> robert_ancell: updated
[03:35] <Trevinho> robert_ancell: ta
[10:18] <alan_g> Rats! alf TA'd an MP I was updating in response to review comments. https://code.launchpad.net/~alan-griffiths/mir/restrict-access-to-private-headers/+merge/242097 - should I kill the updates?
[10:26] <alf> alan_g: We can always switch to needs review again and cancel the autolanding job
[10:26] <alan_g> alf: just doing that. ;)
[11:08] <alf> When compiling with clang I get "multiple definition of `pthread_equal'" errors when linking the tests. Has anyone seen this? (vivid, clang 3.5.0)
[11:14] <mlankhorst> hmm
[11:16] <mlankhorst> I'm toying with enabling copy-less support on DRI2, but it seems to be more concerned about lifetime
[13:37] <mlankhorst> RAOF: hmm... how do I allocate depth buffers?
[14:14] <attente_> hi, is there any progress on https://bugs.launchpad.net/mir/+bug/1391976? i can't seem to get unity8 running from trunk because of it
[14:22] <alan_g> attente_: AFAIK that bug shouldn't be affecting unity8 - could you share why you think it does?
[14:25] <attente_> alan_g: not sure, but i keep getting this in .cache/upstart/unity8.log: http://paste.ubuntu.com/9123860/
[14:26] <attente_> alan_g: is it possible that i need to rebuild another dependency against mir? i'm building u-s-c and unity8
[14:26] <alan_g> are you running on desktop or phone? Are you rebuilding qtmir?
[14:27] <alan_g> does your u-s-c work?
[14:27] <attente_> alan_g: on the desktop, haven't rebuilt qtmir
[14:28] <alan_g> attente_: unity8 uses mir through qtmir, you'll need that
[14:28] <alan_g> greyback: anything I'm missing? ^^
[14:31] <attente_> alan_g: thanks, i'll try rebuilding qtmir to see if it helps
[14:36] <mlankhorst> bleh.. I wish I knew someone who understood this crap better than me :P
[14:36] <anpok> mlankhorst: hm depth buffers.. for that we should have an interface..
[14:36] <anpok> but you are only using mir_client?
[14:37] <anpok> or again, you mean .. you want to configure the depth of the depth buffer?
[14:49] <mlankhorst> I want to figure out how I can create a depth buffer and pass that along for dri2 to use
[14:59] <greyback> alan_g: nothing I can think of.
[15:07] <attente_> alan_g: can't seem to build qtmir for the same reason: tests are failing because of the libprotobuf problem: File already exists in database: mir_protobuf_wire.proto
[15:08] <alan_g> attente_: can't *build* qtmir?
[15:08] <attente_> alan_g: yes
[15:09] <attente_> tests are failing because of that segfault
[15:11] <alan_g> attente_: you don't somehow have the libmirplatform*-android platform library installed do you?
[15:11] <attente_> is there some special way of building/running them from trunk? i've just been trying to build using debuild and ccache, but wondering if there's an easier way to build and run from trunk
[15:12] <attente_> alan_g: no, those aren't installed
[15:13] <alan_g> attente_: I don't often build them but I just point pkgconfig at a local install.
[15:14] <alan_g> greyback: any better suggestion? ^
[15:15] <greyback> attente_: easiest way to build qtmir (after bzr clean-tree) is: qmake "QMAKE_CXX=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK_SHLIB=arm-linux-gnueabihf-g++-4.9"
[15:15] <greyback> then make & make install
[15:15] <greyback> but try "make check" - those are the tests
[15:18] <attente_> greyback: does this work for you on x86_64?
[15:18] <greyback> attente_: ah, I thought you on arm
[15:18] <greyback> attente_: qmake "QMAKE_CXX=g++-4.9" "QMAKE_LINK=g++-4.9" "QMAKE_LINK_SHLIB=g++-4.9"
[15:25] <attente_> greyback: hmm.. i still seem to be getting the protobuf error after doing make check
[15:25] <greyback> attente_: then it's something in Mir IMO
[15:25] <greyback> attente_: are you using a custom build of Mir?
[15:26] <greyback> do the mir-demos work for you?
[15:26] <attente_> greyback: it's mir from the current trunk
[15:26] <attente_> i built using debuild and ccache
[15:27] <greyback> attente_: have you other copies of the mir libraries in /usr/lib by any chance?
[15:28] <attente_> mir demo shell is working
[15:29] <attente_> greyback: i have libmircommon2/libmircommon3, libmirplatform3/libmirplatform4, etc. installed
[15:29] <greyback> attente_: you should only have 1 of each of those
[15:29] <attente_> but there seems to be a bunch of things (including unity8) that are depending on the old ones
[15:30] <greyback> as I'm not certain Mir is good at having multiple versions of itself installed at once
[15:31] <attente_> greyback: ok, i'll remove them and try again. thank you!
[15:31] <alan_g> I'm certain it was bad at it and it's getting fixed (but possibly not there yet)
[15:31] <greyback> attente_: let us know if it helps
[15:38] <attente_> greyback: alan_g: ok, qtmir tests are passing again now, i am hopeful for the rest. thank you!
[15:39] <greyback> attente_: great!
[15:42] <alan_g> attente_: :)
[15:56] <alan_g> camako: are you working on bug 1394221? (If not I'll steal it)
[16:02] <camako> alan_g, yes I am
[17:31] <alan_g> camako: the problem you mentioned - https://code.launchpad.net/~alan-griffiths/mir/fix-set_logger/+merge/242392
[17:34] <camako> alan_g, oh sh*t... my fault... thx for the fix!
[17:35] <alan_g> I just happened to look in the right place
[17:38]  * alan_g suspects he wrote the offending expression in an untested spike and also shares the blame for not seeing it at review time.
[22:00] <RAOF> mlankhorst: You allocate depth buffers yourself.
[22:01] <RAOF> mlankhorst: Mir is only ever going to give you colour buffers. If you need any auxiliary buffers, you're free to allocate them however you want.
[22:14] <mlankhorst> yeah I'll just implement it by ignoring it
[22:14] <mlankhorst> I'm not sure anyone cares about sharing depth/stencil buffers
[22:19] <RAOF> They manifestly do not; Intel at least has been ignoring that part of the spec for a number of years.