[05:33] <StevenK> RAOF: Finally got around to filing a bug.
[05:33] <RAOF> StevenK: About what in particular?
[05:34] <StevenK> RAOF: My Nvidia display corruption, remember?
[05:35] <RAOF> Oh. That one :)
[05:36] <RAOF> So many bugs!
[08:50] <xnox> so, I have uploaded an SRU and it has been accepted into -proposed, but one bug # was not mentioned in the changelog, and has not been mentioned in the changes and therefore is not in the sru-report. Is there any way to mark that bug as fix-committed and get the same comment and ideally manually add it to the sru report?
[08:51] <xnox> bug 946758
[08:51] <xnox> is part of the mdadm sru.
[09:04] <tkamppeter> I havesome problems with a new Intel HD graphics PC
[09:06] <tkamppeter> The mobo has only HDMI and DisplayPort output, but xrandr shows also a VGA output which is limited to 1024x768 and fully automatic startup falls aways into 1024x768.
[09:07] <tkamppeter> How can I makethe login screen 1920x1080?
[10:23] <ev> mpt: it does seem suspicious that the 12.04 and 12.10 lines are so closely mirroring one another http://10.20.66.232/
[10:25] <mpt> ev, it's a 2-or-3-day trend now, so that rules out a mistake in calculating from the day fraction, right?
[10:26] <mpt> (Would be a lot easier to see this if there was only one data point per day, ahem)
[10:27] <ev> mpt: there is only one data point per day. Mouse over the graph
[10:27] <ev> but yes, I still need to fix the axis
[10:27] <mpt> ev, sorry, I meant axis tick mark
[10:28] <mpt> ev, so in order from source to destination, possibilities: (a) fixes in Q, and to a lesser extent SRUs in 12.04, really have made Ubuntu more reliable the past couple of days
[10:28] <mpt> (b) something changed in the client the past few days (did it?)
[10:28] <mpt> (c) there's a date-specific problem that makes the client less likely to report errors
[10:28] <ev> b> nope
[10:29] <mpt> (d) there's a network problem between clients and the data center
[10:29] <mpt> (3) there's a date-specific problem that makes the server less likely to accept error reports
[10:29] <mpt> s/3/e/
[10:29] <ev> yeah, I think we need more data before we know which of these it is
[10:29] <mpt> (f) something changed in the server the past few days (no, since there hasn't been a rollout)
[10:29] <ev> if you turn off the 12.10 line, the 12.04 line shows quite a bit more variability
[10:30] <ev> (you can click the circles in the top right)
[10:30] <mpt> It's smaller than the drop from the 19th to the 20th
[10:31] <ev> yeah, true
[10:31] <mpt> so I concur with the need for more data :-)
[12:46] <Sweetsha1k> mpt: did you get my reply wrt fonts in libreoffice btw?
[12:47] <mpt> Sweetshark, yes thank you. I'm planning to discuss it further today.
[12:53] <mdeslaur> infinity: FYI, I'm stealing your mono merge to get a security fix
[12:54] <Sweetshark> mpt: great
[12:55] <infinity> mdeslaur: Sure, it's a simple merge, go nuts.
[12:55] <infinity> mdeslaur: Or I could do it right now.
[12:56] <infinity> mdeslaur: If you don't want TILM. :P
[12:56] <mdeslaur> infinity: I'm uploading it as we speak
[12:56] <infinity> mdeslaur: Alrighty.
[12:56] <mdeslaur> infinity: but I'm using your gpg key, so you'll still be TIL :)
[12:56] <infinity> mdeslaur: Suuuure you are.
[12:56] <mdeslaur> hehe :)
[12:57] <infinity> Thanks for the reminder that I need to get that change committed to Debian, though.
[12:57] <infinity> We really shouldn't be carrying the delta.
[14:19] <smoser> jodh, i have a upstart job named 'cloud-config', is it silly/wrong/ok that that job would emit 'cloud-config' ?
[14:20] <jodh> smoser: that's fine. Make sure you include 'emits cloud-config" in the job to ensure 'initctl check-config' works of course.
[14:21] <smoser> to ensure?
[14:24] <jodh> smoser: it means that you'll get sane results from initctl2dot (and it means that 'initctl show-config' is parseable too).
[14:24] <smoser> ok, thank you.
[14:24] <smoser> 'emit cloud-config' added.
[14:25] <smoser> err.. emits
[14:31] <smoser> jodh, SpamapS i wonder if either of you have any experience with 'runit'
[14:32] <smoser> it seems it doesn't interact well with upstart if installed via cloud-init.
[14:33] <smoser> i run an instance with http://paste.ubuntu.com/1113891/ as userdata.
[14:33] <SpamapS> smoser: there are two components of runit. One of them is a pid 1 replacement, and that definitely does not work with upstart
[14:33] <smoser> and then it seems to stop boot once runit is installed.  --verbose log at http://paste.ubuntu.com/1113895/
[14:34] <smoser> oh. wow.
[14:34] <smoser> i didn't realize it was a pid 1 replacement.
[14:34] <SpamapS> well the other bit is just a daemon
[14:34] <SpamapS> smoser: in the past it did a dpkg-divert of /sbin/init
[14:35] <SpamapS> smoser: but I think the one installed there is the "safe" one
[14:35] <SpamapS> smoser: but looks like nobody has tested it on Ubuntu in a while ;)
[14:35] <SpamapS> grep: /etc/inittab: No such file or directory
[14:36] <smoser> yeah, i saw that bug figured it was just the postinst script not working right.
[14:36] <smoser> but basically the install of it stops further events from happening.
[14:36] <smoser> ie, my cloud-final.conf never runs.
[14:37] <smoser> SpamapS, you interested in looking at a system really quick? (i'm fine if the answer is no)
[14:37] <smoser> ubuntu@ec2-23-22-213-255.compute-1.amazonaws.com
[14:39] <SpamapS> smoser: yeah I'll poke it. This feels like bug triage to me. :)
[14:39]  * SpamapS plans on spending all day on triage to help us catch up
[14:40] <SpamapS> smoser: security groups
[14:40] <smoser> SpamapS, ? you should be able to get in
[14:40] <SpamapS> hanging at connecting
[14:41] <xnox> slangasek: bug #946758
[14:41] <xnox> slangasek: https://bugs.launchpad.net/ubuntu/precise/+source/mdadm
[14:41] <smoser> SpamapS, http://paste.ubuntu.com/1113904/
[14:42] <smoser> i can get in from here.
[14:42] <smoser> that is weird.
[14:44] <ScottK> barry: Bug #1029640 looks to me like a good one to get fixed before 12.04.1.  Checking to see if you agree?
[14:45] <SpamapS> smoser: totally. I'm bouncing off my ec2 instance in us-west-1 and its working
[14:48] <smoser> SpamapS, thanks.
[14:52] <xnox> infinity: wanna talk about e2fsprogs? =)
[14:55] <barry> ScottK: looking
[14:55] <ScottK> Thanks.
[15:00] <barry> ScottK: yes, it would be nice to have a test case for the sru
[15:00] <ScottK> That's what I'm waiting for before I upload.
[15:11] <infinity> xnox: Not really, but I suppose we should. ;)
[15:12] <xnox> infinity: lol =))))
[15:12] <infinity> xnox: Make me some coffee, please, I'll be with you shortly.
[15:12] <xnox> infinity: ok. here or mumble?
[15:14] <infinity> IRC's fine.  Let me go get some waking up done.
[15:24] <ScottK> You can tell a spec's going well when the diff is:
[15:24] <ScottK> - Work items for quantal-alpha-3:
[15:24] <ScottK> + Work items for ubuntu-12.10-beta-1:
[15:27] <infinity> ScottK: Oh, regarding our bug log argument.  If you're happy with better trumping perfect for now, poke me on the weekend when I'm not hip-deep in glibc, and we can make backports less sad.
[15:27] <ScottK> infinity: Great.  I'll try to remember to do that (being ancient and all, no promises)
[15:27] <infinity> ScottK: It's actually fairly trivial to go the easy route (as in, no code changes, just a quick tweak to chroots, times X releases, times Y arches)
[15:28] <ScottK> Cool.
[15:28] <infinity> At least, assuming that pins can override NotAutomatic's anti-pin.
[15:28] <infinity> If not, then we need to think harder about it.  Or try to implement perfection.
[15:29] <infinity> But, my assumption is that pinning the pocket to 500 will override the 100 it's getting automagically.
[15:29] <infinity> We'll experiment and see a bit later.
[15:29] <ScottK> Great.  Have fun with the glibc.
[15:30] <ScottK> It'd be trading unusable for suboptimal, so it's not a hard choice.
[15:34] <xnox> ScottK: well, tbh it has more progress implementation wise than it ever had...
[15:35] <ScottK> xnox: Certanly.  I wasn't meaning to pick on anyone.
[15:35] <ScottK> I just thought it was ironic.
[15:35] <dobey> barry: is libpeas stuff using python3 yet? or do you have a timeframe for that?
[15:35] <xnox> plus we did mile-stones before the schedule got changed (e.g. the alpha-3 got moved by -1 week)
[15:36] <xnox> ScottK: yeah it is funny though =)
[15:36] <barry> dobey: afaik, libpeas should be good to go
[15:36] <dobey> barry: are gedit/rhythmbox/etc using it with python3 already then?
[15:37] <barry> dobey: those clients afaik have not yet been ported
[15:38] <dobey> barry: will rhythmbox be soon? our plug-in for it is in python, so wondering when i need to get it working under python3 by
[15:39] <barry> dobey: it's not the next thing on my list, and i'm pretty well booked up until mid-aug.  any way i can help you or someone else to take that on?
[15:40] <dobey> not sure, i don't really have time to do it either. :-/
[15:43] <barry> dobey: yeah.  i'd love to see some community contribution around this, but i'm not sure how to help that happen
[15:44] <dobey> not sure exactly either, at the moment. :-/
[15:46] <dobey> need to get lunch now though. bbiab
[21:32] <oly_> hi, got a small packaging issue, i am packaging a mixed python / c program got everything working fine but i get an error complaining the .pyc files where included how do i stop dpkg-buildpackage creating these ?