[00:00] <asac_> i think we can justify to not let koffice stuff in the gnome template folder
[00:00] <seb128> but I can see that quickly turning into a mess
[00:00] <seb128> and to be honest I've a clean menu there I'm using
[00:00] <asac_> right. but we can focus on most common use-cases to unbreak the situation
[00:00] <asac_> and push back the other cases until there is a real solutino
[00:00] <seb128> and I would be able to be able to keep it this way without having to use dpkg-divert
[00:01] <seb128> ie I don't use openoffice and I don't want my menu cluttered with 6 office templates
[00:01] <seb128> I guess I would be happy if we have an easy way to opt out of things
[00:02] <asac_> i wouldnt allow all openoffice apps to install templats i guess ... just odt document, and maybe a spreadsheet and a presentation
[00:02] <seb128> so maybe not install templates with packages but have a default ubuntu-templates
[00:02] <asac_> yeah ... but opting out without editor is hard
[00:02] <seb128> I would remove ubuntu-templates and be fine with it
[00:02] <asac_> seb128: we could require packages to ship templates in a -templates package which is a recommends
[00:02] <asac_> abiword-nautilus-templates
[00:02] <seb128> I don't really like adding extra binaries though
[00:03] <asac_> or we must make the template mechanism sensible on whether the binary referred to exist
[00:03] <seb128> the apt index takes long enough to download and that clutter the package management tools
[00:03] <asac_> well.
[00:03] <asac> i think the apt index can be ignored. that will be like 10 packages in karmic at max and then maybe 10 more later
[00:03] <asac> anyway ;)
[00:04] <asac> needs some thinking and brain-baking
[00:04] <seb128> I would be in favor of an ubuntu-templates for now
[00:04] <seb128> which would be part of the default install with a fixed set of templates
[00:04] <seb128> and easy to uninstall for users
[00:04] <asac> seb128: i like ubuntu-templates, but we need to hide templates that dont have a binary
[00:04] <seb128> it's not too intrusive and replies to the first need
[00:04] <seb128> well that should be easy enough to do from nautilus
[00:05] <seb128> or do we need to do that? nautilus will suggest to install the required software when trying to open one
[00:05] <asac> seb128: how does that work? do templates have a dedicated mime-type?
[00:06] <asac> e.g. application/odt-template-openoffice ?
[00:06] <seb128> no, they are normal files
[00:06] <seb128> copy a file in ~/Templates
[00:06] <seb128> it will be added to the menu
[00:06] <asac> yes. but how does it detect which package to install?
[00:06] <seb128> and using the menu item will copy the file where you are
[00:07] <seb128> nautilus knows the mimetype
[00:07] <asac> right. thats what i mean
[00:07] <seb128> and gnome-app-install has a mapping of mimetypes and softwares
[00:07] <asac> there are special mimetypes for templates of a certain app
[00:07] <asac> but i think that wouldnt help
[00:07] <asac> because the automatic install feature doesnt reduce the amount of menu items
[00:08] <seb128> right
[00:08] <asac> but the amount of packges being installed
[00:08] <asac> you want the other way around
[00:08] <asac> potentially more packages with templates installed than listed
[00:08] <seb128> well, I want an ubuntu-templates which I can uninstall if I want to manage my templates myself ;-)
[00:24] <seb128> 'night everybody
[00:31] <Ampelbein> robert_ancell: i suppose you did not see bug 399046 before starting to update cheese, no?
[00:32] <robert_ancell> Ampelbein, sorry didn't see that.  Have you done the work?
[00:32] <Ampelbein> robert_ancell: but you can do it if you want since someone duped the report anyways.
[00:33] <Ampelbein> i'm at building it
[00:33] <robert_ancell> Ampelbein, there are changes that StevenK didn't commit so I'm adding those now too
[00:33] <Ampelbein> robert_ancell: ok, then you do the update.
[00:34] <Ampelbein> robert_ancell: add x11proto-core-dev to build-dep and pass --enable-mmkeys to configure to build with multimediakeys-support enabled.
[00:43] <Ampelbein> robert_ancell: oh, and build-dep on docbook-utils, too. otherwise the documentation-build will fail with "unable to parse en_GB/cheese.xml"
[00:45] <robert_ancell> Ampelbein, thanks, I've pushed to bzr+ssh://bazaar.launchpad.net/~ubuntu-desktop/cheese/ubuntu/, please check if it looks ok
[00:49] <Ampelbein> robert_ancell: i think rarian-compat is not needed as a build-dep, we build with disable-scrollkeeper anyway.
[00:50] <robert_ancell> Ampelbein, right.  Why do we disable scrollkeeper?
[00:50] <Ampelbein> robert_ancell: and in regard of bug 345772 i chose to not build the non-hildon packages with hildon on lpia.
[00:53] <robert_ancell> Ampelbein, ok I'm reading that line a couple of times to get it.  So many double negatives :)
[00:54] <Ampelbein> robert_ancell: scrollkeeper is of no use on the buildd's as far as i can tell. it's database get's purged after every build.
[00:54] <Ampelbein> robert_ancell: sorry, i'm no native speaker ;-)
[00:56] <robert_ancell> I mean bug 345772 - you say that snippet should be there?
[00:57] <Ampelbein> robert_ancell: no, i meant that should be gone. so that ONLY the -hildon packages get hildon support.
[00:57] <Ampelbein> robert_ancell: with that snippet the "normal" packages on lpia are built with hildon.
[00:57] <Ampelbein> robert_ancell: and i think that's wrong (as stated by the bug reporter)
[00:58] <robert_ancell> Ampelbein, I see.  I'll make that change too
[00:59] <blaine00> Hello everyone!
[00:59] <TheMuso> robert_ancell: Hey there. How was your trip?
[01:00] <robert_ancell> TheMuso, hey yourself.  The trip was really good.  Got to meet up with a bunch of GNOME people
[01:08] <TheMuso> Cool.
[01:10] <DPic> Can somebody help move Empathy dependencies to main and change the desktop seed? https://bugs.launchpad.net/ubuntu/+source/telepathy-farsight/+bug/388898
[01:32] <robert_ancell> TheMuso, Luke, are you going to do gnome-media today?  I have a patch in bug 299642 that I want to put in
[01:36] <TheMuso> robert_ancell: I've just uploaded it. When I see announcements go out of a morning I start working on them right away.
[01:36] <robert_ancell> TheMuso, ok
[01:36] <TheMuso> If its in bzr when I get to uploading the package, i will go in then.
[01:36] <TheMuso> s/i/it/
[01:37] <robert_ancell> I'm negotiating with upstream about it at the moment
[01:37] <TheMuso> aho ok
[01:38] <TheMuso> Well put it in bzr when ready, and feel free to prod me if you want it uploaded sooner than the next point release.
[01:40] <TheMuso> Actually, more to the point, I start working on package updates as soon as I see the listed as uploads on the gnome-ftp list.
[07:09] <pitti> Good morning
[07:10] <JonDoe297> pitti: good morning :)
[07:15] <TheMuso> Morning pitti.
[07:48] <pitti> robert_ancell: is nautilus ready for sponsoring? I just uploaded a 2.27.2 followup with a dependency fix
[07:49] <robert_ancell> morning pitti, yes, please sponsor
[07:49] <pitti> robert_ancell: good morning!
[07:50] <pitti> I wonder why it isn't on http://people.ubuntu.com/~dholbach/sponsoring/index.html
[07:50] <robert_ancell> pitti, did you see the blueprint I opened for a new gdmsetup (https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gdmconfig)
[07:50] <pitti> robert_ancell: I didn't, I just heared that yuo want to work on it (*applauds*)
[07:51] <robert_ancell> guess the page hasn't updated yet?  It shows up in http://people.ubuntu.com/~seb128/versions.html
[07:51] <pitti> robert_ancell: the bug would have been enough, but I don't mind having a blueprint; accepted for karmic
[07:52] <robert_ancell> rick wanted it blueprinted
[07:56] <robert_ancell> pitti, I'm doing the gvfs package - how did you do the 90_relibtoolize.patch? Mine is being difficult...
[07:56] <pitti> robert_ancell: with quilt?
[07:56] <robert_ancell> did you run autoreconf or gnome-autogen.sh?
[07:57] <pitti> robert_ancell: btw, the patches might not apply any more; I recently updated the gphoto port upstream, but hasn't been applied yet
[07:57] <pitti> so if you wish, I can do the update
[07:57] <pitti> then I'd replace the patches with the current versions, etc.
[07:57] <pitti> robert_ancell: I always use autoreconf -fvi
[07:57] <pitti> that worked last time
[07:57] <robert_ancell> pitti, I'm half-way through it.  Seems ok apart from autoreconf.  3 of the patches went upstream
[07:58] <pitti> I'm bugging davidz to commit the other ones as well
[07:59] <pitti> robert_ancell: AFAIR, I pushed up to the previous patch, cp -r gvfs-... gvfs-....new, cd gvfs-....new, autoreconf -fvi, cd .., diff -Nur gvfs-... gvfs-....new > /tmp/p, cd to the original one, mv /tmp/p debian/patches/90_relibtoolize.patch
[07:59] <pitti> go quilt
[08:00] <robert_ancell> heh
[08:00] <robert_ancell> The -fvi works well, it doesn't add all the extra files you get without it
[08:50] <pitti> mvo: btw, do you have any Python programs that talk to policykit? I ported jockey yesterday, so that might help you
[08:51] <pitti> it's delightful, actually; rip out all the stuff from the client side, and just adapt the server side check a bit
[08:55] <mvo> pitti: yeah, system-service-d is one - I have a look at your commit :)
[08:55] <mvo> pitti: did you had a chance to check my apport branch yet?
[08:56] <pitti> mvo: ah, I wanted to ask you about that
[08:57] <pitti> mvo: the diff looks weird, it adds all the debian stuff
[08:57] <pitti> but I guess launchpad just got confused and diffed your branch against trunk instead of the ubuntu branch
[08:57] <pitti> or you branched off the ubuntu branch instead of trunk
[08:57] <mvo> pitti: most likely, I did the work against the ubuntu branch I think
[08:57] <pitti> either way, I'll sort it out
[08:58] <pitti> some stuff needs to go to trunk, some is ubuntu specific
[08:58]  * mvo nods
[08:58] <pitti> mvo: you locally tested the retracing stuff, I guess
[08:58] <mvo> yes
[08:58] <pitti> mvo: great work, btw!
[08:58] <mvo> well, to the extend I know about it :)
[08:58] <mvo> apport-retrace
[08:58] <pitti> I wouldn't have known how to handle kernel crashdumps
[08:58] <mvo> not the magic database
[08:58] <mvo> me neither (until I looked into it)
[08:59] <mvo> but its a pretty elegant thing and crash (the kernel debugger thing) is pretty amazing
[08:59] <pitti> mvo: http://bazaar.launchpad.net/%7Ejockey-hackers/jockey/trunk/revision/562 FYI
[09:00] <pitti> mvo: did you update apport/report.py, crash_signature() for kernel crashes? so that auto-duplication works?
[09:00] <mvo> pitti: thanks for the diff, that looks pretty tame, I have ubuntu-system-service and aptdaemon on the porting list
[09:01] <mvo> pitti: no, but I can do that today (updating crash_signature)
[09:01] <pitti> mvo: indeed, most of it is easy; only difficulty was to find out the incantation of CheckAuthorization()
[09:01] <mvo> it will currently just not to signature checks because there is no executablepath
[09:02] <pitti> mvo: would be great if you could add a "typical" output to test_crash_signature() to the test suite
[09:02] <mvo> I guess that is ok-ish at this point because linux-crashdump is not instaled by default so we probably get few reports
[09:02] <pitti> ah, I see
[09:02] <pitti> so it should not do that exepath check for ProblemType: Kernel
[09:02] <mvo> pitti: yeah, I read over the new code yesterday briefly and found dict a bit odd :)
[09:03] <mvo> pitti: yeah
[09:03] <pitti> mvo: it's much nicer with libpolkit, but with raw D-BUS API it looks like that now
[09:03] <pitti> mvo: mainly because you can identify processes by other stuff than pid nowadays
[09:04] <mvo> pitti: I will add a test and the check_signature today, if the add_os_info() bit in the client could be merged then we can declare the lcient as ready, its the only piece that is missing there
[09:04]  * mvo nods
[09:04] <pitti> mvo: can do
[09:05] <mvo> pitti: thanks, I knew the branch had some warts, but I wanted to pass it along so that you can check and see if it fits into the general direction :)
[10:08] <didrocks> morning o/
[10:09] <chrisccoulson> good morning didrocks
[10:10] <didrocks> hey chrisccoulson
[10:21] <seb128> good morning everybody
[10:22] <pitti> Monsieur!
[10:23] <seb128> hey pitti!
[10:23] <seb128> how is everybody going today?
[10:23] <seb128> pitti, dunno if you read that but I dropped you a note saying that you can do the gvfs update if you want yesterday
[10:23] <pitti> seb128: oh, I woudl have, but seems that robert_ancell beat me to it
[10:24]  * pitti isn't really used to IRC notes, sorry
[10:24] <seb128> ok, if you want to look at it and sponsor then
[10:24] <seb128> since there is lot of your changes there
[10:24] <pitti> yes, I will
[10:24] <pitti> yeah, sorry for those
[10:24] <seb128> pitti, it's not an IRC "note", it's just me writting "pitti: something" on this channel ;-)
[10:24] <seb128> I'm not sure how much you read highlights in the morning
[10:24] <pitti> seb128: hm, didn't see that; I did read overnight scrollback, I guess I just missed it
[10:25] <seb128> ok
[10:27] <seb128> pitti, you managed to build the new nautilus without the new gvfs?
[10:28] <pitti> yes, it just built
[10:28] <pitti> perhaps not correctly then?
[10:28] <pitti> it also built on LP
[10:28] <pitti> if it conditionally enables new features, then we shuold bump the build dep
[10:29]  * pitti drops other work and sponsors gvfs now
[10:29] <didrocks> hello seb128
[10:29] <seb128> pitti, it relies on gvfs changes to work correctly I think but that might not be at build time
[10:30] <pitti> hm, "oops"
[10:30] <seb128> pitti, not sure how it will work on the old gvfs
[10:30] <pitti> I didn't test it extensively TBH
[10:30] <seb128> lut didrocks
[10:30] <pitti> hey didrocks
[10:30] <didrocks> hey pitti
[10:31] <seb128> pitti, no worry, it might work fine the changelog just suggests it use the new gvfs changes
[10:31] <seb128> where would be the fun without some karmic breakages ;-)
[10:31] <pitti> seb128: we should definitively build it again then, with a bumped b-dep
[10:32] <pitti> the new features sound interesting
[10:32] <seb128> pitti, well it might not test a build time but rather use that over dbus at run time
[10:32] <pitti> too bad that the gphoto port didn't make it into 1.3.2
[10:32] <seb128> distro patch it?
[10:32] <pitti> ah, I see
[10:32] <chrisccoulson> hey seb128, pitti. good morning :)
[10:32] <seb128> hey chrisccoulson
[10:32] <pitti> seb128: we already do
[10:33] <seb128> ;-)
[10:33] <pitti> but requires this silly 90_relibtoolize.patch
[10:33] <pitti> seb128: btw, any idea why we have this 01_maintainer_mode.patch thing?
[10:33] <seb128> to avoid random autotools trying to be clever and running again at build time
[10:34] <pitti> E: gvfs source: quilt-series-references-non-existent-patch 02-cdda-backend-support-and-prefer-gudev.patch
[10:34] <pitti> robert_ancell: ^ *cough* :0)
[10:35] <chrisccoulson> pitti - i had to do the same to tracker too. sometimes the autotools update only alters the timestamp of some files without adjusting their contents, and those files drop off the patch
[10:36] <pitti> ok, thanks
[10:38] <seb128> pitti, it's just a way to say "don't try to be clever and run autotools at build time even if timestamp changed"
[10:39] <seb128> pitti, otherwise you can get racy timestamp changes between patches and the build running autoreconf when it should not
[10:41]  * pitti wants a quilt-update-autoreconf-patch
[10:42] <seb128> lool has a such script and there is a quilt patch for that in the debian bts too
[10:43] <seb128> we should make cdbs-edit-patch work on quilt packages
[10:47] <robert_ancell> grr quilt
[10:47] <pitti> robert_ancell: don't worry, fixed; I also updated the gphoto patches while I was at it
[10:47] <robert_ancell> pitti, weird, it built for me using bzr-buildpackage
[10:47] <pitti> perhaps quilt ignores missing patches
[10:48] <seb128> it does
[10:48] <seb128> those not listed in the series are just not applied
[10:48] <pitti> that's a bug..
[10:48] <pitti> seb128: no, I meant patches that do appear in series which are missing
[10:48] <robert_ancell> pitti, was there a problem with the gphoto patches?  They seemed to apply fine
[10:48] <seb128> oh
[10:48] <pitti> robert_ancell: no, not a problem, but I rewrote them last weekend based on some feedback from David
[10:48] <seb128> hey robert_ancell btw ;-)
[10:49] <robert_ancell> seb128, hey seb
[10:49] <seb128> robert_ancell, did you manage to adjust back to your timezone?
[10:50] <robert_ancell> btw can someone drop into #ubuntu-meeting in 10 mins to support me for ubuntu membership?
[10:50] <seb128> robert_ancell, I'm there now
[10:50] <seb128> robert_ancell, not running for motu yet?
[10:51] <robert_ancell> Back to Sydney time.  Was a little tired Sunday night but pretty much ok today
[10:51]  * pitti joins and fetches his fanboy equipment
[10:51] <pitti> I need to run out in some 20 mins, though
[10:52] <robert_ancell> seb128, I was thinking about it but you guys are doing a fine job there :)  I think my return rate on my packages update is getting sufficiently low to go for that next
[10:52] <seb128> robert_ancell, being motu will not give you extra access for main packages anyway
[10:52] <seb128> ie we will still need to sponsor your changes
[10:53] <seb128> but that's one step on the main uploader way ;-)
[10:53] <robert_ancell> sure, then no rush
[10:54] <didrocks> pitti: not sure you read yesterday my demand for reviewing the setup.py for quickly package
[10:56] <pitti> seb128, robert_ancell: can you wave this around in the meeting? http://people.ubuntu.com/~pitti/tmp/robert-ancell-fanboying.txt.asc
[10:56] <pitti> since I might have gone when it's your turn
[10:56] <robert_ancell> pitti, thanks
[10:57]  * pitti hugs robert_ancell
[10:57]  * robert_ancell hugs pitti
[10:58] <pitti> didrocks: oh, that looks complex
[10:58] <pitti> didrocks: you don't want to use DistUtilsExtra.auto?
[10:58] <robert_ancell> http://people.ubuntu.com/~seb128/versions.html is a field of mushrooms :)
[10:58] <seb128> robert_ancell, thanks to you :-p
[10:59] <pitti> didrocks: you could probably drop all the list_files() etc. functions, and move completion/bash/quickly to etc/bash_completion.d/quickly
[10:59] <pitti> gvfs uploaded, BTW
[11:00] <seb128> thanks pitti robert_ancell ;-)
[11:00] <pitti> didrocks: of course you are welcome to write your own build system, but in the interest of dogfooding and DistUtilsExtra.auto testing I'd be interested in how it works for you
[11:01] <didrocks> pitti: do you have any doc on it? (documentation on distutils is well hidden)? :)
[11:01] <pitti> didrocks: see python -c 'import DistUtilsExtra.auto; help(DistUtilsExtra.auto)'
[11:01] <didrocks> pitti: thanks. I'm giving a look at it. Will it resolve my issue with po/ directory?
[11:01] <pitti> didrocks: it's pretty sparse, admittedly; but it gives you the supported file types and their expected extensions/locations
[11:02] <pitti> what's the issue?
[11:02] <pitti> didrocks: you don't need LINGUAS and POTFILES.in with that either
[11:02] <pitti> didrocks: and MANIFEST.in
[11:02] <pitti> eww, Makefile?
[11:02] <pitti> you should drop that
[11:03] <didrocks> pitti: I had to list po/ directory in setup.py an in MANIFEST.in to have it copied in ./setup.py sdist, but then, I have it in /usr/po when installing :/
[11:03] <pitti> didrocks: you'd need to move templates/ to data/templates, I guess (then it will land in /usr/share/quickly/templates/)
[11:03] <didrocks> pitti: yes, my work there is to change the Makefile into a working setup.py :)
[11:03] <pitti> didrocks: yeah; just throw away all that stuff :)
[11:03] <didrocks> ok, noted. I'm giving a try to that
[11:04] <pitti> didrocks: you should reorganize the source tree to have a dir per package (quickly/, already done), and data/* (-> /usr/share/quickly/), and etc/* (-> /etc/)
[11:04] <pitti> po files, manifest, packages, etc. is all auto-handled
[11:04] <pitti> didrocks: if you rename src/quickly to ./quickly or bin/quickly, it'll be auto-handled, too (see above help)
[11:05] <didrocks> pitti: ok, let me try that and I will fire you with questions if it doesn't work :) Thanks pitti!
[11:05] <pitti> didrocks: yes, please do
[11:05] <pitti> didrocks: in general, if you need _anything_ except setup.py with author/project name, etc., I consider that a bug in distutils-extra
[11:06] <pitti> didrocks: i. e. no scripts, data_files, packages, MANIFEST.in, POTFILES.in, etc.
[11:06] <didrocks> pitti: ok. I will list that. is there any backport for Distutilsextra.auto for jaunty?
[11:06] <didrocks> (I will list if I need extra files)
[11:06] <pitti> didrocks: https://edge.launchpad.net/~pitti/+archive/ppa
[11:07] <didrocks> perfect, I know what will take my afternoon then ;)
[11:07] <pitti> I'm off for some errands and lunch then
[11:07] <didrocks> pitti: have a good lunch and thanks again
[11:07] <pitti> I need back a working washing machine soon, after all
[11:08] <pitti> didrocks: have fun!
[11:08] <didrocks> sure ^^
[11:08] <seb128> pitti, see you later
[11:14] <lool> pitti: I didn't check recently but quilt used to fail when a patch was missing
[11:15] <lool> didrocks: http://people.dooz.org/~lool/debian/differ is a script to record a patch; it uses git or bzr to import your current tree, when you're done exit the shell it created and it will output a patch (unless you exit the shell with an error)
[11:16] <didrocks> lool: great, very handy, thanks. I will test it. But the patch thingy was for chrisccoulson I guess :)
[11:17] <lool> chrisccoulson: ^  :-)
[11:17] <chrisccoulson> i think it was for robert_ancell actually
[11:17] <chrisccoulson> ;)
[11:17] <chrisccoulson> i can't remember now
[11:17] <lool> robert_ancell: ^  :-)
[11:17] <didrocks> lool: pitti: FYI, I tested to add a unexisting patch to the series, quilt doesn't fail
[11:17] <lool> robert_ancell: Don't forget to tell me that the patch thingie was actually for someone else
[11:17] <chrisccoulson> thanks anyway look - looks very useful :)
[11:17] <pitti> didrocks: that's bad
[11:17] <didrocks> clearly
[11:18] <pitti> major trap for not applying patches due to typos, etc.
[11:18] <chrisccoulson> look -> lool. d'oh!
[11:18] <didrocks> this can be a easy thing to fix. Added to my todo list :)
[11:18] <lool> dquilt push -a || echo error
[11:18] <lool> Patch foo does not exist
[11:18] <lool> Application de foo
[11:18] <lool> error
[11:18] <lool> It does fail
[11:18] <lool> That's with 0.46-7
[11:19] <lool> didrocks: How did you test that?
[11:19] <didrocks> lool: quilt push -a and I have 0.46-6
[11:19] <didrocks> I see that the patch does not exist, but it applies the first one and exit with 0
[11:20] <lool> let me try with a valid patch first
[11:20] <lool> didrocks: Indeed; if it has a valid patch first, it doesn't fail
[11:20] <lool> Oh sorry it does
[11:20] <lool> Patch foo does not exist
[11:20] <lool> Application de bar
[11:20] <lool> Le patch bar semble vide. Il a été appliqué.
[11:20] <lool> Application de foo
[11:20] <lool> => error
[11:21] <didrocks> strange, I tested before a valid patch, and it fails and then, reverted back to my first test case and it exited with error now :/
[11:21] <didrocks> I don't understand what happened the first time
[11:26] <pitti> really off now, bbl
[11:30] <seb128> robert_ancell, ok, seems you will have to run for motu anyway
[11:31] <robert_ancell> seb128, ok, that makes sense.  Based on the Wiki I wasn't aware membership = "community membership".  There are so many levels :)
[11:31] <seb128> I think there is somewhat a fail in the current membership structure though
[11:31] <seb128> yeah me neither, I didn't go through all those things I was there before
[11:33] <robert_ancell> seb128, ok, I've followed the MOTU membership details on the Wiki and it links back to the original Membership page!!
[11:35] <seb128> lol
[11:36] <Laney> it's the same pretty much, except you get interviewed by the motu council instead of a membership board
[11:36] <Laney> https://wiki.ubuntu.com/UbuntuDevelopers#Applying
[12:38] <mvo> seb128: do we need further coordination for the gnome-control-center polkit1 migration? I ported ubuntu-system-service now and our patches inside g-c-c - can I upload this or is there other stuff pending?
[12:51] <YokoZar> seb128: regarding templates, forgive me if this has been brought up before, but has it been discussed whether users actually expect to interact with templates through the filesystem at all?  It seems very strange to me that ~/Templates isn't a hidden folder, as I suspect many users just see it as a weird empty default directory rather than a place to navigate to and place files
[12:54] <seb128> mvo, talk to chriscoulson when he's around he's working on the g-c-c 2.27 update
[12:55] <seb128> YokoZar, what do you mean exactly?
[12:55] <seb128> YokoZar, ie what else would you suggest?
[12:55] <mvo> seb128: ok
[12:55] <seb128> we could probably display a banner in the templates directory to indicate how to use it
[12:55] <YokoZar> seb128: that was my thought
[12:56] <seb128> that's orthogonal to the system templates issue though
[12:56] <YokoZar> seb128: But then I thought that if you add or remove templates, you currently do this by adding and deleting files from a folder that you interact with in nautilus.  But most other configuration of this sort we use control panels and such
[12:57] <YokoZar> So i don't think that the whole "moving files around" matches user expectations for people that want to mess with templates; worse, since it's user visible, the ~/Templates folder can clutter the home directory
[12:58] <YokoZar> It might be worthwhile to have a way of deactivating systemwide templates from an individual user perspective as well, but that would mean being able to "delete" templates from ~/Templates that aren't actual files there
[12:59] <seb128> all that seems orthogonal to the launchpad bug
[12:59] <seb128> I've no strong opinion either way, it's far from being perfect and patches are welcome
[12:59] <seb128> but it just re-enforce what I was saying, that needs design decisions before starting just adding random templates to fix the issue
[12:59] <YokoZar> Yeah true
[13:00] <YokoZar> Well the launchpad bug is kinda broad ("difficult to use") -- it sure would be convenient if we could put templates into packages and install them by default, that way the odd user that installs 3 word processors and also uses templates all the time could deactivate them
[13:01] <seb128> would you split those packages by formats, ie template for word editors, templates for images, etc?
[13:01] <seb128> and what would you do when a template is installed but not matching software?
[13:02] <YokoZar> Well if the template were part of the matching software package that wouldn't be an issue (thinking of open office here...could be done with depends on the template package)
[13:03] <seb128> YokoZar, still, do you split templates by function then, template-work, template-oocal, template-abiword, template-java?
[13:04] <YokoZar> Honestly I think user testing will reveal that we likely only need a very small number of templates; users may make lots of use of right click->create empty office document, but when they want to make an image they'll instead open gimp and start working until they have something to save
[13:05] <YokoZar> But I was thinking template-odt that then depends on openoffice | koffice and such
[13:06] <YokoZar> and install that in a central place (not the user home folder) so that when they upgrade from 9.04 to 9.10 they'll get the template without having their home folder mangled
[13:06] <asac> dbus-daemon loops and consumes ~20% of CPU here - constantly ... ouch
[13:07] <YokoZar> Then all we need is a convenient way for users to remove/deactivate templates: my suggestion is to right click the context menu and delete it
[13:07] <seb128> YokoZar, the issue is that once you have that in place people will want templates for abiword, and for oocal and for presentations, and for zip and for etc
[13:07] <asac> i guess the dbus problem is caused by indicator-applet which also eats lots of CPU all the time
[13:07] <asac> and gconfd is also looping
[13:07] <YokoZar> seb128: yup, and our design team can then test and figure out which of those we actually need and should have ubuntu-desktop depend on
[13:07] <asac> wth
[13:08] <seb128> YokoZar, the design team will not state on that, some users might uninstall openoffice and use abiword which shouldn't those get templates?
[13:08]  * mvo takes gcalctool and brasero from the sponsoring queue
[13:08] <seb128> YokoZar, why java programmers should not be able to get a template?
[13:08] <seb128> mvo, thanks
[13:09] <asac> i dont think the design team input is valuable for deciding which templates to display
[13:09] <seb128> right, me neither
[13:09] <YokoZar> I see what you mean
[13:09] <asac> design team is for design issues and not the instance we ask for input on everything we haven't found a consent yet
[13:10] <YokoZar> My expectation is that templates for a program will come when I install that program, if they're going to come at all
[13:10] <asac> we already had all those things discussed yesterday
[13:10] <YokoZar> fair enough
[13:11] <asac> http://irclogs.ubuntu.com/2009/07/13/%23ubuntu-desktop.txt
[13:11] <asac> look at 23:18
[13:11] <asac> it continues the next day
[13:11] <asac> http://irclogs.ubuntu.com/2009/07/14/%23ubuntu-desktop.txt
[13:11] <seb128> I commented on the bug with a summary
[13:12] <asac> so about 00:08 we have more or less reached a consent
[13:12] <seb128> we should split the bug anyway
[13:12] <seb128> adding a cluebar in the templates directory is not controversial
[13:12] <asac> seb128: i have another idea though. we could let apps ship their template to a system place
[13:12] <seb128> then we need discussion on how we ship templates, if those are shared between desktop, etc
[13:12] <asac> seb128: and make nautilus-templates-support which then just creates a link to the right dir to enable the system templates
[13:12] <asac> seb128: you could remove nautilus-templates-support to get rid of templates
[13:13] <asac> to prevent general clutter in the system menu, we can use policy
[13:13] <asac> just a slight variation compared to what you suggested with ubuntu-templates package
[13:13] <asac> maybe a compromise?
[13:14] <seb128> asac, we could also have a gconf key to enable system templates
[13:14] <asac> yes. depends on which level we want to approach this
[13:14] <asac> packaging or code
[13:14] <seb128> so the users who find those too cluttered could dnd the ones they want to their user dir and turn the key off to stop using the default list
[13:14] <seb128> easy to pick some in the system dir and turn off the dir use
[13:15] <asac> right. if that works for you we can do the gconf key. but then we could also do a gconf key that allows you to disable a few ;)
[13:15] <seb128> anyway I think there is enough variant to justify a spec or a mailing list or meeting topic
[13:15] <YokoZar> agreed seb128
[13:15] <asac> right.
[13:16] <YokoZar> It sounds like once we have system/user templates together, and the user disabling system templates, the whole deleting/adding files to ~/Templates metaphor breaks down
[13:16] <asac> seb128: i would think we should prepare a mail with the proposed solutions ... its probably a topc where a meeting discussion out of the blue would lead to an unqualified decision
[13:16] <seb128> right
[13:16] <asac> lots of thoughts would get repeated et al
[13:16] <asac> or lets make a wiki page out of it ... which could become a spec
[13:16] <seb128> we should start with list discussions
[13:17] <asac> and then post the content to list
[13:17] <seb128> and maybe discuss in a meeting once discussion is over
[13:17] <asac> right
[13:17] <asac> reach consent based on list discussion
[13:17] <YokoZar> Would it be appropriate to have a context-menu in the context menu (as in right click->create document->hover over office writer document->right click THAT->remove template)
[13:17] <YokoZar> I don't know if we do this anywhere else
[13:17] <asac> seb128: so how about setting up a wiki page where we list the suggested approaches with Pros/Cons
[13:17] <asac> seb128: and once everyone has added his ideas there we sent that to mailing list?
[13:17] <seb128> asac, sounds good to me
[13:18] <asac> YokoZar: i dont think that would be a good user experience
[13:18] <seb128> YokoZar, right click is not discoverable and should not be the only way to do something
[13:18] <YokoZar> of course
[13:18] <asac> YokoZar: the final solution would be a template editor that you can probably open from that menu
[13:18] <asac> e.g. (edit ...)
[13:18] <YokoZar> Yeah
[13:18] <asac> but we are currently not looking to implement the full solution in karmic ... we want something pragmatic
[13:19] <asac> that we can do now
[13:19] <YokoZar> But if we have that we don't need ~/Templates user-visible anyway
[13:19] <asac> YokoZar: why? users might also want to add new templates
[13:19] <YokoZar> instead we could have ~/.templates I mean
[13:19] <asac> template editr == similar to menu editor for gnome menu
[13:19] <YokoZar> And users would get to it by clicking that edit button
[13:19] <asac> e.g. you can remove/add system/user installed ones
[13:19] <seb128> would you move music to .music too because rhythmbox handle it in a transparent way?
[13:19] <asac> YokoZar: it would open a nautilus folder?
[13:20] <seb128> and Desktop to .desktop?
[13:20] <asac> YokoZar: i would rather think that you see in the dialog the currently available templates and can disable/enable them
[13:20] <seb128> I don't think we win anything to move everything to hidden directories
[13:20] <YokoZar> seb128: I'm talking specifically about ~/Templates here, not the rest
[13:20] <asac> i think the user Templates is a good place to store new stuff ... but it shoudlnt be the primary way to configure this
[13:20] <asac> its just the place to dump new user-specific templates
[13:21] <YokoZar> Because I don't think users go into the templates directory at all
[13:21] <seb128> those who know about it do
[13:21] <asac> YokoZar: well. most likely because its completely dubious what kind of files to add there
[13:21] <asac> which is why apps should ship their templates and then users can enable/disable them in the document folder ;)
[13:22] <asac> YokoZar: i am not sure if the menu editor should also allow to add new user defined ones. if it does, it definitly should suggest Templates
[13:22] <asac> menu/template editor
[13:22] <YokoZar> Using the menu editor as an example...we do keep the menu in a hidden folder
[13:22] <asac> yeah. but imo everything that isnt in Places menu is hidden anyway
[13:22] <asac> thats the primary view on file system for a user
[13:23] <asac> everything else is advanced
[13:23] <YokoZar> well different degrees of hidden
[13:23] <YokoZar> since we do have places->home
[13:23] <asac> right. but for the normal user the unix "hidden" feature doesnt really matter - unless he has absolutely no reason to go there, which isnt the case for Templates imo (e.g. the user might want to add stuff there)
[13:24] <YokoZar> It's not something you do often though.  And the first place you look will probably be right click->create document->edit...
[13:24] <YokoZar> so if that just opened the hidden folder it'd be fine
[13:24] <asac> maybe. i dont really care. but i dont see a strong point to hide it
[13:25] <asac> its not something the user shouldn touch at all
[13:25] <YokoZar> I'm more interested in the users that don't care to edit it but instead have this visible folder in their home directory annoying them
[13:25] <asac> YokoZar: how many folders do we have in HOME in a default install?
[13:26] <asac> Templates/ Desktop/ Video/ Music/ ?
[13:26] <asac> what else?
[13:26] <YokoZar> asac: examples
[13:26] <YokoZar> Nevermind that "Templates" and "Examples" sound very similar
[13:26] <artir> asac: Documents, DOwnloads
[13:27] <asac> YokoZar: yeah. so when we hide the Templates stuff we also need to add a Preferences -> entry
[13:27] <artir> and Public
[13:27] <asac> or is there no other way to say "new document" than right clicking in nautilus?
[13:27] <YokoZar> Pretty sure right clicking in nautilus is the only way to see that, so if the configuration was there (and only there) it'd be fine
[13:28] <asac> YokoZar: its also in File menu in nautilus
[13:28] <YokoZar> Well the edit... could go there too
[13:28] <asac> yeah.
[13:28] <asac> anyway. i dont think that the editor is something we have the resources to do in karmic
[13:28] <asac> so we need an intermediate solution ;)
[13:29] <YokoZar> True
[13:29] <YokoZar> My intermediate solution is to ship a couple of open office templates and then talk about the editor at UDS
[13:30] <seb128> karmic solution: add a system dir, a gconf key to not use it and some templates in an ubuntu-templates
[13:30] <asac> YokoZar: our solution was to ship a couple of templates + allow users to easily disable system templates (either remove package or gconf) and also hid templates where  the binary is not installed
[13:30] <YokoZar> I don't think we'll end up with clutter until after we have a few templates in a shipping release ;)
[13:31] <seb128> we will get annoyed users and maintainers if we add briefly something and start breaking it from the moment they start adding things there
[13:31] <asac> we can set a policy
[13:31] <seb128> we should better have a clear plan from the start
[13:36] <seb128> asac, btw did the gtk update fix your daily xulrunner build?
[13:36] <asac> seb128: our dailies run at 1700
[13:36] <asac> (our time zone)
[13:36] <seb128> ok, you didn't do a give back to the build?
[13:36] <asac> but i would think
[13:37] <seb128> alright, let me know if you still get an issue today
[13:37] <asac> also xulrunner trunk wasnt affected, so its seemed the single header problem is already solved there
[13:37] <asac> it was just 1.9.1 (ffox 3.5) breaking
[13:38] <seb128> ok*
[13:42] <asac> https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/NautilusDocumentTemplates
[13:42] <asac> YokoZar: seb128 ^^ if you have more suggestsions or more variants, please add them accordingly
[13:43] <seb128> asac, will do
[13:43] <YokoZar> Will do, thanks asac
[13:43] <asac> seb128: i think your current suggestion should match Plan B ;)
[13:44] <asac> indicator-applet still goes mad
[13:45] <asac>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
[13:45] <asac> 10036 asac      20   0  280m  54m  10m S   23  2.7 201:23.50 indicator-apple
[13:45] <seb128> talk to tedg when he's around
[13:45] <asac> yeah. just wonder if want to keep this process running any longer
[13:45] <seb128> do you do any use of it?
[13:46] <asac> i mean for debugging purpose
[13:46] <asac> no
[13:46] <asac> it shows me when there are gwibber notifications
[13:46] <asac> like 100 ;)
[13:46] <seb128> attach gdb to it to make it stop and keep it this way until tedg is around? ;-)
[13:46] <asac> if i click on it, it just opens gwibber ... not even selects the right tab/messages
[13:46] <asac> hmm
[13:46] <asac> guess i need -dbgsym then ;)
[13:47] <asac> but good idea
[13:55] <asac> seems its because indicator messages add a timeout and then never cancel that timeout
[13:56] <asac> so i probably have a few hundred messages still waking up every 60 seconds
[13:56] <asac> folks, remember that C is not python and you have to cleanup ;)
[13:57] <asac> still even without indicator consuming cycles, dbus-daemon keeps on looping
[13:57] <asac> let me listen to dbus messages to see whats going on
[13:58] <pitti> re
[13:58] <asac> ouch seems like there is a fight over the SessionManager ownership going on
[14:00] <chrisccoulson> what messages are you seeing asac?
[14:00] <asac> hmm its not a fight over name ownership, but zillions of ClientAdded invocations
[14:00] <chrisccoulson> heh
[14:00] <asac> http://paste.ubuntu.com/217918/
[14:00] <chrisccoulson> you havent just enabled compiz by any chance have you?
[14:01] <pitti> seb128: Robert is an Ubuntu member now?
[14:01] <asac> at least this log explains why dbus-daemon and gconfd are going mad here
[14:01] <seb128> pitti, no, they bounced him back to mc because he did mostly technical contributions
[14:01] <asac> chrisccoulson: i tried to enable it yeah
[14:01] <seb128> pitti, ie he's going to apply for motu now
[14:01] <asac> chrisccoulson: it didnt work though ;)
[14:01] <asac> known bug?
[14:01] <chrisccoulson> asac - that's a metacity bug
[14:01] <chrisccoulson> i'll dig out the number
[14:01] <chrisccoulson> 1 sec
[14:01] <asac> do you have the id?
[14:01] <asac> thanks
[14:02] <pitti> seb128: ah, ok; so member is for non-technical contributions now?
[14:02] <seb128> pitti, right
[14:02] <didrocks> pitti: are you now the happy owner of a new washing machine?
[14:02] <chrisccoulson> asac - bug 389686
[14:02] <seb128> pitti, dholbach said that the mc is better placed to judge techical work and to apply for motu directly there
[14:03] <pitti> didrocks: yes, we needed to buy a longer hose pipe; it's running now for the first time
[14:04] <asac> chrisccoulson: great. can i recover without restarting X?
[14:05] <asac> let me kill the older process
[14:05] <chrisccoulson> asac - if you do "killall metacity" just at the right time, you will get the rogue respawned process to exit properly
[14:05] <asac> chrisccoulson: it worked. i had to kill the --replace process
[14:05] <asac> thanks
[14:06] <chrisccoulson> yw
[14:06] <didrocks> pitti: hum, I debugged the packaged distutilsextra version before seing that the fix is already in trunk :/
[14:06] <didrocks> the good news is that my fix is exactly the code in trunk, so :)
[14:07] <asac> heh. so now i have 99% CPU by indicator-applet ;)
[14:07] <asac> good ... but i think i understand that problem
[14:08] <chrisccoulson> that's ok, it's nothing too important now ;)
[14:08] <pitti> Riddell: hmm, is /usr/lib/kde4/libexec/kdesu still the KDE method du jour to run a program as root?
[14:08] <pitti> Riddell: "/usr/lib/kde4/libexec/kdesu id" does nothing (neither with running a terminal, or something); it prompts me for my password, then closes the dialog, and exits
[14:08] <pitti> didrocks: heh; which?
[14:09] <didrocks> pitti: src_all used in __gtkbuilder, which causes some troubles if data/ contains some ui files
[14:10] <didrocks> (you looked into src_all and remove the files from src list, where they don't exist)
[14:10] <pitti> didrocks: ah, right
[14:10] <didrocks> well, another error. I guess I will package the trunk to avoid double efforts
[14:11] <pitti> didrocks: latest trunk is already uploaded to karmic and sid
[14:11] <pitti> (from this morning)
[14:11] <didrocks> pitti: yes, but my desktop is jaunty. Is it just a rebuild question?
[14:11] <pitti> didrocks: please file bugs for stuff that doesn't work (I also want to add test cases for those bugs)
[14:11] <pitti> didrocks: oh, right
[14:11]  * pitti updates PPA
[14:11] <didrocks> thanks :)
[14:12] <chrisccoulson> someone else is still running jaunty? ;)
[14:13] <didrocks> chrisccoulson: it's better when you are giving regular presentation as I did last week :)
[14:13] <pitti> didrocks: you should add a distutils version check like in http://bazaar.launchpad.net/%7Ejockey-hackers/jockey/trunk/annotate/head%3A/setup.py
[14:13] <pitti> assert DistUtilsExtra.auto.__version__ >= '2.4', 'needs DistUtilsExtra.auto >= 2.4'
[14:14] <didrocks> pitti: ok. I add it
[14:14] <pitti> didrocks: 2.4 uploaded to my PPA, thanks
[14:14] <chrisccoulson> didrocks - yeah, i'm still running it too. i havent found time to upgrade it yet, and if it works as well as it does in a VM, then i should probably wait a bit ;)
[14:14] <didrocks> pitti: ok, I just wait for it to build and we will see what happen :)
[14:15] <didrocks> chrisccoulson: ahah ^^
[14:20] <pitti> Riddell: ah, apparently doesn't search $PATH or so; works now
[14:22] <Laney> Aaron posted his gcds slides: http://abock.org/2009/07/14/exciting-updates-on-the-road-to-banshee-2-0
[14:22] <Laney> exciting
[14:34] <pitti> didrocks: meh, backports failed; 2.4~jaunty << 2.4~ubuntu, bah
[14:35] <didrocks> pitti: arf, that's why I didn't see it building in your ppa
[14:35] <didrocks> I can branch, ./setup.py sdist and then build
[14:36] <pitti> didrocks: uploaded again
[14:36] <pitti> didrocks: you can just build it locally, sure
[14:36] <didrocks> pitti: ok, thanks. I will wait then :)
[14:36] <pitti> bzr get lp:~python-distutils-extra-hackers/python-distutils-extra/debian
[14:36] <pitti> and then just debuild -us -uc -b
[14:37] <didrocks> oh, easier than what I was doing :)
[14:39] <pitti> didrocks: that's why we package stuff :) (debian/ FTW)
[14:41] <didrocks> pitti: hum, I have an error in the automatic testsuite, let me check
[14:41] <pitti> didrocks: do you have the build deps installed?
[14:41] <pitti> (check with deblean)
[14:41] <pitti> didrocks: the test suite uses two unrelated python modules
[14:41] <didrocks> xml.parsers.expat is one of them?
[14:43] <pitti> right
[14:43] <pitti> seems I suck and forgot to add that as a build dep then?
[14:44] <didrocks> pitti: I used build deps to install them, but the one on jaunty. I have to check with the one you provided
[14:44] <didrocks> no error in debclean
[14:44] <pitti> didrocks: ah no, python2.6 includes expat
[14:45] <didrocks> pitti: that's what I see. But it's installed on my system in _xmlplus/parser/expat.py
[14:45] <didrocks> and not xml/parsers/expat.py
[14:45] <didrocks> no, sorry, I have xml/parsers/expat.py
[14:46] <pitti> didrocks: what's the error that it shows?
[14:46] <didrocks> pitti: http://paste.ubuntu.com/217954/
[14:46] <pitti> didrocks: package/test suite built fine on karmic, anyway: http://launchpadlibrarian.net/29003079/buildlog_ubuntu-karmic-i386.python-distutils-extra_2.4_FULLYBUILT.txt.gz
[14:47] <didrocks> pitti: ok. I suck somewhere, so…
[14:47] <pitti> didrocks: interesting; it considers xml.parser.expat an external module
[14:47] <pitti> didrocks: hang on, don't touch anything
[14:48] <didrocks> |o|
[14:48] <didrocks> req = [prop.split(' ', 1)[1] for prop in egg if prop.startswith('Requires: ')]. Ok, so, you check in the egg file apparently
[14:49] <pitti> python -c "print __import__('xml.parsers.expat').__file__"
[14:49] <pitti> didrocks: ^ what does that show for you?
[14:49] <pitti> /usr/lib/python2.6/xml/__init__.pyc for me
[14:50] <didrocks> /usr/lib/python2.6/dist-packages/_xmlplus/__init__.pyc
[14:50] <didrocks> that's bad :/
[14:50] <pitti> ah
[14:50] <didrocks> I have a module that interfere…
[14:50] <pitti> so apparently you have a python module installed which overrides the internal one or so?
[14:50] <didrocks> right
[14:51] <pitti> hm; for the test suite it's probably ok to fail in that case
[14:51] <didrocks> yes, seems raisonnable
[14:51] <pitti> or I use a differnet module which doesn't have reimplementations
[14:51] <pitti> didrocks: anyway, built fine in jaunty ppa
[14:51] <pitti> didrocks: just go ahead and dist-upgrade, it's published
[14:52] <didrocks> pitti: thanks, should be easier for testing with a good version
[14:52] <didrocks> (it build successfully, when this module dismissed)
[14:55] <didrocks> ok, I still have the same error when trying to ./setup.py sdist for quickly but now, I know that's in trunk and can try to fix it :)
[14:56]  * didrocks fires up pdb
[14:58] <kenvandine> didrocks, try out epdb :)
[14:58] <kenvandine> https://edge.launchpad.net/~gafton/+archive/ppa
[14:58] <didrocks> kenvandine: never try, what does it bring?
[14:58] <kenvandine> the enhanced python debugger
[14:58] <kenvandine> command completion, etc
[14:59]  * kenvandine is going to try to get it into universe :)
[14:59] <didrocks> great, let's have a look. Thanks :)
[14:59] <kenvandine> it doesn't make me want to dig my eyes out like pdb does :)
[15:09] <didrocks> pitti: the error is in distutils itself (http://paste.ubuntu.com/217970/). I'm not sure that I know enough about distutils to be able to debug it myself. Do you want me to open a bug (I have can push the branch somewhere)? Strange also that the modules in quickly/ prints an error.
[15:09] <pitti> aah
[15:09] <pitti> didrocks: right, python modules can't have dashes
[15:09] <pitti> didrocks: seems distutils-auto picks up too much
[15:09] <pitti> didrocks: can you please create a bug with the reproducer?
[15:10] <djsiegel_> pitti: is it true that we have 20mb of GIMP documentation on the live CD? I've heard concerns about shipping the karmic desktop backgrounds, and if we could jettison GIMP documentation for pretty desktop photos, I think that's a pretty easy choice to make.
[15:11] <pitti> djsiegel_: yes, we have 20 MB of gimp documentation
[15:11] <pitti> djsiegel_: but no, we can't add 20 MB of photos
[15:12] <pitti> djsiegel_: OLS needs to add half a dozen MB for new karmic stuff, empathy needs a lot as well, and we need to put back some langpacks
[15:12] <djsiegel_> great, that's not what I am suggestion
[15:12] <djsiegel_> we will likely want to include 4 or 5 photos
[15:12] <pitti> djsiegel_: but we can certainly negotiate for another MB :)
[15:12] <djsiegel_> how do you recommend we do it?
[15:13] <djsiegel_> sorry for my lack of knowledge about this, but is there a general solution for including more stuff that can't fit on the liveCD?
[15:13] <djsiegel_> like a package that is downloaded during install?
[15:13] <pitti> unfortunately not
[15:13] <djsiegel_> very interesting
[15:14] <pitti> we have some special magic for translations, but not for features (that's deliberate)
[15:14] <pitti> djsiegel_: I recommend to talk to kwwii to have it added to the ubuntu-wallpapers package
[15:14] <djsiegel_> it's deliberate because we believe limiting the install by the constraint of CD size "keeps us honest"?
[15:15] <pitti> pretty much, yes
[15:15] <djsiegel_> ok
[15:15] <pitti> having a lean and mean install which fits on one CD is quite an important design goal
[15:15] <pitti> and keeps us from piling up more and more cruft
[15:15] <djsiegel_> for sure
[15:16] <pitti> djsiegel_: so, the karmic artwork will definitively change, and improving is is great
[15:16] <pitti> djsiegel_: I'm just afraid we can't affort 20 MB :)
[15:16] <djsiegel_> right
[15:16] <djsiegel_> but, if we can't get 10 or 20 HD wallpapers in the install, something has to change
[15:16] <djsiegel_> I'm not sure how we'll do it
[15:16]  * hyperair grumbles about bzr and stupid rich-root compatibility issues with do-core's repository.
[15:16] <djsiegel_> but to say "we will never go over 700mb" is dogmatic
[15:17] <pitti> djsiegel_: why would we need 20 HD wallpapers in a default install?
[15:17] <djsiegel_> we could all cut off one hand, and we would write much leaner, cleaner, faster, more bug-free code
[15:17] <pitti> that sounds like bloat (the kind we want to avoid)
[15:17] <pitti> djsiegel_: easy enough to have them in the archive, of course, for people who want them
[15:17] <djsiegel_> pitti: I am just saying, if it came to something like that
[15:18] <pitti> heh, let's hope it won't :)
[15:18] <djsiegel_> I am interested in delivering a great out-of-the-box experience
[15:18] <djsiegel_> even if we have to fake it with a download
[15:18] <djsiegel_> part of the great experience is beautiful wallpapers that are easy to access
[15:18] <djsiegel_> they can be in the archive
[15:18] <djsiegel_> but they have to be discoverable
[15:18] <djsiegel_> Windows 7 and Mac OS X ship about 50 large wallpapers each
[15:19] <pitti> there could be a button "Find more..." which takes you to the app center with a pre-made search for wallpaper packages or somethign such?
[15:19] <djsiegel_> if we don't have them, it looks pretty bad (I am not saying we have to do everything they do, of course)
[15:19] <djsiegel_> pitti: yeah, something like that
[15:19] <pitti> right, but they need an entire DVD to just ship the bare OS
[15:19] <pitti> even though we do offer DVDs, they aren't very popular
[15:19] <pitti> because they are just too big
[15:19] <djsiegel_> hmm
[15:20] <djsiegel_> well, hopefully that will change
[15:20] <djsiegel_> who know where we'll be in 5 years
[15:20] <djsiegel_> a DVD could take two minutes to download
[15:20] <pitti> sure, eventually the world's bandwidth will grow
[15:21] <mvo> pitti: the crash_signature is added now, I have not seen enough real world crashes to know if its good as it is, but I think we can easily refine it when we get more experience
[15:21] <pitti> mvo: thanks; the main point is that crash_signature() derives a meaningful signature from a kernel crash report (i. e. doesn't stumble over ExecutablePath, or alwasys return empty string, or so)
[15:21] <djsiegel_> but I am questioning the CD size constraint... The discipline it imposes certainly is good, but that's not the only way to be disciplined, and at seems like a lot of time and energy (money) is spent assembling the 700mb jigsaw puzzle each cycle
[15:22] <djsiegel_> It would be really nice to have a bit more flexibility
[15:22] <pitti> mvo: GIGO applies, obviously :) (but that's not something the test suite focuses on)
[15:22] <djsiegel_> yes, it could lead to a slippery slope
[15:22] <djsiegel_> or it could not
[15:22] <pitti> djsiegel_: we already discussed that a lot, really
[15:22] <pitti> but so far we have always managed
[15:23] <djsiegel_> ok
[15:23] <djsiegel_> I would just love to be able to ship 10 great wallpapers and a hi-def icon theme without too much trouble
[15:23] <pitti> but indeed, we do have to spend lots of work on removing cruft
[15:23] <pitti> but that's not solely for the benefit of CD size, it also helps us to maintain a healthy system
[15:23] <pitti> everythign that's on the CD also needs to be supported, maintained, debugged, etc.
[15:23] <mvo> pitti: sure :)
[15:23] <djsiegel_> yeah
[15:24]  * mvo ticks another item off his gtg list
[15:24] <djsiegel_> no, I think the CD limit is great
[15:24] <pitti> mvo: \o/
[15:24] <djsiegel_> but there are downsides, and the design team is wondering how we design around them
[15:24] <djsiegel_> see the designers quitting Google
[15:25] <mvo> pitti: I have not added a test for the vmcore retrace, I have no good idea yet how that could be done, my .crash file is some hunderts of megs :/
[15:25] <djsiegel_> Google optimizes everything, even design
[15:25] <djsiegel_> the designers found it too constraining, and some had to quit
[15:25] <pitti> mvo: apport-retrace currently doesn't have full test cases, for reasons like that
[15:25] <pitti> mvo: if you tested it with a real crash file and apport-retrace, and it worked, that's fine for now
[15:25] <pitti> mvo: however, the test suite shouldn't have a pre-made .crash file anyway
[15:26] <djsiegel_> the notorious examples of Google changing hues and cutting 500bytes to save a datacenter, but corrupting a design
[15:26] <mvo> pitti: yes, works on my test machine
[15:26] <pitti> mvo: it should generate a kernel core dump itself
[15:26] <mvo> pitti: right, generating it on the fly needs a reboot
[15:26] <pitti> mvo: similarly, the apport tests start a program (cat or so), let it segfault, run apport on it, etc.
[15:26] <mvo> pitti: because it loads the crash kernel when the real one panics
[15:26] <pitti> mvo: right, with the kernel that's kinda tricky :)
[15:26] <mvo> pitti: yeah, I like this approach for the normal segfauls :)
[15:27] <pitti> djsiegel_: well, but "good" design is certainly not "20 wallapers" or "30 login themes", but "one really good one which makes a great default"?
[15:28] <pitti> we don't ship 20 webbrowsers or 10 music players either, we select the best and install it by default
[15:28] <pitti> and whoever wants somethign else is free to install it
[15:28] <djsiegel_> pitti: that's not the point, and we aren't going to decide what is good design and what is bad here and now
[15:28] <djsiegel_> I am just talking about design team leeway
[15:28] <djsiegel_> 20 web browsers is strawman for 20 wallpapers
[15:28] <pitti> djsiegel_: right, I'm just a bit confused why CD space is related to being able to do design work?
[15:28] <mvo> it would be fun to generate a test using kvm - it would have to build (and cache) a image via ububuntu-vm-builder and then use the montior io interface to send a sysreq-c - plus a way to get the crash file off the image again and the hunderts of megs big linux-image-debug .. probably a bit too much overkill
[15:29] <pitti> mvo: uh, that'd take a while
[15:29] <mvo> yeah :/
[15:29] <djsiegel_> pitti: because design work creates what you call "cruft" and the design team calls "art" -- do you see how that could be a problem for us?
[15:29] <pitti> djsiegel_: not really, I'm afraid
[15:30] <djsiegel_> pitti: ok
[15:30] <pitti> so far, the design team reviewed applications, workflows, how to work with the desktop, etc.
[15:30] <didrocks> pitti: bug #399324 when you will have some time
[15:30] <pitti> djsiegel_: of course producing artwork is an important piece in that puzzle
[15:31] <pitti> djsiegel_: but shipping dozens of wallpapers isn't going to improve the user experience more than shipping one really good one and e. g. making the desktop appear in the user's language, and shipping the apps that people need
[15:31] <pitti> i. e. we need to give all the components an appropriate amount of space
[15:32] <pitti> and having little of that forces us to avoid duplication
[15:32] <pitti> djsiegel_: and honestly, 3 wallpapers are fine; but I do consider 20 wallpapers "cruft"
[15:32] <djsiegel_> pitti: but who decides that?
[15:33] <djsiegel_> pitti: the desktop team are the gatekeepers
[15:33] <pitti> djsiegel_: nobody alone, really
[15:33] <djsiegel_> It's fine that 20 wallpapers are cruft to you, but what if user testing shows that users love pretty wallpapers in the default install?
[15:34] <pitti> it's working together and planning releases, and knowing the fundamental constraints
[15:34] <djsiegel_> I just want to find out how we can accommodate that with the CD size constraint.
[15:34] <djsiegel_> Please don't tell me that users are wrong, or I'm not a good designer and I should pick 3 wallpapers :)
[15:34] <djsiegel_> I am just giving a hypothetical example
[15:34] <djsiegel_> well, quasi-hypothetical
[15:34] <pitti> djsiegel_: if we can prove that users are fine with having 20 wallpapers and no webbrowser or instant messager, or wahtever, fine for me :)
[15:35] <dpm> djsiegel_: users also like to have the CD in their language.
[15:35] <djsiegel_> we need to think outside the 700mb constraint now
[15:35] <pitti> djsiegel_: as I said, nothign wrong with an "install more..." button
[15:35] <pitti> we have plenty of space on archive.u.c. for downloading
[15:36] <ccheney> making it easy to download 'official' wallpapers in the change desktop background app might help resolve the space vs number of wallpapers available?
[15:36] <djsiegel_> no...
[15:36] <pitti> but the entire idea of Ubuntu is to provide one good solution for every problem by default, instead of 20 and have the user figure it out
[15:36] <djsiegel_> please don't get hung up on the wallpapers example
[15:36] <djsiegel_> I am more interested in downloading in the abstract case
[15:36] <artir> djsiegel_: the next step is a 1gb image that fits in a pendrive, but the desktop team said not yet...
[15:37] <pitti> artir: that's primarily an issue with mirror space, but that's a separate problem
[15:37] <kwwii> as long as the wallpapers are downloaded after installation automatically there shouldn't be that much a problem, or?
[15:37] <pitti> djsiegel_: well, it doesn't even need to be that explicit
[15:37] <pitti> you could ship thumbnails, and download it on the fly if needed, etc.
[15:37] <kwwii> including extra wallpapers has been one of the top requests for a couple of years
[15:38] <pitti> but really, half the users will just use a picture of their own anyway, etc.
[15:39] <djsiegel_> pitti: are you sure? you have that data?
[15:39] <djsiegel_> it would be useful for us
[15:39]  * ccheney thinks having really nice standard set of backgrounds would be useful
[15:39] <kwwii> I think that has been the case in the past because we didn't include any extra wallpapers :p
[15:39] <djsiegel_> kwwii: I like the idea of an RSS-backed wallpaper thingie
[15:39] <djsiegel_> and displaying thumbnails like pitti suggests
[15:39] <kwwii> djsiegel_: indeed, it also allows us to include as many as we want and to update them as they come in
[15:39] <djsiegel_> we could have wallpaper channels
[15:40] <djsiegel_> pulled live from flickr or something
[15:40] <kwwii> kinda like "hot new stuff" or whatever it is called
[15:41] <ccheney> kwwii: i'm sure lots of people used the picture of the month backgrounds, heh
[15:41] <kwwii> gotta run...bye
[15:41] <ccheney> reintroducing something like that with non-offensive material might resolve this issue?
[15:42] <pitti> anyway, if there's large demand for it then we can certainly find a solution
[15:43] <pitti> but "we want to add this" always needs to be accompanied by "we throw out that instead"
[15:43] <seb128> we are always challenging the CD limits and having translations is probably higher on the usefulness list
[15:44] <seb128> auto download things from internet is nice theorically but has lot of issue in practice
[15:44] <pitti> we temporarily removed all of them until we resolve the overflow
[15:44] <ccheney> auto download can't be fully auto due to costs and speed of internet in various places
[15:44]  * kklimonda misses the idea from first ubuntu releases i.e. wallpaper of the month or whatever it was called ;)
[15:45] <pitti> kklimonda: that was a neat idea indeed
[15:45] <ccheney> something like that might work out well since each wallpaper package could be relatively small
[15:45] <pitti> it was just a metapackage, and the actual wallpapers came through -updates
[15:45] <pitti> (the first was already there, of course)
[15:47] <ccheney> also doing it via packages might work better than pulling directly from the net for cases where computers either don't have net access or are heavily firewalled, etc
[15:47] <pitti> ccheney: oh, that's out of question, sure
[15:48] <pitti> well, a "find more..." button doesn't necessarily need packags, but everything (semi-) auto-installed, like "monthly wallpaper" needs to be packaged
[15:48] <ccheney> yea
[15:49]  * ccheney hopes the caffeine kicks in soon, he has a full day of meetings
[15:49] <pitti> djsiegel_: wallpaper channel sounds like a great idea; with "channel" being different topics, like "flowers", "scifi", "kwwii", etc.?
[15:53] <djsiegel_> right
[15:53] <djsiegel_> or your facebook friends
[15:55] <pitti> that indeed sounds like an opportunity - use the flickr stream of a friend of your's as background :)
[15:56]  * pitti is clearly too web 2.0 ignorant to consider all that, it seems
[16:00] <pitti> jcastro: hey, how's it going?
[16:01] <jcastro> hi pitti!
[16:01] <seb128> hey jcastro
[16:09] <djsiegel_> pitti ccheney: I made a script to download and set a new wallpaper from the ubuntu artwork flickr pool every hour: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=6952#a6952
[16:10] <djsiegel_> not ready for general consumption yet, but fyi
[16:13] <ccheney> cool
[16:24] <mvo> james_w: pardon my question, but where are all the imported branches hosted? I want to work on python-central from the latest upload
[16:25] <james_w> mvo: https://code.launchpad.net/ubuntu/+source/python-central if they exist already
[16:26] <mvo> aha, thanks - so not all is there yet?
[16:26] <mvo> and I was wondering if I'm just blind :)
[16:26]  * mvo uses the good old bzr init ; bzr add
[17:09] <mpt> mvo, https://wiki.ubuntu.com/AppCenter#available
[17:17] <walters> Keybuk: around?
[17:19] <Keybuk> walters: yup
[17:19] <walters> Keybuk: i'm a bit unsure about defaulting to -1 for reply timeout...
[17:20] <walters> Keybuk: or hmm wait nevermind that's just the limit, right?
[17:20] <Keybuk> walters: that's just the maximum limit, right
[17:20] <Keybuk> the default is still 15s
[17:20] <walters> got it, ok
[17:21] <walters> so i can nuke this fedora patch then
[17:21] <Keybuk> what was the fedora patch?
[17:21] <walters> upped it to 6 hours
[17:21] <Keybuk> ahh
[17:21] <Keybuk> yeah
[17:21] <Keybuk> dbus/dbus-connection-internal.h:#define _DBUS_DEFAULT_TIMEOUT_VALUE (25 * 1000)
[17:21] <Keybuk> still 25s
[17:22] <Keybuk> I removed the 6 hour clamp as well, that was just bad math on Havoc's part ;)
[17:22] <walters> hehe
[17:22] <Keybuk> so the default timeout when -1 is given remains as 25s
[17:22] <Keybuk> but you can now pass a value from 0 (timeout immediately) to INT_MAX (never timeout)
[17:22] <Keybuk> without it getting clamped to 6 hours, or anything else
[17:24] <walters> Keybuk: yep, makes sense, i'd just confused myself for a min
[17:25] <Keybuk> :)
[17:28] <rickspencer3> team meeting in 2 minutes
[17:29]  * kenvandine is here
[17:29]  * bryce here too
[17:29] <rickspencer3> mpt saw the word "meeting" and ran
[17:30] <kenvandine> :)
[17:30] <rickspencer3> everybody ready?
[17:30]  * ArneGoetje is here
[17:31]  * awe is here
[17:31] <rickspencer3> I believe seb128 is on holiday
[17:31] <pitti> hey all
[17:31] <seb128> (I'm around but might not stay for the whole meeting though)
[17:31] <pitti> yeah, seb128 celebrates the Bastille revolution, I think
[17:31] <tkamppeter> hi
[17:31] <seb128> pitti, indeed ;-)
[17:31] <rickspencer3> he celebrates it by coming to work on his holiday?
[17:31]  * rickspencer3 taps gavel
[17:32] <rickspencer3>  starting with actions from two weeks ago
[17:32] <rickspencer3> kenvandine: what is the eta for FUSA?
[17:32] <pitti> rickspencer3: (FYI, I copied the relevant actions to last week's report)
[17:32] <seb128> lol
[17:32] <kenvandine> rickspencer3, ted couldn't give an eta yet, he said all the features are implemented and not ready to ship
[17:33] <kenvandine> told me to try it on from source, but i couldn't find it on LP
[17:33] <kenvandine> he is on vacation this week, i will mail him
[17:33] <rickspencer3> ok, we can carry that over
[17:33] <rickspencer3> I think the "install and try gdm" is no longer relevant
[17:34] <pitti> everyone should have it now, indeed
[17:34] <rickspencer3> thanks for getting than in seb128, and thanks for helping with bugs pitti
[17:35] <rickspencer3> bryce: are we still expecting to have X pretty much "in" for alpha three, so we stop using edgers?
[17:35] <rickspencer3> This refers to: ACTION: All: run edgers until alpha 3, and then disable (if currently running or otherwise interested)
[17:35] <tkamppeter> Yes, my gdm looks ugly now and I get some message after logging in, but this is already reported.
[17:36] <rickspencer3> tkamppeter: thanks
[17:36] <rickspencer3> k, moving along ...
[17:37] <rickspencer3> # ACTION: ALL: install mozilla security update, report problems to asac
[17:37] <bryce> rickspencer3, that's correct
[17:37] <rickspencer3> :)
[17:37] <asac> rickspencer3: that was ment to be "please enable security PPA permanently - e.g. not an instant action"
[17:37] <bryce> rickspencer3, although scuttlebutt is that xserver 1.7 is behind schedule upstream so YMMV
[17:37] <asac> even though we have new 3.0 bits in there yet
[17:37] <pitti> bryce: how's ati KMS coming along? ISTR it was disabled by default in one of the recent kernel uploads?
[17:37] <rickspencer3> !
[17:37] <bryce> (OMMV?)
[17:37] <asac> https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/ppa
[17:38] <asac> s/yet/already/
[17:38] <pitti> asac: does that apply to karmic as well?
[17:38] <asac> yes
[17:38] <asac> we prepublish karmic bits there too
[17:38] <asac> so testing that helps catching regressions
[17:38] <bryce> pitti, I  didn't hear about that, but the first 2.6.31 kernel was a bit rocky for us
[17:39] <pitti> asac: it's not feasible/practical to upload them to karmic straight instead?
[17:39] <bryce> currently what we're using xorg-edgers for is testing out the -ati kms stuff
[17:39] <pitti> ah, so that should have it? nice
[17:39] <pitti> I'll test it on my wife's computer soon
[17:39] <bryce> excellent
[17:39] <asac> pitti: in general we are not allowed to ship releases before mozilla releases them
[17:40] <asac> to avoid confusion i dont do that anymore
[17:40] <pitti> asac: I see; so they are fine with PPAs then?
[17:40] <asac> yes
[17:40] <asac> thats ok. just should stay out of anything that is official
[17:41] <rickspencer3> okay, so please, everyone get the mozilla security ppa set up by next week
[17:41] <asac> thx
[17:41] <rickspencer3> ACTION: rickspencer3 to review how paper cut effort is working for the team next week
[17:41] <rickspencer3> this seems to be going fairly well
[17:42] <rickspencer3> though it seems that many of the paper cuts are indeed more like stab wounds, as expected
[17:42] <awe> +1
[17:42] <pitti> ^ for a reason
[17:42] <rickspencer3> please contact me outside the meeting if there are concerns, or we can discuss after the meeting
[17:42] <pitti> many of those are open for months/years _because_ they aren't trivial to solve :)
[17:42] <pitti> but great to hear the progress there (also djsiegel_'s last report, that sounded pretty good)
[17:42] <rickspencer3> right, though some of them seem like they get endless debate
[17:42] <rickspencer3> that is not really needed
[17:43] <pitti> sure, GUI issues are very prone to bikeshedding after all :/
[17:43] <asac> i think that papercuts should be vetted to be real papercuts by the platform team and not the design team. design team should suggest them not decide which get approved (but thats a discussion for later)
[17:43]  * rickspencer3 doesn't want to open a can of works now
[17:43] <rickspencer3> :)
[17:43] <bryce> I noticed a lot need design decisions made (like for wording, or to select between several suggested solutions), that I didn't feel qualified to make a decision on
[17:43]  * pitti hands rickspencer3 a worm
[17:43]  * asac is happy he got his line out ;)
[17:44] <rickspencer3> okay, I feel that we are making good progress ... and that if we ever repeat the effort, we will have some good process improvements
[17:44] <rickspencer3> so that's the "previous actions" section
[17:44] <rickspencer3> next is status reports
[17:45] <rickspencer3> kenvandine: care to add anything to your very familiar looking status section?
[17:45] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-07-14
[17:45] <kenvandine> ?
[17:45] <kenvandine> well the partner update should cover it :)
[17:46] <rickspencer3> sorry ... I just meant, do you have any comments aside from what is on the wiki?
[17:46] <kenvandine> oh, no :)
[17:46] <rickspencer3> I like the way you have the seven buckets for the OLS team, it would be good if we could do something like that for the DXE team
[17:46] <pitti> kenvandine: oh, I didn't see MIR bugs for ubuntuone-*?
[17:46] <asac> kenvandine: "firefox bookmarks syncing " -> is that something that is run in firefox?
[17:46]  * kenvandine is a little concerned with getting these new packages reviewed, etc
[17:46] <rickspencer3> ACTION: rickspencer3 to help create buckets for DXE team
[17:47] <kenvandine> pitti, they are there :)
[17:47] <kenvandine> asac, an extension
[17:47] <kenvandine> well, syncing happens in u1/couchdb
[17:47] <asac> kenvandine: you guys should really talk to me more ... you plan to do really many things with firefox i dont know about et
[17:47] <kenvandine> but there is an extension that integrates with it
[17:47] <pitti> kenvandine: good to know, I didn't get mail about it, weird
[17:47] <kenvandine> asac, sorry... there is a blueprint :)
[17:47] <kenvandine> asac, steveA demoed it last week
[17:47] <pitti> kenvandine: ooh - these are against projects, not ubuntu packges, that's why
[17:48] <asac> kenvandine: well, if you dont communicat we will not be able to ship it
[17:48] <kenvandine> asac, i am trying to keep you guys in the loop here
[17:48] <rickspencer3> ACTION: kenvandine to facilitate discussion between SteveA and asac regarding firefox extension
[17:48] <asac> kenvandine: ok thanks
[17:48] <kenvandine> asac, it has been on that status table for a few weeks now
[17:48] <rickspencer3> asac: I thought SteveA did mention this to you ... I fear that I must have dropped the ball
[17:48] <kenvandine> i should have singled you out though, sorry
[17:48] <asac> rickspencer3: there was some remote talk at some point. but nothing concrete
[17:49] <rickspencer3> I think it must have been my fault for not bringing it up after one of our desktop integration calls
[17:49] <asac> ok
[17:49]  * rickspencer3 administers self-dope slap
[17:50] <pitti> kenvandine: fixed MIR bugs, will get to them ASAP
[17:50] <rickspencer3> kenvandine: pitti: I'm a little concerned that pitti did not see mail about the MIR
[17:50] <kenvandine> pitti, rock!
[17:50] <pitti> rickspencer3: as I said, they were reported against upstream projects (where MIR doesn't make sense), my filter doesn't jump on those
[17:50] <pitti> MIR is for ubuntu packages
[17:50] <pitti> fixed now
[17:50] <kenvandine> oh
[17:50] <asac> hehe
[17:50] <pitti> (the bugs)
[17:50] <rickspencer3> k
[17:51] <kenvandine> pitti, we can't assign them to ubuntu source packages until they are in ubuntu :)
[17:51] <asac> kenvandine: you cannot file MIRs for packages that are not in the archive imo
[17:51] <pitti> kenvandine: right, that's a feature
[17:51] <rickspencer3> kenvandine: you said you were concerned about getting everything reviewed, is there anything we should be doing to help?
[17:51] <kenvandine> :)
[17:51] <asac> they should be first in universe
[17:51] <kenvandine> asac, yeah... we did the MIRs in parallel
[17:51] <kenvandine> while they were in REVU
[17:52] <kenvandine> rickspencer3, not yet... i need to get them in REVU first.. i will ping people individual for help as needed
[17:52] <rickspencer3> ok
[17:52] <kenvandine> i just worry if it takes as long as u1 did
[17:52]  * rickspencer3 nods
[17:52] <kenvandine> pitti, MIRs for couchdb and it's deps should come this week
[17:52] <kenvandine> just fyi
[17:52] <pitti> cool
[17:53] <pitti> we worked out a new process in the MIR team
[17:53] <pitti> to get them processed in a better/faster way
[17:53] <asac> couchdb still has the problem with libmozjs.so
[17:53] <kenvandine> anything i should change in my process?
[17:53] <kenvandine> asac, yeah...
[17:53] <pitti> kenvandine: not really, please just make sure that they are against ubuntu packages
[17:53] <asac> kenvandine: please dont file MIRs before thy are packaged
[17:53] <pitti> kenvandine: the change was internal (I'm the gatekeeper now and distribute MIR reviewers by assignment)
[17:53] <kenvandine> i just won't create the bug reports
[17:54] <rickspencer3> thanks kenvandine
[17:54] <rickspencer3> I believe that Riddell is recovering from desktop summit, so not expecting a Kubuntu update
[17:54] <rickspencer3> just a quick update on quickly
[17:54] <rickspencer3> I think it is close to "feature complete" ... I will schedule a meeting to discuss release plans for it
[17:54] <rickspencer3> let me know if you want to attend that meeting
[17:55] <rickspencer3> we'll discuss feature prioritization, getting it into the archives, etc...
[17:55] <rickspencer3> I was in meetings all day, so I haven't had a chance to look at activity reports, but I presume they are all on the wiki or in my mail box
[17:56] <didrocks> (for quickly: I still have little feature to implement on release command and distutilsextra.auto to make it works)
[17:56]  * asac coughs
[17:56] <rickspencer3> lol
[17:56] <rickspencer3> thanks didrocks
[17:57] <rickspencer3> btw, on a total side note .. python-distutils-extra is very cool
[17:57] <rickspencer3> !
[17:57] <rickspencer3> thanks pitti
[17:57] <kenvandine> rickspencer3, ++
[17:57] <pitti> thanks :)
[17:57] <kenvandine> pitti, it does rock
[17:57] <kenvandine> pitti, i showed it off at desktop summit :)
[17:58] <rickspencer3> okay, so we have some Karmic targeted bugs, please be mindful of them if they are assigned to you
[17:58] <rickspencer3> next is discussion section
[17:58]  * rickspencer3 hands mic to pitti for empathy in alpha 3 discussion
[17:58] <kenvandine> pitti, papyon is in debian NEW still
[17:58] <kenvandine> and ted is still reviewing the indicator patch
[17:58] <pitti> right, so we are currently a bit blocked by a pymsn fork
[17:59] <pitti> I wondered whether we should wait until it's all resolved, to deliver the "full" experience
[17:59] <pitti> or temporarily drop the butterfly recommends, and get it into the dailes right now
[17:59] <pitti> and add butterfly (MSN) when it's ready
[17:59]  * kenvandine votes for shipping without
[17:59] <seb128> drop the recommends it works fine with haze
[17:59] <kenvandine> true
[17:59]  * rickspencer3 votes for shipping early and often
[17:59] <pitti> for CD size calculation, and general testing it would be nice to get it in ASAP
[18:00] <pitti> seb128: even better then
[18:00] <pitti> seb128: -haze is libpurple?
[18:00] <seb128> yes
[18:00] <seb128> you will get msn by libpurple
[18:00] <pitti> ok, seems pretty much unanimous?
[18:00] <seb128> which works fine
[18:00] <kenvandine> pitti, do you agree the empathy human theme belongs in ubuntu-artwork?
[18:00]  * rickspencer3 thinks kenvandine is obsessed with empathy human theme
[18:00] <kenvandine> i think that was kwwii's preference
[18:00] <rickspencer3> ;)
[18:00]  * kenvandine wants to deliver the experience :)
[18:01] <seb128> is empathy built with webkit now?
[18:01] <seb128> and without geolocation?
[18:01] <kenvandine> i don't think it is in karmic
[18:01] <pitti> apparently not?
[18:01] <seb128> should it?
[18:01]  * kenvandine thinks so, webkit that is
[18:01] <kenvandine> not geoloc
[18:01] <seb128> right
[18:02] <pitti> oh, it is built with webkit indeed
[18:02] <pitti> I keep forgetting that it's in main :)
[18:02] <rickspencer3> uh ... does building with webkit impact the accessibility?
[18:02]  * rickspencer3 assumes the answer is a simple "no"
[18:02] <kenvandine> so the adium support is much better in trunk... so 2.27.4 will be better
[18:03] <seb128> dunno but GNOME is actively discussing the topic
[18:03] <seb128> they revisit webkit by default for 2.28
[18:03] <kenvandine> rickspencer3, well, that is only chat itself
[18:03] <pitti> ok, so I'll re-add empathy to the seeds, and check how tomorrow's CD will break :)
[18:03] <kenvandine> not sure if a11y matter in that context
[18:03] <seb128> seems many issue have been fixed and they are trying to aim at having it for 2.28
[18:03] <kenvandine> i guess it does for screen readers, etc
[18:03] <kenvandine> good question
[18:04] <rickspencer3> could someone please confirm that building with webkit does not impact accessibility?
[18:04]  * kenvandine doesn't know much about a11y
[18:04] <seb128> best way to know is to upload and wait for bugs
[18:04] <rickspencer3> or to be clearer, that it is accessible if built with web kit
[18:04] <kenvandine> yeah
[18:04] <seb128> that would be a question for themuso rather
[18:05] <pitti> might be a question for TheMuso in the eastern edition?
[18:05] <rickspencer3> ok, I can buy that
[18:05] <rickspencer3> I'll mention it to TheMuso as well
[18:05] <kenvandine> thx
[18:05] <pitti> it is built with webkit already
[18:05] <kenvandine> great
[18:05] <rickspencer3> however, I think we should all be mindful of accessibility in all our deciscions
[18:05] <pitti> I wonder why, though, it doesn't look very HTMLish?
[18:05] <rickspencer3> it's a requirement, not a "nice to have"
[18:05] <kenvandine> it is far better with 2.27.4... i can't wait for it to be released :)
[18:05] <pitti> IOW, what does empathy use webkit for in the first place? just text markup?
[18:05] <kenvandine> pitti, it supports adium themes
[18:05] <seb128> rickspencer3, as said GNOME discuss webkit for 2.28 now
[18:05] <rickspencer3> I'm sure it's fine, I just hear "webkit" and think "inaccesible"
[18:06] <kenvandine> popular on other platforms
[18:06] <kenvandine> renders the chats nicer
[18:06] <seb128> I would tend to follow them they will not switch if it's not ready for accessibility too
[18:06] <rickspencer3> seb128: ack
[18:06] <rickspencer3> let's move on ...
[18:06] <rickspencer3> asac: bluetooth?
[18:06] <asac> so we are close to the point where we want to decide which bluetooth frontend to use for karmic
[18:06] <asac> and later
[18:07] <asac> gnome-bluetooth and blueman
[18:07] <asac> i got a bunch of user feedback and did upstream discussion
[18:07] <pitti> do we have a kind of feature comparison sheet?
[18:07] <asac> and will prepare the facts for next weeks
[18:07] <asac> for this week i would like to ask anyone to use both: gnome-bleutooth and blueman
[18:07] <asac> (if possible)
[18:07] <asac> so you have an opinion on your own
[18:07] <pitti> IIRC g-b was "lean and easy", and blueman "very functional, and advanced"? is that a valid coarse categorization?
[18:08] <asac> also please file bugs and push them to me so we can probe how responsive upstream is in general
[18:08] <seb128> gnome-bluetooth will be discussed this week for GNOME 2.28
[18:08]  * pitti can try file sync, but not much else, it's the only kind of device I have
[18:08] <asac> pitti: try them and decide if thats the categorization you would assign to them ;)
[18:08] <pitti> asac: roget
[18:08] <pitti> roger, too
[18:08] <asac> for me there is nothing easier in g-bt
[18:08] <asac> :)
[18:09] <seb128> has blueman a fixed schedule for new versions, good translations, etc?
[18:09]  * seb128 needs to get a bluetooth device to play with those
[18:09] <asac> they are not a GNOME project. but i guess they will cooperate
[18:09] <asac> but we can talk about the details next week
[18:10] <rickspencer3> ACTION: everyone try both bluetooth front ends, report experience to asac next team meeting
[18:10] <asac> thanks
[18:10] <rickspencer3> thanks asac
[18:10] <rickspencer3> that's everything on the agenda
[18:10] <rickspencer3> any other business?
[18:11] <rickspencer3> ok ... I think Karmic is really shaping up nicely
[18:11] <pitti> +1
[18:11] <rickspencer3> I'd like to throw some kudos to bryce for doing a great job with X and managing x bugs so far this release
[18:12] <rickspencer3> also, the kubuntu team is creating a kubuntu netbook version, this should be very cool
[18:12] <rickspencer3> meeting adjourned?
[18:12] <bryce> thanks
[18:12] <ArneGoetje> thanks
[18:12] <seb128> thanks everybody
[18:13]  * kenvandine is testing bluetooth... wishing the G1 supported file transfer
[18:13] <pitti> thanks everyone
[18:13] <awe> see ya
[18:13]  * seb128 goes back to celebrating the national holiday
[18:13]  * rickspencer3 taps gavel
[18:13] <rickspencer3> bye bye seb128
[18:13] <pitti> kenvandine: I'm using my old Nokia for that
[18:13] <asac> thanks seb128
[18:13] <pitti> kenvandine: OTOH, with "on air", and wifi, and direct SD cardr access, who needs BTW :)
[18:13] <pitti> BT, I mean
[18:13] <kenvandine> pitti, hehe... yeah... but for testing
[18:13] <pitti> aah, bazaar.lp.net is back
[18:13]  * pitti switches seeds
[18:13] <kenvandine> i really want to test bluetooth headset
[18:14] <chrisccoulson> obex is one thing i miss on the G1 too
[18:14] <kenvandine> i have a friend that tried jaunty and the only problem he hit was setting up his bluetooth headphones
[18:14] <kenvandine> so went back to mac for now
[18:17] <pitti> kenvandine: uploading empathy now, and ubuntu-meta
[18:18] <kenvandine> woot
[18:20] <pitti> kenvandine: hm, you saw the libgupnp-igd task in bug 388898? not sure whether we want/need that
[18:21] <kenvandine> pitti, yeah... not sure about that
[18:21]  * pitti -> dinner
[18:21] <kenvandine> i agree it might be nice
[18:21] <kenvandine> but not sure we should jump through hoops for it
[18:22] <bryce> whoa, ajaxy popups for setting status and importance in launchpad.  sweet!
[18:23]  * asac goes outside for a bit
[18:24] <bryce> hrm, unfortunately now the bug title ajaxy editing seems busted
[18:31] <chrisccoulson> seb128 - i worked on the gnome-session update last night. upstream have added a change to the gnome-wm script to launch gtk-window-decorator before compiz now
[18:31] <chrisccoulson> is that actually necessary?
[18:32] <chrisccoulson> the only reason i ask is because if i run gnome-wm without compoisting now, it crashes X when trying to start gtk-window-decorator
[18:41] <asac> awe: you think you might find to bump the connman trees today? i would really love to get them up ;)
[18:41] <awe> asac: yes, i'll do them when i get back from my voice lesson
[18:41] <asac> its just a changelog bump i would think
[18:42] <asac> ok thanks
[18:42] <awe> although actually maybe i can get 'em done before...
[18:42] <asac> (... and a quick test)
[18:42] <asac> even better :-P
[18:42] <awe> by the way, did i propose the correct branch for my scan now merge?
[18:51] <asac> awe: good question. at least i didnt get a mail ;)
[18:51] <asac> let me check
[18:52] <awe> doh
[18:52] <asac> awe: yeah. seems its right. though i would have hoped for trunk patch ;)
[18:52] <asac> (too)
[18:53] <asac> awe: [C. Scott Ananian <cscott@litl.com>]
[18:53] <awe> he's the author of the patch?  was i wrong to credit him like that in the changelog?
[18:53] <asac> you usually dont use that in the changelog if you take patches ... its used to mark who added the change to the branch
[18:53] <asac> like: you
[18:53] <asac> instead you use something like:
[18:53] <asac>  * patch by XXXX to fix YYYY
[18:54] <asac> awe: and we usually have no empty line after it
[18:54] <awe> ok
[18:54] <asac> awe: its ok. i can fix it while merging
[18:55] <awe> np
[18:55] <asac> awe: does the package build with that patch?
[18:56] <awe> so for the trunk patch, i need to branch trunk, and push a new topic branch based on that, correct?
[18:56] <asac> yes
[18:56] <awe> asac: yes, it builds
[18:56] <awe> ;)
[18:56] <asac> ok thanks
[18:56]  * awe deserve a slap if it doesn't
[18:57] <asac> awe: https://code.edge.launchpad.net/~network-manager/network-manager/ubuntu.head
[18:57] <asac> thats the trunk branch
[18:57] <awe> one last question... for connman, i'm doing the same thing... pushing a topic branch that's been updated & tested and proposing a merge with your branches, correct?
[18:58] <asac> awe: ack
[18:58] <asac> awe: i would think that for both branches picking the latest git sounds good. if the last commits appear to be intrusive, go for the tags
[18:58] <awe> ok
[18:59] <seb128> chrisccoulson, no idea but maybe mvo has an opinion
[19:05] <chrisccoulson> thanks seb128
[19:29] <mvo> chrisccoulson: hey, I'm back
[19:29] <mvo> chrisccoulson: gtk-window-decorator should not be needed, its started automatically by compiz
[19:30] <mvo> chrisccoulson: I have a pending update for gnome-control-center that ports it to use the new polkit-1 ubuntu-system-service - are you working on a update there or can/should I just upload?
[19:30] <mvo> chrisccoulson: its all in bzr already
[19:43] <djsiegel_> seb128: Hey Seb, which project does this affect? https://bugs.edge.launchpad.net/hundredpapercuts/+bug/395905
[19:44] <asac> bryce: whats the state on the (supposely newer) mesa pkg in edgers? is that something we should still test?
[19:45] <asac> (sorry if that was answered in meeting)
[19:50] <pitti> asac: AFAIUI, we should test edgers until alpha3
[19:54] <asac> cool
[19:58] <pitti> seb128: taking gnome-session sponsoring, ok with you?
[19:58] <pitti> (the xubuntu guys crave for that)
[20:19] <seb128> pitti, sure, I decided to not do uploads today since I'm not supposed to work ;-)
[20:19] <pitti> seb128: right, sorry; forgot
[20:19] <pitti> I do the g-c-c one now, then versions.html is again mushroom free
[20:20] <seb128> pitti, ok, g-c-c is to sponsor now? I didn't know that chrisccoulson managed to get it done
[20:20] <pitti> bug 393815
[20:20] <seb128> pitti, see mvo's comment one hour ago though, might need merging before upload
[20:20] <pitti> hm, that's two weeks old already
[20:21] <pitti> oh, there's no branch/patch on that one
[20:21] <seb128> pitti, right, opening bugs = claiming work
[20:21] <pitti> ah, stupid me
[20:21] <seb128> pitti, the sponsor team is not subscribed yet
[20:21] <pitti> so, versions.html de-mushroomified then
[20:21] <seb128> pitti, you rock!
[20:22] <seb128> djsiegel_, the ubuntu documentation, they provide the content of about ubuntu
[20:22] <djsiegel_> great, thanks, seb128
[20:22] <seb128> np
[20:23] <seb128> mvo, I would say upload your g-c-c changes, the new version is blocked on a new libgnomekbd using the new libxklavier
[20:26] <bryce> asac, it is a git snapshot heading towards the 7.6.0 release, which we do intend to pull in once it's available
[20:28] <pitti> mvo: can it be that you forgot to drop the libpolkit-gnome-dev b-dep? (otherwise that patching makes little sense)
[20:28] <bryce> asac, in theory it should be reasonably stable, I don't know of major problems with it.
[20:28] <asac> bryce: i am still hoping for compiz on my special R580 card ... could the radeon mesa crack ppa be something for me?
[20:28] <bryce> of course, mesa git can be hit and miss, so be aware of that when updating
[20:28] <pitti> oh jeez, g-c-c is using libhal-dev as well?
[20:29] <asac> hopefully not at runtime ;)
[20:29] <bryce> asac, indeed it could be; a lot of what's being staged and focused on in xorg-edgers is new -ati functionality
[20:29] <bryce> primarily we're focusing on the kms bits, but I would expect glx fixes to be included as well
[20:29] <asac> bryce: is that what brings opengl 2.1 hardware accell for my ati card :-P
[20:30]  * asac hopes to be able to play real games again ;) with ati
[20:30] <seb128> pitti, libhal is used only to build the non pulse capplet apparently which we said we would stop doing this cycle
[20:30] <pitti> seb128: any idea what g-c-c's 96_build_sound_capplet.patch is? upstream g-c-c dosen't use hal any more
[20:30] <pitti> aah
[20:30] <mvo> pitti: drop b-d in g-c-c ? thats quite possible :/
[20:30] <bryce> asac, did you file a bug report on the problem you're having?  I can do a quick follow up on it right now
[20:31] <seb128> pitti, feel free to drop the non pulse change now
[20:31] <pitti> seb128: it's not installed/used any more?
[20:31] <seb128> pitti, what? well we decided to not make pulse mandatory in jaunty
[20:31] <asac> bryce: which package should i file it against?
[20:31] <asac> directly in bugs.freedesktop?
[20:31] <bryce> asac, xserver-xorg-video-ati
[20:31] <pitti> seb128: right, I remember; I mean, the current one is the pulse one?
[20:31] <seb128> pitti, we also said at uds that karmic was the good cycle to follow upstream and make pulse a requirement
[20:32] <seb128> pitti, yes, current GNOME is pulse only
[20:32] <bryce> asac, I can take care of forwarding it upstream for you
[20:32] <pitti> seb128: I'd love to drop that patch (both for being intrusive and backporting upstream-removed stuff, and for dropping hal), I'm just not entirely sure what would break with it
[20:32] <seb128> pitti, the patch is to build the old codebase which uses gstreamer
[20:32] <pitti> seb128: yay
[20:32] <bryce> asac, do 'ubuntu-bug xserver-xorg-video-ati' and give me the bug ID and I'll forward it along from there
[20:32] <pitti> hooray for droppping 300 kB patches
[20:32] <seb128> pitti, it will force you to use pulse to have a working GNOME mixer
[20:32] <asac> bryce: what does that attach?
[20:32] <seb128> pitti, which is what upstream do since 2.26
[20:33] <bryce> asac, bunch of stuff... Xorg.0.log, xorg.conf, lspci -vvnn, dmesg, xdpyinfo, etc.
[20:33] <chrisccoulson> hey mvo, sorry, i went for dinner. i'll remove gtk-window-decorator from the gnome-wm script then
[20:33] <mvo> chrisccoulson: thanks, np
[20:33]  * seb128 looks at the g-c-c list of patch way too many there
[20:33] <pitti> mvo: so, seems I need to touch that package anyway; want me to drop that build dep for you, drop that other sttuff and then test/build/upload?
[20:34] <mvo> pitti: please do
[20:34] <seb128> mvo, next tarball will use gtkbuilder rather than glade I will make you update your glade changes ;-)
[20:34] <mvo> pitti: if you touch it anyway
[20:34] <asac> bryce: too bad. now i am on ppa it doesnt allow it to be submitted
[20:34] <asac> (not a genuine ubuntu package)
[20:34] <bryce> huh
[20:34] <bryce> bugger
[20:34] <chrisccoulson> seb128 / pitti - i'm still working on g-c-c. as you already pointed out, it's blocked on libgnomekbd though
[20:34]  * mvo goes on a *long* vacaton
[20:34] <seb128> mvo, nice try!
[20:34] <chrisccoulson> g-c-c is quite a bit of work with all them patches
[20:34] <bryce> well, file a bug manually and attach those things; I'll ask for anything beyond that which may prove useful
[20:34] <asac> bryce: doesnt that invalidate the whole purpose of that ppa ;)
[20:34] <pitti> chrisccoulson: right, was just confused
[20:34] <chrisccoulson> yeah, i'm a bit confused now ;)
[20:34] <pitti> mvo: sure, doing
[20:34] <asac> pitti: can i force ubnutu-bug?
[20:34] <bryce> asac, erm sorta yeah
[20:35] <pitti> asac: to do what?
[20:35] <asac> it says "not a genuiine ubuntu package"
[20:35] <mvo> pitti: thanks! I
[20:35] <asac> seems it says that because its from a ppa
[20:35] <chrisccoulson> so, there is a new upload porting it to polkit-1 now is there?
[20:35] <asac> let me check if i mistyped the name ;)
[20:36] <pitti> asac: hm, not that easily right now; edit /usr/share/pyshared/apport/ui.py and drop the check from thread_collect_info() (line 52 to 62)
[20:36] <asac> ok
[20:36] <pitti> seb128, mvo: oh, while I'm at it, I'll transition it to new libxklavier-dev
[20:37] <seb128> pitti, \o/
[20:38] <seb128> pitti, don't bother backporting changes though since we will update soon
[20:38] <pitti> seb128: I hope it will just work (-dev name change)
[20:38] <seb128> chrisccoulson, svu seems to not be around I would backport the libgnomekbd changes required
[20:38] <chrisccoulson> seb128 - no problem
[20:40] <chrisccoulson> seb128 - the patch will also force a SO version change too
[20:41] <seb128> chrisccoulson, do a git snapshot then
[20:41] <chrisccoulson> yeah, that might be best
[20:42] <pitti> seb128: and you, go watch a movie or have some ice cream or so :)
[20:42] <pitti> /kick seb128 holiday!!!
[20:42] <seb128> pitti, right, you should that too, it's over work hours in any case ;-)
[20:43] <seb128> we usually have fireworks today
[20:43] <pitti> heh, ok; right after bending g-c-c to my will
[20:43] <seb128> but it's rainy again today, neither is not too nice this year
[20:44] <chrisccoulson> heh, i come home from work and all you guys disappear ;)
[20:45]  * pitti watches chrisccoulson sing "♩ Stand by me! ♫"
[20:45] <chrisccoulson> lol
[20:45] <bryce> chrisccoulson, I'll keep ya company, I still got 5 hrs left in my day ;-)
[20:45] <chrisccoulson> thanks bryce:)
[20:45] <ccheney> bryce: who is the current amd video guy?
[20:45] <ccheney> bryce: er for ubuntu
[20:45] <bryce> ccheney, -fglrx or -ati?
[20:45] <asac> bryce: after some fighting i came up with bug 399451 ;)
[20:46] <ccheney> fgrlx
[20:46] <bryce> asac, thanks
[20:46] <asac> i tried to be funny in title ... didnt know what you wanted  there ;)
[20:46] <bryce> ccheney, depends on the issue... packaging problem, or driver bug?
[20:46] <ccheney> bryce: i guess both
[20:46] <ccheney> bryce: it came up in a discussion i am in
[20:46] <bryce> ccheney, for fglrx packaging issues, superm1 would be the guru to talk to
[20:46] <ccheney> it was mentioned superm1 used to be but may not be anymore
[20:47] <ccheney> ok
[20:47] <bryce> for definite bugs, I have other contacts
[20:47] <ccheney> ok
[20:48] <bryce> asac, thanks this looks good
[20:48] <ccheney> bryce: oh btw are than any xorg plans to support multiple video devices switching like in the new intel cpus or eg thinkpads?
[20:48] <bryce> ccheney, yeah some of that is starting to filter in
[20:48] <ccheney> bryce: ok
[20:48] <chrisccoulson> seb128 - just looking at the gnome-wm script. it seems overly complicated ;)
[20:48]  * ccheney imagines nvidia will be a problem for that situation
[20:49] <chrisccoulson> i notice it sets the gconf key /desktop/gnome/applications/window_manager/current with the WM that it loads
[20:49] <bryce> so far it's mostly been fixing issues so at least those configs don't break horribly.  Actual real support is still wip-ish I think
[20:49] <seb128> chrisccoulson, it's there to work with any wm basically
[20:49] <chrisccoulson> but the value of that key doesn't seem to be used anywhere
[20:50] <bryce> asac, could you try one more thing real quick?  Try mv /etc/X11/xorg.conf /etc/X11/xorg.conf.orig and restart X, and post the Xorg.0.log from that
[20:50] <bryce> asac, reason being is I notice you have AIGLX turned off, which affects mesa
[20:51] <bryce> asac, these days you can largely run -ati with no xorg.conf and stuff should just work.  xorg.conf is needed really only for working around problems now
[20:54] <pitti> seb128: meh, indeed, xklavier 4.0 doesn't work; reverting to 12
[20:56] <chrisccoulson> what's not working?
[20:56] <pitti> building our current g-c-c with libxklavier 4.0; needs newer upstream release
[20:56] <chrisccoulson> ah, ok
[20:56] <pitti> but that'll fix itself over time, no need to waste time on backporting (patch alone doesn't work)
[20:56] <seb128> we are blocking on chrisccoulson to get the update done
[20:57] <chrisccoulson> yeah, it might be worth just merging the changes in to the update i'm doing
[20:57] <chrisccoulson> then i'll update libgnomekbd
[20:57] <chrisccoulson> and do it all in one go ;)
[20:57] <seb128> good
[20:57] <chrisccoulson> btw, i just pushed another gnome-session change to not run gtk-window-decorator from gnome-wm. it causes X to crash here ;)
[20:58] <seb128> X crashing is an xorg bug
[20:58] <seb128> whatever the decorator is doing X should not crash
[20:58] <chrisccoulson> yeah, thats true. but i commented on the changelog - running gtk-window-decorator direclty bypasses the sanity checks that compiz normally does before deciding if it can run or not
[20:58] <chrisccoulson> eg, checking for blacklisted hardware
[21:08] <chrisccoulson> mvo - your g-c-c work only ports the existing ubuntu changes to polkit-1 right?
[21:08] <mvo> chrisccoulson: yes
[21:08] <chrisccoulson> cool
[21:08] <chrisccoulson> thanks;)
[21:08] <mvo> chrisccoulson: the remaining bits are "just" gconf-defaults, right?
[21:09] <chrisccoulson> mvo - yeah, i think so. fedora has a patch for the remaining bits, but it's based against 2.26.0
[21:09] <mvo> nice
[21:09] <chrisccoulson> i'll try and get that in to this release as well, otherwise it will be a bit of a mess;)
[21:20] <pitti> chrisccoulson: so, g-c-c is de-PKified now
[21:20] <pitti> oh, oops
[21:20] <chrisccoulson> not quite ;)
[21:20] <pitti> chrisccoulson: right, I'll let you do the remaining bits then
[21:20] <asac> bryce: ok checking
[21:21] <chrisccoulson> thanks. i'll hopefully get that finished tonight as long as i can get it to build with relative ease;)
[21:21] <pitti> well, *shrug*, it's karmic
[21:21] <chrisccoulson> all the patches apply now, so thats a start;)
[21:23] <asac> bryce: not sure if it changed anything. i saw that i still have .failsafe files lying around
[21:23] <asac> could those be a problem too?
[21:24] <bryce> not likely
[21:24] <bryce> they can be safely deleted though
[21:24] <asac> ok just to be sure, let me remove them
[21:25] <asac> bryce: ok restarted even without failsafe. now i should attach xorg 0 log?
[21:25] <bryce> asac, yep
[21:25] <bryce> asac, also re-try starting compiz with this non-xorg.conf config, and post the output from that as I *think* it will be different
[21:26] <asac> it is different. yeah
[21:26] <asac> getting that now
[21:27] <pitti> good night everyone!
[21:28] <asac> bryce: added info
[21:28] <asac> pitti: 'night
[21:29] <bryce> asac, excellent thanks
[21:29] <asac> Checking for Xgl: not present.
[21:29] <asac> /usr/bin/compiz.real (core) - Error: Could not acquire compositing manager selection on screen 0 display ":0.0"
[21:29] <asac> /usr/bin/compiz.real (core) - Fatal: No manageable screens found on display :0.0
[21:29] <asac> that sounds bad ;)
[21:29] <bryce> yeah
[21:30] <chrisccoulson> i never realised gnome-appearance-properties had the ability to set the default system theme
[21:30] <bryce> but now sounds like a solid bug we can send upstream :-)
[21:30] <asac> what is that weird output at the end ;)?
[21:30] <chrisccoulson> i've never seen the button for that in ubuntu
[21:30] <asac> ok
[21:30] <asac> thanks
[21:32] <asac> bryce: but i see a regression now for my games. previously i could start them, they were just sooooo slow that you couldnt even move the mouse
[21:32] <asac> now they fail
[21:32] <bryce> asac, well my wild guess at this point is that -ati is not implementing some compositing primitive yet on R580, and it's buggering up compiz.  I know some of the 5xx 3d support is still WIPish.
[21:32] <asac> bryce: do you know what those "Slow" things mean in glxinfo ?
[21:32] <bryce> asac, yeah that's because in the former case you were using software rendering, whereas now with this config it's trying to use hardware accelerated 3d, but something's busted
[21:33] <asac> bryce: the slow was there too
[21:33] <asac> before
[21:33] <bryce> asac, no, I should find out though
[21:33] <asac>    visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
[21:33] <asac>  id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
[21:33] <asac> ----------------------------------------------------------------------
[21:33] <asac> 0x62  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
[21:33] <asac> 0x63  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
[21:33] <asac> caveat Slow .... I agree ;)
[21:34]  * chrisccoulson must remember to bzr add new files before running bzr bd-do
[21:35] <asac> chrisccoulson: yeah. and you cannot bzr rm files without committing ;)
[21:35] <asac> that busts everything  - at least for me
[21:35] <chrisccoulson> i thought you had to bzr rm files before committing?
[21:36] <bryce> asac, fwiw, my system also shows similar info - None/Slow/None/Slow
[21:36] <bryce> asac, I'll find out what that means
[21:37] <asac> someone said to me it really means that you dont get good performance ;)
[21:37] <asac> but that might just be false perception ;)
[21:37] <asac> thanks!
[21:37] <asac> let meknow
[21:39] <bryce> here we are - <agd5f> bryce: that it's likely not accelerated
[21:40] <chrisccoulson> pitti - some of this fedora patch must apply to a patch that was already fedora specific i think
[21:41] <chrisccoulson> i didn't think our gnome-appearance-properties capplet has support for setting system theme :-/
[21:41] <chrisccoulson> it would be nice to have that though - it would mean people could set their GDM theme
[21:41] <asac> http://people.ubuntu.com/~asac/tmp/Screenshot-Metacity.png
[21:41] <asac> anyone else sees that stuff all the time when logging in?
[21:41] <chrisccoulson> asac - yeah
[21:41] <asac> it starte with new gdm for me
[21:41] <chrisccoulson> my next task is to remove that dialog from metacity;)
[21:41] <asac> i thought it was too obvious to not go away automatically ;)
[21:42] <asac> ah good. so its worked on.
[21:42] <asac> i was just not patient enough ;)
[21:42] <chrisccoulson> the underlying issue is that the greeter doesn't tell the WM it's client ID, which means metacity cant save it's position
[21:42] <chrisccoulson> its not important enough to bug users about though, and will appear for any application that doesn't support session saving
[21:43] <chrisccoulson> so, i'm going to remove the dialog and convert it to a g_warning or somethingh
[21:43] <chrisccoulson> but GDM should still be fixed too;)
[21:46] <asac> chrisccoulson: is the gdm bug filed upstream?
[21:46] <asac> if its going to be fixed i dont mind keeping it ;)
[21:46] <chrisccoulson> the GDM bug is on LP somewhere, but i'm not sure if it is upstream
[21:46] <asac> i just dont want to see that still in beta or something ;)
[21:47] <chrisccoulson> the fact that GDM doesn't play nice is a non-issue really, as there's not really any state for the WM to save in the greeter
[21:47] <chrisccoulson> but the dialog should dissappear regardless
[21:47] <chrisccoulson> you will get the dialog for anything that doesn;t connect to the session manager, eg xterm
[21:47] <chrisccoulson> it's really annoying ;)
[21:49] <bryce> asac, https://bugs.freedesktop.org/show_bug.cgi?id=22769
[21:51] <asac> bryce: will you ping me if they need something or want me to test something?
[21:51] <asac> i have problems with my bugzilla bugmail
[21:51] <bryce> asac, sure I'll try to remember
[21:51] <asac> meaning: i probably wont see what is coming ;)
[21:51] <asac> even if subscribed ;)
[21:51] <bryce> usually I just have people sub to the upstream bug
[21:51] <bryce> weird
[21:51] <asac> well. thats because i havent found time to fix my filters
[21:52] <walters> asac: if the radeon drivers you're using aren't DRI2 there can only be one accelerated client at a time
[21:52] <asac> and i get too many bugs from bugzilla
[21:52] <walters> asac: so if you're running compiz, any GL using app will be indirect
[21:52] <asac> not that the situation is new ;)
[21:52] <bryce> walters, I don't think that's the problem here
[21:52] <asac> walters: hmm. how can i find out which app occupies the slot?
[21:53] <asac> i dont have anything accellerated running here atm i think
[21:53] <bryce> asac, as long as you're running only one xserver instance the 2nd accelerated client issue doesn't apply
[21:54] <asac> bryce: ok. even if i run a 3d app somewhere?
[21:54]  * asac notices that this doesnt make much sense ;)
[21:54] <bryce> as long as it runs from your primary X session it should work
[21:54] <asac> i only have one monitor and one x session afaik
[21:55] <bryce> if you did a guest login or set up a second X session on one of the other vts or was doing something with virtualization, then it'd matter
[21:55] <bryce> yeah that's what I thought.  that configuration should work properly
[22:11] <superm1> ccheney, if you've got packaging bugs for fglrx point me at them, if they are driver bugs, bryce has other contacts
[22:12] <ccheney> superm1: ok
[22:17] <asac> bryce: hero man ;)
[22:20] <bryce> asac, :-)
[22:20] <bryce> asac, so is compiz working ok now?  3d games?
[22:20] <asac> 3d games i doubt ... let me check
[22:21] <asac> at least edgers broke them more than before
[22:21] <asac> compiz is great ;)
[22:22] <asac> http://paste.ubuntu.com/218319/
[22:22] <asac> thats what i get now
[22:22] <asac> previously it started and it was just way slow
[22:22] <asac> ERROR: couldn't create font (glGenLists)
[22:22] <asac> let me check if openarena works at least still
[22:22] <bryce> asac, ok well at least one problem solved so far :-)
[22:22] <asac> (that one worked good before)
[22:23] <bryce> what is that pastebin output from?  Compiz or a game?
[22:24] <asac> bryce: thats what i get for enemy territory - wolfenstein (pretty old on win it has pentium with 600Mhz minimum requirement) ... think its quake 3 engine
[22:30] <bryce> asac, ok
[22:30] <asac> let me check a few more ;)
[22:30] <bryce> asac, those kinds of errors often indicate API/ABI incompatibilities with the X server
[22:31] <bryce> maybe the game just needs a rebuild against the newer xserver/kernel?
[22:31] <asac> bryce: well. i am quite sure this didnt happen before edgers upgrade ;)
[22:32] <asac> which i did today (psst)
[22:32] <asac> unreal2004 actually runs
[22:32] <asac> its just flickering all the time
[22:32] <asac> like there is no vsync
[22:32] <fta> grr, another crash of evolution today, the 1st was when i was idle (so no action from me), the last when asking the spell checker to fix a word :(
[22:35] <asac> bryce: any idea if i can do something in X settings about vsync?
[22:35] <bryce> asac, hmm
[22:36] <bryce> is it just in the one game?
[22:36] <bryce> are you running it full screen or windowed?
[22:37] <asac> bryce: first full screen, then windowed (so i could chat here)
[22:37] <asac> i changed the option in UT2004.ini to UseVSync=True ... but that didnt have any impact
[22:37] <asac> so i guess its a driver thing
[22:37] <asac> too bad. the mouse and all was quite usable ;)
[22:38] <asac> but all the quake and enemy territory stuff doesnt start anymore ... though it did before. not sure how to best downgrade now to non edgers to verify
[22:39] <asac> oh forums say the flickering might be because compiz is enabled
[22:39]  * asac checks
[22:40] <bryce> yeah I'd probably still shut off compiz when playing games.  It *should* work, but that's a combination that kind of pushes the tech quite a bit ;-)
[22:42] <bryce> asac, for downgrading, I typically comment out the xorg-edgers stuff in apt, then force installation of the specific karmic version of the driver and xserver, and typically everything else gets downgraded properly
[22:42] <bryce> hmm, we probably need a documented method for doing this
[22:47] <asac> bryce: heh. so i managed to start a game, but then mouse stopped working. but its promissing
[22:47] <asac> only problem is that now - even after relogging in - compiz is broken again ;)
[22:47] <asac> but i guess a reboot will do:)
[22:48] <asac> let me check the driver/xserver downgrade trick
[22:48] <asac> well. lets do that tomorrow ,)
[22:48] <asac> thanks a lot
[22:48] <asac> today is a good day ;)
[22:48] <bryce> \o/
[23:07] <asac> bryce: i noticed that the #radeon channel is pretty full of people.
[23:08] <asac> bryce: is that a pure community effort or are ati folks working on that driver too?
[23:11] <bryce> asac, mixture.  adg5f is amd, as is one other guy.  Most of the active people on the channel are redhatters
[23:20] <asac> heh ok. but still amd is in there thats good