[00:45] <bluefoxicy>  1531 root      20   0  350m 166m  11m R   85  4.5   0:27.97 update-apt-xapi
[00:45] <bluefoxicy> what is this process
[00:49] <cjwatson> update-apt-xapian-index
[00:52] <bluefoxicy> cjwatson:  it eats a LOT of CPU, for reasons I'm not sure of.
[06:31] <lucidfox> bluefoxicy, I also ran into that problem
[06:31] <lucidfox> with update-apt-xapian-index hogging CPU
[06:33] <ohsix> slow drive / lots of files? it's ran periodically and niced; it will use some cpu to do its work
[07:07] <lucidfox> "Some" CPU? More like 99%
[07:07] <lucidfox> not on this computer, on my work one
[07:08] <lucidfox> Also, what's with the build failures?
[07:09] <lucidfox> actually, wait
[07:10] <lucidfox> hrm
[07:10] <lucidfox> https://launchpadlibrarian.net/72114285/buildlog_ubuntu-oneiric-i386.steadyflow_0.1.6-0ubuntu1_FAILEDTOBUILD.txt.gz
[07:10] <lucidfox> any idea why this is failing?
[07:10] <lucidfox> The following packages have unmet dependencies:
[07:10] <lucidfox>  libnotify4-dev : Depends: libnotify4 (= 0.7.2-0ubuntu2) but it is not going to be installed
[07:15] <lucidfox> oh right, libnotify4 was removed from oneiric while the package was in NEW? o_O
[07:29] <ohsix> lucidfox: run it manually and see what it's doing
[07:30] <ohsix> if it isn't i/o bound i don't see why it wouldn't use the cpu available
[07:30] <lucidfox> Well, I fixed it already. It failed because libnotify4-dev was not completely removed from oneiric yet, and the buildd never even considered libnotify-dev
[07:30] <lucidfox> I've removed libnotify4-dev and left only libnotify-dev
[07:32] <ohsix> interesting
[08:09] <lucidfox> ...oh what now... dput is not accepting my signature
[08:12] <lucidfox> Huh, but it did upload
[08:13] <lucidfox> dput complained on .changes about "verification failed 3 times (no public key)", but then I received a mail saying the package did get accepted
[08:37] <Laney> launchpad bug
[09:56] <pitti> hallyn: libcap2> getting it through autosyncs is deal IMHO
[09:56] <pitti> broder: ah, thanks for confirming; that was my impression, too
[09:57] <pitti> SpamapS: ok, will do a round of SRU
[09:59] <cjwatson> doko_: may I merge eina?
[10:00] <doko_> cjwatson: sure, merge anything you can't resist =)
[10:00] <cjwatson> heh, just trying to reduce the FTBFS list a bit
[11:14] <apw> anyone else seeing issues with uploads to ubuntu ?
[11:15] <cjwatson> apw: if it's just verification-failed messages, ignore them
[11:16] <cjwatson> it's a known LP bug
[11:16] <cjwatson> your upload was successful
[11:16] <cjwatson> (I checked)
[11:17] <apw> cjwatson, ahh thanks
[11:38] <cjwatson> oh, for goodness' sake - eina is failing a test of some silly joke function
[11:38] <cjwatson> and doesn't fail on the porter box
[16:00] <bluefoxicy> does Cool'n'Quiet work in Ubuntu?
[16:00] <bluefoxicy> I heard you need powernow-k8 loaded in the kernel
[16:01] <bluefoxicy> which is compiled in
[16:11] <hv> is appmenu not working properly at the moment (oneiric)?
[16:56] <bluefoxicy> yay
[16:56] <bluefoxicy> my 31 line bash script to monitor my CPU temperature works!
[16:56] <bluefoxicy> now if my computer is at risk of overheating, it'll send SIGSTOP to a bunch of stuff and then wait for it to cool down.
[16:59] <ion> How about fixing the cooling instead? :-)
[16:59] <bluefoxicy> ion:  I tried that, too :)
[17:00] <bluefoxicy> i suggested also that maybe a small daemon that throttles back the system in interesting ways when the threat of overheating is present would be useful, and people were vehemently against the idea of software fixing a hardware problem
[17:00] <ion> I should do that for my laptop. The thermal grease probably needs reapplying.
[17:00] <bluefoxicy> The discussion kind of broke down after I recommended to the entire mailing list to remove everything tied to "fsck" since the real solution is to fix your disk/power source
[17:01] <bluefoxicy> there's also that silly checksum thing in the kernel, that checks if dirty blocks are corrupted (due to bad RAM) before writing them back to disk; again, the real solution is to replace the faulty RAM ...
[23:30] <bcurtiswx> i have a 32 bit build machine, is there any way to get it to build a 64 bit debian pacakge ?
[23:31] <penguin42> I don't see why you can't cross build it
[23:33] <bcurtiswx> so how do I do that exactly?
[23:33] <slangasek> it's quite non-trivial today
[23:33] <bcurtiswx> slangasek, hmm, is there a wiki page I should be referencing?
[23:34] <penguin42> bcurtiswx: http://wiki.debian.org/BuildingCrossCompilers is one
[23:34] <penguin42> bcurtiswx: Then there are various bits of magic to actually build the packages - none of them are particularly pretty
[23:34] <penguin42> bcurtiswx: xdeb/xapt is the one I've used
[23:34] <penguin42> bcurtiswx: And it doesn't work for all packages
[23:34] <bcurtiswx> penguin42, OK thanks for the links/help :)
[23:35] <penguin42> bcurtiswx: Good luck
[23:35] <slangasek> in theory, an x86_64-linux-gnu-gcc wrapper that simply calls 'gcc -m64 "$@"' would be sufficient, provided that gcc-multilib is installed
[23:35] <cjwatson> FWIW xdeb and xapt are entirely separate projects
[23:36] <slangasek> but actually getting the 64-bit dependencies where you need them requires something like xdeb at the moment, yes
[23:36] <penguin42> yeh? Oh i'd assumed xapt used xdeb
[23:36] <directhex> do they work?
[23:36] <penguin42> directhex: Depends on their mood
[23:37] <bcurtiswx> i thought maybe pbuilder had a special way to create a 64bit build env
[23:37] <cjwatson> no, both xdeb and xapt use dpkg-cross, but they have different philosophies
[23:37] <cjwatson> ultimately, we hope both will be replaced by stage<whatever> multiarch
[23:38] <slangasek> bcurtiswx: the only 64bit build env you can create with pbuilder per se is a *native* 64-bit env; if your machine (or your kernel) is 32-bit, that won't be usable
[23:38] <directhex> you can do 64-bit kernels on 32-bit debian. but afaik not on ubuntu
[23:38] <bcurtiswx> slangasek, yeah that makes sense.  Was worth a thought at least
[23:38] <cjwatson> though, I mean, it's basically the same idea, grab all the dependencies, cross them, install them, build
[23:39] <penguin42> cjwatson: I don't think I'd succeeded in getting xdeb to fetch dependencies for me
[23:39] <cjwatson> xdeb tries to do more work for sequences of builds and is more willing to apply heuristics to get there
[23:39] <slangasek> directhex: well, you can in that you can cross-install an amd64 kernel on your system using multiarch ;P
[23:39] <cjwatson> it worked for me when I wrote it, but it's been a while since I did any work on it :-)
[23:39] <cjwatson> it's wookey's problem nowadays
[23:40] <bcurtiswx> information overload here :) hehe, i appreciate the help tho :)
[23:41] <penguin42> bcurtiswx: What was the package out of interest?
[23:44] <bcurtiswx> penguin42, i've rebased seahorse 3.0.0 with debian, it built and I wanted to test it on my 64 bit machine.. i was hoping there was a "fairly easy" way to cross build, but my laptops quite powerful and i'll just build it on here :)
[23:44] <bcurtiswx> i don't have upload, so i wanted to really verify this package was built well before i went requesting a merge
[23:44] <penguin42> oh I wouldn't give that a good chance of crossbuilding
[23:44] <penguin42> but I'm a pessimist
[23:45] <bcurtiswx> haha, hence my building on my 64 bit laptop
[23:45] <cjwatson> bcurtiswx: you can use a PPA too, if you like
[23:46] <bcurtiswx> cjwatson, yup, i have empathy 3.1 on that for interested parties to test, and if i didn't have the immediate availability to this laptop i would
[23:47] <lfaraone> cjwatson: so in https://launchpad.net/ubuntu/+spec/foundations-o-apt-mirror-method, we'd just use mirror:// rather than having a mirror picker?
[23:47] <cjwatson> lfaraone: yes
[23:47]  * bcurtiswx waves to lfaraone
[23:47] <cjwatson> or at least rather than requiring a mirror picker - we're not out to destroy people's choice, just to make things work better without everyone having to choose
[23:48] <lfaraone> cjwatson: but would software-properties still have a static list, or would it source its list of mirrors from the mirror method?
[23:48] <cjwatson> I would hope that it wouldn't matter any more
[23:48] <cjwatson> but you'll have to ask mvo, I don't know the details of software-properties
[23:48] <cjwatson> I'm mostly involved in that spec to ensure that the installer is synced up
[23:48]  * penguin42 hopes it requires a signed reply to the list of mirrors
[23:49] <lfaraone> penguin42: why would that matter?
[23:50] <lfaraone> penguin42: if I can MITM the mirror list, I can MITM whichever mirror you select anyway.
[23:50] <penguin42> yeh I guess so
[23:50] <lfaraone> that's why we have http://wiki.debian.org/SecureApt
[23:51] <cjwatson> I suspect, without having asked, that mvo is no great fan of having to keep a static list of mirrors; but we don't have a specific work item for replacing it
[23:54] <highvoltage> jbicha: congrats on the membership! I thought you were one already :)
[23:55] <lfaraone> hey bcurtiswx
[23:55] <lfaraone> cjwatson: hmm. well, I could do that, I guess. If the mirror:// list was defined somewhere, I could just add a hook to software-properties to poll it whenever you go to change the mirror.
[23:59] <jbicha> highvoltage: thank you, I should have applied sooner