[00:09] <psusi> cjwatson, will that partman-auto fix automatically make its way into ubiquity, or does more work need done?  ( or did you already do it? )
[00:14]  * stgraber really hates race condition ... it's been 10 boot that pub doesn't get any event
[00:31] <stgraber> cjwatson: updated bug 752393 with some more examples and thoughts. I'll change the package from lsb to plymouth as it seems to be a plymouth issue.
[00:32] <cjwatson> ok
[00:32] <cjwatson> I'm going to bed shortly, will look tomorrow
[02:34] <cjwatson> The archive mirrors aren't updating right now.  IS are aware
[07:18] <pitti> Good morning
[07:22] <cdbs> Good morning pitti
[07:22] <cdbs> pitti: How was your weekend?
[07:26] <pitti> hey cdbs; was nice, thanks! how are you?
[07:27] <cdbs> pitti: Completely fine :)
[07:35] <abhinav-> pitti: good morning. What do you think about the screenshot problem in https://bugs.launchpad.net/ubuntu/+source/apport/+bug/357847
[07:36] <micahg_> pitti: good morning, I'm finishing up a pidgin merge, would you be able to sponsor before the freeze
[07:37] <pitti> abhinav-: sorry, what's the problem?
[07:37] <pitti> micahg_: yes, no problem
[07:37] <pitti> abhinav-: what does this have to do with screenshots? the main task there is to find out the process ID of the faulty app through the window ID?
[07:38] <abhinav-> pitti: yes, but in the comments, there was a suggestion to take screenshot as well of the window having problem
[07:39] <pitti> abhinav-: ah, so that's something different then
[07:39] <pitti> abhinav-: well, both GNOME (gnome-screenshot) and KDE have builtin screenshot capabilities
[07:39] <abhinav-> pitti: gnome-screenshot doesnt let take screenshot by pointing at a window ?
[07:41] <pitti> abhinav-: apparently not via CLI
[07:43] <abhinav-> pitti: but I suppose the solution has to be generic enough, so that it works on both KDE and GNOME ?
[07:44] <pitti> abhinav-: not necessarily; there can be a method in AbstractUI, and the Gtk/KDE/CLI implementations can then differ
[07:48] <abhinav-> pitti: right. I will look more into gnome-screenshot then. Although there is another screenshot application shutter, which provides the feature to point at a window and take screenshot. But it uses0 libgnome2-wnck-perl
[07:50] <broder> Before I start trying to argue with people on the internet, does anybody else want to look at http://lifehacker.com/#!5790311 and confirm that e4rat shouldn't make more than a ~100ms max difference over a correctly functioning ureadahead?
[07:52] <TheMuso> Ok this is weird, for some reason dput is erroring out for me saying that my public key isn't valid... but its the same key I've been using to upload packages for ages, and I've changed nothing locally or in lp.
[07:52] <TheMuso> Can anybody else confirm?
[07:52] <StevenK> TheMuso: Yes, ScottK mentioned it in #launchpad.
[07:53] <TheMuso> ah ok
[07:53] <StevenK> I'm not sure what is going on yet.
[07:53] <TheMuso> np I'll jump over there to follow.
[07:54] <TheMuso> thanks
[07:54] <pitti> abhinav-: shutter and its dependencies are an additional 19 MB compressed packages, which is prohibitively expensive
[07:55] <pitti> TheMuso: confrimed
[07:55] <pitti> TheMuso: it still uploads, though
[07:55] <TheMuso> pitti: oh does it?
[07:55] <pitti> I pulled my hair out on that one for an hour yesterday when uploading langpacks
[07:55] <pitti> until I noticed that they actually work
[07:55] <pitti> TheMuso: well, it did for me. YMMV
[07:55] <TheMuso> Right, we'll see what happens.
[07:56] <TheMuso> I uploaded twice thinking something was transient. :)
[07:56]  * TheMuso checks natty-changes.
[07:56] <RAOF> abhinav-: You can get a one-window screenshot out of gnome-screenshot, too, I'm sure.  GNOME Do appears to, at least :)
[07:56] <pitti> RAOF: you can, but it takes the currently focused window, there's no picker
[07:57] <RAOF> Eh.  That's a SMOP.
[07:57] <abhinav-> pitti: the author of shutter gave me a perl script (~100 lines) which does this, but it requires libgnome2-wnck-perl :)
[07:58] <pitti> abhinav-: then you can probably do the equivalent in python with gir1.2-wnck-1.0
[08:02] <abhinav-> pitti: yes, perhaps. I can try. thanks. :)
[08:02] <pitti> abhinav-: great; good luck!
[08:03] <TheMuso> pitti: yeah my upload went through too.
[08:04] <dholbach> good morning
[08:11] <micahg_> if I have a PKG_CHECK_MODULES check in configure, should the Cflags automatically get added or do I need to do something else?
[08:12] <slangasek> PKG_CHECK_MODULES() will automatically add cflags to a variable for you
[08:12] <slangasek> as long as that variable is then referenced in Makefile.in, you should be good
[08:12] <micahg_> ah, that's what I need to do, thanks :)
[08:12] <pitti> micahg_: no, they won't; you have to do something like myprogram_CFLAGS = $(MYLIB_CFLAGS)
[08:12] <broder> micahg_: you give it a name (e.g. PKG_CHECK_MODULES([GLIB], [glib-2.0]) ) and then it defines, e.g., GLIB_CFLAGS and GLIB_LDFLAGS (or is it GLIB_LIBS? i don't remember)
[08:13] <slangasek> _LIBS iirc
[08:13] <pitti> _LIBS, yes
[08:13] <pitti> and confusingly myprogram_LDADD = $(MYLIB_LIBS)
[08:13] <micahg_> I was trying to add a proper check for launchpad integration for pidgin since the check it was under before was dropped
[08:16] <damno> hello
[08:16] <damno> I need a bit of help
[08:16] <damno> anyone here?
[08:16] <pitti> !ask | damno
[08:17] <damno> i just compiled abiword
[08:17] <damno> successfully
[08:17] <damno> but coolab isnt orking
[08:17] <damno> sorry, collab
[08:17] <ScottK> pitti: I've uploaded KDE 4.5.5 for Maverick and filed Bug #757065 to track it.  I was hoping we could use the free buildd time once the Beta 2 freeze solidifies a bit to get it out the door.
[08:18] <pitti> ScottK: that sounds like a good opportunity indeed; I would like to wait a bit still, as the buildds are still quite busy, and I expect some more last-minute uploads
[08:18] <ScottK> pitti: Certainly.  I was guessing likely tomorrow.
[08:19] <damno> the install process created a archive named 'backup-041120111230-pre-abiword.tgz'. is it essencial to keep it?
[08:19] <ScottK> The core packages are all there.  I don't have the translation updates yet.
[08:19] <ScottK> No need to particularly wait on those though.
[08:20] <pitti> meh, Launchpad's "I hate your key" messages are really confusing
[08:20] <StevenK> pitti: Currently being investigated.
[08:21] <StevenK> But yes, it's exposing internals in an ugly way.
[08:21] <TheMuso> Yes, and prevents dput uploading multiple packages simultaneously.
[08:21] <TheMuso> Since an error is being thrown.
[08:21] <ScottK> Yes.  Yes it does.
[08:22] <TheMuso> ScottK: Oh yeah, that would have been painful.
[08:22] <pitti> ScottK: ok if I upload a new kubuntu-restricted-addons to drop the NBS kopete-gcall?
[08:22] <damno> you guys are too busy to help a new guy ,  I think
[08:22] <damno> buy
[08:22] <ScottK> pitti: Certainly.
[08:41] <micahg_> pitti: in the interest of getting this done, would it be ok to attach the launchpad integration check onto something else (like glib), I can't seem to get this to work
[08:41] <micahg_> it was previously attached to startup notification
[08:41] <pitti> micahg_: so perhaps just leave it where it was before, on startup-notification?
[08:42] <micahg_> pitti: would have loved to do that, but that check was removed in 2.7.11 :)
[08:48] <micahg_> hi seb128, since you've done most of the pidgin merges, do you have an opinion about the above?  (4 lines)
[08:49] <seb128> just put it on whatever is used to build that part of the code
[08:49] <micahg_> ok
[08:53] <\sh> hmm...did anyone see this error lately on natty while uploading? http://paste.ubuntu.com/592510/
[08:54] <lifeless> yes
[08:54] <lifeless> its being fixed
[08:54] <lifeless> gpg.conf file got reaped by tmpreaper
[08:54] <\sh> lifeless: means?
[08:55] <\sh> lifeless: error on user side or on server side?
[08:55] <lifeless> server side
[08:55] <lifeless> workaround is in place if you want to try again
[08:56] <\sh> lifeless: ok...so I don't care, actually the package was accepted
[08:57] <TheMuso> hrm, alsa-lib on amd64 failed for some weird reason. I386 built fine. http://paste.ubuntu.com/592512/
[08:57] <TheMuso> This is on the buildds.
[08:57] <diwic> TheMuso, yeah, saw that as well. "gcc: not found" seems to be the error
[08:58]  * micahg_ thinks slangasek was talking about that earlier
[08:58] <TheMuso> Ok thanks.
[09:00] <apw> there is an incantation (possibly as tasksel one) including a ^ which says 'install everything i would expect to have installed'
[09:00] <apw> can anyone remind me what it is?
[09:00] <pitti> apw: that's called installing a task
[09:00] <pitti> apw: apt-get install ubuntu-desktop^ should do that
[09:01] <apw> pitti, ahh that looks like it ... thanks :)
[09:01] <pitti> hey apw
[09:01] <apw> pitti, hiya
[09:04] <micahg_> seb128: for the new symbols, do you just copy them from Debian and add an epoch?
[09:07] <slangasek> TheMuso, micahg_: no, I was talking about a change that's in a linux-libc-dev version that isn't published yet
[09:07] <TheMuso> hrm ok thanks.
[09:11] <seb128> micahg_, yes
[09:13] <slangasek> TheMuso, micahg_: oh oops, I read the output wrong - yes, linux-libc-dev is published on amd64, so that explains perfectly the failure
[09:15] <TheMuso> slangasek: ok thanks.
[09:15] <micahg_> seb128: do we care about sort order?
[09:15] <seb128> no
[09:15] <micahg_> seb128: thanks
[09:29] <micahg_> pitti: bug 757146 if you have time to sponsor
[09:30] <slangasek> TheMuso: verified that gcc-multilib 4:4.5.2-1ubuntu2 will fix this; as soon as that publishes we can retry alsa-lib
[09:30] <TheMuso> slangasek: Thanks.
[09:33] <pitti> micahg_: on it
[09:33] <micahg_> pitti: thanks
[09:46] <JamesMR> Hi, I'm looking for some help/advice with an error I'm getting when trying to use apt, this is the error - "dpkg: syntax error in file triggers file `/var/lib/dpkg/triggers//File'" I'm on 10.10, it started appearing after trying to update to 11.04 beta via update-manager -d and my system froze partway through. 11 hours later I decded to rebooot my computer, the error has been bugging me since
[09:48] <poolie> JamesMR, try in #ubuntu
[09:48] <poolie> or rather, #ubuntu+1
[09:48] <micahg_> pitti: did you upload pidgin yet? (if not, hold off)
[09:48] <pitti> micahg_: too late
[09:49] <poolie> clint's in a us timezone, right?
[09:49] <poolie> i wanted to push along https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/707075
[09:49] <micahg_> ugh, I built this thing multiple times, and the last time it tells me symbols are missing
[09:50] <TheMuso> heh
[09:56]  * micahg_ wonders if -j17 had anything to do with it
[10:09] <micahg_> pitti: I think I'll have a fixed pidgin in a few minutes, it seems if a symbol is listed twice it fails now
[10:12]  * micahg_ is confused, not all the duplicates failed
[10:26] <micahg_> ok, so there's something I don't understand, can the same symbol appear multiple times in a file?
[10:26] <slangasek> micahg_: the same symbol /name/ can, but only if it has a different symbol version AFAIK
[10:28] <micahg_> slangasek: ok, so these are all the same version
[10:28] <micahg_> can I safely remove one?
[10:29] <slangasek> sorry, maybe I'm confused - are you talking about removing it from a symbols file or from a library?
[10:29] <micahg_> symbols file
[10:29] <slangasek> ah, I thought you were talking about an object file.  Sorry, I'm not sure I know the answer then
[10:31] <soren> micahg_: Which package?
[10:32] <micahg_> soren: pidgin
[10:32] <soren> I probably don't know the answer, I'm just curious :)
[10:33] <micahg_> heh
[10:33] <micahg_> I'm rebuilding without the duplicate symbols which I expect to succeed locally, I just would like to know if it's safe for the archive
[10:34] <soren> "bzr branch lp:ubuntu/pidgin" takes a while...
[10:34] <micahg_> soren: try pull-lp-source pidgin :)
[10:35] <soren> not a bad idea
[10:35] <soren> libpurple0.symbols?
[10:35] <micahg_> soren: yep
[10:37] <micahg_> so Debian removed the symbols, I'm just not sure why, it also wasn't noted in their changelog, but they're duplicates, so idk if that means anything was removed or not
[10:44] <micahg_> pitti: so, the build succeeded w/out the duplicate symbols, but idk if that's the right thing to do or not
[10:44] <pitti> micahg_: duplicate *.symbol entries don't really make sense, so this sounds like the right solution
[10:45] <soren> Well, this particular symbols file has information for two separate libraries.
[10:45] <soren> libpurple.so.0 and libpurple-client.so.0
[10:45] <micahg_> ah
[10:45] <soren> They could both export the same symbol.
[10:45] <soren> Whether they actually *do*... I don't know.
[10:46] <soren> I can imagine situations where it makes sense, but I have no idea if that applies here.
[10:46] <soren> Say, if the same binary package ships two flavours of the same library, both exporting (mostly) the same symbols.
[10:47] <soren> Now that I've added to the confusion, I'll wander off. Toodles :)
[10:48] <micahg_> pitti: so, they're not duplicates, it's as soren suggested, they are gone from libpurple-client and now solely in libpurple
[10:49] <soren> Without a soname bump?
[10:49] <soren> *sob*
[10:49] <soren> Oh, right I wandered off.
[10:51]  * micahg_ doesn't think the pidgin devs know what the so version is for, it seems to be tied to their dev version instead of soname changes
[10:52] <micahg_> or it could just be coincidence
[11:03] <micahg_> pitti: so, options are, upload an ubuntu2 that follows what Debian did (remove symbols w/out soname bump) or upload a 2.7.9-2 version and try to get this fixed properly
[11:04] <pitti> micahg_: I think just removing the duplicates from libpurple-client will do
[11:04] <pitti> at most it'll affect library dependency versions, but they should already be alright with the other symbols
[11:04] <micahg_> pitti: ok, I'll attach the debdiff
[11:07] <TheMuso> ...i thought freeze was at 9:00UTC.
[11:08] <pitti> TheMuso: yes, freezing right now; the higher priority for the admins was to get the archive mirrors back working :)
[11:08] <TheMuso> right
[11:08] <cjwatson> (mirrors should return shortly)
[11:10] <micahg_> pitti: bug 757311, thanks
[11:11] <pitti> micahg_: cheers, uploaded
[11:12] <micahg_> pitti: thanks, sorry for all the trouble :)
[11:12] <pitti> micahg_: no worries, thanks to you for sorting it out!
[11:14] <pitti> archive now frozen for beta-2
[11:17]  * ogra_ curses this insane freeze time 
[11:17] <pitti> ?
[11:17] <ogra_> we shouldnt do freezes on monday mornings
[11:17] <ogra_> that kind of forces people into weekend work
[11:18] <ogra_> either have them in the evening or on the friday before
[11:18] <pitti> the main difference is that the release team cross-checks the uploads; little difference for developers
[11:18] <ogra_> i know :)
[11:18] <pitti> ogra_: how would a freeze on Friday help in any way?
[11:18] <cjwatson> well, I sympathise with the weekend work bit, but how would moving it help?  if you haven't got the work done yet, you haven't got it done, and moving the freeze would make little difference
[11:18] <pitti> if you don't work on the weekend, fri/mon morning freeze is no different
[11:19] <ogra_> if you have work to do that requires less than a day you dont have to work on the weekends to make it into the archive before freeze
[11:19] <ogra_> if the freeze is in the evening or afternoon UTC
[11:19] <cjwatson> moving it later, sure; however that does have other consequences for the release team
[11:20] <pitti> ogra_: you can still do that; freeze -> controlled what's going in, not "doors firmly closed"
[11:20] <pitti> we already have negotiated an exception for unity
[11:20] <cjwatson> the later it is, the higher the chances of Tuesday's daily builds not being usable and us having to scramble
[11:20] <pitti> but we really need to coordinate uploads, to not collide with image builds, QA smoke testing, etc.
[11:20] <ogra_> i know, i also have discussed the possible alsa and pulse changes with kate
[11:20] <cjwatson> in private or in channel/bug?
[11:20] <ogra_> but i still would like to give the community more time before we freeze
[11:21] <ogra_> cjwatson, during fridays meeting
[11:21] <cjwatson> ok
[11:36] <mdz> pitti, is the amd64 retracer possibly down or backlogged? bug 757219 has been pending for 3 hours so far
[11:36] <pitti> mdz: it was, but the log was empty; I restarted it for now
[11:40] <seb128> pitti, I've restarted it 2 times already today
[11:40] <pitti> seb128: and it doesn't produce any log?
[11:40] <seb128> it does "consolidating the duplicates" and seem to crash
[11:40] <pitti> ah, log_dupcheck
[11:40] <seb128> or never went over that
[11:41] <seb128> pitti, well there is nothing in the logs, I guess I should try to run it manually
[11:45] <pitti> sladen: your ubuntu-mono upload dropped --with-scour, but doesn't document why?
[11:46] <sladen> pitti: oh bollocks, could swear I did  bzr revert debian/rules  first
[11:46] <pitti> sladen: want me to reject and you reupload?
[11:46] <pitti> (same version number is fine)
[11:46] <sladen> pitti: yes
[11:47] <sladen> pitti: I just do that to save 20 minutes on the local build time
[11:47] <pitti> quite a large set of new icons as well, I hope they got some testing?
[11:48] <sladen> pitti: urm?  Should only be 1.  But a lot of symlinks/alternate names
[11:48] <pitti> sladen: ah, then debdiff just got confused :0
[11:49] <sladen> pitti: it's overriding one icon (and all of its aliases) from Humanity, as Humanity maintainers/upstream don't want the icon that Mark wants, but Humanity upstream (vish) is being kind enough to ensure it correctly goes into ubuntu-mono as a mutal solution :)
[11:51] <sladen> pitti: weird.  debian/rules  has --with-scour,  and bzr status shows nothing
[11:51] <pitti> sladen: maybe you had an older source package around?
[11:51] <doko> pitti: do you intend to address all the other v4l issues too?
[11:52] <pitti> doko: so far I am aware of gambas (which built locally, but not on the buildds, sorry), and hal, but both are fixed now
[11:52] <pitti> doko: what else?
[11:52] <pitti> I'm mainly fixing NBS right now, but can look into other issues if required
[11:56] <doko> pitti: https://launchpad.net/ubuntu/+bugs?field.tag=ftbfs+natty+v4l&field.tags_combinator=ALL
[11:57]  * pitti sighs on timeout
[11:58] <pitti> doko: if you happen to have the page open, perhaps you can toss me a bug list on IRC?
[11:58] <pitti> tried 5 times now
[11:59] <doko> pitti: http://paste.ubuntu.com/592569/
[12:00] <chrisccoulson> nobody noticed any new firefox issues since i turned on -pie in the builds again last night?
[12:01] <pitti> chrisccoulson: hardly, as the mirrors are still not updated :)
[12:01] <chrisccoulson> ah
[12:01] <chrisccoulson> that's not good ;)
[12:01] <pitti> doko: any priorities there? I can do two or three, but not 25
[12:02] <doko> enoclue, I just filed these with the tag, because it's obvious from the build logs
[12:07] <lamont> ScottK: "fond" isn't exactly the word I would use
[12:08] <pitti> doko: I'll grab linphone, vdr, and kino then, they seem to be the most popular
[12:08] <pitti> doko: ah, linphone already fixed
[12:09] <doko> yeah, sorry, I may have filed issues for superseded versions
[12:09] <pitti> ah, no, LP output is just confusing
[12:09] <pitti> it went to universe, that's why it shows published on Apr 8
[12:09] <pitti> so yeah, will have a look at these three
[12:55] <janimo> what is the procedure for freeze exception uploads?
[12:55] <arand> I wonder if there is a...
[12:55] <arand> !ffe
[12:59] <janimo> arand, thanks
[12:59] <ogra_> janimo, adding features ?
[13:02] <janimo> ogra_, nope, hopefully fixing the gconftool crash
[13:03] <janimo> working around actually by building with -O0 :(
[13:03] <ogra_> well, just have a bug for it and mention the bug number in the changelog will suffice
[13:03] <ogra_> bugfixes that dont add new features dont need an FFE
[13:03] <ogra_> just upload and be in #ubuntu-release if the reviewer has questions
[13:04] <ogra_> (all uploads get reviewed anyway from now on)
[13:04] <janimo> ogra_, ok, just joined that channel
[13:04] <ogra_> makes sense prior to milestones and during freezes
[13:09] <ScottK> lamont: Speaking of stuff you're fond of ...  What are the chances of fpc on armel bootstrapping this cycle?
[13:09] <lamont> well, I did say I'd see about throwing it against the wall again to see if this time is any different than the last 3 times
[13:10] <ScottK> OK.
[13:11] <lamont> of course, if it does bootstrap, it'll just fail to run on most of the buildds, I'm guessing
[14:04] <mdz> seb128, any luck with the retracer?
[14:04] <seb128> mdz, the amd64 is running
[14:05] <mdz> seb128, great, I guess it will catch up soon then
[14:05] <seb128> mdz, but there is quite some backlog from the weekend so it might take another hour before getting yours
[14:05] <mdz> ack
[14:05] <seb128> pitti, I disabled the job which consolidates the db for now to get the retracing going btw
[14:06] <seb128> pitti, I will try to restart it manually once we clear the backlog
[14:06] <pitti> seb128: ah, thanks
[14:27] <bdrung> geser: DMB meeting?
[14:31] <pitti> doko: FYI, I uploaded linphone and kino fixes, and will do a vdr sync after the buildd backlog settled down; then these three are fixed
[14:49] <GunnarHj> doko: Hi Matthias, there is a rumor that you're patch pilot today. ;-)
[15:17] <kirkland> @pilot in
[15:18] <kirkland> GunnarHj: hi, i'm on pilot duty, too, fwiw
[15:21] <GunnarHj> kirkland: Hi Dustin, it's worth a lot. :)
[15:21] <GunnarHj> kirkland: There are two things I'd appreciate your help with. First I'm wondering if it's possible to commit only one of the revisions (322) from https://code.launchpad.net/~gunnarhj/gdm/profile/+merge/56426, or should I create a separate MP for it? (Rev. 323 is pending furter discussion.)
[15:21] <kirkland> GunnarHj: reading ...
[15:25] <kirkland> GunnarHj: hmm, I echo seb128's question ... you should easily be able to: . $HOME/.profile || true
[15:25] <kirkland> GunnarHj: and . $HOME/.xprofile || true
[15:27] <apw> cjwatson, about?  seeing any reports of loss of graphical boot?  my first test box i updated seems to go from purple to black with a cursor ?
[15:27] <GunnarHj> kirkland: Think I have to test it again, to recall why I made another conclusion...
[15:27] <kirkland> GunnarHj: so if you just do:
[15:28] <kirkland> Guest24406: . $HOME/.profile || true
[15:28] <kirkland> GunnarHj: the || true will catch the error that you're testing for with -f (file existence)
[15:28] <kirkland> GunnarHj: and it will also catch any syntax errors in the sourcing of that file
[15:29] <GunnarHj> kirkland: Will get back to you about that.
[15:30] <GunnarHj> kirkland: Then there is https://code.launchpad.net/~gunnarhj/language-selector/help/+merge/57109. Is a pure docs change affected by BetaFreeze?
[15:30] <apw> cjwatson, a quick poke seems to imply that linux_gfx_mode is not keep, ie changing the set to keep gets it back
[15:31] <kirkland> GunnarHj: https://wiki.ubuntu.com/DocumentationStringFreeze
[15:32] <cjwatson> apw: first I've heard of it
[15:32] <apw> cjwatson, i don't see to have a gfxblacklist.cfg
[15:32] <apw> cjwatson, i don't see to have a gfxblacklist.txt even
[15:32] <cjwatson> apw: do you have /boot/grub/gfxblacklist.txt?
[15:32] <GunnarHj> kirkland: I know, but that document is not subject to translation yet (won't be until after the Natty release).
[15:32] <cjwatson> hm, maybe it falls over if that file's missing
[15:33] <apw> cjwatson, nope no such file
[15:33] <kirkland> GunnarHj: ah
[15:33] <apw> and dpkg can't find one either
[15:33] <kirkland> GunnarHj: okay, then i'm willing to sponsor that one, if you open a bug for it
[15:33] <apw> cjwatson, isn't that file from its own  package ?
[15:34] <apw> cjwatson, this machine just has had an apt-get install ubuntu-desktop^ run on it too, so its in theory complete
[15:34] <cjwatson> no, it's from grub-gfxpayload-lists, which I forgot to MIR (doing now)
[15:34] <cjwatson> but grub should tolerate its absence anyway
[15:35] <cjwatson> bug me
[15:35] <apw> cjwatson, welll in theory it might be the right behavour in the absense of the file ...
[15:36] <cjwatson> I think on balance I'd rather default on
[15:37] <apw> cjwatson, ok touching that in seems to fix the issue
[15:37] <apw> cjwatson, i assume you want a bug against grub2 ?
[15:37] <cjwatson> yes
[15:37] <apw> cjwatson, also  ... i have a feeling that something other than drm is switching off the display, contributing to the length of the 'black with no backlight' phase
[15:37] <apw> does that ring a bell at all ?
[15:38] <apw> plymouthd when it starts or something?
[15:39] <kirkland> GunnarHj: can you get me a bug number for the language-selector fix?
[15:40] <cjwatson> apw: no bells ringing there
[15:40] <GunnarHj> kirkland: Sure, just give me two minutes.
[15:41] <apw> cjwatson, bug #757603, want it assigned ?
[15:41] <cjwatson> I'll grab it
[15:42] <apw> ack
[15:43] <GunnarHj> kirkland: Done. Used an ongoing bug on i18n documentation.
[15:52] <pitti> doko, mterry, didrocks: we have two urgent MIRs for beta-2, bug 754661 and bug 757600; does any of you have some time to review them?
[15:52] <mterry> pitti, sure
[15:52]  * mterry takes first, will take second if no one else does
[15:52] <pitti> mterry: cheers
[15:58]  * didrocks still triages unitish things
[15:59] <didrocks> kees: answered on bug #755146, can you please have a look once you have time for it?
[16:01] <seb128> didrocks, njpatel suggested that's a duplicate of the ccsm crash earlier
[16:03] <didrocks> seb128: ok, let's hope so :) weird that we still have a missing unref in sources, I checked everything apart from the dash, will have another look
[16:03] <seb128> kees, did you get your compiz crashes when using ccsm?
[16:04] <kirkland> GunnarHj: #?
[16:05] <stgraber> SpamapS: ping
[16:05] <GunnarHj> kirkland: Sorry, bug 742857
[16:07] <didrocks> seb128: from the ubuntu-devel mailing list: " crashed when clicking launcher for Terminator while Terminators were running"
[16:08] <kirkland> GunnarHj: cool, pushed, uploaded
[16:08] <kirkland> GunnarHj: let me know about the gdm one
[16:09] <seb128> didrocks, ok so maybe njpatel was wrong ;-)
[16:09] <didrocks> seb128: that's why I'm pinging kees :-)
[16:09] <didrocks> seb128: well, the issue will also result in ccsm being uncheck
[16:10] <GunnarHj> kirkland: Thanks. I will (in a few minutes).
[16:25] <GunnarHj> kirkland: Please see my latest comment on https://code.launchpad.net/~gunnarhj/gdm/profile/+merge/56426
[16:31] <mterry> cjwatson, about grub-gfxpayload-lists, I don't see any existing blacklisted IDs and it doesn't seem to install a dpkg trigger, so is this package currently a no-op?
[16:33] <cjwatson> mterry: tseliot was thinking of adding entries to fglrx/nvidia packages, although I'm not sure whether he actually has yet
[16:33] <cjwatson> mterry: rightly or wrongly (perhaps wrongly) the current design is that packages that install blacklist files should call update-grub-gfxpayload
[16:34] <cjwatson> (I wouldn't mind a bug to triggerise that, although I don't think it's necessary for natty)
[16:34] <mterry> cjwatson, sure, OK.
[16:34] <tseliot> cjwatson, mterry: both fglrx and nvidia-current install such blacklist file (currently empty though)
[16:34] <cjwatson> right - I want to have the facility in place though
[16:40] <mterry> pitti, both approved
[16:41] <pitti> mterry: thanks
[16:46] <dholbach> https://wiki.ubuntu.com/UbuntuAppDeveloperWeek starting in 15 minutes in #ubuntu-classroom
[16:49] <abhinav-> dholbach: will the IRC logs be available ?
[16:49] <sladen> abhinav-: irclogs.ubuntu.com
[16:50] <james_w> cjwatson, Can't exec "unxz": No such file or directory at /usr/share/perl5/Dpkg/IPC.pm line 261. <- That's from the xz work I assume? It implies that the updated dpkg is installed, but an xz package is missing?
[16:50] <dholbach> abhinav-, yes, they'll be also put on https://wiki.ubuntu.com/UbuntuAppDeveloperWeek afterwards
[16:50] <abhinav-> dholbach: cool. Thanks :)
[16:53] <seb128> mdz, your bug got retracers, it's an overlay scrollbar issue
[16:54] <mdz> seb128, thanks. when apport filed it, it was tagged ayatana-scrollbar (before even being retraced), but was still filed on rhythmbox for some reason
[16:54] <mdz> is that how it's supposed to work?
[16:54] <seb128> mdz, the tag just means that the scrollbar binary is installed
[16:54] <mdz> oh
[16:54] <seb128> it doesn't mean the bug is due to those
[16:55] <cjwatson> james_w: is that on a DC machine?
[16:55] <mdz> I thought it might have been because of ?? () from /usr/lib/liboverlay-scrollbar-0.1.so.0
[16:55] <james_w> cjwatson, yeah, jubany
[16:55] <mdz> but that makes more sense
[16:55] <cjwatson> james_w: current versions of dpkg pre-depend on xz-utils
[16:55] <mdz> seb128, isn't the scrollbar binary package installed by default though?
[16:55] <seb128> mdz, right, I need to talk to ken about that
[16:55] <cjwatson> james_w: one of the versions floating around the -cat archives might be suitable for jubany; I'd suggest asking IS
[16:56] <seb128> mdz, we should add something to reassign to overlay-scrollbar if liboverlay-scrollbar is in the stacktrace
[16:56] <james_w> cjwatson, ok, thanks
[16:56] <mdz> seb128, yeah, similar to the nautilus->ubuntuone rule
[16:57] <seb128> mdz, well in fact I just checked I was wrong, it does add the tag if the scrollbars are in the ProcMaps, but it just tell you that the application which crashed had those loaded
[16:57] <seb128> not that it crashed in there
[16:57] <mdz> ah
[17:11] <kees> didrocks, seb128: I have no idea where the 755146 crash came from, honestly. the other one (755167) was totally a crash while in ccsm.
[17:11] <didrocks> kees: ok, so "known and prioritized issue"
[17:12] <kees> didrocks: cool, thanks!
[17:12] <kees> didrocks: after turning off focus-follows-mouse, I have had 0 more problems.
[17:12] <kees> I don't like not using FFM, but it does keep me from having unity crash :)
[17:12] <didrocks> kees: yeah, ffm is not supported from the start :/
[17:13] <kees> didrocks: if that's the case, unity should refuse to run if FFM is on. ;)
[17:13] <didrocks> kees: there were a discussion about this 2 monthes ago, but some people argued it was working, so we didn't touch it
[17:15] <kees> didrocks: does the unity (or compiz) apport hook report the state of FFM?
[17:18] <didrocks> kees: no, and yes, nice suggestion :)
[17:18] <didrocks> kees: I'll add that
[17:19] <didrocks> thanks :)
[17:19] <kees> didrocks: cool; that should really help weed out stuff
[17:20] <didrocks> right
[17:22] <kirkland> GunnarHj: okay, another message, back at you ;-)
[17:28] <SpamapS> stgraber: pong, I read your analysis of the console issue. Makes sense to me.
[17:35] <stgraber> SpamapS: can you post the boot.log file after you switch to that lsb-base-logging.sh ? assuming you still have the VM around
[17:37] <SpamapS> stgraber: I do (I have 2 like it actually). Booting them now. :)
[17:38] <stgraber> SpamapS: cool, thanks
[17:42] <GunnarHj> kirkland: That's indeed more elegant than my function. :)
[17:42] <GunnarHj> kirkland: Just a detail: Can't we drop the "|| true" part then? To me it appears to be superfluous. Or what am I missing?
[17:42] <kirkland> GunnarHj: no, that part is essential to catch the (. ~/.profile) failure
[17:52] <kirkland> GunnarHj: wanna update that merge?
[17:55] <GunnarHj> kirkland: Yes, I'll do that. But let's first finish the "|| true" talk. Just submitted a new comment on https://code.launchpad.net/~gunnarhj/gdm/profile/+merge/56426
[17:57] <GunnarHj> kirkland: To me it appears as if the parentheses protect the main process from stopping irrespective of what you put inside them.
[18:01] <kirkland> GunnarHj: interesting, it does seem that way to me
[18:01] <SpamapS> stgraber: boot.log uattached
[18:02] <kirkland> GunnarHj: my tests agree with that
[18:06] <stgraber> SpamapS: thanks. I'm currently working on fixing the apparmor part of it, it's calling a function I didn't make plymouth aware yet. Fixing this one should give a slightly better output.
[18:07] <stgraber> SpamapS: for memcached that's probably as good as it's going to be until someone changes its init script
[18:09] <GunnarHj> kirkland: Ok, then I'll update the merge and get back to you.
[18:10] <kirkland> GunnarHj: perfect
[18:11] <kirkland> smoser: looking at https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/726572
[18:11] <kirkland> smoser: looks like kees gave you your +1 for MIR
[18:11] <kirkland> smoser: nice ;-)
[18:12] <kirkland> smoser: i'll move it over
[18:12] <smoser> yeah, can you commit it to seed ?
[18:12] <smoser> seed "uec"
[18:12] <smoser> and, kirkland, thank you for doing work for me :)
[18:13] <kirkland> smoser: sure
[18:13] <kirkland> smoser: you do work for me all the time;  it's the least I can do :-)
[18:17] <SpamapS> stgraber: are the lsb log messages completely suppressed?
[18:18] <SpamapS> stgraber: I don't see any calls to plymouth update
[18:19] <stgraber> SpamapS: nope, they still go through the console as usual, it's just that instead of showing the first half of the message, then wait and show the "[ OK ]" part, I wait until I know if it worked or failed to show the whole line
[18:20] <stgraber> the problem with apparmor is that it's calling log_action_msg which does a simple "echo" so it gets printed immediately and so appears before the line saying that apparmor is starting :)
[18:21] <stgraber> which makes sense because that line is technically printed before the call to log_end_msg, it just looks weird ...
[18:21] <kirkland> smoser: done
[18:25] <stgraber> SpamapS: plymouth is basically grabbing everything that gets displayed on the console and writes that in boot.log. So you just need to be careful to always echo full lines to the console.
[18:30] <ScottK> kirkland: If you're still patch piloting, I'd appreciate it if you would look at Bug #757540.
[18:30] <kirkland> sconklin: sure
[18:30] <kirkland> ScottK: ^
[18:30] <ScottK> Thanks.
[18:31] <kirkland> ScottK: i'm tackling a likewise-open double merge at the moment, will look at yours next
[18:31] <ScottK> kirkland: Thanks.
[18:35] <superm1> janimo, i wasn't even aware that you had uploaded deltas to mythtv until ScottK pointed it out.  could you try to remember to submit a merge request for the VCS next time so it's not missed?
[18:36] <janimo> superm1, I thought maintainers are notified on upload
[18:36] <janimo> superm1, I almost never notify debian or upstream vcs explicitley unless it is a bugreport
[18:36] <superm1> i didn't see anything come through my mail about it, hm wonder why
[18:37] <superm1> the maintainer is a mailing list, is that maybe why?
[18:37] <janimo> for are there are changes to amany7 packagesa and explicitly doing that for each is a lot less efficient than relying on the fact that LP mails out notifications
[18:39] <janimo> superm1, not sure why, maybe not all maintainers are notified by LP. Failing that I thought package updates even syncs from Debian do not go over ubuntuX changes without at least some notification that there is an ubuntu delta
[18:39] <janimo> s/for are/for ARM/
[18:40] <superm1> for this particular package it's not in debian
[18:40] <micahg_> janimo: I don't think maintainers are notified on upload
[18:40] <micahg_> at least in Ubuntu :)
[18:40] <janimo> micahg_, that is a misfeature of LP I'd say
[18:40] <janimo> I know I get mails for packages I happened to have uploaded first to ubuntu
[18:40] <janimo> and my name sis still in mainatiner field
[18:41] <superm1> i think if it's an explicit person listed as a name in the maintainer field they're notified
[18:41] <janimo> superm1, mythtv has a 'maintainer'/owner in Ubuntu
[18:41] <superm1> mailing lists/teams probably aren't because of the potentially sending out so much upload spam
[18:41] <superm1> think about all the stuff with ubuntu-motu on it
[18:42] <janimo> for packages which I know this is the case I am relying on the fact they follow the package closely - KDE is another example
[18:42] <janimo> instead of filing bugs/debdiffs I make uploads but I am happy to post debdiffs in the future
[18:42] <janimo> if that lessens the chances of miscommunication
[18:43] <superm1> whatever is convenient for you, bug debdiff, email, vcs merge request, ping in irc, just somehow someone in ~mythbuntu getting notified would be good
[18:50] <janimo> superm1, ok
[19:10] <kirkland> ScottK: uploaded;  was a little bit of a pain as AnAnt had only included a tarball of his debian directory, rather than a merge proposal, or a debdiff;  also, i had to repack the upstream tarball
[19:10] <ScottK> kirkland: Thanks.
[19:20] <kirkland> @pilot out
[19:21] <kirkland> jdstrand: slangasek: kees tells me you've had your thinkpad overheat and shut down recently?
[19:21] <kirkland> jdstrand: slangasek: I've had it twice in 2 days
[19:21] <ScottK> kirkland: Thanks to that upload, people who speak Uyghur will be able to read Ubuntu in their native script.
[19:21] <kirkland> ScottK: cool
[19:21] <jdstrand> kirkland: bug #751689
[19:22] <kirkland> jdstrand: thanks
[19:25] <ScottK> dpm: Is there some reference on ubuntu.com about it being an Ubuntu project goal/value that everyone be able to use Ubuntu in their own language?  I thought I remembered that, but I can't find it.
[19:29] <dpm> ScottK, on a session right now, let me come back to you later
[19:32] <ScottK> Thanks
[20:00] <GunnarHj> kirkland: https://code.launchpad.net/~gunnarhj/gdm/profile/+merge/57218 ready for you. Added a comment on the MP.
[20:03] <dpm> ScottK, is this what you were looking for? -> http://www.ubuntu.com/project/about-ubuntu/our-philosophy
[20:08] <slangasek> kirkland: yes, filed a bug against the kernel for this: bug #746924
[20:20] <ScottK> dpm: It was.  I missed the language bit when I read it.  Thanks.
[20:26] <psusi> slangasek: that's the job of the ACPI bios
[20:26] <slangasek> psusi: the bios didn't change, the kernel did
[20:26] <slangasek> and the bios doesn't control cpu frequency in Linux, the kernel does
[20:27] <dpm> ScottK, you're welcome :)
[20:28] <psusi> slangasek: the bios specifies acpi tabeles that are supposed to monitor thermal zones and do things like start fans and limit the cpu speed in response to heat.  the kernel cpufreq govenor has never responded to heat afaik
[20:28] <psusi> unfortunately, most bios vendors don't bother actually complying with the acpi spec in this area
[20:31] <psusi> the cpufreq govenor has no way of knowing which hwmon temperature to respond to, and how it should respond, even if you have an mwmon temperature sensor, which is why acpi bios is supposed to provide the correct tables establishing the linkages
[20:32] <slangasek> psusi: ok, so why has this regressed between maverick and natty?
[20:32] <psusi> why do you think it has?
[20:36] <slangasek> psusi: because I can tell the difference between my machine overheating and shutting down and it not overheating and not shutting down
[20:36] <psusi> that doesn't mean that it used to lower the frequency when it got hot, it could just be that you weren't getting hot before
[20:37] <slangasek> yes, it may not have been lowering the frequency, I'll grant you
[20:37] <slangasek> but the behavior has regressed since maverick
[20:38] <psusi> something could have changed to generate more heat, but I'm fairly certain that cpufreq has not and can not respond to high temp by lowering the frequency.  Have you tried booting back into the older kernel to make sure it isn't something changing in userspace, or maybe a clogged vent or something?
[20:40] <stgraber> psusi: it doesn't seem very likely that slangasek, kirkland, jdstrand and I all happened to have clogged vent issue starting with natty ;)
[20:41] <kirkland> :-D
[20:41] <jjohansen> in general the natty kernel seems to run a little hotter
[20:41] <kirkland> stgraber: yeah, on both of my thinkpads, too
[20:41] <slangasek> no, I do need to reboot to the maverick kernel to check it out; that's on my todo list for this week
[20:41] <kirkland> it could just be global warming at work, too
[20:41]  * jjohansen is unsure if that is because of less lock contention == work work being piped throguh or something else
[20:42]  * jjohansen needs to dig but we had a bug in maverick where things ran hot too
[20:43] <jdstrand> psusi: my vent is not clogged
[20:43] <jdstrand> psusi: I disassembled the laptop and applied new thermal grease and blew out the fan and vent in an effort to fix this
[20:44] <jdstrand> the natty kernel does run hotter
[20:44] <jdstrand> my guess is the lack of big kernel lock, but I have no idea
[20:45] <jdstrand> maverick's fans run just as slow though, and is the kernel is only about 8C cooler when CPUs/threads are fully utilized
[20:45] <jdstrand> s/and is/and/
[20:46] <psusi> how close is that to the critical trip?
[20:46] <psusi> i.e. is that 8C difference the difference between shutdown and not?
[20:47] <jdstrand> psusi: critical is 100C here
[20:47] <jdstrand> psusi: I hit that pretty frequently in natty, less so in maverick
[20:48] <jdstrand> psusi: I am now using an updated thinkfan that will actually kick the fans up to speeds that will keep it cool enough-- I have not gone higher than 86C since and that is with a lot of taxing
[20:48] <chrisccoulson> jdstrand, my laptop runs much hotter in natty too
[20:48] <chrisccoulson> and the battery life is absolutely horrendous
[20:48] <chrisccoulson> it's less than 1 hour in natty. my battery has never been great, but it's dropped through the floor now ;)
[20:49] <jdstrand> psusi: so imho there are too issues-- 1) on at least the x201 the kernel is not spinning the fans up high enough and 2) natty in general seems to run hotter
[20:49] <jdstrand> (all in the bug)
[20:50] <jdstrand> psusi: I don't see the bug in backscroll, it is bug #751689
[20:51] <slangasek> jdstrand: do you think I should mark 746924 a dupe of that one?
[20:51] <slangasek> kirkland: "real-life physical damage" - er, it shouldn't unless the acpi tables are wrong?
[20:52] <slangasek> I'm not sure the cause is slow fans in my case though
[20:52] <kirkland> slangasek: let's just say I quit using my laptop on my lap
[20:52] <kirkland> d-:
[20:52] <slangasek> I guess I should check that out, though I can't use /proc/acpi/ibm/fan in natty anymore to do so...
[20:53] <psusi> yea, the fan spinning faster when temp goes up is also what the acpi bios is supposed to do, but from what I have seen, vendors don't bother implementing
[20:53] <slangasek> kirkland: oh right, because if it were better at dissipating heat, it'll be just fine to blow all the exhaust on you ;)
[20:53] <jdstrand> I looked up the i7 in intel docs and it tends to run hotter than other systems, and don't think 100C will hurt the cpu (ie, when the kernel shuts down), but that won't be good for the thermal grease or other components
[20:53] <kirkland> slangasek: i'd rather it blow 50C exhaust than 98C exhaust
[20:54]  * slangasek prepares to argue the point with equations and diagrams
[20:54] <jdstrand> slangasek: I don't know if it is the same issue or not...
[20:55] <kirkland> iwconfig is reporting Bit Rate=144.4 Mb/s at this coffee shop ... that's um, impressive ...
[20:55] <jdstrand> slangasek: why can't you use /proc/acpi/ibm/fan anymore?
[20:55] <psusi> hrm... thinkfan eh?  I'll have to look more clusely at this.. looks like it may be a better replacement for fancontrol
[20:55] <jdstrand> options thinkpad_acpi fan_control=1
[20:55] <kirkland> slangasek: yeah, /proc/acpi/ibm/fan looks fine for me
[20:55] <jdstrand> slangasek: drop that into /etc/modprobe.d, works fine here
[20:55] <slangasek> jdstrand: oh, I thought /proc/acpi/ibm had gone away, hmm
[20:55] <kirkland> kirkland@x201:~$ cat /proc/acpi/ibm/fan
[20:55] <kirkland> status:         enabled
[20:55] <kirkland> speed:          3274
[20:55] <kirkland> level:          auto
[20:56] <jdstrand> kirkland, slangasek: to manipulate it though, you need to load with fan_control=1
[20:56] <slangasek> ack
[20:56] <kirkland> jdstrand: right
[20:56] <jdstrand> I have a thinkfan patch btw
[20:57] <jdstrand> http://people.canonical.com/~jamie/thinkfan_0.7.1-2ubuntu1~jdstrand1.debdiff
[20:58] <jdstrand> kirkland, slangasek: thinkfan if you don't know is a daemon that will adjust fan speed based on temperature using /proc/acpi/ibm/fan
[20:58]  * slangasek nods
[20:58] <jdstrand> '127' is valid on my x201s
[20:59] <jdstrand> and puts the fan in disengaged mode, which keeps it from overheating (86C is the highest I've seen since using it)
[20:59] <kirkland> jdstrand: interesting
[20:59] <jdstrand> and that debdiff adjust thinkfan to not barf on '127'
[20:59] <kirkland> jdstrand: i'd be willing to test that, if it would help get it into natty
[21:00] <jdstrand> kirkland: thinkfan is universe. I consider this just a workaround. the kernel should be fixed
[21:00] <kirkland> jdstrand: totally agree;  but i'm willing to use a workaround, at this point
[21:01] <jdstrand> kirkland: oh yeah, by all means, use it yourself. you have a x201s?
[21:01] <kirkland> jdstrand: just a plan old lower resolution x201
[21:01] <kirkland> jdstrand: but i do have the i7 proc
[21:02] <kirkland> jdstrand: i have a much older x61 running Maverick that I've seen it on more and more lately
[21:02] <jdstrand> kirkland: be sure to read the docs, etc, but you could use this as a starting point for /etc/thinkfan.conf: http://paste.ubuntu.com/592803/
[21:02] <kirkland> jdstrand: that x61 is a server for me, so it really sucks when it goes down;  i don't notice it immediately, until i need something off of it
[21:02] <stgraber> jdstrand: x201s with i7 L640 ?
[21:02]  * jdstrand nods
[21:03] <jdstrand> stgraber: yep
[21:03] <jdstrand> model name: Intel(R) Core(TM) i7 CPU       L 640  @ 2.13GHz
[21:03] <stgraber> jdstrand: cool, I can use your config as-is then :)
[21:03] <jdstrand> hehe
[21:04] <jdstrand> also, you can adjust the bios to disable cores and/or threads which (unsurprisingly) helps quite a bit too
[21:06] <psusi> slangasek: can you compare powertop readings between maverick and natty?  I wonder if you can see the higher power usage, and maybe identify what is using it
[21:07] <slangasek> psusi: it only happens when I'm running the system at full throttle, there's nothing to look at in powertop that would be meaningful AFAICT
[21:08] <psusi> slangasek: the overheating only happens at full throttle, but it seems likely that it is just generally hotter all the time
[21:08] <psusi> and even under load, there might be too much noise to identify the cause, but confirming the higher power drain would still be informative
[21:09] <psusi> it would rule out say, the fan spinning more slowly
[21:10] <slangasek> sure, I'll look into it
[21:32] <psusi> slangasek: I also wonder if you are seeing this printk in your logs when overheating: CPU%d: %s temperature above threshold, cpu clock throttled (t\
[21:32] <psusi> otal events = %lu)\n"
[21:33] <slangasek> psusi: I have such log entries from 3 days ago, yes
[21:35] <stgraber> psusi: here I'm only getting this: http://paste.ubuntu.com/592821/ can't find any reference to "cpu clock throttled" in my log
[21:38] <psusi> hrm... well I found that in arch/x86/kernel/cpu/mcheck/therm_throt.c, which looks like it is checking intel MSRs to notice overheating... but aside from printing the message to the log, it doesn't look like it does a damn thing about it
[21:40] <slangasek> hah, good show
[21:40]  * psusi grubles about lack of acpi standard compliance
[21:41] <psusi> this whole file looks like an attempt to workaround broken acpi bios by using the processor specific registers directly
[21:44] <slangasek> psusi: so if I'm seeing those messages, does that imply ACPI is being bypassed and not allowed to do its thing?
[21:45] <psusi> slangasek: I don't think so... I think that like most other systems I have looked at, your acpi bios does not bother properly handling thermal events in accordance with the standard...
[21:46] <psusi> I think that basically nobody does, and this code was written to allow the kernel to do something about it despite acpi not working right... but I can't work out just how this is supposed to work
[21:50] <psusi> slangasek: see under acpi, the bios is supposed to define a thermal_zone that represents the temperature in a given area, such as that of the cpu... most venders I have looked at do this, so you can read the acpi temp
[21:51] <psusi> but they are also supposed to define a fan object that allows for monitoring and control of any fans, as well as a relationship between the fan(s) and thermal_zones, including when they should be ramped up..
[21:52] <psusi> also a relationship between the cpu and the tz so that it can be throttled... but from what I have seen, nodboy botheres with all of this
[21:52] <psusi> from what I can see, they just stop at the tz and have it signal critical temp, time to shut down... no fan and no throttling
[21:57] <slangasek> psusi: so my ACPI implementation definitely has exposed under /sys information about four cooling devices and associated temperature trip points; unfortunately they all seem to have a trip point set higher than the critical temp at which emergency shutdown occurs (127.5°C vs. 100°C)
[21:58] <slangasek> I also, under the current kernel, can't find where the emergency shutdown limit is set
[21:59] <psusi> hrm.. interesting.... I think it was set by the thermal_zone
[22:00] <slangasek> under the last kernel I had booted, these limits were *different8
[22:00] <slangasek> the last natty kernel
[22:00] <psusi> you have a 4 core cpu?
[22:01] <slangasek> it was 100 and 92-ish
[22:01] <slangasek> yes
[22:02] <psusi> hrm... yea, I would expect a well behaved bios to have the tz crit at 100 for shutdown, and each cpu core counts as a cooling_device which should be linked to the tz to engage throttling at say, 92
[22:02] <slangasek> ok, here we go
[22:02] <slangasek> $ cat /sys/class/thermal/thermal_zone0/trip_point_*
[22:02] <slangasek> 100000
[22:02] <slangasek> critical
[22:02] <slangasek> 127500
[22:02] <slangasek> passive
[22:02] <slangasek> so the cooling devices all trigger on the latter trip point, which is higher than the critical point
[22:02] <slangasek> say what
[22:03] <psusi> yea, that looks borked
[22:04] <psusi> bbiab, need to head home
[22:22] <LLStarks> hi, i'm wondering whether it's too late to draft up proposals for uds-o. i'd like to present a grub2-gfxmenu implementation to cjwatson and other interested parties.
[22:24] <jdong> kees: random question: I don't suppose SSP can be disabled on a per-function basis, can it?
[22:26] <kees> jdong: no, and if you've got that level of knowledge, why not fix the function? :P
[22:26] <jdong> kees: haha sadly the brokenness is the stack canary actually affects performance in the codepath.
[22:26] <jdong> kees: and I already had to eat my hat for claiming it wouldn't!
[22:27] <kees> jdong: ugh. what code? it's usually very minor. anything that has strings on the stack usually doesn't have a measurable difference when adding SSP
[22:28] <jdong> kees: it's an interrupt service routine on ARM; only discovered the performance discrepancy after porting it to an environment where -fstack-protector is default
[22:29] <jdong> I mean of course I can just change the buffer type to be one that -fstack-protector doesn't care about :)
[22:31] <kees> jdong: in the kernel?
[22:36] <slangasek> mvo: I was pleasantly surprised to see all the multiarch fixes going into the package management infrastructure the past couple of weeks... I really expected multiarch to be enable-on-your-desktop-at-your-peril for this cycle, and was surprised when update-manager started working for me again :)
[22:38] <mvo> slangasek: yeah, its pretty cool, the full stack has support now, even in synaptic we have basic support (and aptdaemon too) and you can click on foo:i386 and watch the resolver churn and try to come up with a solution. its quite cool
[22:38] <slangasek> indeed :)
[22:39]  * mvo sends hugs to donkult and juliank for their great work on this
[22:39] <lifeless> \o/
[22:40] <mvo> bedtime for me now, see you all tomorrow
[22:40]  * mvo waves
[22:43] <micahg_> pitti: so, I discovered what happened to the pidgin symbols, it seems they were intentionally dropped upstream due to portability concerns, I also found that this seems to cause a problem for dockmanager which is a new package in natty, so no inherent regression
[22:44] <pitti> micahg_: ah, that explains it at least
[22:47] <micahg_> pitti: and that probably should've had an FFe, sorry about that
[22:51] <psusi> slangasek, so you said your thermal zone has only critical and passive trip points?  no active?  and the passive is higher than critical?
[22:52] <slangasek> psusi: yes
[22:53] <psusi> slangasek, that shouldn't change with kernel version, but have to checked if it is like that in maverick?
[22:53] <psusi> because that does look like broken acpi bios
[22:53] <slangasek> no, I haven't checked
[22:54] <slangasek> regardless, broken acpi is the world we live in - Ubuntu still needs to behave appropriately in the face of it
[22:55] <psusi> then you need to come up with specific workarounds for every piece of broken hardware
[22:55] <syn-ack> I hate it when a former employer makes it impossible to verify that you worked there because they're that much of a jerk
[23:03] <jcastro> kees: I need you to add some people to ~ubuntu-drivers when you get a chance, only TB folks can do so
[23:05] <kees> jcastro: oh? for UDS planning? I thought all that got sorted out already.
[23:06] <jcastro> kees: we're missing jdstrand and jasonwarner
[23:06] <jcastro> kees: and probably iain-farrell too for the Design track
[23:08] <kees> jcastro: shouldn't they be part of uds organizers?
[23:08]  * jcastro looks
[23:08] <jcastro> ok weird, what's the difference between a track lead and a driver? ok, yeah, uds-organizers makes sense
[23:10] <jcastro> kees: whatever lets people schedule but not also allow them to like upload glibc or something. :p
[23:10] <azeem> it's like rhythm and lead guitar
[23:11] <kees> jcastro: I've added jdstrand jasoncwarner and iain-farrell to uds-organizers now
[23:12] <jcastro> looks good!
[23:12] <jdstrand> does that mean I can't upload glibc anymore? :P
[23:12]  * jdstrand doesn't actually ever touch glibc ;)
[23:12] <psusi> slangasek, heh, I can't even get my netbook to its 85c passive trip point.. seems to top out at 50
[23:13] <kees> jdstrand: that would be funny. have uds-organizers block membership in core-dev ;)
[23:13] <jdstrand> :)
[23:15] <slangasek> psusi: you need a more powerful processor then! :)
[23:16] <psusi> slangasek, indeed... it's only a 1.3 ghz 10 watt celleron ;)
[23:18] <jdstrand> slangasek, kirkland: for giggles, I updated my bios. when I went into my bios after to check on things, I noticed something called Advanced Thermal Management. Thinking that sounded promising, I moved when on AC from 'Maximum Performance' to 'Balanced'. I don't know if it will fix anything or not yet, I just did it
[23:19] <slangasek> jdstrand: do you have similar-looking trip points under /sys/class/thermal/thermal_zone*/ ?
[23:19] <jdstrand> it seems like as soon as the temp gets around 83, it does something because it drops down 5-10 degrees or more every now and again, but I don't know if that is just the state of my builds or what
[23:20] <jdstrand> $ cat ./trip_point_*
[23:20] <jdstrand> 100000
[23:20] <jdstrand> critical
[23:20] <jdstrand> 91500
[23:20] <jdstrand> passive
[23:20] <slangasek> right, that's what I had last time I looked
[23:20] <slangasek> now my passive is higher than my critical which is screwy
[23:28] <jdstrand> interesting-- when compiling 3 kde4libs at the same time, it never goes above 83, and as soon as it gets there, it drops to 75 or so (this is with thinkfan mind you-- but before it would go up to and stay at 86C)
[23:28] <jdstrand> balanved may be worthwhile
[23:28] <jdstrand> (anecdotal)
[23:28] <psusi> jdstrand, what's the fan doing during this time?
[23:29] <psusi> jdstrand, also it would be helpful to run stress for an even full load instead of something unpredictable like a compile
[23:29] <jdstrand> psusi: well, I am using thinkfan atm, and its above my threshold so it is disengaged
[23:29] <jdstrand> re stres> yes, hence the 'anecdotal' :)
[23:29] <psusi> jdstrand, can you read the actual fan speed?  maybe with lm-sensors?
[23:29] <jdstrand> it is 6425
[23:30] <jdstrand> its disengaged-- I setup thinkfan to monitor the temp and go full-speed about 75
[23:30] <psusi> jdstrand, so when the temp drops does the fan speed go up?  or is the cpu being throttled?
[23:30] <jdstrand> s/about/at/
[23:31] <jdstrand> psusi: right, I think the cpu is being throttled with this new 'balanced' thermal management setting in the bios
[23:31] <psusi> jdstrand, did the trip_point values change as a result?
[23:31] <jdstrand> psusi: I didn't look before, so I don't know
[23:32] <psusi> jdstrand, well if the trip point is 91.5 then it shouldn't be throttling until you hit that
[23:32] <psusi> so my guess is that the fan speed is going up
[23:33] <jdstrand> the fan speed is not going up
[23:33] <jdstrand> is is at ~6400
[23:33] <jdstrand> I am monitoring both temp and fan at the same time
[23:33] <jdstrand> 6400 is max fan speed
[23:33] <psusi> jdstrand, both before it hits 83 and while it is dropping to 75?
[23:34] <jdstrand> psusi: yes. thinkfan is setup up to be 'disengaged' at 75 and higher
[23:34] <psusi> jdstrand, then the big question is whether this happens with stress -c instead
[23:34] <jdstrand> fan speed is steady-- cpu meter is pegged to the top, temp is fluctuating between 75 and 83
[23:35] <jdstrand> well, what I need to do is that and disable thinkfan and see what is happening
[23:35] <psusi> jdstrand, also, how about the frequency?  do you keep an eye on that?
[23:35] <jdstrand> not currently
[23:35] <jdstrand> I was trying to see where that is
[23:35] <jdstrand> oh
[23:36] <jdstrand> /proc/cpuinfo
[23:36] <jdstrand> yeah, it just went from 2134.000 to 1199.000
[23:36] <psusi> jdstrand, add the cpu frequency scaling applet to panel
[23:36] <jdstrand> this advanced thermal management thing is a bios deal
[23:37] <jdstrand> I don't have a panel, I am using unity :)
[23:37] <jdstrand> but, I can't stay longer
[23:37]  * jdstrand has an appt
[23:38] <jdstrand> this likely works fine: watch 'cat ./cpuinfo |grep MHz'
[23:38] <jdstrand> yep, got to 82 then dropped to 1199
[23:38] <jdstrand> temp went to 72 and cpu went up to 2134
[23:38] <jdstrand> neat
[23:39] <jdstrand> ok, gotta go
[23:39] <psusi> hrm... weird...
[23:39] <jdstrand> I don't clean to know how 'advanced thermal management' works btw...
[23:39]  * jdstrand -> really gone
[23:40] <jdstrand> s/clean/claim/