=== zyga is now known as zyga-afk
[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?
=== dendro-afk is now known as dendrobates
[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
=== cpg is now known as cpg|away
[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
=== cpg|away is now known as cpg
=== cpg is now known as cpg|away
[06:05] <pitti> Good morning
=== cpg|away is now known as cpg
[06:16] <TheMuso> c
=== doko_ is now known as doko
=== Ursinha is now known as Guest51695
=== cpg is now known as cpg|away
[06:59] <dholbach> good morning
=== smb` is now known as smb
[08:31]  * xnox notes should not try to do too many things simultaneously, otherwise typos happen....
=== Guest59153 is now known as kklimonda
[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] <ubottu> Debian bug 569952 in buildd.debian.org "Please let libunwind build on i386 and amd64" [Normal,Open]
[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
=== cpg|away is now known as cpg
[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
=== cpg is now known as cpg|away
[09:57] <tumbleweed> RAOF: ping on bug 950963: what's the chance of providing compatibility with Debian packages depending on libcuda / libopencl?
[09:57] <ubottu> Launchpad bug 950963 in viennacl (Ubuntu) "nvidia-graphics-drivers needs to provide separate packages such as libcuda1" [High,Confirmed] https://launchpad.net/bugs/950963
[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:03] <ubottu> Launchpad bug 763457 in nvidia-graphics-drivers (Ubuntu) "please provide opencl-icd virtual package" [Medium,Confirmed] https://launchpad.net/bugs/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:04] <ubottu> Launchpad bug 763457 in nvidia-graphics-drivers (Ubuntu) "please provide opencl-icd virtual package" [Medium,Confirmed] https://launchpad.net/bugs/763457
[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
=== MacSlow is now known as MacSlow|lunch
=== glebihan_ is now known as glebihan
[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...
=== zyga is now known as zyga-afk
=== zyga-afk is now known as zyga
=== _salem is now known as salem_
[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!
=== MacSlow|lunch is now known as MacSlow
[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
=== zyga is now known as zyga-food
[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] <ubottu> If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[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
=== fenris is now known as Guest37369
[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:47] <ubottu> Launchpad bug 1006898 in dnsmasq (Ubuntu Precise) "[SRU] dnsmasq fails at leasing issues when using vlan mode" [Medium,Triaged] https://launchpad.net/bugs/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
=== zyga-food is now known as zyga-afk
=== vibhav is now known as vibhavOne
[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?
=== cpg|away is now known as cpg
[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:17] <ubottu> Debian bug 679819 in python-qt4 "Dropping Provides field broke depending software (python-avogadro)" [Serious,Open]
[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
=== salem_ is now known as _salem
[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?
=== jedney is now known as JonEdney