[02:55] <deitarion> Does anyone know where I could get some debugging symbols for the `notification-daemon` package on 14.04? There's no `-dbg` package for it and it's crashing when it tries to hide a notification.
[03:02] <deitarion> Also, if you know that it's a thorny thing to debug, please warn me  so I can just give up without wasting my time and spend a few hours cobbling together a basic notification daemon with "missed notifications" log using PyGTK. I have almost no experience with C.
[03:11] <Laney> deitarion: https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages
[03:13] <deitarion> Laney: Thanks. I'm getting a bit dozy, but that looks like what I want so I'll check it out tomorrow morning.
[03:13] <Laney> 'kay, good luck
[04:52] <pitti> Good morning
[04:53] <pitti> Noskcaj, slangasek: indicator-power needs porting too, for the signals; it builds and starts, but never updates the UI
[04:53] <pitti> Noskcaj: how do you mean, progress with python-dbusmock upower? that was fixed weeks ago for upower 0.99
[06:02] <Noskcaj> pitti, i hadn't realised you fixed it. could you close the "upstream" bug?
[06:02] <pitti> Noskcaj: it's fixed in bug 1330037, is there another one?
[06:03] <pitti> Noskcaj: ah, I seee it, will do
[06:03] <Noskcaj> bug 1324791
[06:56] <dholbach> good morning
[07:00] <Tribaal> hi dholbach
[07:00] <Tribaal> :)
[07:00] <dholbach> hi Tribaal
[07:41] <dholbach> Noskcaj, did you get anywhere with python-wsme?
[08:15] <sarnold> infinity,stgraber, could you guys add a mention to the release announcements for the point releases with HWE stacks that those stacks will EOL before the rest of the software? A friend of mine is very frustrated that his 12.04.x HWE stack isn't as LTS as the rest of the system, and the trusty HWE stack breaks the precise virtualbox dkms packages
[08:15] <sarnold> infinity,stgraber, it'd be nice if the annoucements were clear about just how long the HWE stacks will live on to help reduce the surprise and confusion
[08:23] <infinity> sarnold: I've never done a point release with an HWE stack, but in the future, sure.
[08:23] <infinity> cjwatson: ^
[08:23] <infinity> At least, I don't think I have.
[08:28] <sarnold> infinity: oh, sorry :) I assumed since you've been kind enough to reap our releases that you'd sometimes announce them to the world, too :) sorry
[08:28] <infinity> sarnold: I tend to do final releases.  I also just did 14.04.1, but that didn't have an HWE stack.
[08:29] <infinity> sarnold: I agree that the initial communication around HWE stacks was poor, it's been a work in progress.
[08:29] <infinity> sarnold: I still (personally) think it's poor form to give people a "14.04.2 LTS" CD with fine print that says "except half of this isn't supported beyond 16.04".
[08:30] <infinity> And I'm not sure how best to address that.
[08:32] <sarnold> infinity: yeah, I know the feeling. I still don't know how to best get my pal up and running again with his cruddy virtualbox problem :( if it were in my hands I'd be a bit more cavalier about trying things to fix it, but I can understand his reluctance to try a wholescale downgrade to original precise stack.
[08:33] <infinity> sarnold: Are there bugs about this virtualbox issue?  Can we fix it?
[08:33] <infinity> sarnold: I know some DKMS stuff is best-effort, but vbox has enough users that I assume someone cares.
[08:33] <zyga> offtopic: can anyone on 14.10 run cheese and tell me if their webcams work?
[08:33] <zyga> I get a still frame and then a ton of gstreamer errors
[08:33] <sarnold> infinity: so please count that as encouragement towards finding a nice solution; maintaining a dozen simultaneous HWE stacks doesn't sound like a good use of resources but hopefully we can find something in the middle that makes it less surprising
[08:34] <sarnold> infinity: there's a pile of bug reports kinda like this one: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1343305
[08:35] <sarnold> infinity: there's at least some overlap or mess here, since it fails in different ways for the different stacks, but the end result is the same, the module isn't updated for the kernels
[08:39] <Noskcaj> dholbach, Those depends are needed it seems, i'll try and get the MIRs done, but i've got a heap of school work ATM
[08:39] <dholbach> Noskcaj, hum... it looks like we didn't need them before, right?
[08:40] <infinity> sarnold: I'd love for the right answer to be to tell people "don't use virtualbox" and, indeed, to stop shipping the stupid dkms module.  But...
[08:40] <dholbach> Noskcaj, I'm just asking because the package is stuck for now - I just thought it'd be good to finish this before you start working on other stuff
[08:40] <dholbach> doko pinged me about it too
[08:41] <sarnold> infinity: heh, yeah, oracle for the loss :/
[08:43] <sarnold> infinity: thanks :) good night
[08:46] <darkxst> virtualbox was a mess before oracle!
[08:46] <directhex> i don't know how much virtualbox sucks due to bad packaging, and how much virtualbox sucks due to bad software. but either way, i disrecommend it to people
[08:47] <darkxst> directhex, the 3D drivers are just plain rubbish
[08:48] <directhex> darkxst: are they *capable* of running 32-bit apps in a 64-bit guest os? i know as-packaged that's not possible
[08:50] <darkxst> directhex, not sure about that, would seem silly if they can't though
[08:50] <directhex> darkxst: they certainly can't in deb/buntu
[08:52] <directhex> darkxst: the gl stuff is only in the virtualbox-guest-x11 package, which is not remotely multiarch
[08:53] <darkxst> directhex, I traited and switched to vmware a couple of years ago
[08:53] <infinity> directhex: Packaging might make it worse, but the general non-freeness and awfulness of upstream makes it a poor choice even before packaging might hinder you further.
[08:53] <darkxst> note how a proprietry company has mainline kernel drives and vbox doesnt!
[08:53] <directhex> despite non-Freeness, vmware is an excellent product & has excellent opengl support in linux guests
[08:54] <infinity> directhex: The vmware drivers are free, as pointed out above, which is a huge help (and very smart on their part).
[08:54] <darkxst> directhex, exactly why I have never looked back
[08:54] <darkxst> infinity, vbox drivers would never be accepted into the kernel in their current state
[08:54] <infinity> Not that I recommend vmware either, but if forced to choose the lesser of weavils.
[08:54] <infinity> weevils...
[08:55] <directhex> i use kvm fine for any jobs that don't require uefi or opengl in the guest os
[08:55] <infinity> darkxst: Obviously not, but "our software is crap" is never an excuse to not submit upstream, it's an excuse to not improve your software.
[08:55] <infinity> directhex: EFI on qemu should work now.  So I hear.  I don't use it in such a setup.
[08:55] <Noskcaj> dholbach, The code uses both of those packages, so i'm assuming it just never got noticed
[08:56] <darkxst> infinity, that would just result in a linus rant towards oracles way ;)
[08:56] <dholbach> Noskcaj, probably - I haven't looked that closely yet - maybe it'd make sense to have a chat with the folks who uploaded the package before?
[08:57] <directhex> infinity: it "works" - ovmf has a few teeny tiny missing features. e.g. it has no persistent storage of uefi variables so after rebooting your VM doesn't know which bootable OSes are installed. it also lacks drivers for most of qemu's storage controllers
[08:57] <infinity> darkxst: What I meant was that the solution to "too crap to submit" is "make it less crap", not "don't submit".
[08:57] <slangasek> dholbach: hi, you've cc:ed me on this mail about click frameworks... was this related to my upload for dropping friends?
[08:57] <slangasek> dholbach: or are you cc:ing me because you think I know something? :/
[08:58] <darkxst> infinity, except it was crap before, and its still crap now oracle have taken over
[08:58] <dholbach> slangasek, yeah, I guess, it looked like your update to ubuntu-touch-meta was the last one changing the frameworks - one ot the questions which came up is why we have -qml-dev3 and not -dev3
[08:59] <infinity> darkxst: Preaching to the choir.
[08:59] <doko> xnox, can you have a look at the lvm2 merge? pitti doesn't want to do it, and you are the last uploader then
[09:00] <Noskcaj> dholbach, will do
[09:00] <pitti> doko: well, this should be done by someone who actually uses lvm2
[09:00] <pitti> err, xnox
[09:00] <dholbach> thanks Noskcaj
[09:00] <pitti> I mean, I can look into it, but I have no real-world test setup
[09:00] <xnox> pitti: doko: yeah, it's on my list to do this week.
[09:01] <slangasek> dholbach: ok; so the only framework that changed was the qml one because dropping friends was a qml-only API change, TTBOMK
[09:02] <slangasek> dholbach: and IIRC
[09:02] <slangasek> dholbach: and there's no reason to rev the -dev numbers in lockstep, AFAIK
[09:02] <slangasek> dholbach: but I think jdstrand is the expert on this
[09:12] <dholbach> slangasek, ok - thanks a bunch!
[09:12] <dholbach> popey, ^ did you see what Steve said above?
[09:13] <dholbach> popey, I'm wondering if the general process for an app developer could be easier, maybe to the point, where they just select the framework from a drop-down box in the SDK?
[09:21] <LocutusOfBorg1> seb128, I'm also here if you want
[09:22] <LocutusOfBorg1> for bug 1349385
[10:57] <pitti> xnox: oh, thanks for the upstart-core split! I'm making good progress on bug 1351306
[10:57] <pitti> xnox: although I suppose slangasek might not get to reviewing sysvinit this week at the sprint
[10:57] <xnox> pitti: he did agree to a split with my on a 1-on-1 on friday.
[10:58] <xnox> pitti: he said, we do need "upstart" & "initctl" (stop, start, restart, status...) to e.g. run user session in a separate package that does not conflict with systmed-*
[10:58] <pitti> xnox: although I wonder whether splitting out upstart-sysv might have been easier
[10:58] <pitti> xnox: as upstart has a gazillion conffiles, migrating them will be a pain
[10:59] <pitti> (argh upstart jobs being conffiles)
[10:59] <xnox> pitti: which i have now done. But i've also split out the telinit, to do clean shutdown with systemd-sysv installed.
[11:00] <xnox> pitti: i've pondered about that. Ultimately, while upstart-sysv is easier split, it's a painful upgrade.
[11:00] <pitti> xnox: oh right, got confused; "upstart" would continue to have the actual jobs, upstart-core just the binaries for session init; gotcha
[11:00] <xnox> pitti: let me check that =)
[11:00] <xnox> pitti: yes, "upstart" should have the system jobs.
[11:02] <saiarcot895> Ubuntu armhf only supports OpenGL ES and not OpenGL, right?
[11:02] <xnox> pitti: well, some conffiles are moved. E.g. etc/X11/Xsession.d and etc/upstart-xsessions will be part of core now.
[11:03] <ogra_> saiarcot895, while no precisely right in that formulation ... yes ...
[11:03] <ogra_> (the drivers that exist for armhf usually only support GLES ... not ubuntu specific )
[11:09] <pitti> xnox: reviewed; thanks for the first iteration!
[11:10] <xnox> pitti: cool. let me push update that moves the system etc/init/ back to upstart package though.
[11:10]  * pitti toddles off for lunch
[11:57] <jdstrand> dholbach: I too agree there is no reason to rev the numbers in lockstep, however, there is probably a reason to rev the main one to whatever the highest one is
[11:57] <jdstrand> dholbach: ie, right now there is ubuntu-sdk-14.10-qml-dev3 but there is only ubuntu-sdk-14.10-dev2
[11:57] <dholbach> jdstrand, maybe we could document this somewhere on the wiki and cross-reference it in the code
[11:57] <jdstrand> dholbach: that is probably a lool question ^
[11:58] <dholbach> just so we always keep everyting up to date everywhere - even if that's now two separate parts of the discussion
[11:58]  * jdstrand wasn't part of the discussions for adding -dev3 this time
[11:59] <jdstrand> dholbach: which code?
[12:03] <dholbach> jdstrand, for now probably just somewhere in ubuntu-touch-meta and click-reviewers-tools
[12:04] <dholbach> we could refer to some wiki page, which explains how to do click framework changes and what to bear in mind, ie where else to update it :)
[12:13] <xnox> pitti: would you be able to write a systemd unit for ubiquity?
[12:18] <pitti> xnox: yes, I can certainly look into that
[12:18] <lool> jdstrand: Yes, I agree with your idea that the main one ought to be bumped too
[12:18] <lool> I guess this could go to the Click frameworks wiki page
[12:19] <pitti> xnox: looks like most of debian/ubiquity.ubiquity.upstart shoudl be refactored into a script; the startup condition is quite straightforward
[12:20] <xnox> pitti: sure. startup conditions are quite straightforward, but it should block starting lightdm until the job completes.
[12:20] <xnox> cause it's a task in ubuntu.
[12:21] <xnox> (well block any/all display managers and reaching multi user target)
[12:24] <pitti> xnox: yes, that can be done with Before=
[12:24] <pitti> xnox: in fact, I just did something similar for friendly-recovery
[12:30] <saiarcot895> If I'm doing a merge for a (existing) bug, does the bug need to have ubuntu-sponsors subscribed as well?
[12:31] <rbasak> saiarcot895: if you're doing a merge proposal on Launchpad (UDD), then no, since that MP causes it to appear in the sponsorship queue.
[12:31] <saiarcot895> rbasak: ok, thought so. Thank you.
[12:32] <rbasak> saiarcot895: maybe best to check on http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html. If your work doesn't show up on there (update timestamp at bottom of table), then certainly subscribe ~ubuntu-sponsors to something.
[12:34] <saiarcot895> rbasak: yup, appeared there just now.
[12:37] <rbasak> saiarcot895: great! Though, that MP seems to include multiple unresolved merge conflicts. You probably want to resolve those.
[12:37] <rbasak> saiarcot895: I'm also a little dubious about fixing something if it still FTBFS. I appreciate your efforts in working this all out, but what's the point in uploading something that will still fail?
[12:38] <rbasak> saiarcot895: also, there some special special sauce to do with GL/GLES on armhf, and I don't recall the details. Maybe ogra_ can confirm the build dep changes for you?
[12:38] <rbasak> (ogra_: https://code.launchpad.net/~saiarcot895/ubuntu/utopic/openscenegraph/armhf-support/+merge/229440)
[13:02] <saiarcot895> rbasak: ah, my bad. I think I checked out the trusty version instead of the utopic version.
[13:03] <saiarcot895> rbasak: The hope is that when freeglut 3.0 is released, everything else (well, at last this package) will be ready to go, and that the source of the problem shifts away from openscenegraph
[13:04] <rbasak> saiarcot895: sure, I get that, and I appreciate your work on this.
[13:04] <rbasak> saiarcot895: I just wonder what the benefit is in uploading these changes now, rather than maintaining a branch until everything is in place, and *then* uploading.
[13:06] <rbasak> I think this question might have been raised before a year or two back, probably in some other package. I don't remember what the conclusion was.
[13:08] <stgraber> sarnold: we'll need to keep that in mind for 14.04.2, 12.04.5 which we are about to release won't have that problem since it'll have the trusty kernel and so will be supported until precise EOL
[13:09] <pitti> bonjour stgraber
[13:10] <pitti> jdstrand: just to avoid misunderstanding -- bug 1341083 is in your pipeline now, and you'd like to review before I upload, right?
[13:10] <pitti> stgraber: anything else you need for the lxc systemd patches?
[13:10] <jdstrand> pitti: it is
[13:10] <stgraber> pitti: time :)
[13:11] <pitti> stgraber: right, that :) I meant further testing, sign-offs, questions, etc.
[13:11] <pitti> stgraber: IOW, anything on my plate, or anything I can help with
[13:11] <stgraber> nope, I think I just need time to look at them and apply them :)
[13:11] <pitti> stgraber: ack, thanks!
[13:17] <saiarcot895> New merge proposal is at https://code.launchpad.net/~saiarcot895/ubuntu/utopic/openscenegraph/armhf-support/+merge/229453
[14:05] <barry> @pilot in
[14:17] <xnox> pitti: more systemd code review requests =)))) https://code.launchpad.net/~xnox/upstart/exec-systemctl/+merge/229467
[14:17] <xnox> i think you will like that one ;-)
[14:19] <pitti> xnox: heh, nice one!
[14:51] <LocutusOfBorg1> thanks barry :)
[14:56] <barry> LocutusOfBorg1: yw! :)
[15:20] <LocutusOfBorg1> barry, do you think you can sponsor also busybox?
[15:20] <LocutusOfBorg1> I can send you the debdiff
[15:20] <barry> LocutusOfBorg1: can you file a bug and attach the debdiff?  i'll try to get to it
[15:24] <LocutusOfBorg1> here we are https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1352413
[15:27] <cjwatson> rolling builder downtime for launchpad-buildd upgrades
[15:29] <shadeslayer> pitti: btw can the nvidia-*-updates package get better one line descriptions?
[15:29] <shadeslayer> that differentiate them from the regular nvidia-* packages
[15:29] <shadeslayer> same for fglrx
[15:30] <shadeslayer> pitti: because the UI shows the same string to the user, and that's confusing
[15:32] <barry> LocutusOfBorg1: cool
[15:37] <kentb> Hi.  I've got a fix for Trusty that needs to be reviewed, please.  Utopic was fixed automatically, but, an SRU for Trusty needs to be pushed out as well.  A debdiff for Trusty is here:   https://bugs.launchpad.net/ubuntu/+source/ledmon/+bug/1349920/comments/6    Thanks in advance.
[15:59] <pitti> shadeslayer: yes, I suppose so
[16:02] <Riddell> jdstrand: security love needed on an upload on bug 1352421
[16:02] <Riddell> debdiff is attached
[16:08] <jdstrand> Riddell: ack, mdeslaur is on community this week, so he can look at it/delegate it. thanks!
[16:09]  * jdstrand subcribes ubuntu-security-sponsors
[16:24] <mdeslaur> Riddell: thanks, I'll sponsor it this afternoon
[16:50] <sarnold> stgraber: thank you (re lts hwe early eols) -- I eventually did find a nice wiki documting it all, but someone who just reads the Obvious News might easily overlook it... (I learned about it on irc, forexample..)
[17:58] <doko> dobey, ubuntu-sso-client ping
[18:53] <barry> LocutusOfBorg1: don't think i'm going to get to busybox unfortunately.  maybe the next pp
[18:53] <barry> @pilot out
[19:07] <sarnold> Trevinho,mdeslaur: 1351616 -- multitouch / gestures / etc. killing X enough to unlock a locked session
[19:09] <mdeslaur> sarnold: looks like a dupe of 1121379
[19:09] <sarnold> mdeslaur: could be. but because that got duped to an N7 xorg bug I'm afraid the whole thing has been forgotten.
[19:10] <mdeslaur> sarnold: I'd undupe 1121379, and dupe the new one to it
[19:10] <hallyn> question: cgmanager-utils currently provides only the script 'cgm'.  That's been turned into a compiled program and will moe to the cgmangaer package;  should cgmanager Breaks/Replaces cgmanager-utils, or Conflicts/Replace it, or just Replace it?
[19:12] <sarnold> mdeslaur: hrm, 1121379 may be about that specific hardware device..
[19:13] <mdeslaur> sarnold: same backtrace
[19:14]  * mdeslaur shrugs
[19:14] <sarnold> mdeslaur: the Xorg error may be the same but if the core 'fix' is to a kernel driver the root cause of the bug might be elsewhere
[19:14] <mdeslaur> sarnold: well, I have no idea, just mark it as confirmed, and leave it rot
[19:15] <sarnold> mdeslaur: hehe
[19:22] <mdeslaur> sarnold: I've changed to to xorg, since that is where the crash is
[19:22] <sarnold> mdeslaur: thanks
[19:43] <hallyn> answering my own questions, looks like provides/conflicts/replaces works best
[19:55] <stgraber> pitti: your changes are now upstream, I'll wait a couple of days for things to settle down before tagging alpha2
[20:39] <hallyn> slangasek: hi, so moving cgm from cgmanager-utils to cgmanager does cause cgmanger to have new libdbus-1-dev and libnih-dbus-dev dependencies.  Any objections to that?
[20:40] <barry> bdmurray, slangasek do you still need me to spend time on LP: #1351018?  looks like it's since been marked incomplete
[20:40] <hallyn> slangasek: in case not i've pushed cgmanager 0.30-1 to mentors
[20:42] <bdmurray> barry: no, not right now. I've a got a handle of sorts on it.
[20:42] <bdmurray> barry: thanks for checking
[20:42] <barry> bdmurray: sure.  sorry i ran out of time on friday, but glad it's not blocking you now
[20:43] <bdmurray> barry: well there is still some issue but it doesn't look like its gdb but apport or the error tracker retracers somehow
[20:44] <barry> bdmurray: ack.  ping me if needed
[21:04] <jdstrand> slangasek: hey, if I use 'schroot -c click-ubuntu-sdk-14.10-armhf ...' on my amd64 and want to build armhf binaries with g++ using that schroot, do I have to specify some special flags to g++?
[21:05] <xnox> jdstrand: well, g++ is native compiler, by default dpkg-architecture -aarmhf variables are pre-exported, such that ./debian/rules build will be cross-compiling.
[21:06] <jdstrand> xnox: right, but I am not building a package, I just want to compile a .cpp file for armhf using that click armhf chroot
[21:06] <xnox> jdstrand: arm-linux-gnueabihf-g++ is the compiler you want, which is just $(DEB_HOST_MULTIARCH)-g++ i believe.
[21:06] <jdstrand> ah
[21:06] <jdstrand> nice
[21:06] <jdstrand> let me try that
[21:07] <xnox> jdstrand: or use cmake =) which will be cross-compiling by default again... due to all the env vars we export.
[21:07] <xnox> jdstrand: generally $(DEB_HOST_MULTIARCH)-g++ should work for native compilations as well, since native toolchain provides those symlinks as well.
[21:08] <jdstrand> right, this is literally a one off compile
[21:08] <jdstrand> I have a .cpp file. I want a binary
[21:08] <jdstrand> :)
[22:54] <slangasek> hallyn: why would cgmanager depending on dbus+nih be a problem?  Those are pretty core dependencies on most systems already, certainly so on anything booting with upstart
[22:55] <hallyn> slangasek: yeah not sure what i was thinking :)
[22:55] <slangasek> ok :)
[23:35] <TheMuso> @pilot in
[23:54] <ScottK> pitti: Do you have suggestions on trouble shooting https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-release-upgrader/lastBuild/ARCH=amd64,label=adt/console ?
[23:54] <ScottK> It seems pretty unrelated to pykde4, which is being held back by the failure.