[00:00] ah I see. [00:04] * TheMuso shudders. [00:04] WHy do I hear Windows in this theme? [00:04] hey all [00:06] themuso, there's a theme ready to go. [00:06] people seem to like it [00:06] LLStarks: Yes, I saw it in the bug. [00:06] LLStarks: Count me out of that group. :) [00:06] But it won't be up to me. [00:06] mark isn't opposed to the theme [00:07] But from that bug, I can't see that he has endorced it either. [00:07] That's not exactly a ringing endorsement :) [00:08] RAOF: Exactly. [00:11] TheMuso, speaking about FFE, could you please take a look at empathy bug I've linked above? [00:11] elleuca: If it needs approval, I can't give it that. [00:19] TheMuso, it needs some sort of coordination: by now there is a regression in a feature advised by canonical design team. Who can mark a bug as "blocker" for final release? [00:20] elleuca: Hrm ok, kenvandine probably is the one who needs to look into it. [00:21] slangasek, got a sec? [00:21] bryceh: yep [00:22] slangasek, we've been debugging 8xx on lucid for a while now [00:22] we've been able to get it working well for some, but broken for others [00:22] and are in a situation where it seems fixing it for the latter just ends up breaking it for the former [00:22] themuso, who should i speak to regarding the sound theme? who would be responsible for coordinating an implementation? [00:22] upstream is busily working on the issue but seems pretty insane - see http://cgit.freedesktop.org/~danvet/drm/commit/?h=stuff/i8xx_cache_coherency_for_oga&id=925114122c4bc9864951478e62169e9f34f9d41c [00:23] slangasek, so at this point we see two choices, and your opinion would be helpful [00:23] upstream seems pretty insane, or the bug does? ;) [00:23] a) disable -intel entirely and default to -vesa for this hardware. People can still opt-into -intel via xorg.conf [00:24] b) ship the buggy -intel, and releasenote the issues, with a list of workarounds documented [00:24] slangasek: Have a look at the commit message :) [00:24] bryceh: how confident are you that VESA won't also break for some as-yet-unidentified subset of users? [00:25] one factor is when 10.04.1 rolls around, if we went with (a) we could consider turning -intel back on, but at this point it's hard to predict whether upstream will have a 100% working solution for you [00:25] slangasek, I'm not sure, but in part it's not whether it'll break things but to what degree [00:26] i.e. they'll lose 3D, proper modesetting, maybe video playback, etc. Not sure whether suspend/resume works with vesa, etc. etc. [00:26] so... most likely they'll be able to boot and run Ubuntu enough to look for workarounds [00:26] enough to open gedit xorg.conf and try switching on intel ;-) [00:27] LLStarks: I don't know who is responsible for choosing what goes into the theme, other than Mark. I will likely help with the technical implementation of it though. [00:27] bryceh: has there been subsequent feedback from users that the git commit you pointed to does *not* solve the problem for them? [00:28] slangasek, so few people have 8xx that getting solid representative testing has been challenging [00:28] slangasek: No. The upstream bug reporters all report that this (finally) fixes it for them. We haven't tried pulling it into an Ubuntu kernel yet, as far as I'm aware. [00:28] slangasek, the upstream bug report for this is at https://bugs.freedesktop.org/show_bug.cgi?id=27187 and the tail end of it is *not* filled with happy users saying all is well now [00:28] Freedesktop bug 27187 in Driver/intel "[i855GM] gtt chipset flush is not cache coherent" [Normal,New] [00:29] bryceh: right, which is one of my concerns with plan a) - if we do try to fix it in SRU, we might not get feedback on the regressions until it's a regression-update bug [00:30] slangasek, also the description of the patch does not fill me with confidence... he describes it as a hack that "probabilistically" tunes things so it behaves properly according to feedback from the testers so far. [00:30] slangasek, *nod* [00:30] bryceh: in which case, I would prefer (by a small margin) to ship it broken in release and release note it so that we can make incremental improvements in SRU with some degree of confidence that we're heading in the right direction [00:31] oh, though this change means turning DRM back on by default in SRU, doesn't it [00:31] you mean KMS? I think that'd be orthogonal [00:32] er, you're right [00:32] ok [00:32] RAOF, your comments? [00:32] RAOF: and yes, that is a beautiful commit message [00:33] slangasek, but I think what we'd do is switch DRI back on in the -intel driver (it didn't work around the issues as well as we expected it to, and in fact some people claim it caused further regression for them) [00:34] with that patch dropped, the user could still toggle it on or off to experiment with if it helps them [00:34] If you think it'll be better to ship with known issues so it's easier to fix later, then I'll go with that. We're not *really* sure how widespread this problem is, and it's not a deterministically triggerable bug anyway; getting sufficient testing in -proposed will be difficult if we go with vesa. [00:34] that's reverting the patch from 2:2.9.1-3ubuntu3 ? [00:34] Yes. [00:35] hmm, hate to turn that back on post-RC; also hate to respin all of RC for it [00:37] well, alternatively we could leave DRI off, and update the patch post-release to allow it to be configurable, although RAOF thought that could be difficult to code [00:38] Difficult to code without introducing an Ubuntu-specific xorg.conf option, which I didn't want to do in the initial patch. If we're ok with that, then it won't be too hard. [00:44] RAOF, I don't have a problem with it [00:44] bryceh: let me get a feel for where things are with ISO testing; I think we're far enough along that I would prefer to have that DRI reversion made after RC, but still pre-release if we can [00:44] slangasek, ok [00:45] RAOF, the one thing would be if we add a parameter we'd need to make sure to include mention of it in the man page [00:45] bryceh: Right. [00:46] rickspencer3, ^^ if you're interested, new plan of attack being discussed for 8xx [00:46] I was watching [00:47] rickspencer3, your thoughts? [00:47] so basically, turn it back to the way it was before, and then let folks having trouble turn it back on? [00:47] well, turn off dri and kms [00:47] am I understanding it? [00:47] Yes. [00:47] * bryceh nods [00:48] so then we ship a cleaner upstream configuration, and then update if there is something we know will help? [00:48] by "cleaner" I mean closer to upstream 2.0 [00:48] basically we'd ship known-buggy 8xx support, with anticipation we may be able to improve things in SRU's and/or .1 updates, and document the heck out of workarounds [00:48] oops 2.9 [00:49] bryceh, so, in total, it seems that the mitigations of disabling DRI and KMS made things worse, or at least not better? [00:49] is that your opinion now? [00:49] well I think we're quite far from "upstream clean" right now [00:49] right, thus the *er* [00:49] ;) [00:49] rickspencer3, my suspicion is that we shifted the problem rather than reduced it [00:49] like they are testing it with these turned off and such [00:49] ok [00:49] DRI doesn't seem to have made things significantly better, and also may have regressed things for others. [00:50] so my thoughts are: [00:50] 1. I think slangasek's gut it probably right about this, will take more time that we have to figure out something we *know* will help [00:51] 2. I trust bryceh's judgement about what's help, not helping, and RAOF backs it up [00:51] so, seems like a good plan if we still have time to implement it [00:51] * rickspencer3 chalks up lesson of turning knobs, never seems to help xorg-server much [00:51] heh [00:51] TheMuso, thanks, I'll poke kenvandine [00:52] rickspencer3, sometimes it does [00:52] bryceh: ultimately, are we expecting to turn KMS back on for *all* the intel chips that have been blacklisted in the kernel, or just some of them? [00:52] rickspencer3, but you're right we're back in a similar situation as we were with -intel in jaunty with all those X freezes, and knob turning ain't doing it for us [00:52] it's like Jaunty, except the scope is *much* smaller [00:52] I don't think i830 has anything coming along the pipeline that would make us turn KMS back on for it. [00:53] slangasek, for 8.10 we'll have to. Either that or stop supporting 8xx with -intel [00:53] and users of 8xx can back up to vesa, and have a respectable level of support consider the vintage of their hardware [00:53] AND there are previous releases that still work well for them [00:53] slangasek: So, no. I don't think we'll be unblacklisting all of those cards. [00:53] rickspencer3, *nod* [00:54] slangasek: I've obviously interpreted that question differently to bryceh. I don't think we'll be turning KMS back on *in lucid SRUs*. [00:54] bryceh, RAOF: ok, if we wouldn't be turning it back on for i830, that means trying to add /etc/modprobe.d/i915-kms.conf back wouldn't be the right solution [00:55] RAOF: ok - I wasn't sure if re-enabling KMS for i810 was related at all to fixing the problem [00:56] shall I go ahead and sketch out the release notes entry about this? [00:56] slangasek: For i855 it's entirely orthogonal. I'm not sure that it's known what's needed for i845, and I'm not sure that anyone's *working* on i830 :) [00:56] ok [00:56] bryceh: written on the assumption that we're keeping intel enabled by default for release, and backing out the DRI patch? [00:57] (and giving users instructions on how to get to VESA?) [00:57] RAOF, you seem to already know what to do to add the config option to the dri patch, mind doing that part? [00:57] slangasek, that's correct [00:57] bryceh: Certainly. We're going to keep DRI disabled by default, rather than backing out the patch entirely? [00:57] either backing out the DRI patch or making it more configurable [00:58] if we think that's where we're going to end up, I think we should back out the DRI patch rather than adding more knobs [00:58] RAOF, guess I missed the part of the discussion where we made that decision [00:58] slangasek, okie [00:58] bryceh: I did too :) [00:59] slangasek, ok sounds like a plan [00:59] it may cause a few more users to regress in final, but we have no idea how many, and it will let us converge more quickly on a resolution in SRU if we don't give them another knob [00:59] Yes. [00:59] everyone happy with this plan? [01:00] I wouldn't go so far as *happy*, but I don't think there is a better one. +1 [01:01] yeah +1 here too [01:02] ok [01:02] thanks, guys :) [01:03] In a related query - where does checkbox data go? Could we mine that data to get a better idea of how widespread this problem is? [01:05] RAOF: if you brought your pickaxe [01:05] I have a trowel, will that do? [01:05] :) [01:05] bdmurray: ^^ who has the access / expertise to help with that? [01:07] oh man [01:21] RAOF: You want to catch cr3 to get that data. [01:24] slangasek: Are the changes for that likely to result in a new pre-release kernel upload? [01:35] persia: no [01:35] OK. In that case I won't try to slip anything else in :) [01:36] I think you just did... :) [01:37] slangasek: short known-issue blurb added to https://wiki.ubuntu.com/LucidLynx/TechnicalOverview with longer blurb added at https://wiki.ubuntu.com/X/Lucidi8xxFreezes [01:37] RAOF, please review in case I got something wrong ^^ [01:38] bryceh: could you please add it to https://wiki.ubuntu.com/LucidLynx/ReleaseNotes as well? (Tech Overview stops being used for errata at RC) [01:39] ok [01:41] cjwatson: re bug 558382; it looks like libparted is segv'ing in libparted/label/dos.c on the added DEBUG_CONSTRAINT on the intersection variable. [01:41] Launchpad bug 558382 in partman-base "Partitioner throws "Unable to satisfy all constraints" when trying to use previously created partitions" [High,Incomplete] https://launchpad.net/bugs/558382 [01:42] General g++ question. We have a class which appears to have different sizes from the perspective of main and code within inherited classes. Any thoughts as to why? [01:44] bryceh: We're not turning KMS back on by default for those cards, are we? [01:44] RAOF, no [01:45] RAOF, really it's too late to be making adjustments to the kernel [01:45] I'll fix up the freezes page, then. [01:45] thanks [01:45] (The instructions are currently i915.modeset=0 to turn kms back on ;)) [02:02] slangasek: https://wiki.ubuntu.com/LucidLynx/ReleaseNotes updated [02:02] RAOF, doh [02:02] bryceh: thanks! [02:02] cut-and-paste fail [02:03] wow, CAB is still listed in the release notes [02:04] nomodeset no longer does anything, right? [02:04] RAOF, afaik [02:04] * RAOF tests [02:05] That should be removed from the release notes, then. [02:05] bryceh: it's new since hardy... :) [02:05] nomodeset still works [02:05] slangasek, aha true [02:06] nomodeset just doesn't override an explicit i915.modeset=1 [02:06] hmm [02:06] ok, well I should say I've sene people say nomodeset didn't work but i915.modeset=0 did [02:06] bryceh: that was before I uploaded xserver-xorg-video-{intel,radeon} [02:08] aha [02:08] to take out the explicit i915.modeset=1 ;) [02:08] cjwatson: ah, yeah, at least the first time through _try_constraint(), ped_constraint_intersect() is returning NULL. [02:19] bryceh: do you know if there had been any changes regarding i855 chipsets in the latest kernel update? -21 doesn't boot on my machine, while -20 is fine... [02:21] ArneGoetje: -21 disabled KMS. Does booting with “i915.modeset=1” on the kernel line help? [02:21] RAOF: I'll try [02:21] ArneGoetje, yeah we made some additional changes to try to get things working for more i8xx users [02:22] we weren't too successful [02:22] RAOF, ok that's one case so far where KMS actually made it work better [02:22] :) [02:25] RAOF, bryceh: yes, turning KMS back on fixes it. [02:27] Hooray for -intel! [02:27] *sigh* [02:27] the -intel merry-go-round [02:28] ArneGoetje, ok thanks [02:29] ArneGoetje, not sure if we can update the kernel before release (or if we can, whether we want to) so take that as your workaround for now. We've documented in the release notes about this. [02:29] bryceh: ok, noted [02:45] slangasek: if there is a hardware database query done for something I'm likely the best person [02:45] slangasek: however, I'm heading out the door right now [03:15] bdmurray: ok - I think RAOF has a question for you about ancient intel chips, then [03:16] bdmurray: When you get back in :) [03:18] slangasek: wanted to check on the status of the openoffice.org-dictionaries package waiting? [03:26] ccheney: the status is "waiting" - is there a particularly urgent fix in there that would justify resetting all the ISO tests for RC? [03:31] slangasek: no, forgot about us already having spun the discs [03:32] ccheney: ok. Do any of these changes affect binary package sizes? [03:32] heh guess i should have realized that as nothing new downloaded recently [03:32] slangasek: they shouldn't it just changed some symlinks so possibly a very tiny increase due to that [03:33] slangasek: seb128 did the actual build so he would be more aware of what the precise difference is [03:33] ccheney: debian/openoffice.org-thesaurus-fr.install - that doesn't look like symlinks, and seems to be the main fix people are after? [03:33] ccheney: since seb128 isn't around for several hours yet, would you have time to do a build test of that upload and let me know if openoffice.org-thesaurus-fr changes size and by how much? [03:33] slangasek: i'll look into it more but i was under the impression from reading what the involved parties said that it was an issue of it being installed with the wrong filenames or something to that effect [03:33] i can check to see [03:34] slangasek: is there somewhere i can download his merge from, or i can just redo it, should be fairly trivial [03:35] ccheney: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1 [03:35] thanks [03:36] slangasek: alright will let you know what i find out, is deb size the most important thing to check or also installed size, etc? [03:36] ccheney: both unpacked and packed size are important to know [03:37] (even though "unpacked size" -> "size on liveCD" is a total fudge factor :/ ) [03:38] ok [03:43] About my bug https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/564364 [03:43] Launchpad bug 564364 in qemu-kvm "dpkg install should not assume any services are running. I had to do apt-get dist-upgrade in emergency mode and it broke because this service assumed it could do update-binfmt from a kernel this di..." [Wishlist,Confirmed] [03:43] I think I identified a way to know if dpkg "owns" the running kernel [03:43] not foolproof, but if our own /sbin/init is pid 1, dpkg probably does [03:44] easy to check as root by running stat on /proc/1/fd/exe and /sbin/init [03:44] un214: So, how do you know if the currnet /sbin/int is pid 1? Especially, how can you tell when /sbin/init is binary-identical to /sbin/init outside the chroot? [03:45] ccheney: oh - it seems openoffice.org-thesaurus-fr doesn't land on any ISOs, so no need to double-check this after all - sorry for taking your time [03:45] dev/inode pair of /proc/1/exe will match if true [03:45] if not true, then even if binary identical some other dpkg owns kernel [03:47] un214: OK. Now, to ask a more general question, why is this a bug in dpkg? Why not in update-binfmt? Should it not detect when the running kernel isn't the filesystem kernel, and perhaps not do something, or do it later? [03:47] I listed it as a bug in qemu-kvm [03:47] right, it's not a bug in "dpkg", it's a bug in the qemu-kvm maintainer script called by dpkg [03:47] (or, if triggers are involved, then in the package providing the trigger) [03:48] I'd be quite glad to provide a /usr/sbin/owns-running-kernel if you wish [03:48] Is it? Or is it a bug in binfmt-support? [03:48] (the not foolproof case is a `uname -r` matching kernel with different options on rescue media) [03:49] persia: I'm not sure which [03:49] persia: ah - looking at it, yes, I agree it's binfmt-support [03:49] (but - most importantly - not dpkg :) [03:49] Yeah, dpkg isn't even in control at this point: it doesn't "own" anything. [03:49] OTOH, qemu-kvm-extras-static has a serious bug in its postinst, it calls 'start procps' :P [03:50] I can't even imagine what that would do [03:50] in a chroot? it will fail miserably because 'start' tries to talk to a running upstart that it can't reach [03:51] in my case it would have found upstart, for the wrong architecture [03:51] the only stable interface for maintainer scripts to use currently is still 'invoke-rc.d procps start' [03:51] un214: isn't it running in a chroot? [03:51] with most stuff crossmounted [03:52] So two bugs: one against binfmt-support (should work in chroot) and the other against qemu-kvm-extras-static (should work in a chroot) [03:52] I don't think you can crossmount the control socket [03:52] mount -bind on the directory works [03:52] since it's a unix socket that's not exposed in the filesystem :) [03:52] At least it's not safe (or sane) to crossmount the control socket [03:52] slangasek: oh ok [03:52] slangasek: You could bind it to a fifo if you *really* wanted :) [03:53] if it's not in the filesystem how to programs open it? [03:53] un214: unix sockets have their own API [03:53] persia: hisssss [03:53] well if they're not in the filesystem how are they going to respect chroot then [03:54] un214: The basic rule is: don't use a socket in a chroot unless it's opened in the chroot. [03:54] figured that much [03:55] as you know schroot binds /tmp /proc /var/tmp and /home [03:55] and /dev [03:55] un214: they respect the chroot because they have a path which the kernel still interprets *relative* to the current process root, they just don't have paths that are exposed to 'ls' or trivially cross-mountable [03:55] hmmm [03:56] I'll have to go look up how that works (I'd have guess /proc/1/fd/X) personally [03:57] you did know that you can jailbreak if /proc is shared between jails and you have code as same user in both of them right? [03:58] That's just one of many ways. Let's not go over them now :) [03:58] ok [03:58] But we ought make sure our maintainer scripts work in a way that it's safe to use them in schroot. [03:59] I offer the detect program if it would help you any [03:59] un214: Actually, what would help best is tracking down unsafe cases (like this one), and adding patches to make them safe to the bugs. [04:00] Extra points for getting more involved, and sheparding those patches into the releases, but just finding and fixing them is the key bit. [04:01] probably of me finding another is darn low [04:02] although I found the grub one awhile back [04:02] Most of us only use schroot to build packages, so things not build-dependencies of other things are often missed. [04:02] dist-upgrade inside schroot clobbered the system bootloader [04:02] grub and qemu-kvm-extras-static both fall into that category. [04:02] ah I use it normally [04:02] And it shouldn't, especially now that we have decent support for cross-arch schroots. [04:03] (at least for armel/powerpc on amd64 guests) [04:03] if I get just one more broken driver during apt-get dist-upgrade I'm going to run my whole system in schroot and use core drivers from slackware [04:05] I never could figure out any possible fix for the grub one as it actually needs to do that in some cases === mnepton is now known as mneptok [04:22] incidentally, how to build against klibc? [04:23] Set your build depends differently. [04:23] ... [04:30] apt-get source klibc yielded a GPG error [04:30] public key not found [04:31] a warning, I'm sure [04:33] yeah warning [04:33] anyway looks like can't link against klibc correctly in the stock packages [04:34] or not, just installed funny [04:35] ugh too tired making stupid mistakes [04:35] good night [05:41] hi, [05:42] on offline system there is a need for the software list to be downloaded from ubuntu and then the "generate download script" function of synaptic will do the rest. is it possible to do so? [05:42] https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378 [05:42] Launchpad bug 251378 in synaptic "Synaptic's Generate download script does not update package lists" [Wishlist,Triaged] [05:42] is related [06:15] robert_ancell: simple-scan> this doesn't look critical for release; I'd like to redirect this to SRU [06:46] slangasek, sure, it is not critical [06:49] robert_ancell: ok - rejecting, please reupload to -proposed whenever you wish (but please open a bug report about the issue first, and link it in the changelog) [06:51] slangasek, it already is linked to a bug report... === almaisan-away is now known as al-maisan [07:22] robert_ancell: oh, was it? Hmm, somehow I missed it in the debian/changelog then [07:24] on offline system there is a need for the software list to be downloaded from ubuntu and then the "generate download script" function of synaptic will do the rest. is it possible to do so? [07:24] https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378 is related [07:24] Launchpad bug 251378 in synaptic "Synaptic's Generate download script does not update package lists" [Wishlist,Triaged] [07:27] pitti: around? [07:32] pitti: nm [07:37] Good morning [07:37] mdke: thanks [07:37] mdke: hello [07:38] pitti: hi :) [07:38] hello [07:38] good morning [07:39] pitti: I was going to ask you about a bug in pkgbinarymangler but then realised that there is already a report for it [07:42] hi, I've asked about providing update packages [07:49] mdke: hey - did you see pitti's question yesterday about disabling the "Report a bug" menu item, and whether this will impact documentation/ [07:49] ? [07:51] slangasek: yes, I said to him that it sounded fine [07:52] mdke: aha - sorry, was asynchronous so I didn't notice :) [07:52] slangasek: nw. Is this the "Report a problem" help menu item in Gnome applications? [07:53] mdke: yes [07:54] slangasek: ok, no problem [07:54] mdke: we discussed disabling that on the last UDS, but I totally failed to notice the doc team about that; sorry about this [07:54] pitti: not at all. We don't document bug reporting actually. there is something in the gnome user guide about it but it doesn't mention that menu item [07:55] mdke: right, this is an Ubuntuism anyway [07:55] (launchpad-integration package) [07:55] ah, I see [07:56] mdke: we'll keep the other two (get help online and translate) [07:56] * mdke nods [08:04] pitti: can you approve my nvidia-96, please? [08:08] the source name is nvidia-graphics-drivers-96A [08:08] nvidia-graphics-drivers-96 [08:24] tseliot: not right now, sorry; this has to wait for post-RC or SRU [08:25] good morning [08:26] good morning [08:26] pitti: post RC would be better as it's a rather nasty regression that will break at least dist-upgrades [08:56] tseliot: ah, a fix for that dratted bug that users kept blaming on gdm, excellent... :) yes, I'll take that post-RC [08:56] slangasek: yes, that's the bug. Thanks a lot [08:57] slangasek, those my one liner fixes you don't take but other change you do ;-) [08:57] slangasek, hey btw [08:57] seb128: your one-liners for bugs you yourself marked as 'low'? :-) [08:57] still would avoid me the sru paper work ;-) [08:58] slangasek, btw are lucid-proposed uploads already queued? [08:58] oh, thanks for pointing out the flaw in our system - I'll design more paperwork for freeze exceptions >:) [08:58] lol [08:58] AFAIK lucid-proposed is open, yes [08:58] ok thanks [08:58] if uploading to it doesn't work, let me know [09:00] I guess you are busy with preparing lucid. so my bug need to wait. right? [09:05] Damascene: yes, at this time of the cycle most people you find around on IRC have their hands full with other bugs, sorry [09:06] ok [09:48] How do I make an init script not stop at powering down at all? [09:56] Koterpillar: you mean to not get called on shutdown? [09:56] Yes, not to get called with stop on shutdown [09:56] Koterpillar: do not install symlinks into rc0.d and rc6.d, i. e. do not call update-rc.d with 0 and 6 [09:57] They are not there [09:58] In fact, for 0 and 6, there is neither S nor K link [09:58] then the script doesn't get called === radoe_ is now known as radoe [10:01] Let me check... [10:05] Well, the script doesn't get called, but someone kills the daemon it starts [10:09] Koterpillar: sure, /etc/rc6.d/S20sendsigs will [10:10] there are means for telling sendsigs to skip your process when shutting down, but that's rarely appropriate... [10:11] I want to do exactly that [10:13] So if I'm not an Upstart job, I should register with /lib/init/rw/sendsigs.omit.d/ ? [10:13] slangasek: I uploaded a fixed pkg-create-dbgsym which fixes the missing glib 2.0 dbgsyms (bug 566602); it's all testcase'd, so I'm very confident in that it doesn't cause regressions; the package isn't on any CD/DVD, so it might be okay to accept it? (We'll upload another no-change glib2.0 build after RC then, to get the dbgsyms back) [10:13] Koterpillar: yes, /etc/init.d/sendsigs most probably [10:13] Koterpillar: if you have a daemon which needs to run until the very bitter end, you need to add its pid to /var/run/sendsigs.omit [10:13] Launchpad bug 566602 in pkg-create-dbgsym "does not build libglib2.0-0-dbgsym" [High,Fix committed] https://launchpad.net/bugs/566602 [10:16] sbeattie: the segfault itself is information :-) [10:18] pitti: looking [10:23] slangasek: thanks [10:33] sbeattie: actually never mind that comment, the segfault was during initialisation so not so relevant [10:37] * hyperair wonders if a kind archive admin could look into syncing nautilus-share (Bug #565418) [10:37] Launchpad bug 565418 in nautilus-share "Sync nautilus-share (main) 0.7.2-13 from Debian Unstable" [Wishlist,Triaged] https://launchpad.net/bugs/565418 [10:42] hyperair: not right now, we are frozen for RC [10:42] pitti: ah. RC. [10:50] mdz, do you still see OOM ? i seem to only get it while rhythmbox plays music here [10:51] * ogra had a calm system for the last two days ... just started playing some music and OOM returned [10:55] ogra, I've removed my Google Calendar feed and it seems OK now [10:55] hmm, k, then i probably see a different bug here [10:56] my load bumps above 4 if i change windows ... but i dont see any process consuming a lot of ram [11:25] I confirm that the google calendar feed is driving evolution nuts here too === DrPepperKid is now known as MacSlow [11:26] didrocks, what do you call feed in that context? [11:26] seb128: the calendar account [11:27] didrocks, ok, I've that one configured but I don't notice issues there [11:27] I don't have lot of things in my calendar though [11:27] seb128: I do have multiple calendars (personel and work one), trying to keep just one. === ogra_ is now known as ogra === MacSlow is now known as MacSlow|lunch [12:30] * ogra dist upgrades to see if rhythmbox stops causing OOM [12:32] seb128, did you hear about any bug relating the above (i havent found the root cause yet, but firing up RB makes it 100% reproducable for me) [12:32] ogra: no, is that armel specific? [12:32] i suspect ubuntuone being at fault [12:32] seb128, nope, its my laptop [12:32] ogra: try turning the store off maybe and see if that's still an issue? [12:32] i commented a lot on bug 563879 to find out its likely a different one [12:32] Launchpad bug 563879 in evolution-data-server "evolution-data-server consumes massive amounts of memory, invokes OOM killer" [Undecided,Confirmed] https://launchpad.net/bugs/563879 [12:33] seb128, will do after the upgrade is run [12:33] don't change to many parameters at one [12:33] the confusing bit is that i cant seem to find anything that actually consumes memory [12:33] ie maybe try without change after upgrade [12:33] but oom clearly kicks in [12:33] then if you still get the issue try without the store [12:33] yes [12:34] do you have free ressources when it kicks in? [12:34] will do it like that and file a new bug if its still there [12:34] yes, htop shows about 800MB being used (from 4G) [12:34] top doesnt show any excerssive ram usage either [12:35] i see my load bumping up between 4 and 5 [12:35] but no massive CPU or ram usage ... [12:35] it's weird [12:35] and after a while i see chromium tabs die [12:35] looking at dmesg after that i see they die because of OOM [12:35] do you run package installs during the same time? [12:35] nope [12:35] nothing special [12:36] well that would explain io hits but not ram usage anyway [12:36] i just have three terminals, about ten tabs in chromium, xchat, evo and rb open [12:36] but as soon as rb is playing music my mouse is even hard to move [12:36] weird [12:36] gets jumpy and stuttering [12:37] did you try run iotop to see if it lists something? [12:37] not yet [12:37] try that too [12:37]