[00:03] <robotfuel> kgunn: it doesn't save that information in the logs
[00:03] <robotfuel> kgunn: I will rerun the tests to get that info, it goes to stdout
[00:06] <robotfuel> kgunn: I don't notice any tearing, but open arena is always moving it would be hard to see
[00:07] <robotfuel> kgunn: I'll watch again and get back to you. brb
[00:27] <robotfuel> kgunn: openarena runs too fast to tell if it's tearing
[00:31] <Sarvatt> run non xmir openarena with vblank_mode=0 openarena?
[00:31] <robotfuel> xorg had a segfault on intel with xmir http://<IP_ADDRESS>:8080/job/utah-xmir-troubleshooting/ws/results/Xorg.0.log
[05:08] <tvoss_> RAOF, ping
[05:27] <sgx1> hi. now there're two mir PPAs, which one to use? installing_prebuilt_mir_on_pc.md suggests using system-compositor-testing ppa. but i find packages in Mir staging ppa are newer.
[05:28] <tvoss_> sgx1, yup, but staging revs too fast and system-compositor-testing is the save alternative so far :)
[05:28] <tvoss_> sgx1, we cherry-pick over to system-compositor-testing on a regular basis
[05:28] <RAOF> tvoss_: Pong.
[05:58] <robert_ancell> RAOF, duflu, alf__, hikiko, racarr, kdub, kgunn, meeting time!
[05:58] <robert_ancell> thomi too!
[05:58] <hikiko> hi
[05:59] <hikiko> joining in a sec robert_ancell
[06:06] <kgunn> kdub: you around?
[06:25] <tvoss_> didrocks, ping
[06:29] <didrocks> tvoss_: pong
[06:29] <tvoss_> didrocks, got a branch for you to test on the ati machine :)
[06:30] <didrocks> tvoss_: yeah! there are two ways: building it locally (but I don't have any i386 machines ready)
[06:30] <didrocks> tvoss_: or pushing that to the ppa manually
[06:30] <didrocks> I'm in favor of #2
[06:31] <tvoss_> didrocks, so what do you need from me? just the branch?
[06:31] <didrocks> tvoss_: yep, the branch is fine
[06:32] <tvoss_> didrocks, lp: ~thomas-voss/mir/default-to-null-input-by-default
[06:32] <didrocks> tvoss_: branching, pushing, building
[06:32] <didrocks> then will rerun
[06:32] <tvoss_> didrocks, ack
[07:05] <tvoss_> didrocks, status?
[07:06] <tvoss_> didrocks, I need to step out at 10 my time (in ~55 minute) to run some errands
[07:06] <didrocks> tvoss_: well, it's building in the ppa right now
[07:06] <didrocks> tvoss_: and as there is an ABI break, regarding to latest version, I have to rebuild u-s-c as well
[07:07] <didrocks> so waiting for mir to publish first
[07:07] <tvoss_> didrocks, ack ... which ppa are you using?
[07:09] <didrocks> tvoss_: daily-build-next
[07:09] <tvoss_> didrocks, ack and thx
[07:09] <didrocks> yw ;)
[07:09] <didrocks> will keep you posted
[07:38] <tvoss_> didrocks, stepping out now, back in ~1 hour
[07:38] <didrocks> tvoss_: ok, u-s-c is building now
[07:38] <tvoss_> didrocks, ack
[07:46] <dholbach> good morning
[08:03] <mlankhorst> didrocks: ping
[08:05] <didrocks> mlankhorst: pong
[08:05] <mlankhorst> didrocks: on that non-working machine, could you post the full logs from /var/log/lightdm and full dmesg?
[08:06] <didrocks> mlankhorst: I are running a rerun from tvoss first
[08:06] <didrocks> mlankhorst: so wait for it I would say ;)
[08:06] <didrocks> currently running, so shold have results soon
[08:07] <mlankhorst> yeah my own test machine fails with std::exception::what: Failed to set the current VT mode
[08:07]  * mlankhorst doesn't have plymouth or splash enabled, might be why
[08:13] <mlankhorst> hm seems to be https://bugs.launchpad.net/mir/+bug/1195509
[08:31] <didrocks> mlankhorst: do you start it from lightdm?
[08:31] <mlankhorst> yeah
[08:31] <didrocks> weird
[08:33] <mlankhorst> does lightdm switch to the console before letting unity-system-compositor configure it?
[08:37] <mlankhorst> and can I use strace on ust somehow, to figure this one out
[08:37] <didrocks> mlankhorst: I can answer on the second one
[08:38] <didrocks> mlankhorst: /etc/lightdm/lightdm.conf.d/
[08:38] <didrocks> you have a file shipped by usc
[08:38] <didrocks> you can put a command
[08:38] <didrocks> like: system-compositor=strace unity-system-compositor
[08:40] <mlankhorst> yeah
[08:40] <mlankhorst> hm of course that works..
[08:49] <mlankhorst> didrocks: who spawns the xserver, unity-system-compositor or lightdm?
[08:51] <didrocks> mlankhorst: ligthdm AFAIK
[08:52] <didrocks> but I can be wrong
[08:54] <mlankhorst> hm seems to be a plymouth race :P
[09:38] <tvoss> didrocks, ping
[09:38] <didrocks> tvoss: wb!
[09:38] <didrocks> tvoss: so passed \o/
[09:39] <didrocks> tvoss: please file a MP ;)
[09:39] <didrocks> (I'm still rerunning to ensure we don't get any race, but should be good)
[09:40] <tvoss> didrocks, \o/
[09:40] <tvoss> RAOF, any more insight? any handover tasks I should look into?
[09:40] <mlankhorst> looks like it's still failing locally, I'll try to figure out why :p
[09:41] <RAOF> tvoss: I'm still hooking up exposing the buffer id to the client. Once that's done, I'll instrument everything and give it a run.
[09:41] <tvoss> RAOF, awesome, thank you :)
[09:43] <tvoss> greyback, ping
[09:45] <tvoss> alf__, didrocks https://code.launchpad.net/~thomas-voss/mir/default-to-null-input-by-default/+merge/176638
[09:48] <greyback> tvoss: pong
[10:00] <alf__> tvoss: what's the driving force behind default-to-null-input-by-default ?
[10:01] <tvoss> alf__, first: it saves us a bunch of wakeups per second in the system compositor scenario. Second: it solves issues with booting up on certain ATI HW where creating a bo for the hw cursor results in an exception
[10:02] <alf__> tvoss: can't the system compositor turn this off, instead of making it the default?
[10:02] <tvoss> alf__, possible, too
[10:20] <didrocks> tvoss: should I rebuild Mir without your patch and be ready to take the new system-compositor in?
[10:20] <didrocks> tvoss: ran 4 times, with full test suit and pass
[10:23] <mlankhorst> I think I understand the bug, but not the fix yet :P
[10:23] <tvoss> mlankhorst, which one exactly? the ati one?
[10:23] <mlankhorst> https://bugs.launchpad.net/mir/+bug/1195509
[10:23] <tvoss> mlankhorst, \o/ I have been looking at that, too
[10:23] <tvoss> didrocks, yup, but might take me some time, an hour or so
[10:24] <didrocks> tvoss: ok, I can rebuild Mir meanwhile
[10:24] <didrocks> to not loose time
[10:24] <didrocks> tvoss: or will you have Mir changes?
[10:24] <didrocks> (to expose an API or so on…)
[10:24] <mlankhorst> tvoss: well it's a dumb bug
[10:25] <tvoss> didrocks, most likely no mir changes, at least I hope so
[10:25] <didrocks> tvoss: ok, let me do a preventive build then :)
[10:27] <RAOF> mlankhorst: Something involving plymouth is a dumb bug? Say it ain't so!
[10:28] <mlankhorst> I don't get why plymouth is killed by lightdm *after* xserver started..
[10:28] <mlankhorst> or mir
[10:31] <didrocks> mlankhorst: I think for smooth transitioning? (just a guess)
[10:35] <mlankhorst> anyway the io comes from the TTY having hung up
[10:35] <RAOF> No, that shouldn't be it.
[10:35] <mlankhorst> I'm guessing it is being opened too early, while plymouth still has control over it
[10:36] <RAOF> mlankhorst: How's that mir-plymouth branch goin? :)
[10:36] <mlankhorst> RAOF: blocking on the same thing as I want to block Xmir for, the separate thread is ugly
[10:37] <RAOF> mlankhorst: Indeed it is; bug tvoss about that :)
[10:37] <mlankhorst> but I did a control WARN_ON(1), and I did get that unity-system-compositor had a WARN_ONn hung_up_tty_ioctl+0x27/0x50
[10:38] <mlankhorst> so it looks like this is the issue here
[10:38] <tvoss> mlankhorst, RAOF happy to adjust the separate thread, but can we fix the bug without me on the critical path?
[10:39] <mlankhorst> tvoss: erm sure, just postpone opening the fd or patch lightdm some more
[10:39] <tvoss> mlankhorst, cool
[10:39] <mlankhorst> I can do the latter
[10:39] <RAOF> tvoss: Yeah, it's fixable. It's just that there wouldn't be an opportunity for this bug to exist if we weren't doing the stupidly fragile plymouth dance.
[10:40] <tvoss> RAOF, help me understand, what is the fragile plymouth dance? :)
[10:40] <mlankhorst> tty handover from plymouth
[10:41] <RAOF> Plymouth starts, grabs the display. We then ask plymouth to die but hide its dying, and then X starts up, grabs the display, and takes the contents of the framebuffer.
[10:42] <mlankhorst> well it looks like a workaround here might be to use VT_SETACTIVE instead of VT_ACTIVATE
[10:42] <mlankhorst> erm VT_SETACTIVATE *
[10:43]  * duflu goes to find food
[10:43]  * tvoss loves those subtle differences for VT_* ;)
[10:43] <tvoss> duflu, good luck
[10:43]  * duflu rolls eyes at those identifiers
[10:43] <mlankhorst> we'd snatch the terminal away from plymouth, if it's still active :P
[10:43] <tvoss> RAOF, so in an ideal world, plymouth would just be a mir client, right?
[10:43] <RAOF> Correct!
[10:44] <mlankhorst> meh lets see if it works..
[10:44] <RAOF> mlankhorst: Can we just nuke the whole VT subsystem?
[10:48] <tvoss> RAOF, would disconnecting from the controlling tty for Mir help here?
[10:49] <mlankhorst> lets see if this works...
[10:49] <mlankhorst> tvoss: when touching the modes of the controlling tty, you want to not be attached to the tty?
[10:49] <tvoss> mlankhorst, random idea :)
[10:52] <mlankhorst> I guess not touching the tty at all could work though :p
[10:53]  * tvoss mutters something about process group leaders and setsid
[11:05] <tvoss> alf__, I set the status of https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
[11:05] <tvoss> back to needs review
[11:05] <tvoss> I'm quite sure I can fix the heisenbug :)
[11:09] <mlankhorst> tvoss: actually it might need setsid for this to work correctly..
[11:11] <mlankhorst> is unity-system-compositor run as root?
[11:11] <tvoss> mlankhorst, I think so
[11:12] <alf__> tvoss: as you like, I figured that since this MP was not related to the problem that cause the failure, we might as well merge it
[11:13] <RAOF> mlankhorst: Yes, u-s-c is run as root.
[11:13] <mlankhorst> blergh, looks like we need to do setpgid, setsid, before opening console
[11:14] <mlankhorst> after that when /dev/tty is opened it automatically becomes ours, or in the worst case we need to claim it for ourselves
[11:15] <tvoss> alf__, fair point, I will repropose under a different name
[11:25] <mlankhorst> I now know more about job control than I cared for :p
[11:41] <RAOF> tvoss: I'm off to bed; I've not yet managed to run a fully instrumented stack, so I'm not sure what I'll find.
[11:44] <tvoss> RAOF, ack, thanks
[11:45] <mlankhorst> meh got a fix, I think
[11:46] <mlankhorst> http://paste.debian.net/18230/
[11:47] <mlankhorst> the TIOCSCTTY needs to be uncommented if the setsid is not enough..
[11:50] <mlankhorst> but it's kind of rude since it means snatching the tty away from someone else :p
[11:54] <tvoss> mlankhorst, well, that's the consequence of our plymouth dance, right? :)
[11:54] <mlankhorst> I guess so, what is the sleep for btw
[11:54] <mlankhorst> it seems to work fine without
[11:55] <tvoss> mlankhorst, didrocks was seeing some races iirc :) didrocks ^?
[11:58] <mlankhorst> apart from some gpu stall everything works fine I guess
[11:58] <mlankhorst> and the stall might be related to changes in my own tree
[12:02] <mlankhorst> meh the remainder seems to be related to my card being flaky
[12:05] <tvoss> mlankhorst, \o/
[12:05] <tvoss> mlankhorst, wanna come up with an mp?
[12:07] <mlankhorst> what branch is base?
[12:08] <tvoss> mlankhorst, trunk, bzr branch lp:mir
[12:08] <mlankhorst> ok
[12:12] <mlankhorst> lets see if this works
[12:17] <tvoss> alf__, didrocks https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
[12:17] <mlankhorst> hm, I need a better git-bzr
[12:30] <tvoss> mzanetti, could you retrigger CI for https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
[12:30] <tvoss> ?
[12:30] <tvoss> didrocks, you around?
[12:30] <mzanetti> tvoss: sure. If you want I can give you permissions to retrigger jobs
[12:31] <tvoss> mzanetti, I have, still need to setup my vpn :)
[12:31] <tvoss> again :)
[12:31] <mzanetti> tvoss: actually, in this case its enough to re-set the MR to "Approved" and Jenkins will pick it up again
[12:32] <tvoss> mzanetti, top-state?
[12:32] <mzanetti> tvoss: yeah
[12:32] <didrocks> tvoss: back now
[12:32] <tvoss> didrocks, https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
[12:33] <tvoss> didrocks, that's not the usc adjustment
[12:33] <didrocks> ok, looking for the additional commit
[12:35] <didrocks> tvoss: ok, a little bit complex. What I would suggest is that we get the ATI fix first, then, having that running (with the workaround) a couple of day, and then, removing the sleep workaround, thoughts?
[12:36] <tvoss> didrocks, not sure I do get you :) the mr I pasted is not connected to the ati issue ;)
[12:36] <didrocks> tvoss: right, what I meant is:
[12:36] <didrocks> let's not try to remove the race workaround for now
[12:37] <didrocks> your fix is to avoid this issue, right? ^
[12:37] <tvoss> didrocks, where do you see that I remove it?
[12:37] <tvoss> nope :)
[12:37] <mlankhorst> look I don't think that this is ready for universe if it requires a sleep workaround..
[12:37] <tvoss> didrocks, mlankhorst might have a fix for the sleep workaround
[12:37] <didrocks> tvoss: ah, I thought the waitpid would help that case as well, but maybe not enough context in the diff and it would be better than I download the whole file :)
[12:38] <didrocks> ah good ;)
[12:38] <tvoss> didrocks, yeah, this should fix the armhf races
[12:38] <didrocks> but I would suggest that we keep the sleep for a couple of days (even if we have the fix)
[12:38] <didrocks> to get things flowing
[12:38] <didrocks> and then, trying to removing it and testing several rounds
[12:39] <tvoss> didrocks, for disabling the input: can we pass additional command-line arguments to usc via lightdm?
[12:40] <didrocks> tvoss: it seems to be possible, you just can't use shell expansion or && for instance
[12:40] <didrocks> but command --option seems to work
[12:40] <didrocks> (as "strace unity-system-compositor" worked)
[12:41] <tvoss> didrocks, okay, then you can just pass --enable-input=false to usc :)
[12:42] <didrocks> tvoss: this is already implemented?
[12:42] <tvoss> didrocks, yup
[12:42] <didrocks> hum, grep isn't my friend
[12:42] <tvoss> didrocks, usc uses mir's DefaultServerConfiguration, which in turn respects that command-line option
[12:42] <didrocks> ah ok ;)
[12:43] <tvoss> didrocks, you need to fgrep in mir
[12:43] <didrocks> yeah, makes sense
[12:43] <tvoss> src/server/default_server_configuration.cpp
[12:43] <didrocks> indeed, saw it :)
[12:45] <didrocks> tvoss: https://code.launchpad.net/~didrocks/unity-system-compositor/fix-for-ati/+merge/176674
[12:45] <didrocks> I'll then rebuild once in trunk and ensure with multiple test runs it's reliable
[12:46] <mlankhorst> and again that needs fixing too :P
[12:48] <mlankhorst> https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/176676
[12:50] <tvoss> didrocks, mind filing a bug against usc to make sure that we reenable hw pointer functioanlity shortly?
[12:50] <didrocks> tvoss: sure
[12:50] <tvoss> didrocks, thx
[12:51] <mlankhorst> I don't think papering around it is a good thing though, that bug should be fixed first
[12:51] <didrocks> mlankhorst: we have deadlines as well, we can't be idealistic when working on time constraints
[12:51] <didrocks> as long as bugs are logged in, I don't think we should hold off
[12:52] <didrocks> if we know that the workaround is reliably working
[12:52] <mlankhorst> yeah but you want to land a random git snapshot of mesa, some xorg patches and some other stuff and then put mir in universe?
[12:52] <didrocks> mlankhorst: mir will be in main I guess
[12:52] <didrocks> to be able to build xorg
[12:52] <didrocks> as it's a build-dep, right?
[12:52] <mlankhorst> yes
[12:52] <didrocks> so Mir in main, but not enabled by default
[12:53] <didrocks> just a technology snapshot to get people trying it
[12:53] <mlankhorst> and if it's in main it means I have to support it, including the mir bits. So open bugs that are not understood become a lot more important to me then..
[12:54] <robotfuel> Does anyone know how I change the resolution in xmir? xrandr doesn't work
[12:54] <didrocks> mlankhorst: you're welcome to give a hand to properly resolving them promptly consequently
[12:54] <didrocks> tvoss: https://bugs.launchpad.net/mir/+bug/1204505
[12:55] <tvoss> didrocks, thx
[12:55] <didrocks> tvoss: not sure how you want to prioritize it
[12:55] <tvoss> didrocks, not sure yet, put it high, please
[12:55] <didrocks> doing so
[13:11] <robotfuel> Sarvatt: I tried openarena with vblank_mode=0 in xmir, it still was a lot faster than x
[13:12] <tvoss> bregma, ping
[13:12] <bregma> tvoss, hi
[13:14] <kgunn> tvoss: thank for all your help overnight!
[13:15] <tvoss> bregma, I looked into the acceptance tests, input-related ones specifically, and came up with an MP
[13:15] <tvoss> https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367
[13:15] <kgunn> robotfuel: if that weird "better on xmir than x" only happening on ati gpu ? or e.g. on my intel i did not see this...i saw a 10% drop
[13:15] <tvoss> bregma, it contains a pipe-based cross-process sync appraoch and adds a timeout to wait_for_termination
[13:15] <robotfuel> kgunn: yes this is only ati
[13:15] <kgunn> robotfuel: wondering if its related to ati video driver
[13:16] <bregma> tvoss, will it handle the case where a server child process is waiting for a client child process and the client child process exits without sending a synch message?
[13:16]  * kgunn wonders if intel is vsync'ing properly...and ati is unhinge from vsync
[13:16] <robotfuel> kgunn: we also can't to xmir benchmarks at 800x600 until this bug is fixed https://bugs.launchpad.net/mir/+bug/1196239
[13:17] <robotfuel> kgunn: we can get the default resolution for the monitor though
[13:18] <tvoss> robotfuel, that's fine for now
[13:19] <kgunn> robotfuel: hmmm & that bug is only on ati as well correct ?...again, i get different #s on my intel when i run 600x800 vs native res, meaning...my intel numbers all look sane
[13:20] <robotfuel> kgunn: it might be, intel isn't working for me right now, it has the driver bug
[13:21] <robotfuel> kgunn: can you delete xserver-xorg-video-intel package version 2:2.21.9+xmir5870-1~saucy1 from the mir-team/system-compositor-testing ppa?
[13:22] <robotfuel> kgunn: the 0~saucy1 driver is suppose to work
[13:23] <kgunn> robotfuel: lemme see
[13:28] <kgunn> tvoss: so, robotfuel asked for me to roll back intel driver to 0~saucy1....but before i venture off, do you know why raof manually updated it ? do you have some context ? (is this for sna ?)
[13:29] <tvoss> kgunn, I actually copied it over, it's the driver with sna enabled
[13:29] <tvoss> robotfuel, are you sure that you have the ppa pinned? the driver is working perfectly fine here
[13:31] <kgunn> robotfuel: confirmed...its working on mine for past few days as well
[13:31] <kgunn> i was tvoss guinea pig & just left it installed
[13:42] <robotfuel> tvoss: kgunn  https://bugs.launchpad.net/xmir/+bug/1203776 a lot of people have a problem with the 1~saucy driver
[13:43] <tvoss> robotfuel, are we sure that those people did pin the ppa correctly?
[13:43] <tvoss> robotfuel, can you try the intel driver from staging real quick on the machine?
[13:44] <robotfuel> tvoss: I'll try the one from the staging ppa, RAOF's looked at the bug and verified it.
[13:45] <tvoss> robotfuel, ack and thx
[13:45] <didrocks> tvoss: ok, unity-system-compositor starts and hang (remember that it's with Mir trunk rebuilt from the last couple of hours)
[13:45] <didrocks> tvoss: dm_connection_start
[13:45] <didrocks> Failed to read header
[13:46] <tvoss> didrocks, dm_connection talks to lightdm
[13:46] <tvoss> robotfuel, if your issue is fixed with the intel driver, I will copy it over to the testing-ppa
[13:46] <tvoss> kgunn, ^
[13:47] <didrocks> tvoss: new xorg-server in distro…
[13:47] <didrocks> I bet that's it
[13:47]  * didrocks looks at the version
[13:47] <tvoss> argh
[13:49] <robotfuel> tvoss: didrocks http://<IP_ADDRESS>:8080/job/utah-xmir-troubleshooting/3/artifact/results/dpkg-list.log has the versions of everything installed when the xorg crash happens
[13:49] <didrocks> tvoss: yeah, I bet it's the xorg issue
[13:49] <didrocks> tvoss: I'll just apt-get source the old one
[13:49] <tvoss> didrocks, for the dm_connection thingy?
[13:49] <didrocks> and update with it
[13:49] <didrocks> tvoss: yeah, it's a consequence
[13:50] <didrocks> xorg doesn't have -mir option
[13:50] <tvoss> didrocks, ack
[13:50] <tvoss> didrocks, ah ...
[13:50] <didrocks> so, /me apt-get source, fake a bump changelog and reupload to daily-buid-next ppa
[13:51] <didrocks> mlankhorst: would be nice to coordinate with us and not make the whole thing more painful :p
[13:53] <kgunn> didrocks: so we're not dead yet, once  you update daily-build-next ppa we get another shot at tvoss "disable input" for the ati bug?
[13:54] <didrocks> kgunn: right
[13:54] <didrocks> kgunn: I have faith, his fix in mir directly worked with multiple runs
[13:54] <didrocks> kgunn: I think if the option in unity-system-compositor is correctly wired up, it shouldn't make a difference and should pass as well
[13:54] <kgunn> didrocks: that's good news...
[13:54] <kgunn> thanks
[13:55] <xjunior> Morning edge people
[13:57] <didrocks> mlankhorst: actually, it was doko on that one…
[14:00] <tvoss> robotfuel, did you install the driver, yet?
[14:01] <robotfuel> tvoss: no not yet, I'll do it now.
[14:02] <tvoss> robotfuel, ack
[14:07] <greyback> alf__: ping
[14:10] <robotfuel> tvoss: FYI the drivers in the latest drivers staging ppa failed to build https://launchpad.net/~mir-team/+archive/staging/+packages
[14:12] <alf__> greyback: pong
[14:12] <greyback> alf__: hey, the snapshot API is working great, thank you
[14:14] <alf__> greyback: Great news! Thanks for letting me know.
[14:14] <greyback> alf__: I've one question however. I grab a snapshot just after the application surface is created, which is a touch too early as I guess the application hasn't drawn to it yet (i.e. I get black snapshot). Would there be a way to detect if an app has actually drawn to it's surface
[14:14] <greyback> alf__: this is nothing at all major (for now I just delay snapshot with a timer), but would be nice for later
[14:15] <tvoss> greyback, I think we should postpone that discussion until we have cleaned the scenegraph-conglomerat within mir
[14:16] <robotfuel> tvoss: the lastest successful build from the staging ppa is already installed on the system. It doesn't work
[14:16] <alf__> greyback: We have such a mechanism internally, but I don't think it is exposed in any way to the shell.
[14:22] <greyback> alf__: I see. I'll keep it in mind. I might log a bug for it. Thanks!
[14:23] <alf__> greyback: np
[14:38] <robotfuel> tvoss: I have some other intel systems that didn't have an xorg crash
[14:38] <robotfuel> tvoss: I am retrying to see if it's a race condition.
[14:38] <tvoss> robotfuel, ack
[14:45] <robotfuel> kgunn: resolution changes do work on intel, not on radeon. :)
[14:46] <kgunn> robotfuel: i am so frustrated with the ati...
[14:46] <kgunn> :-/
[14:59] <tvoss> didrocks, status?
[14:59] <didrocks> tvoss: 3 runs until now, it's all green
[14:59] <robotfuel> tvoss: the xmir crash on intel is race condition
[14:59] <didrocks> tvoss: I'm waiting for the 4th to finish
[14:59] <tvoss> robotfuel, where?
[14:59] <didrocks> to send an email :)
[14:59] <tvoss> didrocks, ack and thx
[14:59] <didrocks> tvoss: yw! thanks to you!
[15:01] <robotfuel> tvoss: https://bugs.launchpad.net/xmir/+bug/1203776
[15:03] <tvoss> robotfuel, no, I meant where in the code ;)
[15:03] <robotfuel> tvoss: I haven't looked in to it.
[15:05] <tvoss> robotfuel, okay, thx
[15:05] <qengho> Hi all. I maintain Chromium browser, and I received a pointer from upstream to a doc about their efforts to abstract some of the display interface.  We may find it interesting. https://sites.google.com/a/chromium.org/dev/developers/design-documents/ozone
[15:08] <tvoss> qengho, hey there :)
[15:08] <qengho> tvoss: yo.
[15:11] <tvoss> qengho, I recently read it, quite interesting :)
[15:12] <hikiko_> alf__, revno 881 works better: I see the mouse pointer but I can't move it
[15:15] <qengho> tvoss: Thanks.
[15:16] <tvoss> qengho, thanks for keeping us posted
[16:15] <tvoss> bregma, ping
[16:26] <bregma> tvoss, pong
[16:26] <tvoss> bregma, so my local testing reveals some issues under valgrind, still trying to digest all of the information
[16:28] <bregma> ....
[16:28] <tvoss> bregma, thought I would handover, as your mail suggested to me that you are looking into the issue, too
[16:29] <bregma> sure
[17:46] <kdub> kgunn, ping
[17:48] <kgunn> kdub: pong
[18:53] <racarr> lol...whoops
[18:53] <racarr> I just found a unit-test file which is missing from cMakeLists.txt
[18:53] <racarr> after spending 5 minutes like oh god how does this compile
[18:53] <racarr> do I even understand C++
[18:53] <racarr> what is happening
[18:53] <racarr> etc
[18:53] <kdub> haha
[18:54] <racarr> (missing from CMakeLists in trunk)
[18:54] <racarr> for who knows how long
[18:54] <racarr> because the API it uses is quite old
[18:54] <racarr> thats ok though its a lame test
[18:54] <racarr> *makes new branch*
[18:55] <racarr> I wonder if I should write a failing test that all our test files are built :p
[19:04] <racarr> omg
[19:04] <racarr> more dead files
[19:04] <racarr> this is embarassing -.-
[19:05] <kdub> which tests?
[19:08] <racarr> kdub: test_android_input_registrar
[19:08] <racarr> and mock_input_configuration.h which it includes
[19:08] <kdub> what
[19:08] <racarr> its been this way for at least
[19:08] <racarr> 3 months
[19:08] <racarr> because Ir emember I rebuilt the input configuration
[19:08] <racarr> when I still lived at my old place
[19:08] <racarr> we could use bzr blame but it's almost certainly my fault so
[19:08] <racarr> :p
[19:09] <kdub> ah, i thought you said another registrar test that I was sure was working lately :)
[19:59] <racarr> I hate using droidinput::Vector
[19:59] <racarr> s/hate/have a strong distaste
[20:11] <racarr> https://code.launchpad.net/~robertcarr/mir/support-monitor-input-channels/+merge/176775 whee
[20:12] <racarr> good news, unity is done
[20:12] <racarr> *closes eyes and begins to sleep*
[20:12] <racarr> :p
[20:16] <kdub> racarr, droidinput::Vector can't be as bad as writing new classes that support android::sp :)
[20:17] <racarr> kdub: Ah, android::sp
[20:18] <racarr> you know the input stack still isnt the most beautiful code
[20:18] <racarr> but we have come a long way since
[20:18] <racarr> android::sp in DefaultServerConfiguration
[20:18] <racarr> XD
[20:36] <kdub> oh yeah, much better now :)
[20:36] <kdub> mir on the whole is much better
[20:36] <kdub> remember back in the day, when we wrapped std::thread/mutex/chrono with boost? :)
[20:56] <racarr> kdub: Oh god
[20:56] <racarr> that led to the most fucked up compiler errors.
[20:57] <racarr> I just remember, coming on to the Mir team, in the past I had been a perpetual C++ skeptic but I was like
[20:57] <racarr> ok well I guess if they are doing C++ carefully and the right way it seems pretty good and well lets try it
[20:57] <racarr> then I ran in to some stuff from the std::thread stuff and mir::std and I was just like
[20:57] <racarr> oh god....
[21:00] <racarr> Back soon
[21:24] <olli> robert_ancell, ping
[21:27] <robert_ancell> olli, hello
[21:27] <olli> hey robert_ancell
[21:27] <olli> quick q, I am trying to understand the new dashboard gema announced recently
[21:28] <olli> from there it looks like we are building u-s-c without running any tests
[21:28] <olli> http://<IP_ADDRESS>/staging/merger/unity-system-compositor/
[21:29] <olli> kgunn, ^
[21:30] <robert_ancell> olli, u-s-c doesn't have any tests currently
[21:30] <olli> robert_ancell, how come, I thought anything mir has tons of tests
[21:31] <olli> that's what I keep getting told at least
[21:31] <olli> :)
[21:31] <robert_ancell> olli, not u-s-c. :(
[21:32] <olli> how do we intend to land that in distro if it doesn't have tests
[21:35] <olli> robert_ancell, ^
[21:35] <olli> brb
[21:37] <robert_ancell> olli, it doesn't have much code over top of existing Mir so it is quite well tested. We will have integration tests that ensure that the whole stack works together. But yes, it should have some local tests too
[21:43] <racarr> because of the structure we use kind of like...
[21:43] <racarr> 1. Mir component. 2. default implementation in tree for demo-server and system-compositor
[21:43] <racarr> 3. another implementation for unity
[21:43] <racarr> I agree USC is really pretty well tested
[21:43] <racarr> even if it has no in tree tests
[21:51] <olli> robert_ancell, what's the plan to get tests in place
[21:54] <robert_ancell> olli, file bugs and prioritize them
[21:55] <olli> that's a reaction to my ping but apparently not a long standing plan
[21:57] <robert_ancell> kernel panic, please repeat anything directed at me since " robert_ancell, what's the plan to get tests in place"
 olli, file bugs and prioritize them
 that's a reaction to my ping but apparently not a long standing plan
[22:00] <robert_ancell> olli, the long plan is the same as Mir - new functionality needs new tests. At the moment we have very little functionalty
[22:17] <robert_ancell> racarr, regarding https://code.launchpad.net/~robertcarr/mir/session-transactions/+merge/175669 alan is away
[22:17] <robert_ancell> this week
[22:17] <robert_ancell> So, get a second opinion or you have to wait if you need his response
[22:22] <racarr> robert_ancell: Hoping for a second opinion :)
[22:22] <racarr> not in the, need someone to approve it sense, but in the actually trying to figure out if its a good idea sense
[22:46] <kgunn> thomi: question about http://<IP_ADDRESS>:8080/job/mir-saucy-amd64-ci/
[22:47] <kgunn> am i reading that right...are the number of tests dramatically dropping?
[22:48] <kgunn> or did they migrate...http://<IP_ADDRESS>:8080/job/mir-vm-ci-build/
[22:48] <kgunn> ?
[22:53]  * thomi looks
[22:56] <thomi> kgunn: that graph seems odd - I'm sure we don't have 50000 tests :-/
[22:57] <thomi> kgunn: looks like the results are being repeated a bunch of times: http://<IP_ADDRESS>:8080/job/mir-saucy-amd64-ci/216/testReport/%28root%29/SurfaceCreation/
[23:28] <robert_ancell> 23 outstanding MPs! We need to land some code here
[23:29] <robert_ancell> kdub, can you check if you're happy with https://code.launchpad.net/~afrantzis/mir/rectangle-closed-open/+merge/176348
[23:29] <kdub> robert_ancell, sure
[23:29] <kdub> i think i am, just wanted to get the input take on the matter
[23:31] <robert_ancell> kdub, also, if you've fixed the issues duflu pointed out https://code.launchpad.net/~kdub/mir/add-pf-query/+merge/176451 can land
[23:35] <racarr> greyback: https://code.launchpad.net/~robertcarr/mir/support-monitor-input-channels/+merge/176775
[23:35] <racarr> a present for you
[23:35] <greyback> racarr: aww geee, you shouldn't have!
[23:36] <racarr> greyback: Don't worry, I left a bag of coal in the Qt scene graph thread so it's balanced
[23:36] <greyback> racarr: :)
[23:36] <racarr> the impl is a little different than how it was on SF but I think as long as
[23:36] <racarr> you are using the surface InputRegioni
[23:37] <racarr> int he same way the trap windows were used before
[23:37] <racarr> it should work
[23:37] <racarr> I even read some QML code
[23:39] <greyback> racarr: goodness, you have been busy
[23:43] <racarr> greyback: Nah. it's just a carefully crafted illusion
[23:43] <racarr> *kicks up feet*
[23:43] <racarr> Happy to see your video last night before I went to sleep :)
[23:44] <racarr> did you guys get my email to scene graph thread because I didnt get my own email
[23:45] <racarr> but normally do...
[23:45] <greyback> racarr: it looks like it does all I need. I'll try integrating it tomorrow. Note I'm on holiday Friday, so tomorrow is gonna be busy for me
[23:46] <racarr> if it's simple, i.e. surface needs to become a monitor surface and X needs to be hooked up to Y and bla and bla
[23:46] <racarr> I have some time
[23:47] <racarr> well not tonight probably anyway
[23:47] <racarr> but if you cant finish it tomorrow, maybe send me a brain dump if it makes sense andI can try and run with it
[23:47] <greyback> racarr: yep, got it. I didn't read it as rough-edged
[23:47] <greyback> sure
[23:48] <greyback> it's what I'll attempt first thing. As right now, cannot actually interact with apps!
[23:48] <racarr> pft
[23:48] <racarr> greyback: So we just got it working and now already first thing feature bloat
[23:48] <greyback> racarr: XD
[23:51] <kdub> ooo android 4.3
[23:53] <racarr> kdub: Oooo
[23:53] <kdub> yay, looks like the HAL layer is the same
[23:53] <kdub> for graphics
[23:53] <kdub> racarr, time to start merging their new input stack!
[23:53] <kdub> :P
[23:53] <racarr> kdub: I was about 3 second ahead of you there
[23:53] <racarr> kdub: "Improved window buffer allocation results in a faster image buffer allocation for your apps, reducing the time taken to start rendering when you create a window."
[23:53] <racarr> that ones for you ;)
[23:54] <kdub> where did you see that?
[23:54] <racarr> kdub: http://developer.android.com/about/versions/jelly-bean.html?43
[23:55] <racarr> Video encoding from a surface
[23:55] <racarr> Starting in Android 4.3 you can use a surface as the input to a video encoder. For example, you can now direct a stream from an OpenGL ES surface to the encoder, rather than having to copy between buffers.
[23:55] <racarr> "On-screen GPU profiling
[23:55] <racarr> "
[23:55] <racarr> only new SF stuff
[23:55] <kdub> yeah, seems like all new SF stuff
[23:55] <racarr> well
[23:55] <racarr> and drivers are
[23:55] <racarr> open gles 3 now?!
[23:56] <kdub> probably just an option though?
[23:56] <kdub> lots of new bluetooth hals though
[23:57] <RAOF> Why does xmir suddenly infinite loop in xf86DeleteDriver now that I'm trying to debug?!
[23:57] <kdub> thank goodness we're not a bluetooth server
[23:58] <racarr> kdub: yeah they just say the nexus devices have
[23:58] <racarr> opengles3
[23:58] <racarr> I cant even think of one clever thing you could do with mir and opengles3 XD
[23:59] <racarr> Im sure its good for clients


