[00:06] <RAOF> @pilot in
[00:39] <TheMuso> Are there any QT/KDE folks around who could point me to the QT 4.7 git repo? Thanks.
[00:39] <TheMuso> And not for Ubuntu, I've found the bzr branch for that.
[00:40] <TheMuso> nvm found it.
[04:16] <lucidfox> Any reason the gtkpod binaries have been staying in NEW for longer than usual?
[04:17] <TheMuso> lucidfox: Probably because nobody has got to them yet?
[04:17] <lucidfox> ahh
[04:39] <RAOF> @pilot off
[04:39] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[04:39] <RAOF> @pilot out
[04:42] <RAOF> Time to have lunch and make dinner!
[05:24] <LaserJock> does anybody know of a tool to create a manpage from python optparse code?
[05:27] <sladen> LaserJock: http://andialbrecht.wordpress.com/2009/03/17/creating-a-man-page-with-distutils-and-optparse/  was the first hit
[05:28] <LaserJock> thanks goog... I mean sladen
[05:33] <pitti> Good morning
[05:38] <LaserJock> pitti!!
[05:38] <LaserJock> just the man I was looking for
[05:40] <LaserJock> pitti: if I wanted to submit a patch to python-mkdebian in python-distutils-extras, what would be the best way of doing that?
[05:41] <pitti> LaserJock: I'm not fussed about the form; send a patch with some verbiage, a debdiff, a merge proposal, etc.
[05:41] <pitti> LaserJock: I'm more concerned about adding appropriate test cases than the patch format :)
[06:04] <pitti> LaserJock: got it, thanks
[06:05] <LaserJock> ok, great
[07:15] <didrocks> good morning
[07:44] <dholbach> good morning
[07:47] <jaromil> good morning
[08:22] <ohsix> man, what could stop job control? nothing in one terminal (or more) in this session will succeed running anything in the background with &, it just says "Stopped" next time i hit enter
[08:29] <akheron> ohsix: maybe some terminal attribute?
[08:29] <akheron> ohsix: try invoking reset
[08:30] <ohsix> if i use ^Z then bg it works, hm
[08:31] <ohsix> weird, a reset fixed it
[08:32] <ohsix> and it was only happening with a script i had in my home dir that just ran rdesktop with some switches
[08:32] <akheron> IIRC, processes reading stdin will get "Stopped" once they're backgrounded
[08:33] <akheron> cat &
[08:33] <akheron> [1]+  Stopped                 cat
[08:46] <alkisg> I'd like to file a bug report about "package linux-image-generic-lts-backport-natty missing in Lucid" - where do I file that? Under ubuntu-meta?
[08:49] <cjwatson> no - perhaps linux-meta, but I thought that was being taken care of anyway
[08:50] <alkisg> Ah, I don't have any info on this other than checking the archives - if it's being taken care of no need to file a bug, thanks
[08:50] <cjwatson> you could check with #ubuntu-kernel in case I'm wrong
[08:50] <alkisg> Thank you
[08:50] <cjwatson> I just saw some conversation go by about it a couple of weeks ago
[09:04] <pitti> hm, since yesterday the live fs fails to build due to "Failed to fetch bzip2:/var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_oneiric-security_main_binary-i386_Packages" -- new apt?
[09:04] <pitti> mvo: ^ might coindice with 0.8.14.1ubuntu4, which was uploaded yesterday
[09:05] <mvo> pitti: yeah, that sounds like it, let me check the build log
[09:05] <pitti> mvo: does it try to apply checks to local files which it means to apply only to http:// files or so?
[09:05] <mvo> pitti: it shouldn't, its mostly sanity checking that the release file/package file is correct
[09:05] <pitti> mvo: http://paste.ubuntu.com/615218/
[09:05] <pitti> mvo: not very verbose, I'm afraid
[09:06] <pitti> it does seem to work quite fine locally, though
[09:06] <pitti> mvo: does it unpack the file before the sanity checks?
[09:08] <mvo> pitti: it should, let me double check and also check why the error is not more verbose, its supposed to have  proper error strings. what is the best way to reproduce? is the sources.list public?
[09:09] <pitti> hmm, good question
[09:09] <pitti> setting up cdimage is not exactly trivial
[09:20] <pitti> mvo: fortunately we don't have an alpha-1 to do on Thursday, so it doesn't matter much
[09:20] <pitti> oh, wait :)
[09:21] <pitti> mvo: still puzzled how to reproduce this :/ but I don't think there's any magic in the sources.list, it's by and large just a debootstrap, add standard oneiric sources, update, and then install the desktop task
[09:21] <pitti> well, there's obviously a lot of magic after that
[09:21] <pitti> mvo: let me try building a chroot here and setting up apt there
[09:23] <cjwatson> setting up cdimage is non-trivial, but running livecd-rootfs is not hard
[09:24] <cjwatson> take oneiric system, install livecd-rootfs, change to a scratch directory, run 'livecd.sh -doneiric -ai386 ubuntu'
[09:24] <cjwatson> as root
[09:25] <pitti> ah, there's the sources list
[09:25] <mvo> cjwatson: thanks
[09:27] <pitti> hah
[09:27] <pitti> W: Failed to fetch bzip2:/var/lib/apt/lists/partial/de.archive.ubuntu.com_ubuntu_dists_oneiric-security_main_binary-amd64_Packages
[09:28] <mvo> pitti: with the method that colin outlined?
[09:28] <pitti> mvo: it seems to happen with oneiric-security or oneiric-updates
[09:28] <pitti> as these have empty package files
[09:28] <pitti> mvo: no, in a normal install
[09:28] <pitti> I also tried in a fresh chroot, same issue
[09:28] <pitti> mvo: I think it doesn't consider an empty file as valid
[09:28] <pitti> +deb http://archive.ubuntu.com/ubuntu/ oneiric-security main
[09:28] <pitti> I merely added this, and then apt-get update
[09:29] <pitti> this should make an easy test case in apt's test suite?
[09:32] <mvo> pitti: nice catch, I fix this now \o/
[09:33] <pitti> thanks mvo!
[09:42] <mvo> the fix is ready, uploading now
[09:43] <pitti> mvo: you rock, thanks!
[09:44] <mvo> thank you for the debugging :)
[09:50] <sleon> hi
[09:50] <sleon> which printing subsystem library does ubuntu use to conenct gnome applications to cups?
[09:50] <sleon> is it gutenprint_
[09:50] <sleon> or something?
[09:51] <sleon> or do you communicate other dbus or something?
[09:53] <hrw> can someone take a look at my gcc-4.6-armel-cross 1.48 package? It is same as gcc-4.5-armel-cross (already in archive) and builds gcc-4.6 cross compiler. It is NEW package which I maintain for Ubuntu. Once uploaded I will ask for PPU for it (got it granted during DMB meeting).
[09:53] <hrw> package is at http://home.haerwu.biz/~hrw/ubuntu/
[09:57] <pitti> mvo: hm, did your apt upload fail for some reason? (just to avoid misunderstandings)
[10:01] <pitti> mvo: ah, there now, nevermind
[10:01] <mvo> pitti: let me see, I did not see a error from dput
[10:01] <mvo> aha, ok
[10:01] <mvo> yeah, just got the mail
[10:19] <cjwatson> could an MIR team member look at bug 790547 as soon as possible, please?  ubiquity 2.7.0 is blocked on it
[10:22] <doko> looking
[10:22] <cjwatson> thanks
[10:25] <doko> 40000 lines of packaging for 49 lines of code. interesting ratio
[10:26] <soren> O_o
[10:27] <cjwatson> oh, by packaging you're counting autotools, right
[10:28] <cjwatson> I think you should count xklavier.defs and xklavier.override as code too, though
[10:28] <doko> agreed
[10:28] <doko> ev: what's the python3 status of python-xklavier?
[10:30] <ev> doko: looks like it's fairly quiet upstream, and would need to be ported to python3 (which I'm happy to do as part of the ubiquity port): http://devel.randomink.org/projects/python-xklavier/repository
[10:36] <doko> ev: hmm, the package currently ftbfs
[10:36] <doko> https://launchpad.net/ubuntu/+source/python-xklavier/0.4-2
[10:36] <ev> lovely
[10:36] <ev> I'll have a look in a bit
[10:37] <seb128> ev: there was a cdbs issue that looked similar to that iirc, maybe just retry the build, it has been fixed since
[10:38] <ev> seb128: will do, thanks for the heads up
[10:38] <seb128> yw
[10:46] <pitti> seb128: http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html still has some uninstallables for gnome-python-desktop, I look into this
[10:46] <ev> seb128, doko: yep, that did the trick.
[10:47] <seb128> ev: great
[10:47] <seb128> pitti, thanks
[10:49] <doko> ok, will wait until it's in the archive
[10:50] <pitti> seb128: ah, it's due to libbrasero-media1 being uninstallable
[10:50] <seb128> pitti, it's a NBS lib
[10:50] <seb128> pitti, we should probably drop those bindings, are they used?
[10:50] <pitti> so, working on that then
[10:50] <pitti> seb128: one rdepends (pybackpack)
[10:50] <seb128> pitti, the new lib uses GTK3 so that will require porting
[10:52] <pitti> seb128: right, so no python-brasero then; I guess we drop it then and break pybackpack
[10:53] <seb128> pitti, we will need to break quite some things this cycle imho
[10:53] <seb128> pitti, I will write an email to the lists in a bit about that
[10:53] <seb128> i.e all the transitions going on for gtk3, dconf, gnome-panel-applets on dbus
[10:53] <seb128> g-i
[10:54] <seb128> pitti, we can't really port the world so we should just take it as an opportunity to clean some old unmaintained things are the end of the cycle
[10:54] <pitti> *nod*
[10:55] <pitti> brasero doesn't yet build a .gir, though
[10:55] <pitti> or at least we don't package it
[10:55] <chrisccoulson> talking of cleaning old and unmaintained stuff, i'll probably have some package removals for you this week pitti
[10:55] <pitti> chrisccoulson: bring'em on
[10:55] <chrisccoulson> so make sure your axe is nice and sharp ;)
[10:57] <seb128> chrisccoulson, oh, you want to play who can clean the highest number of cruft this cycle? ;-)
[10:57] <seb128> bring them on! ;-)
[10:58] <seb128> pitti, brasero> it's just a matter of turning it on it seems, I will have a look to it
[10:58] <pitti> ah, nice; we can do that in Debian, too, I figure
[10:59] <seb128> pitti, debian turned it off to not tangle 2 transitions when they uploaded the new version
[10:59] <pitti> hm, it's just a binNEW package?
[10:59] <seb128> pitti, it's an extra stack to migrate to testing at the same time
[10:59] <seb128> but yeah they could probably turn it on in experimental
[10:59] <seb128> "  * Disable introspection support to avoid blocking the totem
[10:59] <seb128>     transition.
[10:59] <seb128> "
[10:59] <seb128> in the changelog
[11:00] <pitti> ah
[11:00] <pitti> not that easy to get gnome-python-desktop build in the first place
[11:05] <seb128> pitti, we should start dropping the bindings that don't have rdepends or a few if needed
[11:05] <pitti> yeah, got it
[11:05] <pitti> I need to drop python-evince
[11:05] <pitti> will also get rid of two more NBS
[11:06] <pitti> sugar-read-activity is the only rdepends, but tomeu said it's being ported upstream
[11:06] <seb128> ok great
[11:10] <pitti> hah, built
[11:11] <pitti> rhythmbox-plugin-cdrecorder just needs a rebuild on amd64, doing that
[11:12] <seb128> pitti, you are sure?
[11:12] <ev> so before I go ahead and start porting ubiquity to gtk3 as I port it to pygi, are we definitely going to have a gtk3 theme this cycle?
[11:12] <doko> pitti, seb128 : rhytmbox faild to build on amd64
[11:12] <seb128> pitti, it seems like it ftbfs due to the new libdmapsharing version
[11:12] <pitti> ah
[11:12] <seb128> not sure a rebuild will work
[11:13] <pitti> just have spotted it on nbs.html, haven't checked details yet
[11:13] <seb128> pitti, we might need http://git.gnome.org/browse/rhythmbox/commit/?id=8ab9e5d08fd0bdfae25de00c225308d575736d50
[11:13] <seb128> well http://git.gnome.org/browse/rhythmbox/log/?qt=grep&q=libdmapsharing
[11:13] <seb128> some of those
[11:13] <seb128> we got 2.9.12
[11:15] <pitti> will have a look after lunch then
[11:15] <seb128> pitti, we have a git snapshot so it's likely just the 2 most recent commits from the previous url to backport
[11:15] <pitti> *nod*
[11:31] <seb128> hum, why is gnome-panel, alacarte etc still on the CD?
[11:31] <seb128> or at least on http://cdimage.ubuntu.com/daily/20110531/oneiric-alternate-amd64.list
[11:31] <seb128> they have been dropped from the desktop seed (http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.oneiric/desktop) and I can't see a rdepends or something that would bring those back in
[11:37] <didrocks> the gnome-session present is the right one, weird…
[11:38] <didrocks> apt-get remove wants to remove indicator-applet*, let's see if we recommend one by error
[11:38] <didrocks> indicator-applet-session is recommended by indicator-me
[11:39] <didrocks> which brings indicator-applet-session, which dep on gnome-panel
[11:40] <cjwatson> shown in http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/rdepends/ALL/gnome-panel
[11:40] <didrocks> hum, no there is an alternative: | indicator-render, nevermind
[11:40] <cjwatson> if you want indicator-render to be preferred, it needs to be the first alternative
[11:41] <didrocks> ah, g-c-c then
[11:41] <cjwatson> germinate (and, for that matter, apt) will normally pick the first one
[11:41] <didrocks> cjwatson: right, and we are not sure unity/unity-2d is already there
[11:41] <didrocks> making the change
[11:41] <cjwatson> but I see that indicator-render is virtual anyway ...
[11:42] <didrocks> cjwatson: yeah, it's provided by unity/unity-2d
[11:42] <didrocks> so, that won't fix it…
[11:42] <cjwatson> unity provides indicator-renderer, not indicator-render
[11:42] <cjwatson> if the former is meant, you have a typo
[11:43] <didrocks> yeah, seems that the indicator part doesn't use the right term for a few release
[11:45] <seb128> didrocks, what needs fixing?
[11:45] <didrocks> cjwatson: but that won't fix it, as if indicator-me is processed before unity/unity-2d, it will pick indicator-applet-session? or all seeded are first processed before checking the dep?
[11:46] <didrocks> seb128: indicator-me recommends indicator-applet-session | indicator-render. Should be renderer at least
[11:46] <seb128> didrocks, do you want me to fix it?
[11:47] <seb128> let's make it unity | indicator-renderer
[11:47] <cjwatson> didrocks: "seeded" -> you're thinking purely in terms of what germinate will do, which is almost always a mistake.  germinate is largely just trying to mirror what apt will do
[11:47] <cjwatson> seb128: agreed
[11:47] <didrocks> cjwatson: ok, so yeah, we need to provide unity again in the recommends:
[11:48] <didrocks> seb128: yeah, looks good
[11:48] <seb128> didrocks, ok, doing that
[11:48] <seb128> didrocks, cjwatson: thanks
[11:48] <didrocks> thanks seb128, cjwatson :)
[11:48] <didrocks> seb128: I didn't check other indicator, it would maybe nice to check all of them?
[11:48] <seb128> didrocks, I will do
[11:48] <cjwatson> as it happens, germinate does process all explicitly-seeded entries before trying to resolve broken dependencies; but it's still better to list the correct preferred alternative first rather than relying on that
[11:49] <didrocks> seb128: indicator-messages should be changed at least
[11:50] <didrocks> cjwatson: ok, so to sum up, with the typo fixed, it should be fine, but better to list the preferred alternative first still
[11:51] <cjwatson> I think so, yeah
[11:51] <didrocks> thanks cjwatson for the explanation :)
[12:01] <apachelogger> who would be best to talk to about libcanberra?
[12:11] <pitti> apachelogger: TheMuso I think
[12:12] <apachelogger> thx
[12:12] <apachelogger> TheMuso: pingy
[12:17] <TheMuso> apachelogger: Please just ask, and I'll get to it when I am around. I am now, but am about to go to bed.
[12:19] <apachelogger> TheMuso: Does bug 790608 sound sane to you? Also, we perhaps shoud have a virtual package libcanberra-plugin or similar that is provided by libcanberra-pulse and libcanberra-gstreamer.
[12:19] <apachelogger> We use a similar virtual package approach for Phonon, which enables users to switch output plugins as they like without us having to depend on all available plugins.
[12:20] <apachelogger> Rumor has it that someone wants to create a Phonon plugin for Canberra.
[13:29] <fta2> mdeslaur, yt?
[13:30] <fta2> mdeslaur, you updated pam in maverick, it totally killed cron
[13:32] <mdeslaur> fta2: yes, I'm working on it now...bug #790538
[13:33] <fta2> mdeslaur, oh, great. thanks.
[13:33] <fta2> mdeslaur, i'm reverting for now.
[13:34] <mdeslaur> fta2: you can just restart cron
[13:34] <mdeslaur> fta2: until a fix is pushed out
[13:34] <fta2> mdeslaur, oh, ok. I'll try
[13:39] <fta2> good, it worked
[13:40] <lool> I got dropped into an initramfs prompt on reboot (hadn't rebooted in some days); is this is a known issue?
[13:41] <lool> (I switched to an older kernel to complete boot, I don't mind investigating if it's not a known bug)
[13:52] <cjwatson> fta2: https://wiki.ubuntu.com/IncidentReports/2011-05-31-pam-security-update-breaks-cron
[14:00] <fta2> cjwatson, thanks. fortunately, i blocked it after it killed a service on the 1st server i updated
[14:06] <jibel> lool, same here, I'm investigating
[14:07] <smb> pitti, Hi Martin, have you been doing the recent copy to updates for the linux package in lucid?
[14:07] <pitti> smb: hey; yes, as it got QA signoff and QA set it to v-done
[14:07] <pitti> something wrong with it?
[14:08] <smb> pitti, Nothing with that, though... smoser was wondering why the linux-ec2 package is lagging
[14:08] <pitti> smb: that one didn't get QA signoff yet
[14:09] <pitti> oh, it did
[14:09] <pitti> smb: ok, publishing that, too
[14:09] <smoser> pitti, smb thanks.
[14:09] <smb> pitti, Thanks... thought it had in Lucid but getting confused with many directions/releases lately
[14:11] <jibel> lool, amd64 or i386 ?
[14:12] <smoser> pitti, smb there will be a linux-ec2-meta update for that also ?
[14:12] <pitti> smoser: yes, that comes as a bundle
[14:13] <smoser> linux-meta-ec2.  ok. .. so -proposed https://launchpad.net/ubuntu/+source/linux-meta-ec2 has had 2.6.32.316.17  for 5 weeks, but the linux-ec2 has only been for 13 days in -proposed
[14:13] <smoser> smb pushed something in 13 days ago to linux-ec2, would that require a linux-meta-ec2 update ?
[14:14] <smb> smoser, Only if the abi number changed and I think that did not
[14:14] <pitti> kees, jdstrand: published linux-ec2 linux-meta-ec2 to lucid-{updates,security}, on top of the main linux/-meta stuff from yesterday
[14:14] <pitti> smb, smoser ^
[14:18] <smoser> pitti, smb, thank you again.
[14:29] <lool> jibel: amd64
[14:29] <jibel> lool, thanks. you can try downgrading udev to 170
[14:50] <dholbach> thanks ev - I'll try it out
[14:50] <dholbach> do you know if somebody is looking into fixing the issue?
[14:50] <ev> sure thing
[14:50] <ev> yeah, pitti is
[14:50] <dholbach> awesome
[14:51] <pitti> I need to reproduce it first
[14:51] <pitti> seems that everyone's boot fails except mine :/
[14:51] <pitti> 1:20 minutes left for alternate download
[14:51] <pitti> (was said to be reproducible in kvm)
[14:51] <dholbach> I upgraded a natty vm to oneiric (very early on), default desktop i386 install
[14:52] <dholbach> since I rebooted with 171 I run into the issue
[14:52] <pitti> dholbach: ah, this is kvm, not your real system?
[14:52] <pitti> lool: what about your's?
[14:52] <dholbach> kvm, yes
[14:57] <evfool> what is the criteria to propose an application to be ported to PyGI for oneiric? I see the GTK/GNOME3 blueprint has a long list of those
[14:58] <pitti> evfool: "everything we can get"
[14:58] <pitti> evfool: i. e. all rdepends of python-gtk2 are welcome
[14:59] <pitti> (and have to be ported at some point)
[14:59] <StevenK> pitti: How many of those are on the CD?
[14:59] <StevenK> (Roughly)
[14:59] <pitti> hmm, some 15 perhaps?
[14:59] <pitti> we have already ported 6 or 7 during natty
[15:00] <pitti> and usb-creator in oneiric
[15:00] <pitti> gnome-about is gone
[15:00] <evfool> just asking because Update-Manager isn't listed at all
[15:00] <pitti> so perhaps it's a lot less these days
[15:00] <pitti> evfool: oh, that's a good target indeed, and shouldn't be too hard to port
[15:01] <evfool> pitti: I've tried to do that, it runs, but the interface is not displayed at all... so maybe someone with a bit more experience should try to do that :)
[15:01] <evfool> and no error message is displayed
[15:02] <pitti> evfool: perhaps you can add a link your branch to the whiteboard, with a status note?
[15:02] <pitti> I can't look at it right now, sorry
[15:02] <pitti> but I'm interested in general
[15:02] <evfool> ok, I'll do that later than
[15:03] <evfool> so it's OK to list update-manager in the blueprint :)
[15:03] <pitti> absolutely, yes
[15:06] <pitti> FWIW, I get a boot failure in kvm with merely upgrading the kernel and initramfs and grub, leaving udev at 167
[15:06] <pitti> (alternate install still running; kvm doesn't like my virtio drive any more, so taking even longer than it used to, sorry)
[15:09] <mvo> pitti, evfool: bear in mind that for u-m the "release-upgrader" part will need to stay gtk2 for a bit because we need to support lucid->P upgrades
[15:09] <pitti> mvo: oh, I thought it would download u-m from the target release
[15:09] <pitti> mvo: i. e. lucid's u-m must be able to upgrade to P?
[15:10] <mvo> pitti: indeed, but if the oneiric version is gtk3 but lucid has no gtk3 instaled lucid->P will not work
[15:10] <mvo> pitti: the release-upgrader part of it need to work on lucid
[15:10] <jibel> pitti, I can reproduce on real hardware as well (and now I need to recover :( )
[15:10] <pitti> jibel: just exiting from the busybox shell doesn't work?
[15:11] <pitti> mvo: i. e. it doesn't fetch new dependencies?
[15:11] <jibel> pitti, I dont know, the keyboard doesn't respond :)
[15:12] <mvo> pitti: we would have to backport them to lucid. its possible to make this work, but it will be more fragile. one of the principles is to chnages the system as little as possible before the final "upgrade now" button is hit.
[15:13] <pitti> mvo: right, understandable
[15:13] <mvo> pitti: if we would fetch P version of gtk etc then half the system would be upgraded already before the upgrader really is run :)
[15:13] <mvo> which makes those transitions unfortuantely a bit cumbersome for it
[15:14] <pitti> mvo: so pygtk and gtk2 will need to stay on the CD for P?
[15:15] <mvo> pitti: hm, let me think about it for a second. so we only need it in oneiric because for oneiric -> P the oneiric version of pygtk2 will be used and once the upgrade is over its no longer needed. so P itself would not need it
[15:16] <mvo> pitti: in order to get rid of pygtk2 in oneiric we will have to have two UIs for the release upgrader actually, that is already supported and should be pretty straightforard
[15:16] <pitti> mvo: but we want to support direct lucid->p upgrades, too?
[15:17] <mvo> pitti: so it will try to import DistUpgradeViewGtk3 if that fails falls back to DistUpgradeViewGtk. then we are on the safe side and it will just work for lucid->p and oneiric (without pygtk2) to P)
[15:17] <pitti> mvo: (I don't think its a major problem to have pygtk on the P CDs)
[15:17] <mvo> pitti: yeah, for the P upgrade we need to support both lucid -> P and oneiric->P
[15:17] <pitti> it's 3 or 4 MB extra of course, but at least in P+1 we have something up our sleeves to save :)
[15:17] <mvo> pitti: ok, but I thnk we can get away without it by just adding the Gtk3 fontend.
[15:18] <mvo> and keeping the gtk2 as a fallback
[15:18] <mvo> means more testing, but the gtk2 code is pretty stable and does not really change much
[15:19] <pitti> mvo: btw, what was the last pygi port you did a couple of days ago? how did that go?
[15:23] <smoser> anyone know who is responsi ble for updating http://releases.ubuntu.com/jigit/ ?
[15:23] <mvo> pitti: gdebi, went very smooth
[15:24] <pitti> mvo: ah, right; that's not in oneiric yet, right?
[15:24] <mvo> not yet, I should upload it
[15:24] <cjwatson> smoser: that would be me
[15:24] <pitti> mvo: or "sid" that is
[15:25] <cjwatson> smoser: oh, huh, yeah, should add natty
[15:25] <mvo> pitti: is sid ready for gtk3/GI yet? I'm not 100% up-to-date here
[15:26] <pitti> mvo: sid has pygobject 2.28, g-i 0.10.8, and gir1.2-gtk-3.0 3.0.8; looks fine
[15:26] <smoser> cjwatson, yeah, thats all.  I was looking at bug 789219 . I sent message to upstream, and he is willing to incorporate the patch in comment 1, so we can eventually drop our ubuntu specific package there.
[15:26] <pitti> mvo: some GNOME 3 stuff is still in experimental, but the basic libraries are in unstable
[15:27] <mvo> pitti: vte is the only exotic depenency that gdebi has
[15:27] <pitti> mvo: you are using vte 2.90?
[15:27] <mvo> yes
[15:27] <pitti> ah, bummer
[15:28] <pitti>  gir1.2-vte-2.90 | 1:0.28.0-1+b1 | experimental | amd64 [...]
[15:28] <zul> who do i talk about broken udd imports?
[15:28] <pitti> mvo: so, for experimental I guess :/
[15:28]  * mvo nods
[15:29] <pitti> mvo: uploading it to unstable is blocked on libgladeui-dev, which is blocking on nautilus, IIRC
[15:29] <smoser> cjwatson, also, i just now notice that lucid doesn't work. (http://releases.ubuntu.com/jigit/ubuntu-10.04-server-amd64.conf says "lucid/ubuntu-10.04-server-amd64.jigdo" but it needs "ubuntu-10.04.2-alternate-amd64.jigdo"
[15:29] <mvo> ok, I upload the gtk3 version as a ubuntu version then for now and resync once unstable is ready
[15:29] <seb128> who is doing syncs?
[15:29] <seb128> cjwatson, ?
[15:29] <smoser> er... without the 'alternate'.  the point was it needs "10.04.2" not "10.04"
[15:30] <pitti> seb128: I synced the keyring stuff, calibre, and a few others
[15:30] <seb128> pitti, can you add gtksourceview3?
[15:30] <pitti> seb128: I'm already flushing, but I can sync that, sure
[15:30] <seb128> oh it already is
[15:30] <pitti> seb128: hm, I updated that, didn't I sync it?
[15:30] <seb128> you did, I didn't see the email on -changes
[15:30] <seb128> ignore me
[15:31] <pitti> :)
[15:31] <seb128> pitti, thanks
[15:31] <seb128> (I was just going to do the keyring syncs ;-)
[15:35] <ev> build depends of a main package also have to be in main, right?
[15:36] <StevenK> ev: Correct.
[15:36] <ev> rubbish :)
[15:36] <StevenK> ev: Then your build will hit MANUALDEPWAIT. :-)
[15:36] <ev> yay
[16:01] <cr3> is germinate the right tool to determine the list of packages that need to be installed from a default ubuntu-desktop installation to the same installation with an extra package which might have some dependencies?
[16:01] <pitti> ev, jibel, lool, dholbach: so I installed today's alternate (20110531) with udev 170, upgraded to udev 171 (no other packages), still boots
[16:02] <pitti> jibel: ^ is that how you tested?
[16:02] <apw> cjwatson, as we don't merge module-init-tools from debian, i assume we should be calling it x.y-0ubuntu1 ie. with the 0
[16:02] <pitti> others: does the boot failure actually show any error message?
[16:02] <pitti> apw: why don't we, OOI?
[16:02]  * pitti does a full dist-upgrade now
[16:02] <dholbach> pitti, AFAIR it showed a UUID that wasn't available
[16:03] <apw> pitti, now that i am unsure of, a scott thing originally i assume
[16:03] <ev> pitti: I upgraded from Natty this morning.
[16:03] <pitti> ev: also wrong UUID?
[16:04] <ev> pitti: correct, though root=/dev/sda1 didn't fix things either
[16:04] <ev> presumably the devtmpfs wasn't mounted yet
[16:05] <cjwatson> apw: might be worth looking at whether we can resync with Debian
[16:05] <apw> cjwatson, yeah i guess so ...
[16:05] <pitti> still boots after full dist-upgrade
[16:05] <cjwatson> cr3: yes; the --seed-packages option may help you
[16:06] <cjwatson> see the man page
[16:06] <cr3> cjwatson: will do, thanks for the pointer!
[16:07] <jibel> pitti, that's how I tested.
[16:08] <pitti> hmm
[16:08] <pitti> dholbach, jibel: do you still have a machine that fails like this?
[16:09] <dholbach> pitti, let me upgrade again and see what happens
[16:10] <pitti> perhaps you can compare the UUID in /etc/fstab, and in grub?
[16:10] <pitti> but root=/dev/sdaX instead of UUID= should really work
[16:10] <pitti> if not, then it's not the UUID, but something else
[16:10] <jibel> pitti, yes, booting
[16:14] <hrw> do we have a tool which can fetch few packages with dependencies and unpack them? kind of debootstrap but without anythin other then just those packages (so for packages=libc6-dev I do not get busybox-initramfs)
[16:15] <lool> pitti: I have one machine with the issue here
[16:15] <jibel> pitti, uuid are the same in fstab and grub
[16:15] <lool> pitti: The search --no-floppy --fs-uuid --set=root UUID matches the one in fstab here too
[16:18] <tkamppeter> sabdfl, hi
[16:21] <jibel> pitti, replacing root=UUID=... by root=/dev/sdaX doesn't work
[16:22] <pitti> jibel: ok, thanks; so it's not a changed UUID (which would have been quite horrible indeed)
[16:24] <ev> ugh, this GTK3 transition seems to have been horrendously managed.  There's no script to convert GTK2 GtkBuilder files to GTK3, for example.
[16:26] <cjwatson> smoser: fixed now
[16:26] <pitti> ev: there is
[16:26] <cjwatson> smoser: (natty, lucid, hardy, dapper)
[16:26] <pitti> ev: hang on, need to remember where it was
[16:27] <pitti> ev: ah, gtk-builder-convert should do it?
[16:28] <seb128> oh
[16:29] <apw> cjwatson, ok so this does look vaguely re-mergable, unfortuanatly they don't have the version i want yet
[16:29] <seb128> gnome-games stopped building gnome-sudoku so we should perhaps drop it from the seeds
[16:29] <seb128> (seems it's still installable though so that's not a real issue yet)
[16:30] <ev> pitti: that only does Glade to GtkBuilder. I'm looking to update an existing GtkBuilder to account for GTK3 dropping things like GtkComboBoxEntry
[16:30] <ev> right now it just helpfully deletes the widget
[16:30] <dholbach> pitti, same as the others said - it's still reproducible
[16:31] <pitti> ev: ah, in my ports it was usually only that and dropping some obsolete separator thing; but I thought that gtk-builder-convert would do it, hmm
[16:38] <ev> mind you, it's not just that.  The complete lack of documentation for the pygi stuff, or even an API reference / integration into python docstrings, leave me wondering if they considered third-party application developers at all
[16:38] <pitti> ev: the lack of a python specific GTK API doc is indeed known; it's on the agenda for the June hackfest
[16:39] <pitti> for now we need to use the GTK 3 docs
[16:39] <pitti> ev: https://live.gnome.org/PyGObject/IntrospectionPorting might give some help
[16:39] <ev> this amateur-hour stuff leaves me laughing hysterically at the "gnome is the platform" rubbish. You're not going to attract application developers by throwing obstacles in their path like this.
[16:39] <ev> apols for the rant
[16:39] <pitti> *nod*
[16:40] <cr3> cjwatson: thanks a lot for the tip about --seed-packages, I could not have imagined a better solution!
[16:41] <ev> thanks for the references
[16:41] <cjwatson> cr3: glad you like it
[16:44] <smoser> cjwatson, have you ever used the generic 'jigit' ?  do you know what possible things use the /jigit data at releases.u.c ? i'm trying to use it, and it doesn't seem like it could possibly work in its current state.
[16:46] <cjwatson> smoser: I used it some years back; I have my own wrapper these days
[16:46] <cjwatson> smoser: feel free to suggest fixes?
[16:46] <smoser> so you're not aware of anything else that uses that data there then?
[16:46] <cjwatson> no
[16:47] <smoser> i'm conversing some with the jigit upstream about it. it seems fairly broken at this point, yet we carry an ubuntu modified source for it.
[16:47] <cjwatson> we worked with Steve a bit some years back on it
[16:47] <cjwatson> it may date from that
[16:48] <cjwatson> I'm entirely happy to fix up the server side if there's something wrong with it
[16:48] <smoser> server was some broken as i pointed out, but client is broken too.
[16:52] <pitti> dholbach, lool: can you confirm that libudev 171 plus udev 170 makes things work again? this would help for bisecting the changes in it
[16:52] <cjwatson> smoser: libjte, OTOH, is used in various places
[16:52] <dholbach> pitti, let me try
[16:52] <pitti> dholbach, lool, jibel: I'll probably build a bunch of test packages then, and ask you which ones work and fail, to bisect the change
[16:52] <cjwatson> or will be, I assume it isn't yet since I'm only just NEWing those binaries, but copies of that code are around elsewhere
[16:53] <apw> cjwatson, where we have diverged for some time, is there a normal algorithm for merging the changlog entries order wise ?
[16:53] <jibel> pitti, k, ping us when there's something ready for testing
[16:54] <apw> cjwatson, i am sort of expecting you to say, just pull in the last version from debian to which you are resyncing
[16:54] <cjwatson> apw: either chronological or by version, pick one ...
[16:54] <cjwatson> apw: if we can get to the point where we can just do a verbatim sync from Debian, then the question becomes moot
[16:54] <cjwatson> I don't know if that's feasible heree
[16:54] <cjwatson> *here
[16:55] <apw> cjwatson, yeah thats unclear currently, we have a heap of extra files right now
[16:55] <pitti> jibel: confirming that it's not in libudev would help enormously, as it would rule out 4 of the 18 changes already (and I can already rule out 8 others)
[16:57] <dholbach> pitti, libudev 171 plus udev 170 does NOT make things work again
[16:57] <pitti> dholbach: thanks for confirming
[16:58] <seb128> dholbach, what sort of error do you get?
[16:58] <dholbach> seb128, something like "giving up on waiting for root device: uuid <...> not found"
[16:59] <seb128> ok, that's a different issue from what some people mentioned in #ubuntu-desktop before where xorg was not starting because of a /run/udev they had
[17:00] <dholbach> no, not xorg
[17:07] <pitti> I think I've got something, hang on
[17:07] <calc`> chrisccoulson: one thing that might annoy users in the switch from evolution to thunderbird, if they are using imap mail stored on server tbird can't (or didn't for many years) sort properly based on 'non-standard' headers, i don't have the bug number atm but its been in bugzilla for a long time
[17:09] <calc`> chrisccoulson: if it still is an issue it might warrant a note in the release notes, istr the bug report noting it would be extremely hard for them to fix the bug due to how tbird was written
[17:13] <pitti> dholbach: oh, hang on
[17:14] <pitti> dholbach: ISTR that jibel(?) said that merely downgrading udev and not libudev would work for him
[17:14] <pitti> ok, I give up for alpha-1; I'll just revert to 170
[17:16] <jibel> pitti, I said "<jibel> pitti, still broken with udev at 170 and libs at 171"
[17:16] <pitti> jibel: oh sorry, then I misunderstood
[17:16] <dholbach> jibel++
[17:16] <pitti> jibel, dholbach: what about udev 171 and libudev 170?
[17:16] <dholbach> let's see
[17:17] <pitti> I have 4 commits for libudev, and 3 for daemon
[17:17] <pitti> so apparenlty it's not the ones for daemon rule processing
[17:19] <jibel> pitti, udev 171, libgudev 171, libudev 170 does not work
[17:19] <pitti> weird
[17:19] <pitti> gudev isn't involved that early
[17:19] <pitti> if it's not libudev and not udev, then what else..
[17:20] <pitti> anyway, prep'ing a reversion for now
[17:22] <dholbach> jibel, pitti: installing libudev 170 and updating the initramfs makes it work
[17:22] <pitti> ah, interesting!
[17:22] <dholbach> let me double check the versions
[17:22] <pitti> right, merely downgrading libudev won't rebuild initramfs
[17:22] <pitti> udev will do that
[17:22] <dholbach> yes, just downgraded libudev to 170
[17:29] <jibel> pitti, I confirm what dholbach said. running initramfs after downgrading libudev 'fixes' the problem
[17:30] <dholbach> jibel, everybody loves 'fixes' :)
[17:31] <pitti> ok, test-booting my reversion now, and hoping that it'll fix stuff for you guys, too
[17:35] <pitti> dholbach, jibel, lool: I uploaded udev 171-0ubuntu2 which is pretty much a reversion to 170; it should work, but confirming appreciated
[17:36] <pitti> I'll dissect the libudev patches tomorrow then
[17:36] <dholbach> on it
[17:37] <ubuntu_> i was wondering when the daily-live .isos for xubuntu 11.10 would be out
[17:38] <pitti> dholbach: needs to build first :) but you can grab the .debs from https://launchpad.net/ubuntu/+source/udev/171-0ubuntu2/+build/2538535 (amd64) or https://launchpad.net/ubuntu/+source/udev/171-0ubuntu2/+build/2538537 (i386) when they are ready
[17:39] <cjwatson> ubuntu_: please use a less generic nick
[17:40] <cjwatson> ubuntu_: the Xubuntu CD builds are failing due to a conflict between xfce4-notifyd and notification-daemon (http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/xubuntu/20110530/livecd-20110530-i386.out); the Xubuntu developers need to fix that
[17:40] <cjwatson> bah
[17:40] <cjwatson> suppose I should have given the useful answer first
[17:41] <luk> he's not coming back :-)
[17:42] <charlie-tca> he also cross-posts to at least three channels
[17:43] <pitti> lool, jibel, dholbach: amd64 binaries ready for testing: https://launchpad.net/ubuntu/+source/udev/171-0ubuntu2/+build/2538535
[17:44]  * dholbach waits for i386 :)
[17:44] <pitti> they work here, but then again 171 did as well, so I'm not a good test case
[17:44] <ricotz_> pitti, is the plain 170 again?
[17:44] <pitti> yes, except that the diff.gz looks horrible :)
[17:45] <ricotz_> pitti, ok, i just reverted to 170 package which solved it for me
[17:45] <pitti> bbl
[17:45] <jibel> pitti, thanks, have a nice evening
[17:47] <dholbach> i386 built too: https://launchpad.net/ubuntu/+source/udev/171-0ubuntu2/+build/2538537
[17:48] <dholbach> let's see if it works
[17:48] <charlie-tca> why does gdm now depend on ubuntu-desktop? it makes it pull in all of gnome for Xubuntu again
[17:49] <dholbach> charlie-tca, are you talking about oneiric gdm?
[17:49] <dholbach> I can't find it in the dependency list
[17:49] <seb128> charlie-tca, it doesn't?
[17:50] <charlie-tca> I read it wrong then?
[17:50] <seb128> charlie-tca, what do you read?
[17:51] <charlie-tca> I read the wrong thing, looked at apt-cache rdepends gdm instead of depends
[17:52] <seb128> ok
[17:52] <dholbach> pitti, issue 'fixed' on i386 with 171-0ubuntu2
[17:52] <cjwatson> charlie-tca: http://people.canonical.com/~ubuntu-archive/germinate-output/xubuntu.oneiric/rdepends/ALL/notification-daemon is probably more useful
[17:52] <pitti> dholbach: danke!
[17:52] <charlie-tca> Thank you
[17:52] <dholbach> de rien
[17:52] <cjwatson> charlie-tca: (I assume that xfce4-notifyd is desirable)
[17:53] <charlie-tca> yes, it seems so
[17:53] <charlie-tca> Thanks very much for the help. We will keep looking.
[17:57] <cjwatson> debfx: please just request syncs rather than re-signing .dsc files from Debian and reuploading them (qtzeitgeist)
[17:57] <cjwatson> debfx: I'm going to reject this and replace it with a verbatim sync, since I'd rather have the exact same source file from Debian
[17:57] <debfx> cjwatson: okay
[17:58] <cjwatson> debfx: how does this interact with libqzeitgeist?
[17:59] <cjwatson> ah, you uploaded both so I presume OK ...
[18:00] <debfx> cjwatson: libqzeitgeist should be removed after it's synced
[18:00] <cjwatson> OK - it's making its way through now, thanks
[18:00] <cjwatson> (why does syncpackage re-sign the .dsc file, anyway?  it seems completely pointless)
[18:03] <cjwatson> hmm, maybe LP does care if it's being uploaded the usual way
[18:10] <micahg> cjwatson: if xfce4-notifyd provides/conflicts notification-daemon, why would it be pulled in if the -desktop package depends on xfce4-notifyd?  Would something in -standard or -minimal get to pull stuff in "first"?
[18:11] <cjwatson> micahg: I assume that something depends on only notification-daemon
[18:11] <micahg> cjwatson: well, that package is virtual and real
[18:11] <cjwatson> you're going to make me do a proper analysis aren't you :)
[18:12] <micahg> cjwatson: no, trying not to, I'm just lacking some understanding on how the dependency resolution works
[18:14] <micahg> cjwatson: libnotify4 seems to pull it in, but I'm wondering why xfce4-notifyd isn't fulfilling the requirement
[18:19] <TerminX_> micahg: maybe something is depending on notification-daemon with a specific version and xfce-notifyd isn't providing that
[18:20] <Laney> aptitude why notification-daemon might tell you
[18:22] <micahg> no and no
[18:26] <micahg> cjwatson: do build depends affect the seeds for the live env?
[18:26] <seb128> micahg, no
[18:28] <cjwatson> micahg: have you looked at the germinate output?
[18:28] <micahg> cjwatson: yes, but it's like gibberish to me, I don't know what to look for, it's a virtual package so it makes sense that it would have a lot of rdepends
[18:29] <cjwatson> so it's being pulled in by Recommends from libnotify4 in the desktop-common seed
[18:30] <cjwatson> that's expanded completely before considering the Xubuntu desktop seed, so it makes sense that a specific seed entry for xfce4-notifyd there wouldn't have any effect
[18:30] <micahg> right, so desktop-common takes precedence over xubuntu-desktop?
[18:30] <micahg> ah
[18:30] <cjwatson> precedence is the wrong way to think about it ...
[18:30] <cjwatson> anyway, stuff that depends on / recommends desktop-environment-specific things like a notification daemon should not be in desktop-common
[18:31] <cjwatson> the proper fix is to isolate those dependency chains and move them to the DE-specific desktop seeds
[18:32] <micahg> so, it's libnotify-bin that's in the seed
[18:32] <micahg> desktop-common that is
[18:32] <cjwatson> I think it's just a matter of moving that, yes
[18:32] <cjwatson> it'll have to be moved to all the things that use desktop-comomn
[18:32] <cjwatson> ^T
[18:32] <cjwatson> do you want me to take care of that?
[18:33] <cjwatson> I have all the branches checked out already
[18:33] <micahg> cjwatson: yes, please, I don't have access to the seeds
[18:33] <cjwatson> OK
[18:33] <cjwatson> you aren't core-dev yet?
[18:33] <micahg> cjwatson: no, not yet
[18:33] <cjwatson> bah :)
[18:33] <cjwatson> clearly should be
[18:33] <micahg> cjwatson: thanks :)
[18:34] <cjwatson> ah, libnotify-bin in desktop-common was a recent changes
[18:34] <cjwatson> *change
[18:35] <cjwatson> for bug 616028
[18:37] <seb128> cjwatson, libnotify-bin shouldn't force a server though
[18:37] <seb128> Depends: libc6 (>= 2.3.6-6~), libglib2.0-0 (>= 2.26), libnotify4 (>= 0.7.0)
[18:38] <cjwatson> libnotify4 Recommends: notification-daemon
[18:38] <cjwatson> it will work once it's moved to the desktop seed
[18:38] <seb128> cjwatson, but xfce4-notifyd provides notification-daemon
[18:39] <cjwatson> having it in the desktop-common seed means that germinate is forced to pick one before it knows what desktop environment it's working on
[18:39] <seb128> so it should be enough for the recommends
[18:39] <cjwatson> not with it in the desktop-common seed it isn't
[18:39] <cjwatson> it will be fine when it's moved to the desktop seed
[18:39] <seb128> oh, ok, gotcha
[18:40] <cjwatson> the desktop-common seed has to be common *when expanded*, as well as just having common seed entries
[18:40] <seb128> right, makes sense
[18:40] <seb128> how do we fix it then?
[18:40]  * micahg now knows to look for seed entries in germinate output :)
[18:41] <cjwatson> seb128: by moving it to desktop in all the flavours.  I'm doing that now
[18:41] <seb128> cjwatson, thanks
[18:48] <cjwatson> micahg: seed changes done; I'll go and respin -meta now
[18:49] <micahg> cjwatson: thanks!
[18:54] <apw> cjwatson, ok i've had a go at resyncing with module-init-tools with debian, i wonder if you might have time tommorrow to look it over as a sanity check ... i've compared the binary packages for content but not yet tested them: lp:~apw/module-init-tools/resync
[18:54] <cjwatson> I'm on holiday tomorrow to Friday
[18:54] <cjwatson> probably best to find somebody who's more around :)
[18:54] <apw> cjwatson, will do, enjoy :)
[18:55] <cjwatson> (though shouldn't it wait 'til after alpha 1, really?)
[18:55] <apw> cjwatson, oh i am not intending to upload anything till after A1 indeed
[18:57] <micahg> cjwatson: I wanted to ask you, where you're the TIL person only for a no-change rebuild, can I request syncs for those packages?
[18:57] <cjwatson> sure
[18:58] <micahg> k, thanks
[18:58] <cjwatson> I assume that's a no-change rebuild on top of a real Ubuntu modification
[18:58] <micahg> yes
[18:58] <cjwatson> some day it might be nice if MoM could work out TIL-except-for-rebuilds
[18:58] <cjwatson> never been worth the bother though ...
[18:59] <micahg> in theory, haven't looked for anything real yet,but I know you touched several hundred packages for the rebuilds and  are now TIL where there might be no diff
[18:59] <cjwatson> yeah, there are a few
[18:59] <micahg> s/rebuilds/transitions/
[18:59] <infinity> Used to happen to me all the time.
[19:02] <cjwatson> ah, good, xubuntu-meta doesn't need to be changed
[19:02] <cjwatson> ... which implies that we just need to wait for a couple of publisher run
[19:02] <cjwatson> s
[19:14] <micahg> jelmer: I saw the bzr-rebase package was dropped for oneiric, don't we need it for Lucid -> P upgrades/
[19:16] <jelmer> micahg, hi
[19:16] <jelmer> micahg, yeah, we'll need to worry about that - we should probably diverge from Debian because of that
[19:18] <micahg> jelmer: why not keep it in Debian (what does it hurt, at least until wheezy is a bit closer to release)
[19:50] <broder> slangasek: ping? is there a recommended way to discover what the multiarch-friendly directory for pam modules is? i'm working on fixing up the google-authenticator package, and i'll likely try to set it up as multiarch-enabled
[19:52] <slangasek> broder: "discover"... well, it's /lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/security
[19:52] <slangasek> you'll need to make sure you have a versioned pre-dep on libpam0g (>= 1.1.2-2ubuntu4) for that
[19:53]  * broder nods
[19:54] <broder> hmm...i guess this is actually a bit complicated, since the package also ships with a binary, and i don't actually want to create a new package as an ubuntu delta. oh well
[20:04] <slangasek> broder: why would it need to create a new package?
[20:05] <broder> i can't mark two packages as multiarch: same if they both ship a binary in /usr/bin, right? (i'd need to split off the binary and mark it as multiarch: foreign)
[20:05] <broder> err, one package, rather :)
[20:06] <broder> (libpam-google-authenticator has a /usr/bin/google-authenticator that you use to setup the shared secret for the 2-factor token)
[20:06] <slangasek> oh right
[20:07] <slangasek> is /usr/bin/google-authenticator actually an internal interface?  Could it move to /lib/$triplet/ ?
[20:07] <slangasek> or is it a user-facing executable?
[20:07] <broder> it's user-facing
[20:07] <slangasek> ok
[20:07] <broder> you run that, and it spits out a QR code that you scan on your phone to synchronize the OTP generation
[20:08]  * slangasek nods
[20:08] <broder> i'll try to get it cleaned up on the debian side, and i'll settle for just making it build on ours for the moment :)
[22:16] <mikey_> Hello. I'm wondering if I can get a little help with understanding ubuntu's take on X and its security policy?
[22:18] <mikey_> Basically a while ago I made a little tool to start up applications in a second X session as a way of circumventing the issues of running games under compiz.
[22:19] <mikey_> http://code.google.com/p/xgamer/
[22:21] <mikey_> I did this in frustration with these issues, and at the time I wrote to the compiz developers to ask if they were working on a solution to these issues. They told me they were but 2 years on and there's nothing forthcoming.
[22:24] <mikey_> Unity is now standard so compiz in unavoidable. My tool was used by a few as a work around. Ubuntu has changed the security policy for X so that user applications cannot independently modify sessions in the way that mine seeks to.
[22:25] <mikey_> So is there anyone who understands X and security issues in ubuntu who can help me form a better strategy?
[22:26] <lifeless> mmm, kees might, or RAOF or bryce
[22:31] <TheMuso> apachelogger: It does. My only concern is that we will be hearing sounds from the freedesktop theme that we don't want, however we do have this cycle to fix that up. The only other issue is that the freedesktop sound theme is in universe.
[22:32] <apachelogger> TheMuso: MIR for the theme is filed, and on the way to main.
[22:32] <TheMuso> apachelogger: As for having a package for plugins, you may want to talk to debian about that.
[22:32] <apachelogger> ok
[22:34] <apachelogger> TheMuso: As for the hearing of sounds from freedesktop theme, that is what it is meant to do. Just like hicolor for icons, if the requested sound is not available in the default theme, then it searches the fallbacks of that theme and if that too fails it looks in the freedesktop theme. Equally if an application deployes its own sounds, they would get installed to the freedesktop theme (applying the same fallback logic).
[22:35] <TheMuso> apachelogger: Right, some in design/Mark may question such sounds.
[22:35] <TheMuso> As in their quality.
[22:35] <TheMuso> i.e too windows esc or some such
[22:36] <TheMuso> apachelogger: But I guess we can resolve that as it comes up.
[22:37] <apachelogger> TheMuso: Agreed.
[22:41] <apachelogger> TheMuso: I'll prepare an upload to introduce the dependency then.
[22:42] <TheMuso> apachelogger: ok thanks