[02:19] <mfisch> robert_ancell: bryceh suggested I write an appoort script for lightdm
[02:19] <mfisch> robert_ancell: I think it would be pretty useful
[02:20] <robert_ancell> mfisch, we already have one
[02:20] <robert_ancell> debian/source_lightdm.py
[02:20] <mfisch> that was my first question
[02:23] <mfisch> robert_ancell: bryceh's xorg script prompts the user before collecting the logs, wonder if we should too
[02:23] <robert_ancell> sure, sounds good
[02:23] <mfisch> I'd also like to grab lightdm.conf
[02:47] <mfisch> robert_ancell: is there a reason the hook script isn't being installed?
[02:47] <robert_ancell> mfisch, it isn't?
[02:48] <mfisch> let me check an unmodified deb
[02:48] <mfisch> robert_ancell: it is not in 1.4.0
[02:50] <mfisch> it's also not in the lightdm.install scripts
[02:52] <robert_ancell> must be broen
[02:52] <robert_ancell> broken
[02:52] <mfisch> I'll fix that too
[02:57] <mfisch> robert_ancell: you want a bug for this?
[02:57] <robert_ancell> sure
[02:57] <mfisch> or just a MP
[03:18] <hallyn> hrw: jinkeys, my sparc-cross-toolchain-base-1.89 has been building here all day long :)  hopefully it doesn't bail right at the end and want to be restarted :)
[03:35] <mfisch> robert_ancell: just need to fix one thing: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1067591
[03:35] <mfisch> robert_ancell: thats the bug that apport made
[04:21] <pitti> Good morning
[04:22] <ajmitch> hi pitti
[07:11] <dholbach> good morning
[07:17] <OdyX> tkamppeter: Hi. I've been trying to debug this ipp-1.1 failure in cups for 4 hours now and can't get to a solution. I noticed it works with testfile.pdf though. Any idea where I should look into?
[07:17] <OdyX> (in cups, eh)
[07:33] <hrw> hallyn: share packages please :)
[07:40] <didrocks> @pilot on
[07:40] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[07:40] <didrocks> @pilot in
[07:42]  * dholbach hugs didrocks
[07:43] <didrocks> dholbach: not sure how much I can do today, unity SRU world (well, sponsoring popey's team, it's still sponsorship) :)
[07:43] <didrocks> will try to do as much as possible :)
[07:43] <dholbach> yeah, I did clean up mostly yesterday
[07:43] <dholbach> and looked at some SRUs
[07:44] <dholbach> that's the time of year, isn't it? :)
[07:45] <didrocks> indeed :)
[08:51] <tkamppeter> OdyX, unfortunately, I do not have an idea there, I never looked into the test programs. They always worked and when they stopped I had too many other, more important bugs to fix.
[08:56] <OdyX> tkamppeter: yeah; guessed so. I'll file a bug at cups directly as they also fail without any patches (well, the test runs with a .ps file which is probably not supported…)
[09:02] <ev> Is it possible to do a one off sync to precise-proposed?
[09:03] <ev> gnat-gps is still causing trouble on the retracers and 5.0-13 fixes it
[09:05] <cjwatson> Not sure it would be sensible to sync back quantal binaries - could you backport the fix instead, please?
[09:05] <cjwatson> (We can't do a sync without binaries either because same pool)
[09:39] <Laney> mvo: is it known/intended that apt-cache show pkg doesn't show the long description on Q?
[09:39] <mvo> Laney: neither
[09:40] <Laney> :P
[09:40] <mvo> Laney: what do I need to do to reproduce?
[09:40] <mvo> Laney: don't ansewr apt-cache show apt ;)
[09:40] <Laney> apt-cache show apt
[09:40] <Laney> hahaha
[09:40] <mvo> Laney: is that on the livecd?
[09:40] <Laney> no, I'm trying it in a quantal schroot
[09:40] <mvo> Laney: or a fresh install? before the first evar apt-get update was done?
[09:41] <mlankhorst> Laney: hey when does https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda get updated? I want to put myself on for core-dev :)
[09:41] <Laney> mlankhorst: when bdrung updates it, but you can add yourself whenever
[09:41] <Laney> the next meeting is during UDS
[09:41] <mlankhorst> I know
[09:41] <Laney> just do it any time
[09:42] <Laney> mvo: you don't see it in your setup?
[09:42] <mvo> Laney: I don't use schroot but I'm happy to give it a try
[09:43] <Laney> weird, I don't see it on our porter-amd64
[09:43] <mvo> Laney: which setup should I follow? https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment  ?
[09:43] <mvo> Laney: aha, is that one a server that I can use to reproduce?
[09:43] <Laney> no, because I don't reproduce it there
[09:43] <Laney> that is Description-en: foo whereas in my chroot it's Description: foo
[09:44] <Laney> and outside of the chroot it's the same as inside for me locally
[09:44] <mvo> Laney: so no apt-cache show apt even outside the chroot for you?
[09:44] <Laney> nope
[09:44] <Laney> I made the chroot with mk-sbuild quantal (from ubuntu-dev-tools)
[09:45]  * Laney fires up the VM
[09:46]  * mvo runs this now
[09:47] <cjwatson> Laney: there are separate Translations files - you may need to set a locale
[09:47] <cjwatson> now, apt is supposed to use English for LANG=C
[09:47] <mvo> yeah, exactly
[09:47] <mvo> this is whats puzzling me
[09:47] <Laney> well, on my bare metal it's en_GB.UTF-8
[09:48] <mvo> Laney: does apt-get update show it fetching Translation-en files at all?
[09:48] <cjwatson> mm, I don't see it in my schroots
[09:49] <Laney> ah, wait
[09:49] <Laney> they all share my local mirror, I bet that's busted
[09:49] <cjwatson> --include=i18n/Translation-en
[09:49] <cjwatson> Well
[09:50] <cjwatson> My debmirror run has --i18n --exclude='i18n/Translation-' --include='i18n/Translation-en' actually
[09:50] <Laney> Ign .../Translation-en{,_GB}
[09:50] <cjwatson> it's the --i18n that matters but you probably don't want to fetch all the translations if you have any kind of limited bandwidth
[09:51]  * Laney wonders how to do that in config
[09:52] <Laney> mvo: yeah that was it, sorry for noise
[09:52]  * Laney goes to twiddle debmirror
[09:54] <mvo> Laney: puhh, I was a bit worried
[09:54] <mvo> good that its fixed now
[09:54] <mvo> (or on the way)
[10:06] <mpt> omg the error rate is going down
[10:06] <mpt> for four days straight
[10:09] <pitti> ev, mpt: btw, what exactly does the y axis mean on errors.u.c.? avg errors per calender day is certainly not the whole story -- that should be a magnitude of 1.000 to 100.000 submissions per day surely?
[10:10] <mpt> pitti, why would it be 1.000 to 1000.000?
[10:11] <pitti> mpt: well, how can we get 0.04 error reports on a day?
[10:11] <pitti> we should get several thousands, and certainly not a fractional
[10:11] <pitti> I assume this number is "average errors per calender day per <something I don't know>"?
[10:12] <mpt> pitti, if 4% of the active machines reported exactly one error that day, for example. Or if 2% reported exactly one error and 1% reported exactly 2 errors.
[10:12] <pitti> mpt: ooh, so "errors per day per active machine"
[10:12] <mpt> yes
[10:12] <pitti> thanks, that's what I was missing
[10:13] <Laney> what's an active machine?
[10:13] <mpt> I knew someone was going to ask that :-)
[10:13] <Laney> those who have submitted an error over some time period?
[10:13] <mpt> Correct, an active machine is one that has submitted any error reports in the past 90 days.
[10:14] <mpt> That overcounts machines that have been destroyed or had Ubuntu wiped from them sometime in the past 90 days.
[10:14] <mpt> And it undercounts machines where the user would have reported errors, but was fortunate enough to get none at all.
[10:14] <mpt> Hopefully those two biases roughly cancel each other out.
[10:14] <pitti> seb128, cjwatson, Daviey, all: dholbach and I were just discussing for which packages we would like to see autopkgtests for; we are going to have a little competition at UDS and want to collect a list (people can work on their own packages, of course); so far I came up with http://paste.ubuntu.com/1284747/, do you have any others?
[10:15] <seb128> pitti, there are a lot of those in desktop we could add
[10:16] <pitti> seb128: FYI, I know that indicator-* is probably not going to happen there, but it's something that would benefit
[10:16] <pitti> seb128: dholbach will set up a wiki page, and I'll put the list there
[10:16] <dholbach> pitti, seb128, cjwatson, Daviey: shall we use a pad to brainstorm now?
[10:16] <pitti> seb128: so if you know of a library that breaks often, it shoudl be there
[10:16] <dholbach> then I can move it to a wiki page later
[10:16] <dholbach> pitti, gtk- too many gtk boogs!
[10:17] <pitti> dholbach: GTK already has tests
[10:17] <pitti> glib, too
[10:17] <dholbach> http://pad.ubuntu.com/lHeOelgRuJ
[10:17] <seb128> pitti, like I can image we could add libsoup librsvg libsecret libunity libarchive libdbusmenu libgdata libical
[10:17] <cjwatson> dholbach,pitti: count me out, busy with 12.10 emergency
[10:17] <seb128> pitti, poppler
[10:17] <dholbach> cjwatson, good luck!
[10:17] <pitti> cjwatson: *ack*
[10:17] <pitti> seb128: libunity is already on the list; thanks
[10:17] <seb128> pitti, cairo
[10:17] <pitti> seb128: ooh, poppler
[10:20] <pitti> dholbach: we already have s-c
[10:20] <dholbach> ok
[10:20] <pitti> https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-software-center/
[10:20] <pitti> they need to be fixed, though
[10:20]  * pitti bats eyelashes towards mvo
[10:21] <dholbach> hah :)
[10:21] <mvo> pitti: *cough* indeed
[10:21] <pitti> dholbach: actually, anything that's red on https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/, like maas or network-manager
[10:22] <seb128> pitti, dholbach: you can drop "libindicate-gtk3-dev", that lib is deprecated in quantal
[10:22] <pitti> done
[10:23] <seb128> it's replaced by libmessaging-menu from indicator-messages
[10:23] <pitti> seb128: just libindicate-dev now?
[10:23] <pitti> aah
[10:23] <pitti> that seemed more specialized, though
[10:23] <seb128> pitti, no, libindicate stop being used, lars is brining sanity to indicators
[10:23] <seb128> pitti, well, libindicator is still used
[10:23] <seb128> libappindicator as well
[10:23] <pitti> seb128: GMenuModel?
[10:24] <seb128> pitti, no, orthogonal things, libindicat* is confusing
[10:24] <pitti> seb128: added libindicator3-dev then
[10:24] <seb128> libindicate -> indicate message -> lib to use for client to integrate in indicator-messages ... that's libmessaging-menu now
[10:24] <seb128> libindicator -> lib to do system indicators
[10:24] <pitti> aah
[10:24] <seb128> libappindicator -> lib for apps, equivalent of the gtkstatusicon
[10:24] <pitti> yeah, I've always been confused about these two
[10:24] <cjwatson> pitti: FWIW I fixed software-properties and about half of unattended-upgrades in bzr, but didn't think it worth disrupting the release process with uploads
[10:25] <pitti> cjwatson: thanks, noting so in pad to avoid double work
[10:25] <seb128> pitti, lars plan to consolidate with only a libindicator gmenumodel based
[10:25] <cjwatson> (since the bugs were test-only)
[10:25] <seb128> pitti, so hopefully all the confusions go away
[10:31] <pitti> dholbach: that looks like a lot of fodder now :)
[10:31] <dholbach> yes, a good start :9
[10:31] <dholbach> :-)
[10:31] <dholbach> I'll set up the wiki docs and add this there
[10:37] <seb128> dholbach, pitti: great list ;-)
[10:37] <pitti> seb128, dholbach: I'm not sure whether unity is suitable as an autopkgtest -- sounds more like a case for UTAH to me (i. e. testing under a full desktop session, not just a tiny server environment with no session/system d-bus, no gnome session, etc.)
[10:38] <pitti> if someone can make it work, sure :)
[10:38] <pitti> (this would certainly deserve the "winner" prize)
[10:38] <seb128> pitti, sorry, I misunderstood "system installed packages"
[10:38] <dholbach> pitti, yeah, I listed it because I thought it must have a bunch of upstream test cases (built tree) as well
[10:38] <dholbach> but I'm sure you're right
[10:38] <pitti> seb128: clarified in the pad
[10:38] <seb128> pitti, danke
[10:39] <seb128> pitti, btw how far are we to be able to e.g throw a gtk update somewhere and have the system tell us if it breaks any autotest somewhere else?
[10:39] <seb128> e.g rdpends testing
[10:39] <pitti> seb128: that's called https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/
[10:40] <seb128> pitti, well, where somewhere is not the archive :p
[10:40] <pitti> seb128: it tests -proposed uploads and all its rdepends, and creates red dots
[10:40] <pitti> seb128: well, for somewhere == -proposed
[10:40] <seb128> proposed is not supposed to be used as a test bed afaik
[10:40] <pitti> seb128: in principle we have the machinery to do it for PPA
[10:40] <cjwatson> seb128: not a manual test bed
[10:40] <pitti> just not wired up to do it
[10:40] <cjwatson> seb128: it's definitely intended for autopkgtests to run on it
[10:40] <pitti> but with that we'll run into capacity issues, so we'd need to limit that a bit
[10:41] <cjwatson> this is part of the grand plan
[10:41] <seb128> cjwatson, right, but I guess it would be nicer if we had a way to see the result of autopkgtests without having to send the package to proposed
[10:41] <pitti> we certainly need a facility like that
[10:41] <cjwatson> seb128: oh, sure, though of course you can just run it locally :)
[10:41] <seb128> like "I'm not ready to upload to the archive yet but I would like to know how good that GTK is"
[10:41] <cjwatson> maybe not all the rdepends
[10:42] <pitti> we are very close to having the whole thing charmed (not including jenkins itself, though)
[10:42] <pitti> but this needs some more love, as well as documentatino
[10:43] <seb128> where I'm getting at I guess is that I whole love to have a daily gtk-trunk build going through autotests
[10:43] <seb128> I would*
[10:43] <seb128> so we know when upstream breaks something
[10:43] <seb128> rather than waiting for the next tarball 3 weeks later
[10:43] <pitti> seb128: right, that sounds like an excellent case for "juju deploy ubuntu-adt" with an extra PPA
[10:43] <pitti> seb128: but it also ties into what we are doing with jhbuild
[10:43] <seb128> pitti, yeah
[10:44] <pitti> seb128: did you see https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/ ?
[10:44] <pitti> that now runs with --check
[10:44]  * pitti hugs jibel
[10:44] <seb128> pitti, I think I bookmarked a blog post from jibel about that
[10:44] <seb128> or email, or g+ or something
[10:44] <seb128> but I didn't go back to read it yet
[10:44] <jibel> seb128, we have something very close https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/
[10:44] <seb128> does that run autopkgtests?
[10:44] <seb128> or just upstream tests?
[10:44] <pitti> seb128: so my hope is that https://code.launchpad.net/unity-jhbuild will work well enough to be able to integrate it there, too
[10:45] <jibel> not autopkgtest, it does a checkout, build and run upstream tests
[10:45] <pitti> seb128: that's upstream tests; "jhbuild --check build" by and large
[10:45] <seb128> ok
[10:45] <jibel> so we know when upstream breaks something
[10:45] <seb128> so it's great
[10:45] <seb128> but it doesn't tell me when I break s-c for mvo :p
[10:45] <pitti> seb128: oui, that's where the juju charm for setting up the adt environment with an extra PPA comes into play, I think
[10:46] <seb128> but combined with the ""juju deploy ubuntu-adt" with an extra PPA" we have the best on both side
[10:46] <pitti> we can certainly enable an extra PPA, but for a more general service the DC doesn't scale
[10:46] <seb128> pitti, sounds great to me ;-)
[10:46] <seb128> pitti, yeah, I don't want that level of testing for everything, mainly glib and gtk
[10:46] <seb128> it might convince me to keep tracking the unstable serie of those :p
[10:46] <pitti> jibel: capacity issues aside, I guess it would be relatively easy to enable adt runs with the ubuntu-desktop PPA enabled, right?
[10:47] <pitti> now that it works for -proposed
[10:47]  * pitti really feels bad for never having tried juju yet; something high on my "want to try" list
[10:47] <jibel> pitti, yes, it'd be easy, the functionality to test from a ppa has been added to the tool a couple of weeks ago
[10:48] <seb128> \o/
[10:48] <seb128> pitti, I feel bad that I didn't have more time to play with autopkgtests this cycle and add some, I hope to fix that next cycle ;-)
[10:50] <seb128> pitti, jibel: https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/job/jhbuild-gnome-amd64-nautilus/28/artifact/nautilus.log ..."Could not open X display", do you consider that an upstream test bug (e.g they should use xvfb-run) or a setup bug on the qa machine?
[10:50] <pitti> seb128: or at UDS, where we'll hopefully get a whole bunch
[10:51] <seb128> pitti, well, I count on UDS to get started and keep that ball rolling from then on ;-)
[10:51] <pitti> seb128, jibel: I guess for jhbuild in GNOME it'd probably be appropriate to run the whole thing under xvfb-run?
[10:51] <seb128> +1 from me
[10:51] <jibel> seb128, I'm fixing the system to run tests through xvfb
[10:51] <pitti> I always run it under my normal desktop session
[10:51] <pitti> we just need to check if you can nest those
[10:52] <pitti> i. e. for test suites which call xvfb on their own
[10:52] <cjwatson> might need [ "$DISPLAY" ] || xvfb-run, or similar
[10:52] <jibel> seb128, I'm reviewing all the failures and reached package 49/206
[10:52] <seb128> jibel, ok
[10:52] <cjwatson> Well, or not
[10:52] <cjwatson> I guess under a regular X session you still want xvfb-run so that it doesn't pop up windows all over your desktop
[10:52] <pitti> right
[10:53] <pitti> I have an env var in apport to disable xvfb, in case I actually do want to see the windows (visual inspection), but most of the time I don't
[10:53] <cjwatson> 'xvfb-run xvfb-run xterm' gives 'xvfb-run: error: Xvfb fails to start'
[10:53] <cjwatson> *failed
[10:53] <cjwatson> OTOH
[10:53] <cjwatson> 'xvfb-run -n 98 xvfb-run xterm' works
[10:53] <pitti> maybe with -n 87?
[10:54] <pitti> right; I'd use a different number in the "outside" jhbuild machinery, so that the defaults work "inside"
[10:54] <cjwatson> yeah
[10:56] <pitti> jibel: that might actually fix a lot of failures; I don't use xvfb in pygobject either
[10:57] <pitti> "DISPLAY= jhbuild run make check" indeed fails
[10:58] <cjwatson> ubiquity's test runner automatically uses xvfb
[11:01] <pitti> a/way -all lunch
[11:01] <pitti> erk, let's try that again
[11:02] <jibel> jhbuild is supposed to start the tests with xvfb when it doesn't find a display, but it doesn't for some reason. I'll search why after the release.
[11:33] <didrocks> @pilot out
[11:42] <OdyX> tkamppeter, pitti: https://cups.org/str.php?L4214 :)
[11:57] <quadrispro> hello everybody!
[11:59] <pitti> OdyX: ah, thanks :)
[12:02] <OdyX> pitti: besides that bug, the testsuite runs fully without too many problems here, you might want to include my patches into quantal's cups.
[12:05] <ev> cjwatson: just saw your reply. Thank you and I will.
[12:31] <gogo> Hello, I am writing an app in python for Ubuntu. I am using pkexec and subprocess to escalate privileges. Is there a way to get user authorization without using subprocess?
[13:03] <cyphermox> @pilot out
[13:03] <cyphermox> oops.
[13:50] <micahg> ogra_: I'll be spinning up a webkit update for quantal after the release team is done with respins, so I can switch the optimization to -00 to see if that helps on arm* if you like
[13:51] <ogra_> yeah, i surely do
[13:51] <micahg> ogra_: ok, I'll let you know when it's ready for testing then
[13:52] <ogra_> thx !
[14:20] <ScottK> bryce: Could you have a look into https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1019444/comments/5 ?
[14:22] <gogo> Hello, When I run my Ubuntu indicator as root, i am getting this dbus error > http://pastebin.com/thvqYZFh Any idea what is this about?
[14:26] <dobey> gogo: root processes can't user the user's session bus. you need to run indicators as the user you're logged in as, not as root
[14:30] <gogo> dobey: Oh, my indicator app asks user for root access 4-5 times. Is these a way the indicator can be granted root access for whole session. I tried polkit policy and pkexec but as you said, it wont work.
[14:30] <gogo> there*
[14:31] <ScottK> You need to break your app into a front end that runs as user and a backend that runs as root and use policykit.
[14:34] <gogo> ScottK: Right, that makes sense. Thanks for the suggestion.
[14:34] <dobey> gogo: what does your indicator do?
[14:35] <gogo> its for managing fan speed
[14:40] <barry> slangasek: wondering if you had any other progress on bug #1054712
[14:40] <doko> jodh, can you attach your test program for 1066351?
[14:45] <jodh> doko: done.
[14:45] <stokachu> slangasek: http://paste.ubuntu.com/1285155/ - would something like this be acceptable for that appmenu-gtk bug?
[14:46] <slangasek> barry: no other progress besides getting angry at pdb permuting things to where it doesn't crash
[14:46] <slangasek> stokachu: is UBUNTU_MENUPROXY a single variable, or are there separate ones for gtk2 vs. gtk3?
[14:47] <stokachu> slangasek: its just a single variable
[14:47] <stokachu> slangasek: though one thing to note is that libappmenu.so is the same no matter which package is installed
[14:47] <slangasek> stokachu: oh, then that looks perfectly fine then
[14:47] <stokachu> no hardcoded paths
[14:47] <slangasek> yep, that's important
[14:47] <stokachu> slangasek: ok cool ill get a debdiff create and sent up for when you have time :)
[14:48] <slangasek> stokachu: so that looks great as a script snippet; there's some monkeying that has to go into the package around deprecating the old file too
[14:48] <doko> jodh, and assign a kernel task, if you think it's the kernel? ;)
[14:48] <slangasek> stokachu: oh, I guess we can just ship two copies of this exact file for now, which is probably the simplest change and not incorrect
[14:48] <stokachu> slangasek: hmmmm this is after purging you mean?
[14:48] <slangasek> stokachu: pretend I didn't say anything :)
[14:48] <stokachu> slangasek: lol ok
[14:56] <barry> mvo: what's the difference between ~mvo/ubuntu/quantal/dbus-python/lp846044 and lp846044-2?
[14:58] <mvo> barry: none, sorry, I will delete the later one
[14:59] <barry> mvo: np
[14:59] <mvo> barry: if you take care of the SRU that will be great and I erase it from my memory^Wtodo list :)
[15:00] <barry> mvo: sru for quantal?  np, i can take care of that
[15:00] <mvo> barry: yeah, once we get final approval from upstream I think it should go into quantal-proposed ASAP
[15:01] <barry> mvo: +1.  what about the oneiric bug task? (currently assigned to you?)
[15:01] <dholbach> pitti, I set up https://wiki.ubuntu.com/QATeam/RequiredTests
[15:02] <dholbach> seb128, jibel: ^ - so we can drop the pad page
[15:02] <mvo> barry: fixed
[15:03] <barry> mvo: perfect
[15:03] <mvo> (well won't fixed but…)
[15:13] <stokachu> mterry: hey are you planning on pushing pbuilder-scripts into precise as well?
[15:14] <mterry> stokachu, no, since it'd be a new package.  I suppose I could add it via extras, but I hadn't planned on it
[15:15] <stokachu> mterry: ok i can just rebuild it myself -- the scripts are an awesome addition btw
[15:16] <mterry> stokachu, thanks!  :)  Hope they are useful
[15:16]  * micahg reminds mterry about backports for stable new packages and ubuntu-dev-tools for putting dev helper stuff
[15:17] <micahg> s/stable new packages/new packages in stable/
[15:17] <ogra_> stapled new packages ?
[15:19] <stokachu> mterry: definately useful, the organization part is particularly sweeet
[15:20] <mterry> micahg, yeah  :)
[15:42] <fishor> hallo all, are any one of ubuntu devs works on gnome-bluetooth?
[15:43] <stgraber> cyphermox: ^
[15:43] <pitti> dholbach: merci!
[15:45] <cyphermox> fishor: what's up
[15:50] <fishor> cyphermox, hi! i fallowing some crashes in G-B, and have some patches... but it looks like the problem is a bit deeper. I jast lost the trace. On some casts between Device -> GDbsProxy -> Device, device is lost..
[15:51] <fishor> and i confused with this self genretade gdbs code. some times it used some times it is replicated on main code
[15:52] <fishor> should it dependencies on bluetooth-client-glue* actually be removed?
[15:52] <fishor> or are they other reason why the code is so confusing :)
[15:53] <fishor> currently im in bluetooth-client.c:disconnect_collback
[15:56] <tkamppeter> pitti, hi
[15:56] <stokachu> no patch pilots today?
[15:57] <micahg> stokachu: need something right now?
[15:57] <stokachu> micahg: ive got an FFe but not sure if its possible to include at this point?
[15:57] <micahg> stokachu: no, at this point an SRU is probably best
[15:57] <micahg> stokachu: what's the bug?
[15:58] <stokachu> micahg: http://pad.lv/932860
[15:59] <stokachu> if the archive is frozen are -proposed being accepted for quantal now?
[15:59] <micahg> stokachu: yes, SRUs are being accepted time permitting
[15:59] <stokachu> micahg: ok, quantal isnt my biggest concern its just getting it in quantal so i can create a precise proposal
[16:00] <stokachu> but i guess they go hand in hand anyway
[16:00] <micahg> stokachu: yeah, both are SRUs at this point
[16:00] <stokachu> micahg: ok cool so ill need to wait until time permits then?
[16:01] <micahg> stokachu: well, unless you need this today, someone will get to it in the queue, if you need it uploaded today I can have a look in a bit
[16:02] <stokachu> micahg: pm
[16:18] <fishor> hmm... looks like i DoS-ed cyphermox, was it my english or question?
[16:19] <_jmp_> pgraner: hi! is tomorrow too late for the pandaboard? I can bring mine tomorrow 9ish
[16:20] <pgraner> _jmp_, too late sorry
[16:20] <stokachu> _jmp_: dont forget to check your email before partying
[16:20] <_jmp_> stokachu: hmm surprises.. /me checks :)
[16:21] <_jmp_> stokachu: let me get you the agent bits
[16:21] <stokachu> thanks
[16:23] <stokachu> _jmp_: and also I wont "taint" my contributions by looking at it either
[16:26] <_jmp_> stokachu: https://launchpad.net/ubuntu/+source/walinuxagent
[16:27] <_jmp_> stokachu: nah its fine imo, apache license
[16:27] <stokachu> ok
[16:38] <stokachu> slangasek: so when upgrading appmenu with my changes it keeps around /etc/X11/Xsession.d/80appmenu-gtk3 should I remove that file in our rules?
[16:38] <slangasek> stokachu: ah, that was the bit I was thinking out loud about earlier
[16:38] <stokachu> yea i just realize that during testing
[16:38] <slangasek> stokachu: don't remove it, we want both files
[16:38] <slangasek> stokachu: otherwise, we have two packages having to share a single config file, and that's not pretty
[16:39] <stokachu> slangasek: so for whatever reason though only 80appmenu gets updated with latest but appmenu-gtk3 stays untouched
[16:39] <stokachu> so its still looking for a hardcoded moduledir
[16:39] <slangasek> oh really
[16:39] <slangasek> did you update both packages?
[16:39] <stokachu> oh
[16:39] <stokachu> no LOL
[16:39] <slangasek> :)
[16:39] <stokachu> damnit ok lemme check right quick
[16:40] <stokachu> slangasek: lol ok forget i ever said anything
[16:41]  * stokachu needs coffee
[16:41] <slangasek> stokachu: coffee++
[17:01] <barry> slangasek: thanks for the great email follow up there
[17:02] <slangasek> barry: at your service :)
[17:02] <barry> :)
[17:22] <stokachu> slangasek: is it advisable to set #!/bin/bash in these xsessions scripts?
[17:22] <stokachu> i dont see it done in any other ones though
[17:23] <slangasek> stokachu: the files are sourced, not executed, so it doesn't matter
[17:23] <slangasek> (must be sourced, not executed, otherwise you couldn't use them to set env vars)
[17:24] <stokachu> hmm ok
[17:54] <bdmurray> mterry: could you have a look at bug 1065806?
[17:54]  * mterry looks
[21:20] <smoser> stgraber, around ?
[21:20] <smoser> you looking at https://bugs.launchpad.net/bugs/1061639 ?
[21:25] <stgraber> smoser: I saw the comments, but I highly doubt it's still ifupdown's fault
[21:26] <smoser> well, have you tried to reproduce?
[21:26] <stgraber> smoser: yes, without any success so far. The guy is also saying he had that with 12.04
[21:37] <slangasek> smoser: those users are reporting a symptom and asserting that they have the same bug, which is not helpful
[21:38] <slangasek> smoser: any upstart job that's wrongly holding files open at shutdown could trigger a "device busy" error; these users really need to file separate bugs and work through them from first principles
[21:38] <slangasek> I think there is a bug open on plymouth about this exact problem at the moment, fwiw
[21:38] <slangasek> (bug #1019347)
[21:39] <slangasek> which, er, probably needs to be escalated to the desktop team
[21:40] <smoser> slangasek, "really should open another bug" doesn't mean "problem doesn't exist"
[21:40] <smoser> i agree that separate issues is right, but i just dont want to ignore the complaints.
[21:45] <slangasek> smoser: there are limits to how much handholding we can do for users who fail at the basics of bug reporting.  It is not an efficient use of our time to chase up every dogpile comment from a user that is mis-diagnosing their own bug.  If you're seeing this issue, you could help by filing a bug report yourself?
[21:45] <smoser> i'm not seeing the issue. but the comments were implying almost fresh install.
[21:46] <smoser> i really just wnted to ensure that that was not the case (which i've not seen)
[21:46] <slangasek> ok