[01:24] <sgCoder> hi
[01:48] <hyperair> huh there's a really huge multiarch breakage today in the archive
[01:49] <hyperair> all my :i386 packages got removed
[01:52] <hyperair> ...even nautilus got removed?!
[01:53] <hyperair> oh it looks like it's fixed
[04:42] <cyphermox> SpamapS: poke
[04:43] <cyphermox> re bug 211631: I'm not certain your comment is true. I think the binaries that run the VPN plugins would get killed by sendsigs.
[04:43] <ubottu> Launchpad bug 211631 in wpasupplicant (Ubuntu Natty) "Network is brought down before network filesystems are unmounted (CIFS timeout at shutdown)" [Undecided,New] https://launchpad.net/bugs/211631
[04:44] <cyphermox> (and I should fix that ;)
=== jalcine is now known as JackyAlcine
=== JackyAlcine is now known as jalcine
[05:49] <SpamapS> cyphermox: Ah so just like dnsmasq, they need to add themselves to the whitelist
[05:50] <cyphermox> SpamapS: possibly. It depends at what point the stuff gets unmounted. if it's a SysVinit script, it would get unmounted before sendsigs, then the vpn plugin binary XYZ would get killed, and all is well
[05:50] <cyphermox> if it's an upstart job, then all is not well; but that's easy enough to fix
[05:50] <cyphermox> I just don't remember and didn't bother to look at the setup again to make sure, yet ;)
[05:51] <trijntje> ping pitti: I'm trying to build a localised image using a PPA, but ubuntu-defaults-image returns "Invalid fingerprint returned by launchpad"
[05:51] <cyphermox> SpamapS: I think regardless it makes sense to avoid the plugins getting killed before NM turns interfaces and VPNs off, which would get stop these processes anyway
=== jalcine is now known as JackyAlcine
=== Whoopie_ is now known as Whoopie
[06:27] <slangasek> cyphermox: sendsigs is run from a sysvinit script, one which deliberately runs before unmounting network filesystems
[06:28] <slangasek> that's the same root issue as it's been all along, just now with a different type of network helper being killed
[06:28] <cyphermox> slangasek: right, because the processes could have been started from a remote FS or depend on it
[06:28] <slangasek> yes
[06:28] <cyphermox> aye aye, will just need to make the processes spawned by NM be omitted for that too
[06:29] <slangasek> yep - *any* process NM spawns, that it expects to keep running and reap on its own at shutdown, should be in the omit list
[06:29] <cyphermox> that's a fix in each of the vpn plugin packages, there are only for.
[06:29] <cyphermox> *four
[06:29] <slangasek> ok
[06:30] <trijntje> pitti: Nevermind, I was using the wrong name for the ppa
[08:21] <rectec> How are you guys? Before I ask for help, I just want to ask how development is going along. We have only 5 days until release and currently my installation looks a bit shabby...
[08:23] <rectec> anyone?
[08:28] <rectec> ok, well... I have a problem in which the text inside dialog boxes is too light to read. This affects the Ambiance theme and one other theme. (The Hope theme, only 3rd-party theme I've tested.) The Radiance theme doesn't seem to have this issue.
[08:29] <rectec> I don't know if this is a known issue and has/has not been solved, or if I'm the only one with this issue.
[10:35] <vibhav> Ive updated a package (onboard) to 0.97-0-0ubuntu3 locally, How Do I get it into oneiric?
[13:56] <jtaylor> doko_: numpy -8 merge: https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/merge-8/+merge/102970
[13:57] <jtaylor> its not very important so if its to late feel free to reject it
[14:52] <jeinor> slangasek: I got the Cubox up and running with kernel 3.3.1 and Ubuntu Core 12.04 beta 2 :D
[14:53] <jeinor> slangasek: got some (a lot) of help from ogra_ in #ubuntu-arm, and with his directions I finally got a login console!
[14:53] <jeinor> slangasek: thanks for all your help too, really helpful!
[14:59] <SpamapS> vibhav: You need to file a bug, make sure that bug is fixed in the latest dev release (precise still.. soon "q"), and then choose 'Nominate for series' in launchpad and choose Oneiric.  https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
=== jsjgruber is now known as Guest18144
[19:08] <hdon-> hi all :) in many months using the latest ubuntu LTS i have noticed that all my CPU cores are rarely used. even if i am building large software packages with -j5 only 1/4 CPU cores are being fully utilized. i'm certainly not I/O bound at the hard disk. if anyone has any advice for me i would be very thankful
[19:18] <penguin42> how many cores do you have?
[19:33] <infinity> penguin42: I'm assuming 4.
[19:33] <infinity> hdon-: How are you determining if your cores are being "used"?
[19:33] <infinity> hdon-: If you make -j5, you should get 5 forks of make (assuming the Makefile can parallelize well, the kernel's always a good test).
[19:34] <infinity> hdon-: That doesn't mean each CPU will get pegged at 100%, but it does mean each will get "used".
[19:34] <hdon-> infinity, the system monitor application
[19:34] <hdon-> infinity, it seems to my eye that only one CPU is being used fully at a time. the others all hover around 20%, and of course they switch off. one core isn't always the same one on duty
[19:35] <infinity> If you make a kernel with -j4 (or higher), you should see a system load in top >= 4.
[19:35] <infinity> Snapshots of system use are rarely accurate.
[19:35] <infinity> (For instance, in the above kernel scenario, with -j4, you'll often see 4 instances of "cc1", but they won't necessarily all report using 100% CPU at all times)
=== Guest94473 is now known as JackyAlcine
[20:00] <IntuitiveNipple> What's the procedure for requesting a freeze exception for a bug-fix at this stage? I've subscribed ubuntut-release as per one wiki recommendation (bug #927828 in sudo) ?
[20:00] <ubottu> Launchpad bug 927828 in sudo (Ubuntu) "sudo: pam_mount.c:417: modify_pm_count: Assertion `user != ((void *)0)' failed." [Undecided,In progress] https://launchpad.net/bugs/927828
[20:46] <cjwatson> IntuitiveNipple: that sounds like a good candidate for an SRU, I think, rather than trying to squeeze a fix in a few days before release when we don't have much time for validation or for recovering if something goes wrong
[20:46] <cjwatson> I assume it only affects people with pam-mount installed (?), so perhaps it's release-note and fix for .1
[20:47] <maxb> cjwatson: Oh, about the subversion FTBFS - I've been slowly slowly plodding through building a set of backported patches, but every time I think I'm done, another test randomly fails.
[20:47] <IntuitiveNipple> It affects all pam modules... its just that pam_mount complains with an assert
[20:47] <IntuitiveNipple> The key issue is, that the bug revealed, pam_open_session() isn't called when sudo has a valid timestamp
[20:48] <IntuitiveNipple> So pam modules that are hooking the begin_session won't get triggered
[20:48] <IntuitiveNipple> I suppose a work-around would be to temporarily set "timestamp 0"
[20:50] <cjwatson> maxb: I know the feeling
[20:50] <cjwatson> doesn't help that it's a slow build
[20:51] <maxb> It builds quite quickly on my desktop; the testsuite is a bit slow, though
[20:51] <cjwatson> IntuitiveNipple: well, what I mean is, this bug was reported in February, and *I* haven't been seeing the second use of every sudo ticket fail
[20:51] <cjwatson> If it were doing that for everyone, this would be High or Critical and likely a showstopper - but it isn't
[20:51] <IntuitiveNipple> Maybe it affects Oneiric->Precise upgrades ?
[20:51] <cjwatson> Then it would affect me
[20:52] <cjwatson> This is the first I've heard of this bug, in fact
[20:52] <IntuitiveNipple> yeah, I was trying to figure out what it is that is causing it. For those that it affects, it occurs whenever there's a valid timestamp
[20:52] <cjwatson> So it must have some kind of narrowed criteria
[20:52] <IntuitiveNipple> Maybe it's something to do with PAM configuration
[20:53] <cjwatson> Hence my comment about libpam-mount, if that's the only thing that fails hard
[20:53] <cjwatson> And since that's an add-on not installed by default, IIRC ...
[20:53] <IntuitiveNipple> Really? I didn't know anything about it until this bug then I found it installed
[20:53] <IntuitiveNipple> Hmmm!
[20:54] <IntuitiveNipple> Maybe it's to do with if encrypted home is in use?
[20:54] <cjwatson> I don't see anything like that in its reverse-depends
[20:54] <IntuitiveNipple> Interesting - I assumed it was part of the standard installation since I didn't recognise it
[20:55] <cjwatson> Just sadms, which isn't by default either
[20:57] <cjwatson> It's been in server-ship since hardy, but that's all I see immediately - can look a bit harder later
[20:57] <IntuitiveNipple> I've just grepped all of /var/log/apt/* which goes back to Dec 5th without seeing libpam_mount ... so maybe it was installed originally by oneiric on my system, since Oneiric was a clean install
[20:58] <IntuitiveNipple> OK .. so I should write up an SRU for it?
[20:58] <maxb> subversion-wise, I think we just have to release precise with it FTBFS; there'll be a SRU soonish for 1.6.18, so it's not completely horrid to do so
[21:01] <cjwatson> maxb: I really want to reach zero out-of-date binaries - perhaps I could help on Monday given your state so far?
[21:01] <cjwatson> although it's on some images I guess, argh
[21:05] <slangasek> IntuitiveNipple, cjwatson: I certainly think not opening pam sessions for authentications with an existing ticket is SRU-worthy but not a show-stopper; in fact there are several bugs in sudo session handling that I think need sorted out in SRU, and this is among them.  But yes, pam-mount isn't stock.
[21:06] <IntuitiveNipple> It must be have been sadms that brought it in - I _vaguely_ recall looking at that package for some reason last year
[21:07] <IntuitiveNipple> slangasek: Well it looks like the sudo author accepts there is an issue now, despite initially saying my analysis was wrong, so maybe now's the time to push bugs upstream
[21:08] <slangasek> IntuitiveNipple: where is the upstream discussion happening?  bug tracker / list / private email?
[21:09] <IntuitiveNipple> Well I found the sudo bugzilla and there were only a handful of bugs in it, so it looks like folks rarely use it. It's linked to the launchpad sudo project though, and I've linked it on the bug itself
[21:10] <slangasek> which bug is that?
[21:10] <IntuitiveNipple> bug #927828
[21:10] <ubottu> Launchpad bug 927828 in sudo (Ubuntu) "sudo: pam_mount.c:417: modify_pm_count: Assertion `user != ((void *)0)' failed." [Undecided,New] https://launchpad.net/bugs/927828
[21:10] <slangasek> ok
[21:11] <IntuitiveNipple> Rich Miller _is_ the upstream author, was very quick and precise in responding
[21:22] <slangasek> pitti: so we've worked out with some difficulty that a client-side apport dupe check is causing update-manager crash reports to be treated as duplicates of a closed bug (bug #628104) and we want to have them *not* treated that way so we can get full clean backtraces from bug submitters.  How do we do that?
[21:22] <ubottu> Launchpad bug 628104 in Aptdaemon "update-manager crashes: AptDaemonError: org.debian.apt: Could not cancel transaction" [Undecided,Confirmed] https://launchpad.net/bugs/628104
[21:23] <slangasek> well, a bug that /was/ closed
[21:23] <slangasek> pitti: I don't have confidence here that the duplicate signature is accurate and would like to see a recent backtrace
[21:24] <slangasek> pitti: or at least get a better understanding of the duplication algorithm :)
=== Nisstyre is now known as nisstyre
=== nisstyre is now known as Nisstyre
[22:29] <maxb> cjwatson: Sorry, was away; yeah, I figured it was already too late what with it being seeded
=== Ursinha` is now known as Ursinha
=== Ursinha is now known as Guest65814