[00:10] <tran4> I'm a senior CS undergrad. I applied to a company for co-op and intern positions: http://pastebin.com/LdAH6eaZ  Are they good? Should I respond to the recruiter about this job or wait and see if the company contacts me?  I applied thru both. The recruiter's ad lists $14/hr. I live with my parents and they want me to get some work experience this summer. I havent had many replies.
[00:23] <micahg> bkerensa: upstream is either actual xchat upstream or Debian in this case, I just don't think it makes sense for us to carry a binary didd
[00:23] <micahg> *diff
[00:24] <bkerensa> micahg: I understand that but at the sametime I think actual xchat upstream and Debian would not think it would make sense for them to change their package just to satisfy a bug existing in Ubuntu?
[00:24] <micahg> bkerensa: upstream could ship both versions as could Debian if they choose
[00:29] <slangasek> micahg: xchat is already a 3.0 (quilt) package, and there's an existing (and substantial) Ubuntu delta.  Of course this should be upstreamed as far as possible, but why does it hurt to carry a binary diff in the meantime?
[00:29] <slangasek> bkerensa: fwiw I don't see any reason that a high-res icon would be specific to Ubuntu either
[00:30] <bkerensa> slangasek: Ok well I can submit a patch to debian and see if it will be accepted.
[00:31] <micahg> slangasek: well, I guess it wouldn't hurt that much if we ship it in the debian dir and copy it into place, it's just a pain for non-UDD merging :)
[00:31] <bkerensa> micahg: I will put this on my todo list and update the related bug we have
[00:32] <slangasek> micahg: echo path/to/other/binary >> debian/source/include-binaries
[00:33] <micahg> I was personally thinking more along the lines of Debian when I said upstream as xchat upstream for linux seems to have stalled, but I guess the Debian maintainer has as well
[00:33] <slangasek> micahg: ^^ no copying required, just add that line :)
[00:34] <micahg> slangasek: I"m not familiar with that option
[00:35] <micahg> ah, I see now
[01:18] <infinity> bryceh: Did you mean to aim that mesa upload at a PPA instead of the archive?  That's a rather special version number.
[01:19] <Sarvatt> infinity: whoops, guaranteed he did
[01:19] <infinity> Well, here's hoping it doesn't break anything. :P
[01:20] <Sarvatt> it'll be superseded by 8.0.2 in a few days anyway at least and is a good fix :)
[01:22] <bryceh> infinity, aw crap
[01:22] <bryceh> infinity, actually it's the right upload, just wrong version number
[01:22] <bryceh> I should be able to load the proper one over it
[01:22] <infinity> bryceh: No harm done, then.
[01:22] <bryceh> there we go, thanks for catching that
[06:04] <pitti> slangasek: cryptsetup> oops, sorry; I'll commit it
[06:04] <pitti> Good morning
[06:07] <pitti> slangasek: ah, you did already, thanks
[08:05] <dholbach> good morning
[09:08] <dupondje> debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable when updating. What could cause this?
[09:09] <cjwatson> having some other package management program running
[09:09] <cjwatson> perhaps an automatic update you were unaware of, or something like that
[09:10] <dupondje> the automatic update should see dpkg is running, and not interfer imo :)
[09:10] <cjwatson> feel free to debug it locally ... ;-)
[09:26] <ivoks> cjwatson: have you seen bug 880119?
[09:28] <ivoks> cjwatson: i'm not sure if live-build needs to be fixed or syslinux themes
[09:31] <cjwatson> syslinux themes - it's not just a matter of moving them though, it may require actually writing new theme content
[09:31]  * cjwatson isn't sure he has time to look just at the moment
[09:32] <ivoks> cjwatson: thanks... should i use iso-hybrid instead of usb-hdd to workaround this?
[09:32] <cjwatson> I expect it's a workaround, yes; whether it meets your needs I can't say :)
[09:33] <cjwatson> I think my answer is "patches welcome" ;-)
[09:33] <ivoks> scary, but true
[09:33] <ivoks> hehe
[09:34] <ivoks> but it makes live-build unable to create usb images, if i understand this correctly
[09:34] <ivoks> i see what i can do
[09:34] <cjwatson> isohybrid images are valid usb images too ...
[10:05]  * cjwatson eyes desktopcouch and wonders why this didn't completely screw upgrades from maverick
[10:06]  * nijaba grumbles at nasty bug #954793 biting me since this morning 
[10:09] <seb128> nijaba, opening a bug with apport to get a stacktrace would be useful
[10:28] <nijaba> seb128: would gladly do so, but I do not get a crash report, just the graphical environment that restarts everytime I right click.  Any hint on steps that would help
[10:28] <nijaba> ?
[10:29] <seb128> nijaba, can you pastebin your /var/log/apport.log?
[10:29] <nijaba> sure
[10:30] <nijaba> seb128: http://paste.ubuntu.com/883055/
[10:31] <nijaba> smells like compiz.  not sure why it is ignoring it
[10:32] <seb128> nijaba, because it already have a file in /var/crash with a counter > 2
[10:32] <seb128> nijaba, it stops collecting then to avoid triggering apport in loop for stuff which keeps hitting the same bug
[10:32] <nijaba> seb128: k, how can I send what it has?
[10:32] <seb128> nijaba, ubuntu-bug /var/crash/_usr_bin_compiz....
[10:32] <seb128> nijaba, or rm /var/crash/* and get the bug
[10:32] <nijaba> seb128: thanks, doing it now
[10:33] <seb128> nijaba, it should prompt you to report it if there is no staled .crash already there
[10:33] <seb128> nijaba, thank you
[10:35] <nijaba> seb128: it did.  Uploading now.  will come back with new bug# when done
[10:35] <seb128> nijaba, thanks
[10:40] <nijaba> seb128: Bug #954888
[10:46] <seb128> nijaba, seems your issue is bug #808007
[10:47]  * nijaba looks
[10:47] <seb128> dbarth_, ^ can we get somebody to look at that? unity exit for nijaba every time he right click
[10:47] <nijaba> seb128: yep, sounds similar, but with up to date precise and only since today for me.
[10:48] <seb128> nijaba, right, it started getting dups recently it seems
[10:52]  * nijaba goes to a meeting.  back in a couple h
[11:21] <dbarth_> seb128, nijaba: uh, a crasher?
[11:21] <seb128> dbarth_, yeah, some people have unity going down on right click, seems "fun"
[11:22] <seb128> dbarth_, well since nijaba has the issue he can probably help somebody in dx to debug it by provinding infos?
[11:22] <dbarth_> yeah
[11:22] <dbarth_> it's an exception that goes untrapped
[11:22] <dbarth_> rather brutal for an exit
[11:58] <mdeslaur> @pilot in
[12:15]  * dholbach hugs mdeslaur
[13:03] <apw> cjwatson, how is the kernel version which is in the ubuntu-srver images chosed ?
[13:04] <apw> cjwatson, they seem to have 3.2.0-18.28 in them, but .29 was in the archive since monday
[13:05] <cjwatson> http://cdimage.ubuntu.com/ubuntu-server/daily/current/precise-server-i386.list disagrees with you
[13:05] <cjwatson> likewise amd64
[13:11] <apw> cjwatson, people booting them are pasting me output with -28.28 in them ... i will investigate
[13:14] <cjwatson> apw: the kernel version that's booted only changes following debian-installer uploads
[13:15] <cjwatson> apw: I happened to do one of those for other reasons earlier today, although after the daily server build
[13:15] <apw> cjwatson, right but the image only has 18.29 in it, does that mean there is an older kernel in there separate to the one in the manifest?
[13:16] <cjwatson> as I said, debian-installer builds deliver a kernel and an initrd (and other stuff), which is what's used to boot the image
[13:16] <cjwatson> you can't boot an .iso using the kernel in a .deb, it's got to be extracted somewhere
[13:16] <cjwatson> that's done as part of the debian-installer build process
[13:17] <apw> ahhh ... ok ... so its entirly possible that the boot kernel is older, which would fit the behaviour the reporter has
[13:17] <cjwatson> yes
[13:17] <apw> and ... you did one today so the new images in the AM will be updated
[13:17] <cjwatson> tomorrow's daily will have -18.29, yes
[13:21] <nijaba> dbarth_: I am back if can help
[13:21] <apw> cjwatson, thanks for the explanation, added to my checklist
[13:24] <cjwatson> FWIW I don't think we need to rebuild d-i after every kernel upload as a rule; only on ABI changes, before milestones, or if there's some particular installer-relevant fix
[13:39] <dbarth_> nijaba: ok
[14:01] <Laney> tkamppeter: hey, we got a backport request for hplip precise→lucid. Should this be possible? bug #838431
[14:05] <dbarth_> nijaba: can you try downgrading glibmm maybe
[14:05] <apw> jodh, does upstart assume we have pts mounted ?
[14:05] <dbarth_> nijaba: otherwise, what's the test case: you right click anywhere on the screen (app, dash, panel) and it goes kaboom?
[14:06] <nijaba> dbarth_: yes, ANY right click does provoke the crash
[14:06] <nijaba> dbarth_: I can try downgrading now if you want
[14:06] <jodh> apw: for now, yes. I'll be putting a change in soon that disables logging if pts is not available.
[14:06] <apw> jodh, and is that the only thing it uses it for ?
[14:06] <jodh> apw: yes.
[14:07] <seb128> nijaba, when did the bug start?
[14:07] <seb128> nijaba, wget https://launchpad.net/ubuntu/+source/glibmm2.4/2.31.18.1-0ubuntu1/+build/3252325/+files/libglibmm-2.4-1c2a_2.31.18.1-0ubuntu1_amd64.deb
[14:07] <apw> jodh, will our upstart jobs then go ahead and mount it?
[14:07] <seb128> nijaba, try that, restart compiz (or right click that will do it for you) and try again
[14:08] <nijaba> seb128: today, but last update of glibmm seems to date back from 9 March
[14:08] <jodh> apw: currently mountall does that for us if the initramfs hasn't already.
[14:08] <nijaba> seb128: so I think it won't change much
[14:08] <seb128> nijaba, do you update daily?
[14:08] <nijaba> seb128: I do
[14:09] <seb128> nijaba, do you restart daily?
[14:09] <dbarth_> seb128: well, he has restarted unity multiple times because of that crash at least
[14:09] <nijaba> seb128: I did today, and in general yes, but not sure of that over the we
[14:09] <seb128> dbarth_, nijaba: unity 5.6 and new compiz got uploaded on monday, I would blame those
[14:10] <jodh> apw: however, we're seeing evidence of users who are already using (custom) initramfs-less kernels which causes problems for jobs that start before mountall gets /dev/pts mounted, hence the upcoming change.
[14:10] <apw> jodh, so does that mean if i boot --no-log we don't need pts's then ?
[14:10] <jodh> apw: correct.
[14:10] <seb128> dbarth_, nijaba: I guess you got the update yesterday but didn't run the new version before today
[14:10] <nijaba> seb128: very possible.  I was on the road yestday
[14:11] <jodh> apw: the immediate change is to have upstart degrade the console value from "log" to "none" if /dev/pts isn't available, so your jobs output won't get logged in that instance, but the job will atleast run.
[14:11] <apw> jodh, yep ... sounds sensible that upstart should always degrade in some sensible way rather than prevent your machine booting
[14:12] <jodh> apw: the full change would be to have upstart handle mounts of course :)
[14:12] <apw> jodh, yeah that would be nice of course
[14:12] <apw> jodh, we could probabally burn in ubuntu specific mounts ourselves in our version
[14:14] <jodh> apw: right.
[14:21] <nijaba> seb128: dbarth_: confirming that the downgrade of libglibmm does not solve the issue.
[14:21] <seb128> nijaba, ok, thanks
[14:21] <seb128> dbarth_, ^
[14:23] <nijaba> hmmm...  looks like there is is a new unity version available since this morning.  Trying the update
[14:29] <nijaba> drat... no luck
[14:32]  * mpt wonders whether an update removing libiodbc2 is a good or a bad thing
[14:32] <cjwatson> apw: better not to hack it in in advance of full mountall integration, IMO, because it would need a reasonable amount of mountall's code already just to honour fstab mount options for /dev/pts
[14:33] <apw> cjwatson, are our /dev/pts options variable at all ?
[14:33] <cjwatson> we support the user modifying them in /etc/fstab, right no
[14:33] <cjwatson> w
[14:34] <pitti> mpt: good, it's obsolete
[14:34] <apw> cjwatson, could we not let mountall mount -oremount them perhaps
[14:34] <cjwatson> given that they're currently "noexec,nosuid,gid=tty,mode=0620", they aren't so simple that I'd want to rule out anyone modifying them
[14:34] <cjwatson> could we perhaps not mess with this at this stage :)
[14:35] <apw> cjwatson, looking for something to let the 'initramfs less' boot to work, right now it goes pop
[14:35] <cjwatson> jodh's patch to just drop logging for things that happen at that stage in the initramfsless case is the sensible least-impact workaround for precise
[14:35] <cjwatson> apw: jodh already has such a thing; no need to look for more
[14:35] <apw> ok cool
[14:36] <mpt> thanks pitti :-)
[14:36] <slangasek> mpt: it's a good thing...
[14:36] <apw> cjwatson, in better news, devpts does support remount, so you might not need to do it right at inital mount when you get to it
[14:39] <cjwatson> once mountall is integrated into upstart we shouldn't need to worry about that
[14:39] <cjwatson> it can just mount it with the right options from the start
[14:42] <apw> jodh, do you have a bug # for the log changes you are doing, so i can refer to i in my bug ... ta
[14:43] <cjwatson> apw: bug 936667
[14:43] <ogra_> heh
[14:44]  * ogra_ duplicates his pandaboard bug to that then
[14:46] <ogra_> stgraber, hmm, didnt i see you add a fix for the "wait 60sec for the network to come up" issue a while ago ?
[14:49] <stgraber> ogra_: depends on the issue :)
[14:53] <ogra_> heh
[14:53] <ogra_> well, i leave the network unconfigured on my panda during install and it shows the msg (/e/n/i is completely empty post install)
[14:54] <ogra_> (didnt we use to put loopback in there at least)
[14:58] <stgraber> ogra_: you should at least have a loopback in there yes
[14:59] <ogra_> hmm, i dont even have the file
[14:59] <ogra_> but i have a loopback device ;)
[15:30] <dbarth_> nijaba: ok, at least we know it's not coming from there
[15:30] <nijaba> yup
[15:45]  * ogra_ greins and wonders if dholbach follows the meeting 
[15:45] <ogra_> *grins even
[15:46] <ogra_> (i would have done it even without calendar entry ;) )
[15:48] <roaksoax> Hi guys, I have a quick question. Can I have 2 upstart jobs in 1 binary package?
[15:49] <pitti> roaksoax: yes; name it debian/binarypackagename.jobname.upstart
[15:49] <pitti> it'll become /etc/init/jobname.conf
[15:49] <roaksoax> pitti: cool thanks
[15:49] <dholbach> ogra_, in a call
[15:51] <mdeslaur> @pilot out
[15:52] <tkamppeter> slangasek, bdmurray, about bug 911436, it prevents many users from updating CUPS (cupsd simply crashes). Is there a chance that it gets fixed in Precise?
[15:55] <slangasek> yes, it's targeted for precise
[15:55] <slangasek> but that bug certainly shouldn't prevent upgrading
[15:55] <slangasek> all it does is cause crashes *during* the upgrade
[16:06] <SpamapS> you know.. if we were really evil.. we would integrate command-not-found and sl together into one big "for-your-worst-days" package..
[16:16] <pitti> offli
[16:16] <pitti> -EFOCUS, sorry
[16:16] <ogra_> now change your password from offline1 to something new :P
[16:29] <pitti> lol
[16:30] <pitti> offlineimap FTW!
[16:57] <chrisccoulson> dang, i got excited there when i saw the subject of ogasawara's mail "[RFC] Drop Non-smp PowerPC Kernel Flavor" -> I glanced at that and thought i saw "[RFC] Drop PowerPC Flavor"
[16:58] <ogasawara> heh
[16:58] <mdeslaur> die.powerpc.die.die.die
[16:58] <chrisccoulson> yes please
[16:58] <mdeslaur> ogasawara: can't you just push a completely broken powerpc kernel that will get the builders off line permanently? :)
[16:59] <chrisccoulson> i promise that i'm saving up some money to buy our 3 powerpc users a new computer
[16:59] <mdeslaur> chrisccoulson: I may contribute to that fund, I've got some empties to bring back to the store
[16:59] <chrisccoulson> heh :)
[17:02] <infinity> chrisccoulson: Wait, I missed that mail.  -devel?
[17:02]  * infinity goes to look.
[17:02] <chrisccoulson> infinity, yeah, it went to ubuntu-devel
[17:03] <infinity> ogasawara: Do we know if the powerpc-smp kernel will be happy on non-smp hardware (you know, like mine)?
[17:04] <infinity> ogasawara: And does it use the same on-the-fly spinlock->noop rewrite tricks when booting non-smp that x86 uses (which was our argument for dropping x86 non-smp years ago)
[17:04] <cjwatson> infinity: that's related to what I was getting at in my reply, yes ...
[17:06] <ogasawara> infinity: jk did testing to confirm smp kernel should be ok on non-smp hw
[17:07] <infinity> ogasawara: For values of "okay" that probably don't measure performance, but at least it'll boot. :/
[17:07] <ogasawara> infinity: he did mention there could be a small performance degredation
[17:07] <infinity> ogasawara: The reason we dropped SMP on x86 was because of the cute runtime patching bits that noop spinlocks, AFAIK that patch was x86-only.
[17:08] <infinity> ogasawara: The degradation isn't particularly small without that trick in play.
[17:08] <infinity> (And it's nonexistant with the patch, in theory)
[17:08] <ogasawara> infinity: I can ping him to see if he can provide the actual stats
[17:08] <infinity> ogasawara: I know it came up years ago, when we first introduced said patch.
[17:09] <infinity> ogasawara: And given that PPC32UP hardware is kinda slow by default, I'm not sure that making it slower in the name of reducing kernel build time is a pleasant scenario.
[17:10] <infinity> ogasawara: Though, Colin's point that there's a vanishingly small number of PPC32SMP hardware out there might be worth considering, if the build time is really killing us.
[17:10] <infinity> (Or, someone could eBay some PPC hardware for the DC that isn't 10 year old Applie iServes...)
[17:10] <infinity> s/Applie/Apple/
[17:11] <ogra_> they sell 9 year old ones there ?
[17:11] <infinity> :P
[17:15] <ogasawara> infinity: I'd think the number of impacted users would be decreasing.  And selfishly speaking from the teams perspective, powerpc is our bottleneck currently in terms of package preparation.   we can crank out amd64, i386, and arm test builds in under an hour for all flavors
[17:16] <infinity> ogasawara: ARM in under an hour?
[17:16] <ogasawara> infinity: cross compiling
[17:16] <infinity> ogasawara: Cross hardly counts.. You could cross-compile PPC too.
[17:17] <infinity> ogasawara: I realise the goal is rapid turnaround, but there are plenty of packages that take a lot longer than 6 hours, and some us actually do run this hardware. :P
[17:18] <infinity> ogasawara: I don't disagree that we need more CPU time for PPC buildds (and that's bein worked on), but I'm not wildly happy about making my PPC machines slower just to reduce the build time of a package.  Build time is supposed to make sacrifices in the name of better runtime, isn't it?  At least, that's what I learned from compiler hackers. :P
[17:31] <tkamppeter> slangasek, but causing crashes during the upgrade leads to the package installation not concluding and the users reporting bugs.
[17:54] <slangasek> tkamppeter: "users reporting bugs" is a separate issue from whether it actually breaks their system, which AIUI it doesn't
[17:54] <slangasek> bdmurray: bug #911436 is still accumulating duplicates; did you make any progress on debugging the bug pattern?
[17:57] <mhall119> If I have a package in precise universe already, but I want to bump it to a newer version, do I need to file another FFe?
[17:57] <bdmurray> slangasek: oh some recent duplicates are ProblemType: Package and the pattern is for a stacktrace
[17:57] <mhall119> 0.2.1->0.2.2
[17:57] <slangasek> mhall119: yes, https://wiki.ubuntu.com/FreezeExceptionProcess
[17:58] <bdmurray> I'll work on a pattern for it
[17:58] <slangasek> ok, thanks
[18:06] <tkamppeter> slangasek, I did not modify the bug pattern yet.
[18:07] <tkamppeter> slangasek, how do I change the bug pattern?
[18:23] <slangasek> tkamppeter: I think bdmurray has the problem in hand
[18:24] <bdmurray> slangasek, tkamppeter: yes I'll fix it
[18:34] <tkamppeter> bdmurray, slangasek, thanks.
[18:47] <roaksoax> ok :)
[18:47] <roaksoax> lol
[19:21] <slangasek> jibel_: the last two days of upgrades are showing disk i/o errors here - known problem?  https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/
[19:22] <slangasek> jibel_: sorry, not the last two days, just today
[19:42] <slangasek> jodh: bug #955287> this really shouldn't be handled in acpi-support, which is deprecated
[19:43] <slangasek> jodh: the hot v. critical levels are set in the ACPI tables, so are system specific; the kernel is already supposed to step down the CPU when hitting the threshold - does it not do so for you, or is it not enough?
[19:56] <happyface> Wooh, 12.04 runs so good on vmware tech preview
[20:07] <doko> slangasek, for the pycompile error: what did you upgrade? plain CD/DVD installation?
[20:08] <slangasek> doko: this was an auto upgrade test in jenkins; in this case it was "install all of main, then upgrade" - see the referenced URL
[20:09] <doko> wonderful ...
[20:09] <slangasek> doko: so actually, whatever causes it seems to not be included in either the default desktop or server installs - maybe ok to downgrade to 'high' instead of 'critical'
[20:09] <doko> slangasek, I'll look first to improve the diagnostics for beta2
[20:10] <slangasek> doko: right - if you can fix it to get a better error message out, there'll be a daily test every day between now and beta-2 :)
[20:25] <jibel> slangasek, never seen this error before. main amd64 is running, I'll check if it occurs today again.
[20:30] <slangasek> jibel: sounds good, thanks :)
[20:48] <SpamapS> slangasek: heh.. after years of nis not working in lucid.. updates are just a verification away.. hopefully just in time for people to stop using NIS. :)
[20:48] <slangasek> SpamapS: I conclude from the demand for this SRU that people will never stop using NIS
[20:49] <SpamapS> slangasek: yeah, I'm starting to think the same thing about this "PHP" language people are still refusing to let go of.. ;)
[20:49] <Daviey> BURN
[20:50] <Daviey> SpamapS: Maybe we can bump php to universe for 14.04 ?
[20:50] <Daviey> :)
[20:50] <SpamapS> Daviey: ohpleaseohpleaseohplease lets do it
[20:51] <Daviey> Maybe jdstrand would object.. it's keeping them in business
[20:51] <SpamapS> True.. might have to downsize w/o PHP
[20:51] <SpamapS> Though that might free up resources for all the rebuilding that golang will bring! :)
[20:51] <jdstrand> uhh, we have quite a lot keeping us in business. I think not a one of us would shed a tear over not supporting php5 :P
[20:52]  * slangasek sets a target of php6 for 14.04
[20:52] <ajmitch> Daviey: careful, you might get certain sites reporting on it being dropped within a few minutes of suggesting it here
[20:53]  * jdstrand wouldn't shed a tear over php6 either
[20:53] <jdstrand> I'm here all night! :)
[20:53] <SpamapS> slangasek: can we also get free mermaid rides at UDS-T then? ;)
[20:54] <mdeslaur> oh, can we also get the kernel demoted to universe, please?? that one's a bitch
[20:54] <SpamapS> mdeslaur: we'll have to promote something in its place.. kfreebsd?
[20:55] <mdeslaur> SpamapS: we'll all be using keyboards hooked up to the cloud soon anyway...who needs a kernel? :)
[20:56] <Daviey> ajmitch: Good point.. for the avoidance of doubt, i don't think it will be possible...
[21:01] <micahg> ajmitch: Daviey: as an example of a discussion turning into reality before a decision is made: http://www.phoronix.com/scan.php?page=news_item&px=MTA3MDc
[21:02] <mdeslaur> lol, that didn't take long :)
[21:03] <Daviey> heh
[21:03] <barry> slangasek: hi.  would you have time+interest in debugging an installation problem w/today's 12.04 live cd on a thinkpad x130e?
[21:04] <broder> ajmitch, Daviey, micahg: for UDS i'm planning to start a (clearly labeled) twitter account that consists entirely of highly controversial decisions that didn't happen and see how long it takes for something to show up on omg or phoronix
[21:06] <slangasek> barry: I can give it a shot
[21:06] <Daviey> broder: hah
[21:06] <ScottK> slangasek: Make him get rid of /usr/bin/python2 first.
[21:07]  * slangasek chuckles
[21:07] <barry> slangasek: there's a machine here where the installer eventually just hangs the whole machine.  we think it's a memory starvation problem with ubiquity.  3.02g RES right now and *very* slow response at the virtual console.  any suggestions on how we might debug the problem (we're looking at ps output and nothing relevant shows up in the various logs)
[21:07] <barry> ScottK: ;)
[21:08] <barry> yeah, keyboard input is slooooooooooooooooooooooooooooooooooow
[21:08] <slangasek> 3.02g res> !!
[21:08] <barry> killing ubiquity restored responsiveness, but of course crashed the installer :)
[21:08] <tumbleweed> broder: :)
[21:08] <slangasek> not really meant to do that
[21:08] <slangasek> hmm
[21:09] <barry> can we re-run ubiquity with more debugging?
[21:10]  * barry suspects he'll learn all the tricks next week :)
[21:10] <slangasek> yes, I think there's a --debug flag
[21:10] <ajmitch> broder: that twitter account sounds like an excellent idea
[21:11] <broder> i think the biggest risk is actually reporting something true :-P
[21:12] <ajmitch> broder: I'll be sure to RT it then
[21:22] <slangasek> barry: does --debug work?
[21:23] <barry> slangasek: not so much.  didn't really help get a clue as to what's going on.  it just looks like it's leaking memory.  he's going to ping me next week so maybe we can drill into it some more then.
[21:23] <slangasek> ok
[21:24] <slangasek> next week should be a good time for it :)
[21:26] <barry> slangasek: yep! :)
[21:34] <jodh> slangasek: I've changed pkg for bug 955287 to linux. For my Thinkpad, the kernel does not DTRT: it forcibly reboots when the CPU temperature reaches 128C! ;)
[21:35] <slangasek> jodh: do you have the same buggy acpi tables that I do (command to check posted to the bug)?
[21:37] <jodh> slangasek: just posted comment - my tables look sane. I've been running a tool cjking pointed me to (tp-thermstat) to help him track down the problem (bug 751689).
[21:38] <slangasek> jodh: huh, alrighty then
[21:39] <slangasek> jodh: do you see any change in behavior when you hit the passive threshold?  fans spinning up, or cpu stepping down?
[21:39] <slangasek> jodh: fwiw, in the end I've worked around all my problems by changing my performance profile in the BIOS - before that I was overheating nearly every time I compiled anything interesting, now my compiles just take longer instead
[21:40] <jodh> slangasek: just forwarded you the info. Difficult to say - whenever I hit the problem, I seem to have headphones on :) Will try tests in more controlled environment tomorrow.
[21:40] <slangasek> ok :)
[21:41] <jodh> slangasek: a possible solution is apparently for me to upgrade my bios. I may try that. I'd seen 751689 some time (releases) back, but hadn't been affected by it again until trying to compile eglibc with a few kvms running.
[21:41] <jodh> gotta dash - will get more info tomorrow...
[21:41]  * slangasek waves
[22:06] <bdmurray> slangasek: so I've written a package install pattern for bug 911436 but I don't think its very specific
[22:06] <slangasek> bdmurray: what's it look like?
[22:08] <slangasek> oh; the duplicate bugs don't even show why the job failed to start, do they :/
[22:08] <bdmurray> ah, but dependencies.txt might help
[22:09] <bdmurray> libp11-kit0 0.10-1 as part of the pattern should do it
[22:10] <bdmurray> slangasek: thanks for the help ;-)
[22:10] <slangasek> my pleasure :-)