[00:25] <robert_ancell> TheMuso, does syncing a new package from Debian require archive-admin permissions?
[00:25] <TheMuso> robert_ancell: it requires an archive admin to do it yes.
[00:26] <RAOF> Until the magical “sync me!” button gets implemented, at least.
[00:30] <RAOF> Thinking of which... it's time to upload Xserver 1.8.1 + all the goodies.
[00:30] <lifeless> RAOF: oh btw
[00:30] <RAOF> lifeless: Yah?
[00:30] <lifeless> RAOF: please please please figure out how to disable the 96dpi pinning
[00:30] <lifeless> RAOF: I just went multimonitor
[00:30] <lifeless> and it really wrecks that
[00:31] <lifeless> my CRT != my laptop LCD in DPI, resolution or aspect ratio.
[00:31] <bryceh> lifeless, that's not X that's pinning it, it's gnome
[00:31] <bryceh> lifeless, and it's easy to change, just go to the Appearance system tool, and go into the Fonts section
[00:31] <lifeless> bryceh: how so? xrandr is showing it
[00:31] <RAOF> Well, it's actually X too, isn't it?
[00:32] <bryceh> there's an input widget for selecting a different DPI
[00:32] <lifeless> sorry, xdpyinfo
[00:32] <bryceh> RAOF, shouldn't be anymore
[00:32] <lifeless> bryceh: I've had my font setting set correctly for 10 years
[00:32] <lifeless> bryceh: when I set the mm in my xorg.conf correctly, and it gets ignored - even though the x and y sizes are reported correctly, I blame X
[00:32] <bryceh> xdpyinfo calculates based on the resolution and physical dimensions of the screen - you can check those numbers in your calculator to see what the right dpi is
[00:33] <bryceh> I don't think anything in X is "pinning" it
[00:33] <lifeless> screen #0:
[00:33] <lifeless>   dimensions:    2840x1050 pixels (751x278 millimeters)
[00:33] <lifeless>   resolution:    96x96 dots per inch
[00:34] <lifeless> thats weird too, let me unplug the CRT for a sec
[00:35] <bryceh> yep, that works out to 96 dpi
[00:35] <bryceh> so it's correct... still it may not be what you *want*
[00:35] <RAOF>   dimensions:    1440x900 pixels (381x238 millimeters)
[00:35] <RAOF>   resolution:    96x96 dots per inch
[00:35] <bryceh> thus the ability to override it
[00:36] <RAOF> Those dimensions are *wrong*
[00:36] <JanC> mine says:
[00:36] <JanC>   dimensions:    1920x1080 pixels (508x285 millimeters)
[00:36] <JanC>   resolution:    96x96 dots per inch
[00:36] <JanC> and the fysical dimensions are incorrect  :P
[00:36] <bryceh>   dimensions:    1280x1024 pixels (338x270 millimeters)
[00:36] <bryceh>   resolution:    96x96 dots per inch
[00:36]  * RAOF suspects that something is calculating the physical size based on the resolution & 96 DPI
[00:37] <lifeless> bryceh: so, in xorg.confg I have DisplaySize 261 163
[00:37] <JanC> it's only 480mm wide
[00:37] <lifeless> bryceh: thats very different to 2840x1050
[00:37] <lifeless> blah unit confusion
[00:37] <lifeless> thats different oo 751x278
[00:37] <bryceh> RAOF, possibly
[00:38] <lifeless> bryceh: my laptop screen is 1440x900 - and 261mm x 163mm
[00:38] <JanC> so my screen is really closer to 100 dpi than to 96 dpi
[00:38] <RAOF> Well, my monitor is ~260mm wide, and the EDID is correct: [    62.251] (II) intel(0): clock: 74.1 MHz   Image Size:  261 x 163 mm
[00:39] <Tm_T> I has silly 92 dpi forced here
[00:39] <lifeless> and mine is 144dpi
[00:39] <lifeless> 96 is *waaay* off
[00:39] <lifeless> RAOF: what does your xdpyinfo claim
[00:39] <RAOF> I've already pasted it above.
[00:39] <lifeless> ahright\
[00:39] <lifeless> yes, its wrong
[00:39] <RAOF> 381x238 mm
[00:39] <bryceh> on karmic:  dimensions:    3840x1200 pixels (1036x324 millimeters)
[00:39] <bryceh>   resolution:    94x94 dots per inch
[00:40] <bryceh> which is correct dimensions according to xrandr
[00:40] <lifeless> bryceh: check your edid output in the X log
[00:41] <lifeless> bryceh: my xrandr gets it more right than xdpyinfo, but xrandr doesn't report the dpi being reported to programs
[00:41] <Tm_T> I presume whatever you have set in gnome has it's own affect
[00:41] <RAOF> Yes, on GTK apps.
[00:42] <bryceh> DVI-I-2 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
[00:42] <bryceh>   dimensions:    1280x1024 pixels (338x270 millimeters)
[00:42] <bryceh> that's xrandr and xdpyinfo from a lucid system... clearly wrong
[00:44]  * ajmitch sees that the correct dimensions are found in Xorg.0.log, but xdpyinfo says differently (and 96DPI, again)
[00:44] <RAOF> I suspect we're talking about https://bugs.freedesktop.org/show_bug.cgi?id=23705
[00:44] <ubot2> Freedesktop bug 23705 in Server/general "xserver 1.7.0rc0 uses wrong dimensions" [Normal,Reopened]
[00:45] <ajmitch> I doubt my my laptop screen is 423 mm wide
[00:45] <bryceh> lifeless, you can add that ^^ watch on your bug report
[00:46] <lifeless> I haven't bugginated yet
[00:46] <lifeless> I thought it was widely known
[00:46] <RAOF> bryceh: Incidentally, this is what I was talking about at UDS when DPI came up :)
[00:57] <bryceh> hmm, if you look at xorg-server and grep on dpi you can see the history of this
[00:57] <bryceh> we carried various patches to force it to 96 for quite a while, but then finally dropped that (and later reintroduced it via gnome)
[00:57] <bryceh> it seems meanwhile upstream took the patch
[00:58] <Tm_T> I think forcing dpi something for all is silly
[00:59] <bryceh> that's kind of my opinion too, but I can see the point in having it forced since it breaks quite a few people.  but I rather see it forced at the window manager layer than at the X layer
[01:00] <Tm_T> true that
[01:00] <bryceh> but maybe upstream knows something we don't
[01:01] <bryceh> RAOF, anyway you could doublecheck with seb128 that we're still having GNOME do 96 dpi and if so revert that upstream change if you'd like.
[01:01] <bryceh> iirc when I talked to the kubuntu guys they preferred to configure to not force to 96 dpi but you could doublecheck that with Riddell
[01:02] <bryceh> anyway
[01:02]  * bryceh goes back to NOT working on X.org for the afternoon ;-)
[01:02] <Tm_T> bryceh: ye, and it's simple one config option if we choose otherwise
[01:19] <RAOF> lifeless: Incidentally, if you're using an external monitor I assume you've got one of those docking stations for the x201?  How are they?
[01:20] <lifeless> no
[01:20] <lifeless> just plugged in
[01:20] <lifeless> RAOF: so, can you file a bug on this, as I've no particular interest in tracking all the bits
[01:20] <lifeless> just in seeing it work better ;)
[01:24] <RAOF> Does your x201 have digital output ports?  That's the main thing lacking from my x200
[01:26] <lifeless> no
[01:26] <lifeless> standard analogue VGA D connector
[03:41] <robert_ancell> TheMuso, can you sponsor nautilus, libwnck? Thanks
[03:41] <TheMuso> robert_ancell: sure
[04:01] <TheMuso> robert_ancell: uploading both.
[04:01]  * TheMuso -> lunch.
[04:31] <ccheney> RAOF, x200 ultrabase has a displayport connector, i have one but haven't bought a displayport to dvi converter to use it with my monitor
[04:31] <ccheney> RAOF, the ultrabase is the part that snaps on the bottom that can hold another hd or optical drive
[04:31] <RAOF> ccheney: Yeah.  I was looking at that.
[04:32] <RAOF> And while I'm in the “stuff I'd like to spend money on” store, a nice big 20+ inch monitor would also be high on the list :)
[04:32] <ccheney> i guess vga projectors are still more common than digital ones
[04:33] <ccheney> 20"+ monitors are fairly cheap unless you go for IPS (which is better and what i have), i have an old HP 23" IPS
[04:33] <RAOF> I'd have preferred Lenovo to go the Apple route - small, non-standard connector + adapters to everything.
[04:33] <ccheney> mini display port is actually standardized now and iirc free to license
[04:34] <ccheney> but i'm not sure if you can go from that to vga, at least cheaply since it would need digital to analog converter in the adaptor
[04:34] <ccheney> hmm actually its only $20 for the apple apparently so is not bad
[09:20] <ayan> good morning.
[13:43] <freud_> hi all
[13:44] <freud_> if i boot my ubuntu desktop without monitor connected i cannot get logon through VNC, only putty...any solutions?
[13:45] <fagan> freud_: thats off topic for this channel ask on #ubuntu
[13:45] <fagan> this is for development of ubuntu desktop
[13:45] <fagan> not support
[13:46] <freud_> sorry
[13:47] <fagan> freud_: its fine :)
[13:55] <AnAnt> Hello, I have a question about XDG menus, an app. has those categories in .desktop file: Categories=Education;Literature;Science;Electronics
[13:55] <AnAnt> usually Electronics menu is not installed by default on systems
[13:56] <AnAnt> the question is, how can I make this app. appear in Science *ONLY IF* Electronics menu does not exist ? Otherwise if, the menu exists, it should ONLY appear in Electronics menu ?
[13:56] <fagan> AnAnt: it should just go into science main
[13:57] <AnAnt> fagan: meaning ?
[13:57] <fagan> if electronics doesnt exist it will just go into the main science part
[13:58] <fagan> it would go into electronics if it exists
[13:58] <AnAnt> fagan: it would appear in BOTH electronics & science if electronics exist
[13:58] <fagan> electronics is a sub menu to science
[13:58] <AnAnt> no, it isn't
[13:59] <fagan> anyway electronics isnt in the menu anyway so it doesnt matter
[13:59] <AnAnt> fagan: it is if you install extra-xdg-menus package
[14:00] <fagan> hmmmm then I dont really know id say it might have a link in both
[14:01] <fagan> like the way evolution used to be in internet and office
[14:34] <ccheney> Riddell, are you processing sync requests today?
[14:36] <ccheney> seb128, i saw you commented on my two sync requests saying it happens automatically but they haven't been synced yet and were uploaded to debian over a week ago, how often does it happen? i need those two packages for OOo
[14:37] <ccheney> er the latest versions were uploaded over a week ago, they had been in debian but not ubuntu prior to that also
[14:38] <ccheney> hmm nm, they used to be in experimental before then, so only been in unstable a little over a week
[16:04] <ogra> didrocks, tickle
[18:17] <didrocks> kenvandine: hey, desktopcouch which doesn't want to start on a fresh maverick alpha1, known bug?
[18:18] <kenvandine> yes
[18:18] <kenvandine> it doesn't like the maverick kernel :/
[18:18] <kenvandine> if you boot the 2.6.32 kernel it'll work
[18:18] <didrocks> kenvandine: ok, no need to feed a new bug so :)
[18:18] <kenvandine> chad is working on that
[18:18] <kenvandine> :)
[18:18] <didrocks> kenvandine: well, it was working on the first 2.6.34 kernel
[18:19] <kenvandine> yeah, i think it was
[18:19] <didrocks> (as I dist-upgraded to maverick then and used it)
[18:19] <didrocks> but just reinstalled from scratch and just saw that :)
[18:19] <kenvandine> we think it is the proc digging they do to find the port
[18:20] <didrocks> ok, I just stopped at "I can't find the port" :)
[18:20] <kenvandine> yup :)
[18:20] <didrocks> they make some proc digging for that?
[18:20] <didrocks> how it works,
[18:20] <didrocks> ?
[18:20] <kenvandine> yes...
[18:20] <kenvandine> it is kind of ugly
[18:20] <kenvandine> and the regex never finds a match now
[18:21] <didrocks> oh bad :/
[18:21] <didrocks> ok, hope that will be fixed easily :)
[18:22] <didrocks> ok, signing off again (and for good) for the week-end!
[18:22] <kenvandine> later!
[18:22] <didrocks> kenvandine: have a good week-end too!
[18:23] <kenvandine> you too!
[18:26] <seb128> didrocks, kenvandine: we have a bug about lpi being broken which is due to normal users not having access to proc entries it seems
[18:26] <seb128> it's likely some new security thing
[18:27] <kenvandine> yeah
[18:27] <kenvandine> got a bug number?
[18:27] <seb128> not sure if that can break the desktopcouch code
[18:27] <seb128> pedro_, ^
[18:27] <seb128> no but I know pedro triaged some duplicates
[18:27] <ogra> didrocks, do you plan to still ship the 2D fallback UI in maverick for netbook ? or do i need to do some special stuff for armel ?
[18:27] <seb128> or check with kees
[18:27] <kenvandine> i think that is the same issue then
[18:33] <didrocks> seb128: I saw the lpi bug but didn't read it (yet), ok, thanks for the notice
[18:33] <didrocks> ogra: well, I'm not sure for now. I would say "no" as the 2 interfaces are quite different
[18:33] <ogra> hrm
[18:33] <didrocks> ogra: we still can ship the 2 sessions (one une "unity" and one une "efl")
[18:33] <ogra> we need some similar behavior to the old way ... i.e. autodetection
[18:34] <ogra> for arm at least
[18:34] <ogra> the image will come without 3D support but there will be drivers you can install from a ppa or multiverse
[18:34] <ogra> i.e. imagine nvidia
[18:35] <didrocks> ogra: hum, ok, and can depends on which drivers is installed changed the default session?
[18:35] <didrocks> (just thinking…)
[18:35] <ogra> that would be best, yes
[18:35] <ogra> i think asac was working on a way to hook that into jockey
[18:35] <didrocks> ogra: for instance, there was a bug in an kernel update, people got fallback to efl and were puzzled
[18:35] <ogra> but effectively the old way we had in lucid was good
[18:36] <didrocks> ogra: it would be better, I still have my script to change default session. It's just about triggering it at the right time
[18:36] <ogra> ok
[18:36] <ogra> lets talk about that later (i currently dont even have images) the issue came up in a customer call today
[18:37] <ogra> if there is any way thats suitable i'm fine
[18:37] <ogra> and i'll happily take the task to work on it, i just wnat to have it on the desktop team radar that such issues exist
[18:37] <didrocks> ogra: ok, let's discuss in a week (I'll upload unity next week into maverick, the time to write MIR, seed it, and so on)
[18:37] <didrocks> ogra: and then we will concentrate on that :)
[18:38] <ogra> yeah, no hurry
[18:38] <didrocks> ogra: understood :)
[18:38] <ogra> will take me another week to even get images
[18:38] <didrocks> ogra: we still can retake my code for netbook-launcher in the worst case :)
[18:38] <ogra> or even two
[18:38] <ogra> since we're redoing our way of images completely for arm
[18:38] <ogra> well, the guys want uinity actually :)
[18:39] <didrocks> Laney: did you test banshee before syncing it into ubuntu? It's broken here FYI
[18:39] <didrocks> ogra: that's understandable :)
[18:39] <ogra> hehe
[18:39] <didrocks> ogra: do you have good driver now for it?
[18:39] <ogra> no, thats the point
[18:39] <ogra> they want to work it out during maverick development
[18:40] <didrocks> that would rock :-)
[18:40] <ogra> the HW uses GLES and nobody ever tested unity on that
[18:40] <ogra> there are roumors that clutter works very bad
[18:40] <ogra> but nobody has ever proven that
[18:40] <didrocks> hum, I never tried GLES, but I won't be surprized that clutter suffers on it
[18:41] <ogra> well, there are different camps ... clutter guys claim it works fine
[18:41] <ogra> (but have never proven it)
[18:42] <ogra> GLES guys claim its dog slow (but have never proven it) :)
[18:42] <ogra> its a funny situation
[18:42] <didrocks> heh :)
[18:42] <didrocks> well, testing is the only way to know, so
[18:42] <ogra> so having unity in the arm images and having the HW guys provide use a driver will actually get us some data :)
[18:42] <ogra> s/use/us/&
[18:43] <didrocks> sure, we'll see :)
[18:43] <ogra> thansk for your time :)
[18:43] <ogra> go back to work ! :)
[18:43] <didrocks> ogra: you're welcome ;)
[18:43] <ogra> and have a nice weekend
[18:43] <didrocks> ogra: well, today is off in fact, that's why I didn't answer you at your first ping
[18:44] <didrocks> just get annoyed by desktopcouch crashing, and then by banshee too :)
[18:44] <didrocks> but this time, /me out
[18:44] <didrocks> enjoy your week-end ogra
[18:44] <ogra> yeah, you too
[18:44] <didrocks> thanks
[19:04] <asac> didrocks: do you know something about jockey?
[19:09] <pedro_> didrocks, seb128, kenvandine bug 589656 ; kees is following on it now
[19:09] <ubot2> Launchpad bug 589656 in linux (Ubuntu) (and 1 other project) "help -> report a problem doesn't work on Maverick (affects: 2) (dups: 1) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/589656
[19:09] <pedro_> (sorry was at lunch)
[19:10] <kenvandine> pedro_, thx
[19:10] <pedro_> ah already discussed in the other channel ;-)
[19:10] <kenvandine> :)
[19:35] <rickspencer3> kenvandine, libgwibber for vala ftw!
[19:35] <kenvandine> got mono too... but it crashes atm
[19:36] <kenvandine> :)
[19:41] <jcastro> kenvandine: hey wait, does this mean an app like Pino could libgwibber?
[19:42] <rickspencer3> jcastro, what would that even mean?
[19:42] <rickspencer3> weird
[19:42] <jcastro> Oh I know it's weird
[19:43] <kenvandine> :)
[19:43] <jcastro> rickspencer3: it's like a library for twitter and all that right?
[19:43] <rickspencer3> jcastro, right
[19:43] <kenvandine> jcastro, sort of
[19:43] <rickspencer3> I thought Pino was basically a gwibber
[19:43] <kenvandine> it isn't complete enough for that sort of thing though
[19:43] <rickspencer3> kenvandine, you mean "yet" ;)
[19:44] <kenvandine> yup :)
[19:47] <jcastro> rickspencer3: I'm just saying, if I were writing a competing app I would use the library and make Ken do all the work!
[19:47] <jcastro> While I lay back and collect all the money!
[19:47] <kenvandine> hehe
[19:47] <rickspencer3> jcastro, yup
[19:47] <rickspencer3> but more to the point, you could add social features to your app
[19:48] <rickspencer3> with just a few lines of coherent code
[20:10] <vish> seb128: hi , Bug #589450 might be a bug due to gtk csd , could you have a look at it? or whom should i refer it to?
[20:10] <ubot2> Launchpad bug 589450 in cheese (Ubuntu) "Cheese crashes shortly after startup (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/589450
[20:24] <kenvandine> jcastro, btw all uploaded to the ppa... just waiting for the builders to get them
[20:28] <jcastro> kenvandine: awesome!
[20:30] <seb128> vish, tag it gtk-csd
[20:30] <seb128> vish, brastche will look at those
[20:30] <vish> seb128: cool , thanks
[21:17] <didrocks> asac: well, enough to had a look at the code past monthes, but nothing too much in deep. Shouldn't be hard if required (but not before alpha2, I'm already full :))
[21:34] <asac> didrocks: i have a question ... does jockey carry local data about pci/usb ids that have drivers available? or is that all online