[01:00] <pp7> anyone else have suspend problems since last update?
[01:01] <ajmitch> pp7: what sort of problems are you seeing? I haven't had a chance to file a bug about it yet
[01:02] <pp7> ajmitch, well it wont suspend at all anymore
[01:02] <pp7> i just have a script that calls pm-suspend after locking the screen but it doesnt suspend, just goes to lock screen
[01:03] <ajmitch> a different problem than what I've been seeing. I'd file a bug with 'ubuntu-bug linux'
[01:03] <pp7> mm k
[01:05] <lifeless> there is a dbug page
[01:05] <lifeless> debug page for debugging whats going on
[01:05] <lifeless> I'd run through it quickly, I forget the URL.
[01:06] <ajmitch> https://wiki.ubuntu.com/Kernel/Debugging perhaps
[01:07] <pp7> k
[02:16] <vibhav> mterry: Do we need 02_fix_install_path.patch in https://launchpad.net/ubuntu/+source/gbirthday/0.6.5-1ubuntu1 for quantal too?
[03:27] <OdyX> n
[03:41] <pp7> is there anything wrong with running echo -n "mem" > /sys/power/state on its own to suspend?  I just did it and it came back fine but i'm wondering if something will get screwed up next time
[03:47] <OdyX> pp7: besides you don't benefit from all the preparation pm-suspend does for you, no.
[04:15] <pp7> what preparation?
[04:15] <pp7> i am doing this because pm-suspend now does nothing after latest update
[04:51] <slangasek> pp7: pm-utils runs a series of scripts to set the hardware in a correct state before and after suspend (/usr/lib/pm-utils/sleep.d/); on some hardware, skipping these makes resuming from suspend fail completely, on others it might just mean your machine is in a suboptimal state after resume
[04:52] <slangasek> pp7: if pm-suspend is failing for you, you might want to check /var/log/pm-suspend.log
[05:03] <pp7> slangasek, yea i checked that but nothing useful, says it was successful when it wasn't
[06:05] <pitti> Good morning
[06:16] <TheMuso> c
[06:59] <dholbach> good morning
[08:31]  * xnox notes should not try to do too many things simultaneously, otherwise typos happen....
[08:46] <jamespage> can someone help me understand why this package - https://launchpad.net/ubuntu/+source/libunwind/1.0.1-1ubuntu1
[08:46] <jamespage> is only building for i386 and amd64? I was expecting powerpc and armel as well...
[08:52] <seb128> jamespage, P-a-S has "%libunwind: ia64 i386 amd64 ppc64"
[08:52] <seb128> jamespage, https://code.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu
[08:53] <seb128> jamespage, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569952
[08:53] <seb128> jamespage, I guess you need to tweak that if it can build on powerpc,armel nowadays
[08:54] <jamespage> seb128, thanks for the pointer - I still seem to learn something new every day on this project :-)
[08:56] <jamespage> seb128, I'll test those two architectures first and enable if it looks OK
[08:57] <seb128> jamespage, sounds good
[08:57] <seb128> jamespage, you might want to file a bug for Debian to do it as well if it works on those archs
[08:58] <jamespage> seb128, ack
[09:57] <tumbleweed> RAOF: ping on bug 950963: what's the chance of providing compatibility with Debian packages depending on libcuda / libopencl?
[10:00] <xnox> tumbleweed: RAOF: this looks familiar
[10:01]  * tumbleweed prodded RAOF about it at UDS. He suggested Provides, but IIRC some packages have versioned dependencies
[10:02] <tumbleweed> it's making the scientific computing people sad :)
[10:03] <xnox> tumbleweed: there is a similar request for opencl
[10:03] <tumbleweed> unsuprisingly
[10:03] <xnox> tumbleweed: bug 763457
[10:04] <xnox> tumbleweed: RAOF: i have pinged tseliot about bug 763457 and he said it should be easy to do for opencl, but I am not sure about the cuda bits.
[10:05] <xnox> the opencl stuff came up as part of boost1.49 transition
[10:05] <tseliot> xnox: last time I checked, the cuda package in debian needed some work to include it in Ubuntu
[10:06] <tumbleweed> our nvidia driver packages include libcuda, don't they?
[10:39] <mhr3_> doko, hey i hear you can help me with valgrind-related issue
[10:40] <mhr3_> doko, so, it's pretty simple - callgrind_control doesn't work for us, cause there's a regex which fails, any chance to patch it?
[10:40] <mhr3_> (it's just a perl script)
[10:41] <mhr3_> it fails cause it expects valgrind to be valgrind, yet it's valgrind.bin for us
[10:54] <jamespage> seb128, I am correct in thinking that I 1) push the required changes to the p-a-s branch and then 2) upload a new version to enable the new archtectures?
[10:55] <cjwatson> Yes
[10:55] <cjwatson> Wait a bit in between though
[10:55] <cjwatson> (Also send the patch to Debian, Package: buildd.debian.org, if it applies there too)
[10:55] <cjwatson> "a bit" here is an hour or so:
[10:55] <cjwatson> 15 * * * *  cd /srv/launchpad.net/builddmaster/pas-bzr/ && bzr up -q
[10:56] <jamespage> cjwatson, yep - I just finished testing on powerpc and arm*
[10:56] <jamespage> I will submit patches for fixing arm* and enabling in debian
[11:12] <doko> mhr3_, what to send a patch?
[11:14] <mhr3_> doko, i just did
[11:14] <mhr3_> $ diff callgrind_control.old callgrind_control
[11:14] <mhr3_> 32c32
[11:14] <mhr3_> <       if (/^use --pid=(\d+) for \S*?valgrind\s+(.*?)\s*$/) {
[11:14] <mhr3_> ---
[11:14] <mhr3_> >       if (/^use --pid=(\d+) for \S*?valgrind\S*?\s+(.*?)\s*$/) {
[11:15] <mhr3_> sorry, didn't do the pkg-foo
[11:15] <doko> mhr3_, I'm travelling, so please put it into a bug report for now
[11:16] <mhr3_> ok
[11:34] <gigix> Hello everyone. I'd like to contribute to the development of Ubuntu, read quite a few articles and wiki pages about how to do so, but I am still a bit confused about where to start. Could you guys share thoughts about a recommended path for 1st time contributors ?
[11:38] <ev> mpt: yay, I just landed hanging application support in apport. I'll let you know when it's in the archive so you can poke around the UI and make sure it meets your expectations. Just need to land my compiz branch now and we're there.
[11:39] <ev> much thanks to pitti for the steady stream of thorough code reviews
[11:39] <mpt> ev, does it require a Q installation?
[11:39] <ev> mpt: hmm, probably not
[11:39] <ev> I can throw it in a ppa for precise
[11:40] <ev> and we can evaluate backporting to get data from 12.04.1 users
[11:50] <jamespage> anyone aware of any issues with the 3.5.0-3 kernel in quantal?  I get 0 peripherals including network, usb, monitor etc...
[12:59] <pitti> ev: FYI, I have a build recipe for apport's trunk
[13:11] <pitti> ev: FYI, bumping apport's version to 2.3, as it has new features (should have done this before already)
[13:14] <ev> pitti: cheers!
[13:56] <smb> cjwatson, While meddling around trying to figure kdump, I took the opportunity to do a merge of kexec-tools from Debian. Since you uploaded it last, I wanted to let you know and also ask how you would prefer me to go on. LP bug and subscribe you or just generic sponsors?
[13:56] <cjwatson> Go ahead; just generic sponsors, I have no attachment to it
[13:57] <smb> ok
[14:41] <PaoloRotolo> Hi all
[15:03] <zyga-food> mvo, hey, what decides that apt-get install selects a package from precise vs precise-backports? (when both repositories are enabled)
[15:07] <stgraber> zyga-food: -backports is marked as NotAutomatic and ButAutomaticUpgrades. So apt will never select a package from it unless explicitly asked to do so, but once a package is installed from it, apt will continue pulling updates from -backports.
[15:08] <zyga-food> stgraber, interesting, how would one install a package from backports? with explicit version provided to apt?
[15:08] <Laney> zyga-food: apt-get install foo/precise-backports
[15:08] <zyga-food> stgraber, and once you actually get that package, does it 'unlock' all other backport packages or just the package (name) that was installed
[15:08] <zyga-food> ah
[15:08] <zyga-food> interesting
[15:09]  * zyga-food is trying to install something from backports and managed to do it with apt-get install foo=very-long-version
[15:09] <Laney> that works too
[15:09] <zyga-food> where can I read about it?
[15:09] <Laney> !backports
[15:09] <zyga-food> I'd like to understand how that works
[15:09] <zyga-food> thanks!
[15:15] <pitti> apw, ogasawara: is it planned to apply our remaining Ubuntu delta of module-init-tools to kmod and move to that?
[15:15] <apw> pitti, i don't think we've done anything other than think that it was a good idea
[15:16] <apw> i am sure its where most peopel are going
[15:18] <pitti> apw: kmod should be backwards compatible from what I can tell; the "upgrade quirks" are most probably obsolete anyway after precise's release, so we just have some modprobe.d/ customizations
[15:18] <pitti> you can't build systemd and newer udev without it, that's why I'm asking
[15:22] <apw> pitti, heh ... well then our hand is forced, i can put it on my list
[15:23] <pitti> apw: alternatively we could modify the Debian source package to not build the transitional module-init-tools package
[15:23] <pitti> but it seems to be the official successor, also in debian
[15:24] <apw> pitti, yep i think we want to change if we can, i'll look at it next
[15:24] <pitti> apw: cheers! hopefully our delta is not too big
[16:38] <micahg> xnox: why not just let mongodb fail than disabling it? (failure is a sign to fix)
[16:40] <xnox> micahg: it's a toolchain issue, with bugs filed with tag boost1.49
[16:40] <micahg> xnox: so what?
[16:40] <xnox> it's one of the 3 remaining packages to remove boost1.46 from the archive
[16:41] <micahg> xnox: and, as much as it would be nice to have boost1.46 gone, at this point in the cycle, it doesn't matter that much
[16:41] <micahg> xnox: also, you can remove the binaries without disabling the build
[16:42] <gmi> can anybody confirm if a new version of dnsmasq-base was added to precise-proposed? it was reportedly added around June 15th but I cannot seem to find it; the only version is 2.59-4 and I'm looking for 2.61
[16:43] <micahg> xnox: when you disable the build, it no longer shows up here: http://qa.ubuntuwire.com/ftbfs/, so no one sees that there is an FTBFS bug to fix
[16:44] <micahg> gmi: 2.62-3 is in quantal, it's unlikely that 2.61 would be uploaded to precise
[16:46] <gmi> micahg: Chuck Short sent an email on the openstack mailing list on June 15th about uploading a fix to a dnsmasq bug affecting Ubuntu Precise users to the precise-proposed repo, but I don't see any new new version being available
[16:47] <zul> gmi: no i said we are working on it...still working on it
[16:47] <micahg> bug 1006898
[16:48] <gmi> zul: the email was worded differently, but if I have to wait I'll wait http://openstack.markmail.org/search/?q=or%20those%20who%20are%20affected%20by%20the%20dnsmasq%2Fvlan%20issues%20on%20Ubuntu%2C%20I%20have%20uploaded%20a%20fix%20for%20precise-proposed.%20It%20should%20be%20available%20for%20testing%20of%20the%20fix%20soon.%20You%20will%20have%20to%20turn%20on%20%22precise-proposed%22%20on%20your%20servers%20to%20test%20the%20f
[16:48] <micahg> gmi: it was uploaded and rejected, see the bug for more info
[16:53] <gmi> micahg and zul: thanks for the update; I'll be patient and wait for the update to land in precise-proposed
[16:53] <micahg> BenC: thanks for the PPC patch for Firefox
[16:55] <BenC> micahg: No problem
[17:19] <xnox> micahg: I know that. I will have arm hardware in 1.5 weeks, and I'm planning on making them build again.
[17:20] <xnox> micahg: but you do have a point, now that armhf builds, there is little point in not keeping armel as FTBFS
[17:26] <micahg> xnox: also, something to keep in mind is Ubuntu isn't like Debian (yet) where we have to worry about binaries migrating
[17:36] <xnox> micahg: but i can't remove the source package without binaries...
[17:36] <micahg> xnox: huh?
[19:11] <micahg> jamespage: doko: is it time to flip the openjdk 7 plugin to main in quantal?
[19:14] <micahg> jamespage: doko: I mean switch the openjdk7 version to be default (and what icedtea-plugin pulls in)
[20:06] <jamespage> micahg, I think so; the java alternates need to be updated as well to favour java7 over java6 when both are installed.
[20:06] <jamespage> doko, I think I'm correct in what I say above ^^
[20:11] <cousteau> so...  could someone please fix the problem on nvidia-96?
[20:11]  * cousteau is considering the possibility of just opening the package and deleting the xorg-video-10-abi line
[20:12] <micahg> cousteau: the person I poked is off today
[20:13] <cousteau> ok
[20:13] <cousteau> but it's a work in progress then
[20:13] <cousteau> ok...  I've not upgraded to precise yet but when I do I don't want to be installing the Nvidia drivers manually again
[20:13] <micahg> cousteau: I would do it myself, but I'm not sure if it needs more than a rebuild r not
[20:14] <cousteau> (also another IRC user happens to have exactly the same graphics card model as I do...)
[20:14] <cousteau> maybe the install can be forced by telling dpkg to ignore missing dependencies?
[20:16] <stgraber> ScottK: around?
[20:16] <ScottK> stgraber: Yes.
[20:17] <stgraber> ScottK: Edubuntu has failed to build for a few days now because of python-avogadro not being installable
[20:17] <stgraber> ScottK: as it depends on python2.7-qt4
[20:17] <stgraber> which doesn't seem to exist
[20:17] <ScottK> The Debian avogadro maintainer and I are arguing about that very point.
[20:17] <ScottK> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679819
[20:18] <stgraber> based on germinate output, I should be able to avoid python-avogdaro by changing the libavogadro1 recommends but I'm open to better solutions, as long as we get Edubuntu buildable again quickly :)
[20:18] <highvoltage> thanks ScottK :)
[20:18] <ScottK> It's easy enough to fix in either avogadro or PyQt.
[20:19] <ScottK> I think fixing it in avogadro is better, but as you can see if the bug the avogadro maintainer has not agreed.
[20:19] <ScottK> The needed diff for avogadro is in the bug.
[20:19] <ScottK> Fixing PyQt makes even less sense in Ubuntu where there's only one Python version.
[20:20] <stgraber> ok, I'll upload the avogadro change in Ubuntu, and once people are done fighting we'll use whatever they decide :)
[20:20] <ScottK> Sounds good.
[20:28] <xnox> stgraber: what avogadro changes? =)
[20:30] <ScottK> xnox: Look in the bug I referenced.
[20:34]  * xnox was offline.... looking up irclogs..
[20:37] <Laney> lesson: never go offline
[20:41] <doko> jamespage, yes the priorities need an update.
[20:46] <micahg> jamespage: so, can you fix up icedtea-web then?
[20:46] <micahg> xnox: what did you mean before about removing sources with binaries?
[20:47] <jamespage> micahg, I can but not immediately - I have a few other things I need to clear first
[20:47] <micahg> jamespage: sure, no rush, just want to make sure someone's taking it :)
[20:49] <xnox> micahg: mongodb is part of boost1.46 -> boost1.49 transition.
[20:49] <xnox> it's one of the last 4 packages
[20:50] <xnox> can i remove boost1.46 sources, while keeping the remaining boost1.46 binaries which mongodb old version depends on in precise (and copied into quantal)
[20:50] <ScottK> xnox: In that case no you can't.
[20:50] <micahg> xnox: right, but you can remove the offending armel binary without disabling the build
[20:50] <ajmitch> there are probably good (legal) reasons why you can't remove the source if binaries still exist
[20:55] <xnox> micahg: that's why I disabled armel build, as far as mongodb armel build goes: either upstream should finally support things that are not *-x86, or armel toolchain needs target profile changes.
[20:55] <xnox> it doesn't look like either of fixes will happen any time soon.
[20:56] <micahg> xnox: right, but it was established that it's a toolchain bug that should be fixed, not an upstream issue, and the FTBFS reminder makes it more likely for some +1 maintenance person like infinity to actually fix it
[20:59] <ScottK> I can remove binaries on a single arch if neeeded.
[21:14] <xnox> ok. thanks.
[21:14] <xnox> I will fix player and give another round to ball, before comming back to this
[22:11] <xnox> ScottK: interesting maintainer of avogadro...
[22:13] <ScottK> Yes.
[22:53] <alazare619> anyone here build ubuntu 12.04 from scratch using live-build?