[01:16] <bcurtiswx> xclaesse: Send me an email and I can get to it.
[01:55] <cyphermox> bcurtiswx: nm 0.9 is pretty much ready, but I'm struggling a bit porting the indicator patch to nm-applet 0.9.
[01:55] <cyphermox> once that's done I'll upload to oneiric and we can put it in the PPA too
[01:56] <bcurtiswx> It needs gtk3 and kenvandine may be able to help once he catches up.
[01:56] <bcurtiswx> cyphermox: Great though!
[01:57] <cyphermox> bah, we already have gtk3
[01:58] <bcurtiswx> The indicator patch needs to be gtk3ified
[01:58] <cyphermox> yeah, I'm working on it
[01:58] <cyphermox> that's all that's stopping me from uploading NM, because otherwise the applet is broken, and wifi is pretty much unusable :)
[01:59] <bcurtiswx> I may steal your work when your done O:-)
[01:59] <cyphermox> sure
[01:59] <cyphermox> I'm already running 0.9 on my laptop, but without applet for now
[02:02] <bcurtiswx> I am in NY camping with my 'rents this weekend.
[02:05] <cyphermox> camping with the intarwebs ? ;)
[02:06] <bcurtiswx> 3G phone and colloquy :) I start tomorrow
[02:06] <cyphermox> ahh!
[02:58] <cyphermox> bcurtiswx: done! I'll give it some more testing locally and push/upload tomorrow :)
[03:14] <bcurtiswx> cyphermox: Great! :)
[05:26] <EhsanSanayei> Hi does anyone know how can I add a keyboard input layout using terminal?Im Using ubuntu 11.04
[05:27] <pitti> Good morning
[05:28] <RAOF> Good morning!
[05:28] <EhsanSanayei> Hi Good morning
[05:28] <EhsanSanayei> do you guys know how can I add a keyboard input layout using terminal?Im Using ubuntu 11.04
[05:29] <RAOF> EhsanSanayei: This is not a support channel; a better place to ask would be #ubuntu or askubuntu.com.  That said, ‘sudo dpkg-reconfigure keyboard-configuration’ is likely to do what you want.
[05:30] <pitti> robert_ancell: hey Robert, how are you?
[05:30] <EhsanSanayei> what channel is this?
[05:30] <robert_ancell> pitti, hello
[05:30] <pitti> robert_ancell: urgh, that must have been the worst ubuflu ever -- do you feel any better?
[05:31] <robert_ancell> pitti, I've been feeling better the last two days, but still not 100%
[05:32] <TheMuso> Good morning pitti.
[05:32] <pitti> robert_ancell: so, I hope the weekend will provide the rest! *hug*
[05:32] <pitti> hey TheMuso, how are you?
[05:33] <TheMuso> pitti: Not too bad thanks.
[05:33] <RAOF> robert_ancell: I see that you've managed to eliminate the flicker on login between lightdm and unity.  Yay!
[05:34] <robert_ancell> RAOF, yeah, it seems just setting the background pixmap and cursor was all that was required
[05:34] <robert_ancell> I just need to add Plymouth integration (which seems overly complicated) and then I think it's ready for A1
[05:35] <robert_ancell> RAOF, actually, do you know the details of Plymouth?
[05:35] <RAOF> Plymouth integration shouldn't be hard, right?  As far as I'm aware, all you need to do is pass X the “no background” option and tell plymouth to quit?
[05:37] <robert_ancell> RAOF, well, actually the display managers do more: 1. They tell Plymouth to get ready to quit, and then they tell it to quit in different ways, and if the X server fails to start they do it differently again
[05:37] <robert_ancell> I can't see what the point is, it's only going to save microseconds instead of just going.  "I am the display manager and you shalt quit now!"
[05:38] <RAOF> Ah, ok.  I'm more aware of the X side, which is basically just ‘pass -nr to copy whatever was left on the fb to the root pixmap’
[05:39] <RAOF> I guess as long as you tell plymoth to quit in such a way that it doesn't clear the framebuffer you're golden - as long as you can clean up if X doesn't start.
[05:40] <robert_ancell> what do you need to do to clean up?
[05:40] <RAOF> Well, you'd like to leave the user with a text mode VT with a login prompt on it, I guess.
[05:41] <RAOF> Although that's really a lie.  You *want* to leave the user with X up, whatever it takes to get it there.
[05:41] <pitti> kenvandine_: are you still awake by any chance?
[05:41] <robert_ancell> RAOF, is that just a matter of telling the kernel to switch VT?
[05:42] <RAOF> robert_ancell: I'm not familiar with the details of what plymouth does in the various exit scenarios, sorry.
[05:42] <robert_ancell> RAOF, but in terms of graphics, Plymouth is just writing to the frame buffer on one VT right?
[05:42] <RAOF> Although if you could ensure that plymouth doesn't mess with the tty's input mode, making “enter” send SIGQUIT, that'd be ace :)
[05:42] <RAOF> robert_ancell: Precisely, yes.
[05:44] <pitti> robert_ancell: I don't think anything except plymouth itself should ever do a VT switch these days
[05:45] <robert_ancell> pitti, doesn't CK do VT switches too?
[05:45] <pitti> OMGno; CK only tracks VT switches, but never actively does them
[05:46] <pitti> there's some clever handover between plymouth and X.org, but I don't know the details of that
[05:46] <pitti> (to get it completely flicker-free)
[05:46] <robert_ancell> pitti, so how do you switch user? I thought that went via CK and it did the VT switch
[05:47] <RAOF> I presumed that's gdm?
[05:47] <pitti> robert_ancell: yes, you can tell it to change to a different VT
[05:47] <pitti> robert_ancell: sorry, I thought you were talking about the initial startup and plymouth handover
[05:47] <robert_ancell> RAOF, no, that was outsourced to CK
[05:47] <pitti> once X is running, plymouth is gone, so from then on it's not involved any more
[05:51] <robert_ancell> pitti, The GDM plymouth patch calls plymouth_quit_without_transition if the X server dies.  I'm guessing the idea is to quit Plymouth if you fail to start the server?
[05:56] <pitti> robert_ancell: I think so, so that you at least have a VT
[07:11] <didrocks> good morning
[07:13] <pitti> bonjour didrocks
[07:13] <pitti> didrocks: seems unity-2d and dependencies currently pull in 10.6 MB of extra .debs
[07:14] <didrocks> pitti: guten morgen. compressed or uncompressed?
[07:14] <pitti> didrocks: compressed (.deb size)
[07:15] <didrocks> how did you see that? there was no respin. did you try manually?
[07:15] <pitti> I apt-get upgraded, removed all Qt stuff from my system, and then dist-upgraded (which was only ubuntu-desktop pulling in unity)
[07:15] <didrocks> ok
[07:15] <pitti> i. e. upgraded everything else except unity-2d, and then pulled that in by itself
[07:15] <pitti> I wanted to see the magnitude of it
[07:15] <didrocks> pitti: it seems not as bad as what we were thinking of first (15/18MB)
[07:16] <didrocks> do you know what changed yesterday to make the CD oversize (and win 15 MB) btw?
[07:17] <pitti> didrocks: no; actually I still don't know what made the 0525 one so small
[07:17] <pitti> we added GTK3, numpy, langpacks got bigger (due to update packs), gcc/g++ got bigger, etc.
[07:17] <pitti> that's why it really surprised me that the first build was not oversized
[07:17] <pitti> now we are about 15 MB oversized which is about what I expected
[07:18] <pitti> I mean, 10 MB oversized, grew by 15 MB
[07:18] <didrocks> pitti: ok, so 15 MB to win now that we everything in. That will be challenging…
[07:18] <pitti> I'm fixing numpy right now
[07:18] <pitti> didrocks: today's build should come out as 720 MB, with unity-2d in
[07:19]  * pitti unseeds g-s-t
[07:19] <didrocks> sorry, I miss 5 MB there :-)
[07:19] <didrocks> ok no
[07:19] <pitti> ?
[07:19] <didrocks> you are speaking of amd64, right?
[07:19] <pitti> right
[07:19] <didrocks> ok, I was focusing on i386 ;)
[07:20] <didrocks> so, I found the 5 Mb delta I was missing ;)
[07:25] <didrocks> pitti: a quick look at gnome-panel + applets + alacarte and we should win 1.3 Mb one unseeded
[07:26] <pitti> I also unseeded g-s-t
[07:26] <pitti> didrocks: do you already have an idea how much can be squeezed out of qt?
[07:26] <didrocks> pitti: those are replaced by g-c-c modules for most of them?
[07:27] <pitti> didrocks: we only used users-admin in natty
[07:27] <pitti> the rest already had replacements
[07:27] <pitti> and g-c-c 3 now provides that
[07:27] <didrocks> pitti: well, the dep seems to be quite minimal, I need to first do the merge with debian (next week) which will be touchy to have a deeper look, but it seems we only pool the modules we need
[07:27] <didrocks> ok, nice :)
[07:27] <didrocks> pull*
[07:28] <pitti> didrocks: so shoudl we unseed gnome-panel/-applets, as they are already pulled in by session-fallback?
[07:28] <pitti> so that they fall off the CD once session-fallback does?
[07:29] <didrocks> pitti: exactly
[07:29] <didrocks> pitti: do you want me to do that? (or are you already modifying the seed with g-s-t)
[07:29] <pitti> I'm at it
[07:30] <didrocks> pitti: don't forget alacarte
[07:30] <pitti> got it
[07:31] <pitti> didrocks: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.oneiric/revision/1841
[07:32] <didrocks> pitti: excellent :)
[07:32] <pitti> didrocks: does unity-2d use metacity?
[07:32] <pitti> we still seed this directly
[07:33] <didrocks> pitti: yeah, we can remove the direct seed
[07:33] <didrocks> unity-2d depends on it
[07:33] <didrocks> hum, indicator-applet-session, dpkg -L seems to show it's only the applet, so safe to remove
[07:33] <didrocks> well, once we will remove the fallback session
[07:33]  * didrocks adds a note to the pad
[07:34] <pitti> = GUI infrastructure =
[07:34] <pitti>  * xterm                         # Provide a backup terminal and complete X env.
[07:34] <pitti> *chuckle*
[07:34]  * pitti kicks out gconf-editor; dconf-editor FTW!
[07:35] <didrocks> \o/
[07:35] <didrocks> will we install dconf-editor by default?
[07:36] <didrocks> I like the "Provide […] complete X env" :-)
[07:36] <pitti> we don't install it right now
[07:37] <didrocks> seems we shouldn't?
[07:37] <pitti> not sure
[07:41] <pitti> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.oneiric/changes has some further cleanup now
[07:42]  * didrocks pulls
[07:43] <pitti> I left metacity for now
[07:43] <didrocks> gtk2-engines isn't needed anymore?
[07:44] <didrocks> pitti: oh, why?
[07:44] <pitti> it's already a dependency, and should be
[07:44] <pitti> it's not a top-level app which we want to seed, is it?
[07:44] <didrocks> pitti: the why is for "left metacity", sorry about the confusion
[07:45] <didrocks> yeah, for gtk2-engines, themes should depend on it
[07:45] <pitti> I'm not 100% clear that we can drop it; if you are, please drop it
[07:45] <didrocks> yes we can
[07:45] <didrocks> doing
[07:45] <pitti> that's the Obama spirit! :)
[07:46] <didrocks> :-)
[07:48] <didrocks> dropping compiz as well, unity pulls it in
[07:48] <alex3f> mvo: you around?
[07:48] <pitti> didrocks: committing small cleanup, please update again
[07:49] <didrocks> pitti: sure, and done :-)
[07:50] <didrocks> what's the firefox's thing? seems to take some disk space… :-)
[07:50] <pitti> wget -O- |less !
[07:51] <didrocks> isn't the way everyone is browsing the web? ;)
[07:53]  * pitti kills gnome-about, pulls in pygtk2, and unity doesn't show it anyway
[07:53] <pitti> and classic session pulls it in
[07:54] <pitti> uh, we still install pulseaudio-esound-compat -- do we still need that? it's 2011!
[07:54] <pitti> TheMuso: ^ opinion?
[07:55] <pitti> pulseaudio still recommends that, too
[07:55]  * pitti unseeds
[07:56] <pitti> didrocks: what about gnome-menus?
[07:57] <pitti> unity uses these as well for the categories, right?
[07:57] <didrocks> pitti: unity-place-applications uses it IIRC
[07:57] <didrocks> let me check
[07:57] <pitti> for the category view, presumably
[07:57] <didrocks> libgnome-menu2
[07:57] <didrocks> yeah, it's merging the usc categories with the gnome-menu ones
[07:58] <didrocks> the final goal is only to rely on usc categories (and have everything in the right category)
[07:58] <didrocks> but with mikkel out for 4 months, that won't happen this cycle
[07:58] <alex3f> software-center related question, anyone?
[08:00] <pitti> didrocks: ok, I think that was a nice cleanup round, I'll rebuild
[08:01] <didrocks> pitti: great, let's see how bad it goes :-)
[08:01] <pitti> didrocks: shouldn't make a lot of actual difference on the CD
[08:01] <didrocks> pitti: I'm help smspillaz to prepare the compiz SRU and then, I'll be able to *finally* upgrade to oneiric
[08:01] <pitti> most of the cleanup was stuff that already is a dependency
[08:01] <pitti> just shouldn't be seeded directly
[08:01] <didrocks> yeah, if we didn't screw up one dep, which should be ok ;)
[08:03] <didrocks> pitti: btw, what is the scheme policy to upload unity 3.8.14-0ubuntu1 for -proposed? adding a ~sru1?
[08:03] <pitti> didrocks: if you actually take the oneiric package and backport it, use ~natty1
[08:04] <didrocks> pitti: ok, doing that :)
[08:04] <didrocks> thanks
[08:04] <pitti> if you take the natty package and update the version only (i. e. don't change the packagin), use -0ubuntu0.11.04
[08:04] <didrocks> there is a change in the packaging (adding a compiz dep)
[08:07] <mvo> hey alex3f - yes
[08:07] <alex3f> morning, I found a problem in running s-c locally (not installed)
[08:08] <alex3f> it doesn't detect software-center.menu from build
[08:08] <mvo> ok
[08:08] <alex3f> instead searches for /usr/share/app-install/desktop/software-center.menu
[08:08] <alex3f> I will patch it
[08:08] <alex3f> (the visible result: no categories are loaded)
[08:08] <mvo> alex3f: cool, please do
[08:09] <mvo> alex3f: I will be happy to take the patch
[08:09] <alex3f> great
[08:40] <pitti> robert_ancell: FYI, I'm applying our remainign libgtop2 delta to Debian and will sync afterwards, no need to merge
[08:41] <pitti> (addition of the gir package)
[08:49] <pitti> ugh, today's alternates are at 729 MB
[08:50] <pitti> that's going to be fun
[08:52] <rodrigo_> morning
[08:53] <pitti> hey rodrigo_
[08:55] <rodrigo_> hi pitti
[08:57] <didrocks> hey rodrigo_
[08:57] <rodrigo_> hi didrocks
[08:59] <seb128> hey
[08:59] <didrocks> lut seb128
[09:02] <pitti> bonjour seb128
[09:02] <rodrigo_> bonjour seb128
[09:05] <seb128> hey guys
[09:06] <jibel> seb128, is the retracer offline ?
[09:06] <seb128> jibel, dunno I didn't check since we turned apport off before natty
[09:06] <seb128> jibel, we have no oneiric retracers set up yet for sure
[09:06] <seb128> let me check if the natty ones are working
[09:07] <jibel> seb128, ah ok. I'm selfish here and more concerned about oneiric ;-)
[09:07] <seb128> well I'm not ;-)
[09:08] <seb128> we usually don't turn apport on so early because it would spam launchpad with bugs that will be fixed by upstream before we triage them
[09:08] <seb128> not to mention that keeping an oneiric system uptodate and running for the retracers is costing in maintainance time so early in the cycle
[09:09] <htorque> hello everyone! is it a bug that i cannot change gdm's config using 'sudo -u gdm gsettings set ...'?
[09:10] <pitti> our gdm is using GTK2 and gconf
[09:10] <pitti> (ATM)
[09:11] <pitti> seb128: do you have a minute to discuss icon downsizing? on mumble perhaps?
[09:13] <htorque> pitti: thanks, yet the key is there and writable but always stays 'true' (org.gnome.power-manager 'backlight-enable')
[09:14] <jibel> seb128, no worries, understood. thanks.
[09:15] <seb128> jibel, if you feel like we need retracers now we can discuss it, you should just know it has an impact on the launchpad noise level and is work to keep them running so early
[09:16] <seb128> pitti, heh, sure, I can discuss it there or on mumble, I'm just not sure I know enough about icons to be useful to you
[09:16] <seb128> could be better to discuss there to let a chance to people who have a clue about icons to comment if we need input?
[09:16] <pitti> seb128: (@phone, brb)
[09:16] <pitti> ok, let's do that here the
[09:16] <pitti> n
[09:17] <seb128> lol, I can picture pitti the phone on one side, mumble on the other side and the discussing on IRC on the middle ;-)
[09:17] <htorque> another question: is it ok to ask questions like above in the ubuntu-* channels? i'm not looking for support, i just don't want to create useless bug reports.
[09:17] <jibel> seb128, no, there are very few crash report coming in for Oneiric, I was just wondering.
[09:18] <seb128> jibel, ok, I think we will set up the retracers when we have a moment without turning on apport by default to start
[09:21] <pitti> seb128: so, given that we are now 30 MB oversized, I think the "reduce icons" thing is pretty much non-optional now; so I ponder about the "how"
[09:21] <pitti> there are 207 icons in gnome-icon-theme which aren't provided by humanity
[09:21] <pitti> which is too much to just copy to -humanity
[09:21] <pitti> so I had this in mind:
[09:21] <seb128> we are? cdimage are 709meg
[09:22] <seb128> didn't we say we would go to 720meg isos?
[09:22] <pitti> - split out these icons into gnome-icon-theme-shared
[09:22] <pitti> seb128: alternates from today are at 730
[09:22] <seb128> ok
[09:22] <pitti> seb128: yesterday's live images don't have unity-2d/qt yet
[09:22] <seb128> sorry keep going I didn't mean to stop you
[09:22] <pitti> and none of them have the LLVM gallium drivers
[09:22] <seb128> right but they still have gnome-panel etc though, but that's another discussion
[09:22] <pitti> - add build dep to humanity to dynamically determine the missing ones and which ones to move to -shared
[09:23] <pitti> - g-i-t depends: g-i-t-shared
[09:23] <pitti> - add human-i-t depends: g-i-t-shared
[09:23] <pitti> - replace all g-i-t depends on the default install with human-i-t | g-i-t
[09:24] <pitti> add g-i-t depends to tweak tool (for people wanting to change theme)
[09:24] <pitti> that should save us some 5.8 MB
[09:25] <pitti> it's hackish, but it's quite a large savings
[09:25] <pitti> we need to fix the dependencies of some 10 packages, so not too bad
[09:25] <pitti> does that sound reasonable to you?
[09:27] <seb128> hum
[09:28] <pitti> vish: ^ I'd appreciate your opinion as well, you worked with icons quite a lot
[09:28] <seb128> pitti, the " - replace all g-i-t depends on the default install with human-i-t | g-i-t" means having to have a delta over debian for all of those?
[09:28] <seb128> i.e we can't be on sync due to that?
[09:29] <pitti> a lot of those are already "ours": ubuntu-mono, gdebi, unity-asset-pool, apturl
[09:29] <pitti> for the others, yes
[09:30] <pitti> we don't currently have any of those in sync anyway, but if that would be the only delta, perhaps we can check if the dependency is necessary in the first place
[09:30] <seb128> I can't say I'm happy about it but I don't have a better suggestion yet
[09:30] <seb128> pitti, we have some, gnome-icon-theme-symbolic for example
[09:30] <pitti> I'm not exactly fond of the delta myself, but it seems to be the biggest potential savings that we have right now
[09:31] <pitti> seb128: right, that one seems to be the only one
[09:31] <pitti> ah, the other is libgtkhtml-4.0-common
[09:31] <vish> pitti: do you have a list of those 207 icons? In Humanity, We have not done a few icons in all the sizes because they are not used/required in all the sizes, (so we could narrow it down and copy it over and drop g-i-t)
[09:31] <pitti> seb128: FTR, http://cdimage.ubuntu.com/daily-live/20110527/ just came in
[09:31] <pitti> 733 MB :(
[09:31] <seb128> pitti, did you diff consider missing variants or only missing names?
[09:32] <pitti> diff -u <(dpkg -L humanity-icon-theme | sed 's_.*/__; s/\.\(png\|svg\)//'|sort -u) <(dpkg -L gnome-icon-theme | sed 's_.*/__; s/\.\(png\|svg\)//'|sort -u)|grep ^+
[09:32] <seb128> pitti, will we go for 720 isos this cycle? ie is that only 13meg over?
[09:32] <pitti> that's missing icon names
[09:32] <seb128> pitti, so we need to check also missing variants
[09:32] <pitti> seb128: we don't have a commitment to go to 720 this cycle yet
[09:33] <pitti> it indeed e. g. has
[09:33] <didrocks> pitti: hum, more than the additional +15 Mb with unity-2d you counted?
[09:33] <pitti> +battery-full-charged
[09:33] <pitti> but humanity already has "battery_full"
[09:34] <pitti> I wonder why we have two icons with the smae purpose but different names
[09:34] <seb128> well even moving the icons to h-i-t would not solve the "need to change the depends"
[09:34] <pitti> right, it would just simplify the g-i-t packaging
[09:34] <pitti> well
[09:34] <pitti> seb128: in theeeeory we could add a Provides: gnome-icon-theme to humanity-i-t
[09:34] <pitti> well, no
[09:34] <seb128> provides are not versioned
[09:34] <pitti> a lot of depends on it are versioned
[09:35] <seb128> right
[09:35] <seb128> pitti, same function, different name? because they added some names to the fdo spec and cleaned the naming while they were at it
[09:35] <seb128> some names are deprecated probably
[09:36] <seb128> pitti, but otherwise I've no better plan than yours for now and I don't see a real issue with it so go for it if you can so we can get testing and spot issues
[09:36] <pitti> I ran with g-i-t purged and didn't see any difference, but I'm sure there are some where I didn't notice easily
[09:37] <seb128> pitti, it might also allow use to reinstall icons we stopped installing previous cycle that will make i.e the gnome-shell users happy since they need nice icons for their alt-tab and overview
[09:37] <pitti> right
[09:37] <pitti> the 256x256 ones
[09:37] <seb128> indeed
[09:37] <pitti> we can put them back then
[09:37] <pitti> +yast_joystick
[09:37] <pitti> ugh, we will so much miss this..
[09:38] <seb128> one way to avoid the depends tweaking would be to have gnome-icon-theme depending on gnome-icon-theme-real | humanity-icon-theme
[09:38] <pitti> well, we can also try to uninstall it completely
[09:38] <pitti> it seems that a lot of these aren't very useful anyway
[09:38] <seb128> or reverse
[09:38] <pitti> oh, nice trick
[09:38] <seb128> h-i-t | g-i-t-r
[09:38] <pitti> -full and -shared
[09:39] <pitti> then we seed h-i-t early
[09:39] <pitti> and have tweak-tool depend on -full
[09:39] <seb128> right, for example
[09:39] <pitti> much less intrusive indeed
[09:39] <pitti> we don't even need -shared then, I think
[09:40] <pitti> g-i-t with the shared set, and depends: h-i-t | g-i-t-full
[09:40] <pitti> that way we only add one more package
[09:41]  * pitti hugs seb128, nice idea
[09:41]  * seb128 hugs pitti ;-)
[09:42] <seb128> pitti, we could maybe bribe mvo or kees to grep for the names not in h-i-t through a checkout of the sources from the default installation
[09:42] <seb128> like your 200 names
[09:42] <seb128> just to see which ones are used and where
[09:43] <seb128> it might be down to a few and we would get those in h-i-t
[09:49] <didrocks> we really need some kind of cross reference with all sources available for grep
[09:50] <pitti> seb128: I think I might do that first indeed
[09:52] <seb128> pitti, well I was just suggested kees or mvo because I know they have mirrors they can use for those sort of things
[09:52] <pitti> seb128: people.c.c. (lillypilly) has one
[09:52] <seb128> kees grepped through main for gtkstatusicon users previous cycle for dx
[09:52] <seb128> oh ok, great
[09:53]  * pitti dusts off his old for-srcarchive scritp
[09:53] <seb128> pitti, I've the feeling we will get like 10 icons used and that we can copy them to h-i-t
[09:54] <pitti> yeah, me too
[09:54] <pitti> I have run without g-i-t for a week, and haven't seen a single broken icon
[09:55] <didrocks> that's a nice plan :)
[09:56] <fagan> chrisccoulson: not around yet?
[09:56] <seb128> didrocks, is the yellow color on the etherpad yours?
[09:57] <didrocks> seb128: there are two yellow colors IIRC, let me open it
[09:57] <seb128> didrocks, is that you who added a comment about indicator-applet-session?
[09:57] <didrocks> seb128: right
[09:57] <seb128> ok, I just wanted to confirm that it's indeed only the applet ;-)
[09:58] <didrocks> seb128: great! :-)
[09:58] <didrocks> so an easy target for removal once gnome-panel isn't there
[09:58] <didrocks> not sure why g-p didn't recommend it btw?
[09:58] <seb128> didrocks, we can already drop it btw
[09:58] <fagan> Looks like he isnt when does chrisccoulson start his day anyone im looking into the bindwood addon in 11.10 and im looking for some help with debugging
[09:58] <njpatel> pitti, Morning dude, I ended up quitting irc right after asking this a few days back, but how does one get a page like http://people.canonical.com/~platform/workitems/oneiric/u/jorge.html ?
[09:59] <seb128> didrocks, it recommends indicator-applet-complete which is the one we use since natty
[09:59] <didrocks> seb128: oh nice, so yeah, let's shot it:
[10:02] <didrocks> seb128: doing as well for indicator-message which a recommends of indicator-complete and recommends of unity
[10:02] <seb128> didrocks, thanks
[10:02] <seb128> while you are at it maybe drop g-s-t if that's not done yet
[10:02] <seb128> we have useraccounts in g-c-c
[10:03] <didrocks> seb128: pitti did g-s-t this morning
[10:03] <seb128> didrocks, btw if you review the at-spi2 mirs bonus point since that's at-spi which is basically the remaining libbonobo user on the CD
[10:04] <didrocks> seb128: we touched a little the seed, makes some cleanup (like removing window managers, and such)
[10:04] <didrocks> seb128: can do
[10:04] <seb128> thanks ;-)
[10:04] <didrocks> yw ;-)
[10:09] <seb128> ok, done with emails, let's get some work done ;-)
[10:12] <seb128> didrocks, btw if we have unity-2d on the CD did you guys drop gnome-panel?
[10:17] <pitti> seb128: we did a major round of seed cleanup this morning
[10:17] <pitti> see the recent ubuntu-meta upload
[10:17] <pitti> most of it won't actually fall off, as it's depended on by something else already
[10:17] <seb128> ok
[10:18] <pitti> njpatel: hm, they shoudl be produced for everyone, let me check
[10:18] <didrocks> seb128: we can't, because the version of gnome-panel recommending the fallback session is dep-waiting
[10:18] <seb128> well we can clean the rdepends next
[10:18] <seb128> didrocks, ok, that will be sorted today, I started on the GNOME3 version
[10:18] <seb128> which I will probably upload when it's ready
[10:18] <didrocks> seb128: so, for people upgrading to alpha1, they won't have the session on upgrade if we don't have gnome-session dep on gnome-session-fallback
[10:18] <didrocks> seb128: awesome! :)
[10:19] <seb128> didrocks, if you want to workaround it make gnome-session recommends gnome-session-fallback and don't make gnome-session-fallback install gnome-panel
[10:19] <didrocks> hum indicator-appmenu only recommends appmenu-gtk, not sure what we should do with appmenu-qt
[10:19] <seb128> users who have gnome-panel will still have it
[10:20] <seb128> didrocks, it should probably recommend both if we have the appmenu-qt depends on the CD
[10:20] <didrocks> seb128: right on the workaround, we can do that if you don't achieve to upoad it today
[10:20] <rodrigo_> brb
[10:20] <pitti> njpatel: hm, seems like a bug :(
[10:20] <didrocks> seb128: my estimate for gnome-panel + some deps are 1.6Mb
[10:21] <seb128> if we land gnome-panel it will be not be ubuntu-ish
[10:21] <seb128> the update will reset to an upstream layout and indicators are not ported yet
[10:21] <didrocks> seb128: for recommending both, that was my first shot (it's already on the cd by unity-2d, but I feel it's wrong), better to use indicator-appmenu for this
[10:21] <seb128> but that's fine, that will make GNOME users happy since they will get a GNOME experience
[10:21] <didrocks> seb128: the thing is that, will there be the case when we only want appmenu-gtk or appmenu-qt?
[10:21] <didrocks> seb128: agreed
[10:22] <seb128> didrocks, ? what I suggested is indicator-appmenu Recommends: appmenu-gtk, appmenu-qt
[10:22] <seb128> didrocks, those are small pieces of codes and recommends can be uninstalled if for some reason some users don't want them
[10:22] <didrocks> seb128: yeah, that what's I did in the vcs, but I'm wondering if there can be a spin of the cd where we want indicator-appmenu but without both toolkits
[10:23] <didrocks> appmenu-qt will bring qt?
[10:23] <seb128> didrocks, let's deal with real world complain when they come
[10:23] <didrocks> yeah
[10:23] <didrocks> seb128: ok :)
[10:23] <didrocks> doing that then
[10:23] <didrocks> and cleaning unity-2d dep
[10:23] <seb128> didrocks, the other option is to make libqt<something> recommend appmenu-qt
[10:24] <didrocks> seb128: I still find logical that the indicator recommends it, let's see later if we have special corner case with only one toolkit
[10:25] <seb128> didrocks, ok
[10:25] <didrocks> seb128: thanks for confirming :)
[10:25] <seb128> I'm wondering if we could make appmenu-qt not depends on qt and be a no-op if that one is not installed
[10:26] <didrocks> seb128: that would be the best way to handle it, right, same for appmenu-gtk
[10:27] <didrocks> seb128: let's see with aurelien on Monday, I'm dropping a note on the pad
[10:27] <seb128> ok
[10:42] <didrocks> hum, 3 MIRs on at-spi2-core?
[10:42] <didrocks> seems duplication of the same
[10:42] <seb128> didrocks, copy error in the title
[10:42] <seb128> one it -atk for sure
[10:42] <seb128> not sure about the third one
[10:42] <didrocks> ok, looking at affects then
[10:43] <didrocks> hum, 2 for -core and one for -atk
[10:43] <seb128> ok, one dup then
[10:43] <didrocks> duplicating
[10:44] <didrocks> ah, and pyatspi
[10:59] <pitti> njpatel: for the moment, you can use http://people.canonical.com/~platform/workitems/oneiric/all.html#njpatel
[11:04] <njpatel> pitti, awesome, thank you :)
[11:05] <ricotz> fta, hello :), could you run your magic ppa-stats-script for the gnome3-ppa again?
[11:11] <pitti> seb128: 27 kB grep result, that's not too bad; now let's go through it with a fine comb
[11:11] <seb128> pitti, can you pastebin it somewhere?
[11:13] <pitti> seb128: http://people.canonical.com/~pitti/tmp/g-i-t-grep.txt
[11:13] <pitti> but let me weed out the noise first
[11:26] <asac> pitti: moin moin ... apport is set to enabled=0 in etc/default ... however, for all crashes i get this bug reporting tool blocking my workflow
[11:26] <asac> pitti: how can i disable that ;)?
[11:26] <asac> i am only on stable releases atm, so i dont really want to report crashes anyway
[11:26] <pitti> seb128: ah, it was 270 kB instead; cleaned up, now it's 55
[11:26] <pitti> asac: which kind of crashes?
[11:27] <pitti> asac: with enabled=0 it shoudln't trigger indeed
[11:27] <pitti> package crashes will, though
[11:27] <asac> pitti: a few minutes ago gnome-terminal crashed and this bug reporting tool shoed up
[11:27] <asac> and did core dump analysis i guess because it was high load for a minute blocking everything
[11:28] <pitti> asac: cat /proc/sys/kernel/core_pattern
[11:28] <pitti> ?
[11:28] <asac> core
[11:28] <asac>  cat /proc/sys/kernel/core_pattern
[11:28] <asac> core
[11:28] <pitti> so it's not apport
[11:28] <asac> hmm
[11:28] <asac> what is it?
[11:28] <asac> ;)
[11:28] <pitti> do you have bug-buddy perhaps?
[11:28] <pitti> asac: do a screenshot?
[11:28] <asac> yeah... i thought actually that apport was now integrated with their tool
[11:28] <asac> pitti: its gone ... let me check
[11:28] <pitti> no, it's not
[11:28] <asac> if bug-buddy is installed
[11:29] <pitti> asac: do you have recent stuff in /var/crash/?
[11:29] <asac> pitti: no its empty :/
[11:29] <asac> pitti: i had bug-buddy installed ... no clue why
[11:29] <asac> purging it does not remove any other package. thanks a bunch!!
[11:29] <pitti> yw :)
[11:31] <seb128> pitti, that list is managable, some probably just miss a symlink in h-i-t
[11:31] <pitti> seb128: http://people.canonical.com/~pitti/tmp/g-i-t-list.txt
[11:31] <pitti> icon names grepped out, and sort -u'ed
[11:31] <pitti> 98 items
[11:31] <seb128> some are probably missing like the smiley ones or the style (italic, etc) ones
[11:32] <pitti> right, icons can have aliases, can't they?
[11:32] <pitti> vish: ^
[11:33] <pitti> vish: http://people.canonical.com/~pitti/tmp/g-i-t-list.txt are the icon names which we actually use which humanity doesn't provide; I'm sure that many of them are just slightly different names
[11:33] <pitti> so I wonder whether I should go ahead and split them out, or whether we want to link/copy them into humanity
[11:33] <pitti> but, lunch first, or I fall off my chair
[11:33] <seb128> pitti, the smiley ones are probably missing, we should maybe just keep those in g-i-t and move the other ones to the new binary
[11:34] <seb128> hum, lunch!
[11:34] <seb128> pitti, enjoy ;-)
[11:34] <pitti> thanks!
[11:34] <pitti> still some lasagne left from yesterday's dinner
[11:36] <seb128> hum lasagne
[11:36] <seb128> pitti, stop it, my stomach start complaining ;-)
[11:36] <seb128> in fact I should have lunch as well seems about time
[11:47] <mpt> seb128, hi, what was that gconf key that you got me to delete at the sprint, to stop the XKB error messages appearing?
[11:47] <mpt> Someone else in the office has the same problem :-)
[11:48] <seb128> mpt, the ones in
[11:48] <seb128> mpt, the ones in
[11:48] <seb128> mpt, the ones in /desktop/gnome/peripherals/keyboard/kbd
[11:48] <seb128> sorry, select and middle click doesn't work with gconf-editor ;-)
[11:48] <mpt> thanks seb128, I knew I should have written it down :-)
[11:49] <seb128> mpt, the error dialog should hint you iirc it ask for the value of those keys
[11:59] <rodrigo_> ok, evo-indicator wasn't as easy as we discussed yesterday, but not too hard, so proposing merge now
[12:29] <mvo> I finally have enough from this block-theme, how can I change the theme in gtk3?
[12:29] <mvo> (in oneiric)
[12:32] <xclaesse> mvo, with gnome-tweak-tool
[12:32] <didrocks> seb128: commented on the 3 MIR for atspi2, still need some work
[12:33] <mvo> nice, thanks xclaesse!
[12:33] <xclaesse> mvo, note that only adwaita theme works on gtk3
[12:34] <mvo> hrm, hrm, it crashes here on startup, can't find org.gnome.shell.clock appparently
[12:35] <zniavre> i got his crash too
[12:35] <zniavre> this*
[12:37] <xclaesse> it probably doesn't run on unity :(
[12:38] <ricotz> it depends on an installed gnome-shell package
[12:38] <mvo> and that is not in oneiric yet, right?
[12:38] <rodrigo_> mvo, it needs the Gsettings schemas from gnome-shell, yes
[12:39] <zniavre> :o) wich is not into repos ...
[12:39] <rodrigo_> mvo, you can install it from the gnome3 ppa
[12:39] <mvo> anything I can do with dconf-edit/gconf-edit/*-editor?
[12:39] <ricotz> mvo, not yet ;)
[12:39] <mvo> I really don't mind the theme that much, but multiple tabs in gnome-terminal are really hard for me to distinguish (what tab is active). its not really a great default theme
[12:40] <xclaesse> mvo, you can probably write manually "Adwaita" in org.gnome.desktop.interface
[12:40] <xclaesse> using dconf-editor
[12:41] <xclaesse> and/or desktop.gnome.interface
[12:41] <pitti> mvo: I merely installed gnome-themes-standard, and it just worked
[12:41] <rodrigo_> yes, dconf-editor or gsettings command line should be enough
[12:41] <pitti> no need to dconfify anything
[12:45] <rodrigo_> right, that works also, since it has the default theme
[12:49] <mvo> hrm, dosn't work for me, gnome-themes-standard is installed now, but I still seem to have the default, dconf-editor also has no effect
[12:49] <mvo> ohhhh
[12:49] <mvo> now :)
[12:49] <mvo> much nicer!
[12:50] <seb128> mvo, there is no nice theme for gtk3 yet
[12:50] <seb128> mvo, you can try https://code.launchpad.net/~lucazade/+junk/ambiance-gtk3/ other if you used ambiance before
[12:50] <mvo> well, niceness(default) < niceness(adwaita)
[12:51] <mvo> radiance I was using
[12:51] <seb128> same here
[12:51] <mvo> at least I can see my g-t tabs properly now :)
[12:51]  * mvo is happy
[12:52] <seb128> lucazade is working on the gtk3 theme, not sure if he did a light version yet
[12:52] <seb128> "the -> a" rather
[12:53]  * mvo nods
[12:53] <lucazade> seb128... not yet, when ambiance style will be finished it'll be simpler to make also radiance
[12:54] <seb128> ok
[12:55] <lucazade> they share same style but different color scheme
[12:56] <seb128> ok
[12:56] <RAOF> Oooh, how's ambiance-gtk3 coming along?
[12:56] <seb128> didrocks, ^ can you review rodrigo_'s evolution-indicator upstream merge request?
[12:56] <didrocks> seb128: aready started it
[12:57] <seb128> RAOF, it's not from dx but lucazade work on his own version cf url before
[12:57] <seb128> didrocks, thank
[12:57] <seb128> s
[12:57] <didrocks> yw :)
[12:57] <lucazade> RAOF http://dl.dropbox.com/u/1338581/varie/Schermata.png
[12:58] <seb128> pitti, who wrote the evo,tb pro and con arguments?
[12:58] <RAOF> lucazade: Oooh, that looks substantially nicer :)
[12:58] <lucazade> :)
[12:58] <pitti> seb128: I think jasoncwarner c&p'ed them from the original thread on u-desktop@; I assumed it was chrisccoulson ?
[12:58] <seb128> ok
[12:59] <chrisccoulson> yeah, that might have been me
[12:59] <seb128> I was wondering about the initial account setup and the tabs
[12:59] <seb128> evo in oneiric pre-file all the settings for you if you enter i.e a gmail email
[12:59] <seb128> like smtp, imap etc are all filed from the email info
[13:00] <chrisccoulson> i haven't tried it in oneiric yet
[13:01] <seb128> ok
[13:01] <seb128> pitti, btw you copied the text twice it seems
[13:01] <pitti> oh, oops?
[13:01]  * pitti fixes
[13:02] <pitti> meh, this ajax editor field is so utterly broken
[13:06] <didrocks> rodrigo_: see my answer on https://code.launchpad.net/~rodrigo-moya/evolution-indicator/port-to-3-0/+merge/62653
[13:07] <didrocks> chrisccoulson: it's there since maverick AFAIK
[13:08] <didrocks> that was part of the express part backported
[13:14] <chrisccoulson> didrocks, oh, so i've used the setup wizard before tehn
[13:14] <chrisccoulson> *then
[13:14] <chrisccoulson> i just tried it in a guest session
[13:14] <chrisccoulson> it presents way too much information, even if some of it is filled out by default ;)
[13:15] <fta> pitti, i have g++ crashing in a 32bit pbuilder, how do i get a crash file inside the chroot instead of in the host (64bit)?
[13:15] <chrisccoulson> with thunderbird, all it asks for is a name, email address and password. if the account settings can be figured out, and they work (it tests the settings), then it doesn't present or ask for any more info
[13:19] <pitti> fta: tricky with apport, as the kernel calls it, which isn't chroot aware
[13:19] <pitti> fta: you could set "ulimit -c unlimited" to get a core file?
[13:21] <seb128> didrocks, +       GTKHTML_EDITOR=gtkhtml-editor-4.0,
[13:21] <hyperair> chrisccoulson:
[13:21] <hyperair> pign
[13:21] <seb128> -                  gtkhtml-editor-3.14
[13:21] <seb128> +                  $GTKHTML_EDITOR
[13:21] <seb128> didrocks, in the diff?
[13:21] <fta> pitti, yep, but how do i figure out which symbols i need? http://paste.ubuntu.com/613723/
[13:21] <seb128> didrocks, not sure to understand your review comment
[13:22] <pitti> fta: apport-retrace should work quite well in a chroot, doesn't it?
[13:22] <didrocks> seb128: +GTKHTML_EDITOR=gtkhtml-editor-3.14,
[13:22] <didrocks> seb128: line 22
[13:23] <didrocks> seems to be the 2.0 version, but depends on the 3.0 include?
[13:23] <seb128> didrocks, that's the fallback case though, if that one is not installed it uses the previous one?
[13:23] <didrocks> seb128: well, it's in PKG_CHECK_EXISTS(evolution-plugin-3.0,
[13:23] <didrocks> and not along
[13:23] <pitti> fta: hm, gcc-4.6-dbgsym, g++-4.6-dbgsym, and libc6-dbg should get you quite far
[13:23] <fta> pitti, it's all broken. 1/ it doesn't request enough deps, 2/ the multiarch thing i told you about yesterday 3/ crash file from the host leads to crc mismatches in pbuilder
[13:23] <seb128> didrocks, right, that seems buggy but if the build-depends is not there it should just use what is installed which is the new version?
[13:24] <seb128> didrocks, i.e it should only be an issue if you have the old version leftover locally
[13:24] <seb128> well I will let rodrigo_ comment but the review is confusing in that regard
[13:24] <didrocks> seb128: I added a comment to be more clear about that
[13:24] <seb128> thanks
[13:25] <seb128> in fact
[13:25] <seb128> +               AC_MSG_ERROR(You need evolution-plugin to compile evolution-couchdb))
[13:25] <seb128> seems like a copy error from evo-couchdb
[13:25] <didrocks> seb128: I guess so
[13:26] <rodrigo_> seb128, yes, it is
[13:26]  * rodrigo_ fixes
[13:29] <rodrigo_> didrocks, I left the 3.14 thing just in the fallback case, so that it can be compiled with 2.0, if needed
[13:29] <rodrigo_> didrocks, I didn't want to just remove support for that, with no reason
[13:29] <rodrigo_> didrocks, so, if we build-depend on evolution 3.0, it will try to use gtkhtml-editor-4.0
[13:29] <didrocks> rodrigo_: as long as it's a real fallback we can build, that's fine :)
[13:30] <seb128> rodrigo_, well it seems it does error if it's not available
[13:30] <seb128> it's not an if else
[13:30] <rodrigo_> it does error if no evolution-plugin is available
[13:30] <didrocks> hum, not that I though, even with the refresh
[13:30] <seb128> well so it errors if only the new version is available
[13:31] <didrocks> rodrigo_: if we have only the old version
[13:31] <seb128> like it try the new version and then the old and error
[13:31] <didrocks> PKG_CHECK_EXISTS(evolution-plugin-3.0, will fail, right?
[13:31] <didrocks> so, we will never execute PKG_CHECK_EXISTS(evolution-plugin, ?
[13:31] <rodrigo_> no, if it's not available, it will run the 3rd part of the PKG_CHECK_EXISTS
[13:31] <rodrigo_> which will check for evolution-plugin, and then error if that's not available
[13:32] <didrocks> oh right
[13:32] <rodrigo_> PKG_CHECK_EXISTS(check, what_to_do_if_ok, what_to_do_on_error)
[13:32] <didrocks> yeah, approved then
[13:32] <rodrigo_> ok
[13:32] <seb128> oh, it's still a call from the same function
[13:32] <seb128> the autotools are confusing :p
[13:32] <rodrigo_> is it merged automatically?
[13:32] <rodrigo_> seb128, :)
[13:32] <didrocks> rodrigo_: no, will sponsor you
[13:32] <rodrigo_> ok
[13:33] <rodrigo_> didrocks, also, do we want that patch in the package, or should we wait for a new release?
[13:33] <didrocks> rodrigo_: I can do a new release
[13:33] <rodrigo_> didrocks, ok
[13:36] <fta> pitti, hm, gdb is pretty raw in the chroot, iy doesn't load any dbg/dbgsym
[13:37] <pitti> strange; but the versions match?
[13:39] <didrocks> I'm not on oneiric (still waiting for the compiz SRU before migrating), can someone on oneiric finish the release? (not real found of doing a release in a chroot)
[13:40] <seb128> didrocks, you mean? rolling the tarball?
[13:40] <didrocks> seb128: yeah
[13:40] <seb128> do you need to be on oneiric for that?
[13:40] <didrocks> seb128: you need to configure ; make ; make dist
[13:40] <didrocks> so yeah, for configure and make to pass, you need evolution 3.0
[13:41] <seb128> well, I can roll a tarball for you but I've no clue how to upload tarballs to a launchpad project etc
[13:41] <didrocks> seb128: time to learn? :p
[13:41] <seb128> rodrigo_, ^ you probably know how to do that?
[13:41] <seb128> not to mention you have a local checkout of the code you built ;-)
[13:41] <didrocks> rodrigo_: I bzr pushed the merge + release tag
[13:43] <seb128> didrocks, if rodrigo_ doesn't reply in a bit I will roll the tarball
[13:44] <didrocks> seb128: just FYI, I will certainly leave at 16h10 (having my train at 17h for going to the Ubuntu Party in Paris)
[13:45] <seb128> didrocks, ok, no worry we can roll a tarball and package it even if we don't upload it to the launchpad project today ;-)
[13:45] <didrocks> I'm preparing the milestone meanwhile
[13:45] <didrocks> seb128: what? and being a bad upstream? no way! :-p
[13:45]  * cyphermox bbl -> travelling to the office.
[13:47] <didrocks> seb128: ok, I have created the milestone and released it, you will just need to go to https://launchpad.net/evolution-indicator/+milestone/0.2.16 and click on "Add download file" (think to add a .asc file as well)
[13:47] <didrocks> well, only if rodrigo_ isn't back :)
[13:57] <fta> is it expected that nautilus 3 is no longer doing thumbnails for pdfs?
[13:57] <fta> it still does for video files though..
[14:03] <rodrigo_> didrocks, I can do the tarball, yes
[14:03] <didrocks> rodrigo_: excellent, thanks :) trunk should have all what you need
[14:04] <rodrigo_> ok
[14:07] <seb128> rodrigo_, thanks
[14:08] <seb128> fta, nautilus is not doing thumbnails, other softwares are responsive to do those for the formats they handle
[14:08] <seb128> i.e evince does it for pdf for example
[14:14] <rodrigo_> didrocks, ok, tarball done, so just upload to https://launchpad.net/evolution-indicator/+milestone/0.2.16 right?
[14:14] <didrocks> rodrigo_: right, do you have access?
[14:14] <rodrigo_> let me try
[14:14] <rodrigo_> seems so
[14:14] <didrocks> nice :)
[14:14] <didrocks> do you want to handle the package update then?
[14:15] <rodrigo_> yes
[14:15] <didrocks> (I think it's using merge-upstream)
[14:16] <rodrigo_> in ~ubuntu-desktop, right?
[14:17] <didrocks> rodrigo_: yeah: ~ubuntu-desktop/evolution-indicator/ubuntu
[14:18] <didrocks> rodrigo_: so yeah, it's using merge-upstream with the upstream tarball + branch
[14:18] <rodrigo_> yes, taking a long time to get it :)
[14:26] <seb128> does anybody know off hand what broke tomboy in oneiric before I debug it?
[14:26] <fta> seb128, so, how do i check why evince stopped doing the thumbnails?
[14:27] <seb128> fta, you can start by running evince-thumbnailer by hand and see if it works
[14:27] <fta> seb128, it does
[14:28] <fta> seb128, .. while in nautilus, i get what looks like an acrobat logo
[14:28] <seb128> ok so somewhat the thumbnailer is not called by nautilus
[14:28] <fta> (i have acroread installed)
[14:28] <seb128> it used to be a gconf key not sure how it work in GNOME3
[14:29] <seb128> check with ricotz if he knows maybe
[14:30] <fta> ricotz, ^^ ?
[14:34] <seb128> fta, seems a packaging but, I will fix it
[14:40] <ricotz> seb128, fta, sorry, i dont know
[14:41] <ricotz> seb128, i will look a the bug fix later ;)
[14:41] <fta> $ gsettings list-recursively org.gnome.desktop.thumbnailers
[14:41] <fta> org.gnome.desktop.thumbnailers disable @as []
[14:41] <fta> org.gnome.desktop.thumbnailers disable-all false
[14:41] <seb128> ricotz, it's likely a dir not installed in the .install
[14:41] <seb128> i.e it should install a file in /usr/share/thumbnailers
[14:42] <seb128> the multi build sources suck in that regard, dh_install --list-missing doesn't work
[14:42] <fta> ricotz, btw, gnome3 stats updated
[14:45] <ricotz> fta, thank you
[14:46] <vish> pitti: ah, thanks for the list, a few would just need symlinks but we need the smilies and emblems.. we could copy it over too, whichever is preferable for you guys..
[14:47] <vish> pitti: also to note is that new theme g-i-t-symbolic is required in GNOME3..
[14:47] <pitti> vish: at least the symlinks would be more correct to have in humanity itself, so that programs using these alternate names would actually get the humanity icons, not the gnome-* ones, right?
[14:47] <vish> a lot of apps depend on it for the monochrome toolbars and stuff..
[14:48] <pitti> yes, we'll keep -symbolic
[14:48] <vish> pitti: yea, a few are just missing symlinks in Humanity, I'll fix that
[14:48] <pitti> vish: thanks a lot
[14:49] <vish> np..
[14:49] <pitti> vish: for the rest, I'm happy with splitting the g-i-t package to avoid duplication
[14:49] <pitti> or would you prefer having a complete set in humanity, for this to be self-contained?
[14:50] <vish> pitti: we can add it to humanity and replace the icons later, when we have a better alternative.. but a split g-i-t is good too.. either way I'm fine with it :)
[14:51] <pitti> vish: how many of these (roughly) will be handled through aliases (symlinks)? just a few, or like half of the missing ones?
[14:52] <pitti> copying 10 icons into humanity seems fine, it's much easier packaging-wise and avoids a lot of confusion
[14:52] <vish> just a few, let me count and get a closer number
[14:52] <pitti> but copying 100 icons, maybe not
[15:01] <fta> http://people.ubuntu.com/~fta/weird-gtk3-resize-corner.ogv
[15:01] <vish> pitti: hmm, only around 10 can be fixed by symlinks, so we'd have to copy a lot...  I guess splitting is better
[15:02] <pitti> vish: ok, thanks for checking!
[15:02] <vish> np.
[15:05] <seb128> ok, I figured the tomboy thing
[15:05] <seb128> Laney, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622207, how did you try without dh-autoreconf for this one?
[15:06] <ubot2> Debian bug 622207 in tomboy "Fails to start, missing library" [Grave,Fixed]
[15:06] <seb128> seems similar to bug #787587
[15:06] <ubot2> Launchpad bug 787587 in xserver-xorg-video-intel "Cannot change screen resolution on Dell Duo in Natty" [Undecided,New] https://launchpad.net/bugs/787587
[15:06] <seb128> ups, wrong number
[15:06] <Laney> seb128: I just patched out the tests differently
[15:06] <seb128> bug #786101
[15:06] <ubot2> Launchpad bug 786101 in libao "libao (main) tries to pull in b-d roaraudio (universe)" [High,Fix released] https://launchpad.net/bugs/786101
[15:06] <Laney> see the referenced commit
[15:07] <seb128> oh, come on #788588
[15:07] <Laney> haha
[15:07] <seb128> Laney, seems like the issue is the ltmain.sh copy you have (had) in the rules
[15:07] <Laney> I didn't really investigate where the autoreconfing problem was I'm afraid
[15:07] <Laney> yeah
[15:07] <Laney> might have needed updating
[15:07] <seb128> you copy a version built from an older version
[15:08] <seb128> commenting that line fixes the issue
[15:08] <Laney> wasn't needed any more anyway
[15:08] <seb128> is as-needed still required nowadays?
[15:08] <Laney> i diffed the binaries and there were no new deps
[15:08] <seb128> well it is in ubuntu ;-)
[15:08] <Laney> so it is now gone
[15:08] <seb128> well dh-autoreconf is
[15:08] <seb128> ok, so let's drop the buggy line
[15:08] <Laney> i forgot what the ubuntu tomboy patches are
[15:09] <Laney> but you can probably just remove the ltmain stuff indeed
[15:09] <seb128> right
[15:09] <Laney> just debdiff the binaries to check the dependencies are ok
[15:09] <seb128> will do, thanks
[15:09] <seb128> brb session restart
[15:11] <didrocks> need to catch the train, have a nice week-end everyone and see you on Monday!
[15:11] <pitti> see you didrocks
[15:12] <pitti> enjoy the weekend
[15:12] <seb128> didrocks, have fun at the ubuntuparty
[15:12] <didrocks> thanks, you too pitti, seb128 :-)
[15:21] <pitti> seb128: hm, wrt. gtkmm2.4 on versions.html, I figure that should actually become a new gtkmm3.0 source, right?
[15:22] <pitti> hmm
[15:22] <seb128> pitti, right, it's in pkg-gnome svn ready for sponsoring it seems
[15:22] <seb128> someone should review
[15:22] <seb128> it's on my list but I will not likely come to it today
[15:23] <pitti> libgnomemm2.6 is only in main because of libgnomeuimm2.6, which is only in main because cdrdao b-deps on it
[15:24] <pitti> libgnomecanvasmm2.6 is also only due to libgnomeui
[15:24] <pitti> same for libglademm2.4
[15:25] <seb128> pitti, we could build cdrdao without xdao, I can do that if you want
[15:25] <seb128> (just looking at it, I've a checkout there)
[15:25] <pitti> I was already wondering
[15:25] <pitti> oh, it builds a gcdmaster binary
[15:25] <pitti> I figure that's it
[15:25] <seb128> AC_ARG_WITH(xdao,[  --with-xdao             enable build of gcdmaster Gnome GUI front-end (default is YES)],[xdao=$withval],[xdao=default])
[15:25] <seb128> let's turn that off, I bet nobody use it
[15:25] <pitti> it uses bonobo, glade, libgnome-vfs, etc.
[15:26] <pitti> and all the old stuff
[15:26] <pitti> pangomm, too
[15:26] <pitti> does that thing even work still?
[15:26] <pitti> seb128: I'm all for that
[15:26] <chrisccoulson> you're removing something? that's it, i'm switching to arch!
[15:26] <chrisccoulson> :)
[15:26] <seb128> chrisccoulson, good for you!
[15:26] <chrisccoulson> lol
[15:26] <seb128> chrisccoulson, or you would maybe port the code to use xulrunner? ;-)
[15:26] <pitti> seb128: seems by disabling that we can get rid of a whole lot of cruft
[15:27] <chrisccoulson> seb128 - well, i'm in the process of killing that off ;)
[15:27] <pitti> seb128: I guess we just need to drop the b-dep and the package in debian/control; want me to look at it, or do you want to have the honor?
[15:27] <seb128> pitti, well I bet that things using those old libs is not maintained well enough to be of any use, let me drop it
[15:27] <pitti> what else is left for gtkmm
[15:27] <seb128> pitti, I'm on it
[15:27] <pitti> seb128: 'zactly; thanks!
[15:27] <seb128> pitti, gnome-system-monitor is left
[15:27] <pitti> -- oneiric/main amd64 deps on libgtkmm-2.4-1c2a:
[15:28] <pitti> gnome-system-monitor
[15:28] <pitti> gparted
[15:28] <seb128> but current version use gtkmm3
[15:28] <pitti> inkscape
[15:28] <pitti> these mainly
[15:28] <seb128> the bindings are in the pkg-gnome svn
[15:28] <seb128> the real "blocker" for gtkmm is gparted
[15:28] <seb128> that was the case when we looked at it previous cycle
[15:28] <pitti> there's some more build deps on it, but a lot of them are also cruft
[15:28] <pitti> dbus-c++ and aptitude are the real additional ones
[15:28] <seb128> gnome-system-monitor would be easy to port in vala or such
[15:28] <seb128> but gparted is not
[15:35] <pitti> ah, k3b still uses cdrdao
[15:35] <pitti> I wondered, I thought brasero & co used cdrkit
[15:46] <pitti> argh, we need to merge gnome-python, as Debian removed the python:Provides from pygtk2
[15:46] <pitti> I'll get to it
[15:46] <seb128> pitti, if you do you can drop most of the diff
[15:46] <seb128> pitti, we don't need the -dbg so we can drop the rules dual build thing
[15:47] <pitti> yeah, I wouldn't bother carrying these for this old stuff
[15:47] <seb128> the dbg has never been used by anybody and the binding are deprecated anyway and it has no rdepends
[15:47] <seb128> those -dbg have costed lot of work for nothing if you ask me but shrug...
[15:48] <pitti> and apparently we split out python-gnomecanvas
[15:48] <seb128> right, it's probably not worth the transition work to merge it back
[15:49] <pitti> it has one rdepends (system-config-date)
[15:49] <seb128> that diff is pretty small and can stay there until things go to use g-i
[15:50] <seb128> hum, I guess it could be merged back and go back in sync if we add the replaces in debian then
[15:50] <pitti> *nod*
[15:50] <pitti> ok, meeting time
[15:50] <pitti> I'll put that on my list for Monday
[15:52] <pitti> seb128: I'm not sure about 01-dont-build-with-lpython.patch, otherwise the diff doesn't really look interesting any more
[15:53] <pitti> so adding the replaces in Debian, syncing, and fixing system-config-date seems easiest to me
[15:53] <pitti> then we can stop worrying about it for the longer tail of rdepends
[15:53] <seb128> pitti, it was to avoid getting a depends on a specific libpython version iirc
[15:54] <seb128> pitti, right
[15:54] <seb128> pitti, which was an issue when we were building for i.e 2.5 and 2.6
[15:55] <pitti> seb128: ah, if it does, I'll fix that in Debian, too
[16:50] <pitti> good night everyone, enjoy the weekend!
[16:51] <cyphermox> ciao pitti
[17:45] <seb128> vuntz, seems http://git.gnome.org/browse/gnome-panel/patch/?id=76dc5a00044de3076fe7117ff9944e4c5660e5ba got dropped from the gnome-3 serie, the issue is back
[17:45] <seb128> vuntz, could you apply it again?
[17:49] <ricotz> seb128, are mutter and gnome-shell considered to move to main in this cycle?
[17:49] <seb128> not sure, we didn't really discuss but the default reply is probably "not if we don't have a good reason"
[17:50] <seb128> it's easier to get contribution
[17:50] <seb128> it's easier to get contribution to it if it's in universe
[17:52] <ricotz> alright, so i wont care about dependencies to universe
[17:53] <seb128> it's still better to not add extra depends if not required
[17:55] <ricotz> ok, but for now it isnt needed to move debian-dependencies to Recommends if they are in universe
[17:56] <ricotz> in case of gnome-shell it would be mesa-utils
[17:56] <seb128> no, and you can't recommends things in universe either it would have to be a suggests
[17:56] <seb128> but yeah don't bother about that
[17:56] <seb128> those can be discussed the day it's promoted if that happens
[17:56] <ricotz> ok
[18:00] <vuntz> seb128: done (had to-redo it as cherry-pick failed)
[18:00] <seb128> vuntz, thanks
[18:01] <seb128> vuntz, well the 3 was changed to 4 but instead the diff applied as it
[19:02] <fta> seb128, thanks for the evince fix. wfm now \o/
[19:02] <seb128> yw
[19:06] <chrisccoulson> *sigh* @ bug 789198
[19:06] <ubot2> Launchpad bug 789198 in firefox "Firefox crashes when attempting to play webm video embedded in the home page on Linaro 11.05 LEB with Ubuntu on OMAP4 Panda Board A2, with "panda" hwpack." [Undecided,Incomplete] https://launchpad.net/bugs/789198
[19:07] <chrisccoulson> i wonder why people do that, especially when they know that hardly anybody else has the hardware ;)
[19:52] <nivardus> I must have ran into an odd package, gtk3 was uninstalled and while gnome-shell functions all my windows are in an old funky theme and GDM is reverted and has a plain blue background
[22:18] <bratsche> Is there an irc channel specifically for the GNOME3 PPA stuff?
[22:20] <micahg> bratsche: I don't think so, most of that stuff should be in oneiric already
[22:41] <bratsche> micahg: I'm not using oneiric, I'm using Natty.  Do I have to upgrade to not have conflicts?
[22:42] <micahg> bratsche: idk, I think there's still an effort to backport stuff to natty, but I think most of the people involved are EOW
[22:42] <bratsche> EOW?
[22:43] <micahg> bratsche: end of wekk
[22:43] <micahg> week
[22:43] <bratsche> Oh, right.
[22:44] <chrisccoulson> yeah, i'm not sure how much effort people are spending to get stuff working on natty
[22:44] <chrisccoulson> i'm hardly involved with the desktop team at all ;)
[22:51] <bratsche> Yeah, I guess that's always the problem.  Everyone is working on the new version now. :)


[12:14] <Tm_T> dealt
[14:11] <k1l> @mark User564 crazy insulting nonsense
[14:11] <k1l> @mark #ubuntu User564 crazy insulting nonsense
[14:12] <DJones> They change nicks & ip's & post that or something similar maybe once a day
[14:12] <Pici> isn't there a way to get that added to unopaste?
[14:12] <DJones> Bans 62122 and 62060 seem relevant & similar
[15:38] <bazhang> lucido suddenly claims it's ubuntu, after saying debian, but is crossposting in #debian
[15:44] <genii> Sounds confused
 bazhang: i'm not looking for zorin support Moaky.
[15:53] <bazhang> moaky?
[15:54] <Pici> not sure why he would bring it up if he wasn't asking for support.
[15:54] <bazhang> his entire entry post is zorin os zorin os etc etc
[18:16] <DJones> Anybody any idea what carswell is trying to do in #ubuntu
[18:17] <bazhang> activate the ubuntu spaceship
[18:26] <genii> connectar 123456!
[18:28] <bazhang> ubottu, random spaceship zune
[19:25] <genii> Man. I really need more coffee.
[20:35] <irreverant> Is this an Official Ubuntu Channel?
[20:35] <k1l_> this is the ops channnel.
[20:35] <irreverant> Well I mean the ##Ubuntu channel?
[20:36] <irreverant> What I mean to say is #Ubuntu officially associated with Ubuntu Support or it's affliates?
[20:36] <k1l_> ths ubuntu support channel is #ubuntu
[20:37] <k1l_> yes, #ubuntu is the official ubuntu support channel
[20:40] <irreverant> Great thank you.
[20:41] <irreverant> Will that channel be able to answer questions regarding licensing and monies?
[20:41] <irreverant> I mean making money from supporting Ubuntu as a MSP or other (Consultant/Contractor/Reseller)
[20:41] <k1l_> that sounds more like you want to talk with canonical
[20:42] <irreverant> Let's say selling Ubuntu as a solution for people that can't afford to buy a new computer due to XP support outdated?
[20:42] <irreverant> Ok that's what I was figuring. Should I just contact them through their traditional communication channel or is there a preferred method you can recommend.
[20:44] <k1l_> dont know if this falls into this but at least they can verify that: http://www.ubuntu.com/legal and http://www.canonical.com/intellectual-property-rights-policy (they have a contact us from)
[20:45] <k1l_> *form
[20:45] <irreverant> No that's perfect... great first step I can take. Thank you for that, I really appreciate your help.
[20:45] <k1l_> no problem
[21:40] <genii> Probably should have pointed them at http://www.canonical.com/intellectual-property-rights-policy
[21:40] <genii> Oh, nvm


[23:31] <flexiondotorg> If there's anyone here who has time to upload a new package to the artful archive I'd appreciate it :-)
[23:31] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+bug/1699334
[23:31] <flexiondotorg> Packaging work is done.