[00:43] <phillw> Hi, is dns-nameservers still command in the new server release? As if it is, it is not.
[00:58] <micahg> stgraber: can we get the blueman crash fix in for 12.04.1
[01:03] <infinity> phillw: If by "command", you mean "/etc/network/interfaces option", then yes, but it requires having resolvconf installed.
[01:17] <phillw> infinity: is this another thing that needs installing>
[01:20] <phillw> with not wishing to start a war.... the fact I have to go back into Ubuntu system just to add ssh access, does seem rather crazy.
[01:21] <phillw> and now, it cannot access the outside world.... Okies, i learn as i install ubuntu server onto VM's
[01:28] <infinity> phillw: The installer does offer you the otion to install ssh...
[01:33] <stgraber> micahg: I'd be fine with that, it's a frequent crasher and isn't on the Ubuntu images
[01:35] <stgraber> infinity: if you have a minute, can you look at blueman? it's a frequent crasher and the diff is quite small
[01:36] <stgraber> micahg: I'm assuming you have some people with that bug ready to verify the fix when it lands?
[01:36] <phillw> infinity: it did, I did, I also installed LAMP from the tick-list, but now I have to add one aditional areas just so it can work?
[01:37] <stgraber> skaet: world rebuilt, turned the cron jobs back on. Will disable again on Thursday 21:00 UTC
[01:38] <infinity> phillw: I don't see how resolvconf configuration in interfaces(5) has anything to do with "making ssh work".  In a pure dhcp network setup, that's not necessary, and in a pure static setup, it tends to get done for you by the installer, or you do it all at once yourself by hand...
[01:39] <infinity> stgraber: Done.
[01:39] <micahg> stgraber: I can verify myself
[01:40] <phillw> infinity: this was not a problem with 12.04. Adding ssh seemed daft, but I was aware of that. But the loss of the ability to set up resolve.conf is really taking the micky... That is only my personal view & I'm sure you server people know why we should not have a server that will actually work.
[01:41] <phillw> infinity: next time, i will use minimal iso & just add in the basic requirements for a server that talks under a VM
[01:43] <infinity> phillw: I'm not sure what you mean by "loss of the ability to set up resolv.conf", nor do I think that anyone's intention is "a server that [won't] actually work".
[01:43] <phillw> infinity: a VM does note use dhcp.
[01:43] <phillw> it requires manaully setting up.
[01:43] <infinity> Yep.
[01:44] <phillw> infinity: the loss of the app that does it is is silly.
[01:44] <infinity> What "app"?
[01:44] <phillw> I cannot command the new system, yet the system removes it at boot.
[01:45] <phillw> infinity: dns-nameservers
[01:45] <infinity> That wasn't an "app", it was a config option in /etc/network/interfaces.
[01:45] <infinity> And it's still there.
[01:45] <infinity> And it still works.
[01:45] <phillw> I can assure that it is not and does not
[01:46] <infinity> It's on ALL the images.
[01:46] <infinity> It's in the minimal task.
[01:46] <infinity> (Well, all the images except ubuntu-core, but since you used an installer, you clearly didn't use core)
[01:47] <phillw> infinity: I used todays spin
[01:47] <infinity> Kay.
[01:47] <phillw> for server
[01:47] <infinity> And the package "recolvconf" isn't installed?
[01:47] <phillw> command not found
[01:48] <infinity> It's.  Not.  A.  Command.
[01:48] <infinity> I've said this three times.
[01:48] <phillw> dns-nameservers == command not found
[01:48] <infinity> See above.
[01:48] <infinity> Not a command.
[01:48] <infinity> Never was.
[01:48] <phillw> dns-nameservers is the command
[01:48] <infinity> It's an config option in /etc/network/interfaces.
[01:49] <phillw> accoroding to your instructions
[01:49] <infinity> Dude.  It was never a command.  And it's still not.
[01:49] <infinity> My instructions?
[01:50] <phillw> infinity: dns-nameservers 213.186.33.99 # OVH DNS Server dns-search ovh.net # To quickly fix the hosts on the OVH network
[01:50] <phillw> for get all about after the #. that is a comment
[01:50] <infinity> phillw: I'm not sure where you're pasting that from, but it's an /etc/network/interfaces snippet.
[01:50] <infinity> phillw: Not a shell command.
[01:51] <phillw> infinity: no, the file the holds them gets overwritten
[01:51] <phillw> I can manually edit /etc/resolve.conf
[01:51] <infinity> phillw: "The file that holds them" is supposed to be (wait for it, it's fun repeating myself, I love it) /etc/network/interfaces
[01:51] <phillw> but it will get over written
[01:52] <phillw> so, the command dns-nameservers is now obsoluete?
[01:53] <infinity> phillw: No, this is EXACTLY how it worked in precise.
[01:53] <infinity> phillw: It had no command.
[01:53] <stgraber> phillw: can you stop typing and read what infinity told you at least 4-5 times over the past 10 minutes? as the de-facto maintainer of both ifupdown (/etc/network/interfaces) and resolvconf (/etc/resolv.conf), I can ensure you that what he's telling you is right and WORKS on up to date quantal
[01:53] <infinity> phillw: It had an interfaces(5) option.
[01:53] <stgraber> phillw: none of it changed since 12.04
[01:53] <phillw> It worked in 12.04, I have 12,04 VMs which work perfectly happy.
[01:53] <stgraber> phillw: just set dns-nameservers in /etc/network/interfaces (<-- NOT /etc/resolv.conf), reboot and you'll magically see your /etc/resolv.conf containing the right thing
[01:53] <infinity> phillw: dns-nameservers was never a command.  And if you put it in resolv.conf, that also did nothing useful.
[01:54] <infinity> phillw: If it's in interfaces, it writes a resolv.conf for you.
[01:54] <phillw> http://help.ovh.co.uk/BridgeClient
[01:54] <stgraber> phillw: you may also want to read the documentation (linked from the 12.04 release notes): http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/
[01:54] <infinity> phillw: Quoting from that page:
[01:54] <infinity>     For Debian 6*, the DNS server configuration is done directly in the file /etc/network/interfaces or you find it in this section:
[01:54] <infinity>     dns-* options are implemented by the resolvconf package, if installed (default)
[01:54] <phillw> if this has changed recently, let me know.....
[01:55] <phillw> so, by default?
[01:55] <infinity> phillw: It's been installed by default in Ubuntu on all installs since precise, yes.
[01:55] <stgraber> resolvconf hasn't changed since at least warty, though we only started using it in 12.04
[01:55] <phillw> so, why does it not work for 12.10?
[01:56] <infinity> It DOES.
[01:56] <phillw> infinity: I can assure you that those instructions do not work
[01:56] <stgraber> phillw: can you pastebin your /etc/network/interfaces please?
[01:57] <phillw> I've just tried to set up a server VM for 12.10 for a vilunteer.
[01:57] <infinity> phillw: That adding "dns-nameservers 12.3.4.5 5.4.3.21" to your eth0 stanza in interfaces doesn't work?
[01:57] <infinity> phillw: And yes, please pastebin it.
[01:57] <phillw> stgraber: they are as stated on those simple instructions
[01:58] <phillw> what is not happening is the stable of resolve.com Which *used* to need the command, as the file gets written over.
[01:58] <stgraber> phillw: use that: http://paste.ubuntu.com/1146080/
[01:58] <phillw> If now I need to enter it into the static area, I'm happy to do so & will alert them of the subtle change.
[01:59] <infinity> stgraber: You missed the "dns-search ovh.net" ;)
[01:59] <stgraber> which is what the ovh help page is trying to tell you to do, but apparently you don't seem to agree with that interpretation
[01:59] <ScottK> skaet: I'm not sure.  I'll leave it for Riddell  to answer.
[01:59] <phillw> i cannot copy and paste whilst I'm accessing via the MAC address of a VM
[02:00] <phillw> I'll just delete it & put back on 12.04 - I know that works.
[02:00] <phillw> but, there is a bug somewhere.
[02:01] <infinity> phillw: This works exactly the same in 12.04.  Honest.
[02:01] <phillw> infinity: it does not, honest!
[02:02] <stgraber> phillw: the only difference with what ovh has on their site besides the fact that I moved to a reasonable layout and non-broken auto line, is that I added that dns-nameservers line to the config, the rest is identical
[02:02] <phillw> the instructions are the same, and I have 12,04 VM's working - same instructions
[02:02] <phillw> 12.10 VM is not working.... the evidence says....
[02:03] <infinity> phillw: Compare the configs between the two.
[02:03] <infinity> phillw: The evidence says you're not setting up interfaces(5) correctly.
[02:03] <stgraber> and don't just assume they are the same, because they're not
[02:03] <phillw> infinity: I can see them, I have followed the same instructions. This is the 1st time I've tried a 12.10
[02:04] <infinity> stgraber: Well, the other possibiliy is that he broke the resolvconf resolv.conf links and forced a static version, and hence his broken interfaces config would be a no-op.
[02:04] <stgraber> believe it or not, but we test that stuff and I can ENSURE you there's absolutely no difference between 12.04 and 12.10, any difference you see is the result of a mistake you did, either on 12.04 or 12.10
[02:04] <phillw> infinity: If you'd lime to have a play, i do still one free ipV4 that you can set up with a MAC address and try yourself.
[02:05] <infinity> phillw: I use the software every day.
[02:05] <phillw> I'd really like this to be solved, ovh have a shit load of servers around the world, if an edit is needed; I'm sure they will do it.
[02:05] <phillw> infinity: PM please.
[02:08] <infinity> phillw: I have a gin calling my name.  But compare stgraber's pastebin above to the ovh instructions, and you'll see that he's just formatting their directions in a more pleasantly readable way (and his paste will work correctly).
[02:08] <infinity> phillw: And add the dns-search bit to his paste as well, for correctness, if you care about search domains.
[02:09] <phillw> stgraber: you want to prove it?
[02:11] <phillw> I'll hand the VM over to you, all I want is for it to work. If there are alterations to be made in the instructions; I'm sure they will be swiftly made.
[02:12] <phillw> the VM is alive, it just needs to IP stuff to be sorted.
[02:29] <phillw> stgraber: here goes :)
[02:30] <phillw> :)
[02:30] <phillw> :(
[02:31] <phillw> stgraber: do you have a decent internet speed, I'm on sub 1Mb, which makes doing stuuf via 'X' painful
[02:33] <stgraber> not as fast as I'd like, but still reasonable (30Mb)
[02:48] <phillw> stgraber: my link at ~1Mb at best is painful, could you install the VM for 12.10?
[02:49] <phillw> it requires -X access which really does make it slow for me :(
[04:22] <tjaalton> stgraber, infinity: uploading mesa now..
[04:27] <tjaalton> oh there it is
[04:35] <infinity> Oh lord, LP is going to diff it against the deleted 8.0.3.  USEFUL.
[04:36]  * infinity does a slightly more manual audit.
[04:40] <infinity> tjaalton: Thanks for that, accepted.
[04:40] <tjaalton> :) thanks
[11:53] <seb128> cjwatson, hum, NBS report screwed again, should I rm .launchpadlib/api.launchpad.net/cache on p.c.c ... anything else to do out of waiting then?
[12:08] <cjwatson> seb128: feel free to remove the cache.  a more complete workaround is tedious in excelsis; the right fix is to get the lazr.restfulclient fix released and SRUed, which I'm prodding about on and off
[12:08] <seb128> cjwatson, ok, I did move the directory away since I was unsure ;-)
[12:09] <seb128> let's wait for the next run
[12:10] <cjwatson> just nuke it, been done several times before
[12:17] <seb128> cjwatson, right, I did the mv before you replied in case it was a stupid idea to rm it ;-) now that you replied I can rm it
[13:30] <stgraber> micahg: can you spend a few minutes testing the blueman in proposed?
[13:31] <stgraber> slangasek, infinity: just noticed that we're missing two more copies to get the upgrade to work fine, perl and libxml-sax-perl, would be nice to have these copied now.
[13:39] <stgraber> seb128: I created http://pad.ubuntu.com/12-04-1-preparation with an early list of packages that I'm tracking for 12.04.1, can you add the desktop ones that you want to see in 12.04.1?
[13:40] <stgraber> seb128: (thinking of at least compiz, nux, ... I haven't checked the exact bugs so don't know whether they are planned for inclusion in 12.04.1)
[13:40] <seb128> stgraber, thanks ... is that a list of things in proposed that we want to see acked and in updates?
[13:40] <stgraber> yep
[13:41] <stgraber> I'm going to start nagging people to get these tested, then for most of them will get them copied early to -updates if there's not much risk involved
[13:41] <seb128> checking
[13:41] <seb128> I dropped a bit on that recently, things have been crazy, I did need to catch up on quantal work before ff and I'm on quantal +1 team as well
[13:55] <stgraber> jibel: now that we're building the CDs without proposed, can you also turn off proposed in jenkins?
[13:59] <jibel> stgraber, done. Running server upgrades to verify it is disabled.
[14:00] <stgraber> jibel: thanks
[14:01] <seb128> stgraber, ok, I've done a round of reviews,comments and put some notes on the etherpad
[14:24] <stgraber> seb128: tested gnome-settings-daemon, windows+p now works here
[14:25] <stgraber> jocarter: looks like we were both right... /usr/share/gnome-fallback is used when starting gnome in "no effect" mode, /usr/share/gnome-classic/ is used in the "with effect" mode.
[14:25] <stgraber> jocarter: so both our SRUs were wrong... I'll SRU again with the overrides in both paths and push that to quantal too...
[14:27] <seb128> stgraber, great
[14:31] <stgraber> jocarter: uploaded
[14:47] <stgraber> infinity, slangasek, ...: can someone accept that edubuntu-artwork please?
[14:48] <stgraber> (only difference should be that the .desktop files are now pushed to both /usr/share/gnome-classic and /usr/share/gnome-fallback)
[14:51] <skaet> stgraber,  looks like we've got the commitment for testing the chinese images for precise,   should be some results showing up tomorrow (for the test build I did last week).    I'll add them to cron.
[14:52] <stgraber> skaet: ok
[15:22] <micahg> stgraber: sure
[16:27] <jamespage> stgraber, I'm assuming its to late for bug 973741 to make 12.04.1 now?
[16:27] <ubot2`> Launchpad bug 973741 in openssl "[SRU] segmentation fault for all https operations in libcrypto.so.1.0.0 on 'legacy' Intel Xeon CPUs" [High,Confirmed] https://launchpad.net/bugs/973741
[16:36] <ScottK> From the bug title it sounds scary enough to at least be considered.
[16:40] <jamespage> ScottK, it did enter proposed but caused a number of issues in its first version
[16:40] <jamespage> adam_g proposed a second patch but its not been uploaded (fell off my list unfortunately)
[16:41] <stgraber> jamespage: upload to -proposed, we'll discuss it once it' there
[16:42] <jamespage> stgraber, ack
[16:42] <stgraber> the diff is quite readable at least and I don't see much regression potential in there, so it might still make it to .1
[16:42] <infinity> If it's the patchset I proposed, it's entirely reasonable.
[16:42]  * infinity wishes LP would actually load the bug...
[16:42] <stgraber> infinity: https://launchpadlibrarian.net/111702599/lp973741-2.debdiff
[16:44] <infinity> stgraber: Yup, that matches the upstream bits I pointed at.  Works for me, if it's tested, which the bug claims it is.
[16:45] <jamespage> I'll upload it now...
[16:45] <infinity> Danke.
[16:47] <stgraber> infinity: can you copy perl and libxml-sax-perl?
[16:47] <stgraber> these two are also required for the lts to lts upgrades but weren't copied yesterday
[16:47] <infinity> stgraber: Do I get a cookie?
[16:52] <infinity> stgraber: (done)
[16:55] <jamespage> stgraber, thats now in the -proposed queue
[16:55] <stgraber> infinity: thanks!
[16:56] <stgraber> infinity: there'll likely be a few more we'll want to fast track into -updates but I'll review the list with skaet first
[18:00] <ScottK> jamespage or infinity: Is there a chance that openssl bug would affect ssh?  I have an affected server (right CPU type) that I was about to upgrade to precise.  If it's not going to affect SSH, I can do that and then test the fixed package.
[18:02] <infinity> ScottK: It won't affect ssh if you're already logged in.  Can't say otherwise.
[18:03] <infinity> ScottK: So, log in to several root sessions, just in case, and then test away. :P
[18:04] <ScottK> Which, of course, I won't be if I reboot into the new install.
[18:04] <ScottK> It's a remote system, so I think I'm not going to experiment.
[18:05] <infinity> ScottK: You could probably test in a precise chroot on said system.
[18:05] <ScottK> Good point.
[18:06] <slangasek> stgraber: were the perl and libxml-sax-perl SRUs needed for the CD upgrade case?  I thought they weren't so I was going to let them age a little more
[18:06] <slangasek> (but I see that's done now anyway, so)
[18:07] <stgraber> slangasek: yeah, they were. They are causing an upgrade failure (not a resolution failure)
[18:09] <slangasek> stgraber, jibel: I don't think we should be turning off proposed in jenkins so soon.
[18:10] <slangasek> I think we should have that there still for continued pre-testing of any other SRUs that might be accepted at the last minute.
[18:11] <stgraber> slangasek: hmm, I guess we probably want both actually... we don't want to get in the case where -proposed somehow magically fixes an upgrade path
[18:12] <slangasek> stgraber: that would be optimal, but I'm not sure jenkins would keep up with the job load
[18:14] <slangasek> anyway, I guess which of the two is more important depends on what other way-past-the-deadline SRUs are getting accepted
[18:15] <jibel> slangasek, stgraber I can setup server and desktop for both -updates and -proposed, and main and universe for either -updates or -proposed.
[18:27] <slangasek> stgraber: ^^ what do you think?  both for server+desktop, and -proposed for now for main and universe, until we're sure we're done?
[18:28] <stgraber> slangasek: sounds good
[18:29] <stgraber> just re-tested edubuntu-artwork with the fix I pushed this morning, it's all good with both fallback sessions this time, would be good if someone could copy it over (so both fallback sessions are consistent)
[18:34] <slangasek> ok, copying
[18:35] <slangasek> anybody want to take care of the SRU verification for bug #928596?
[18:35] <ubot2`> Launchpad bug 928596 in indicator-weather "Flurries condition is marked as 'Unknown'" [Medium,Fix committed] https://launchpad.net/bugs/928596
[18:40] <stgraber> yeah, it was next on my list
[18:44] <ScottK> infinity: I can't replicate it on i386, which is what I have on that CPU.  So I guess no help from me.
[18:51] <slangasek> looks like firefox is ready for copying to precise-updates
[18:51] <slangasek> but maybe somebody not on vicodin should check me on that ;)
[18:52] <micahg> slangasek: it fixed the issue, but it was compounded by other issues, chrisccoulson should probably comment on whether or not it should go
[18:53] <slangasek> micahg: ah; nobody documented that in the bug tags?
[18:55] <chrisccoulson> slangasek, there's going to be another upload, with the fix for bug 1035305
[18:55] <ubot2`> Launchpad bug 1035305 in firefox "Crash when switching apps back to Firefox (may be Firebug related)" [Critical,Fix released] https://launchpad.net/bugs/1035305
[18:55] <slangasek> chrisccoulson: and is that a regression in the package currently in -proposed, vs. the one in -updates?
[18:56] <chrisccoulson> slangasek, no, neither of them are really a regression. they were both dormant bugs that are no longer dormant thanks to http://code.google.com/p/fbug/issues/detail?id=5809
[18:56] <slangasek> chrisccoulson: so, is there any reason to hold up publication of this SRU?
[18:57] <stgraber> slangasek: finding a place where it's snowing is surprisingly more difficult than I thought it'd be ;)
[18:57] <chrisccoulson> slangasek, other than to avoid providing 2 separate updates, not really
[18:57] <slangasek> chrisccoulson: I guess the original bug report is also about firebug; so maybe the -proposed version provides insufficient benefit to push out to everyone?
[18:57] <stgraber> oh, looks like norway will do the trick
[18:58] <chrisccoulson> slangasek, yeah, it probably isn't worth pushing out just yet. it seems a lot of people will still get a startup crash afterwards, but just a different one
[18:58] <slangasek> chrisccoulson: ok, setting to v-failed then
[18:59] <chrisccoulson> thanks
[19:26] <balloons> seems the server images today won't boot with today's kernel
[19:34] <xnox> stgraber: i would have thought it would be snowing in the yukon & territories
[19:35] <stgraber> xnox: nope, it's around 10-15C according to environment canada
[19:35] <stgraber> xnox: I found a few palces in new zealand that were cold enough, but no flurries, so couldn't reproduce the bug :)
[19:36] <xnox> stgraber: Flurries is not a new game in the Humble Bundle?! /me goes to check dictionary
[19:37] <xnox> stgraber: aboug bug 1036612
[19:37] <ubot2`> Launchpad bug 1036612 in linux "Quantal Server failed to install with LVM: VFS: Cannot open root device "mapper/ubuntu-root" or unknown-block(0,0): error -6" [Critical,Incomplete] https://launchpad.net/bugs/1036612
[19:37] <xnox> do you think it's the live-build which got out of sync, and we simply need to respin the image.
[19:38] <xnox> or do you think it is something else?
[19:38] <xnox> initramfs got out of sync with the kernel
[19:38] <xnox> on the squashfs install media, and the installed system
[19:39] <slangasek> xnox: flurries are the thing that people in the UK call "snow" :)
[19:39] <stgraber> xnox: sounds like either d-i or the seeds are out of sync
[19:39] <stgraber> xnox: last d-i was for -9
[19:40] <xnox> well not just snow - a lot of snow with wind =)
[19:40] <xnox> A small swirling mass of something, esp. snow or leaves, moved by sudden gusts of wind: "a flurry of snow".
[19:40] <infinity> xnox: Yeah, d-i and seeds needed updating.
[19:40] <xnox> stgraber: so a new d-i stack upload is required?
[19:40]  * infinity will do that.
[19:40] <stgraber> xnox: seed also says -9 not -10
[19:41] <xnox> infinity: thanks. is it documented anywhere?
[19:41] <slangasek> xnox: flurry != "a lot of snow"; it's light snow + enough wind that it doesn't come straight down
[19:42] <infinity> xnox: I'm not sure there's a "how to do ABI bumps" doc, nor where one could put it that's discoverable enough to make it useful.
[19:42] <xnox> infinity: i'd expect something in the wiki.ubuntu.com Archive or Installer pages
[19:43] <infinity> xnox: Installer, potentially.
[19:43] <stgraber> slangasek: gnome-settings-daemon, telepathy-mission-control-5, gcalctool and indicator-weather are all > 7 days and fully tested, so ready to copy
[19:43] <infinity> Anyhow, it's entirely my fault for doing the copy without the other bits, I was a bit out of it.
[19:44] <slangasek> stgraber: anything urgent in that set?  Otherwise I'll leave it to someone with better attention to detail currently
[19:44] <infinity> xnox: Fixed.
[19:45] <stgraber> slangasek: nope, nothing urgent in there
[19:45] <infinity> Aaaand, I just got a call from the bank that the cheque from Australia they've been trying to cash for the last 2 months just got returned again.  I need to run and yell at someone.
[19:45] <infinity> Back in a bit.
[20:06] <tjaalton> stgraber: the mesa fix for .1 is now confirmed
[20:07] <balloons> stgraber, have we ever considered marking images for rebuild when we discover critical errors in automated testing?
[20:07] <stgraber> tjaalton: thanks
[20:08] <stgraber> balloons: I guess that'd make sense, no point in wasting everyone's time on it
[20:08] <stgraber> balloons: not sure how reliable the detection of "critical" errors in the automated testing is
[20:09] <balloons> stgraber, yea i know.. but manual testing kind of has the same issue
[20:09] <stgraber> balloons: I think it'd be best to first implement that as a manual action to whoever looks at the Jenkins results
[20:09] <balloons> I was thinking about last thursday's massive image breaking as well
[20:10] <balloons> I don't believe any automated tests failed, since it was a ubiquity bug.. but since we were cadence testing we found it :-) But we all got to confirm the bug across many images and people
[20:11] <balloons> stgraber, yes, something for whomever files the bug
[20:13] <micahg> stgraber: Bug #962469 test case verified (didn't actually try bluetooth though)
[20:13] <ubot2`> Launchpad bug 962469 in blueman "blueman-applet crashed with KeyError in card_cb(): 'bluez.path'" [High,Fix committed] https://launchpad.net/bugs/962469
[20:22] <seb128> cyphermox, thanks for the blueman fix
[20:23] <seb128> cyphermox, micahg: we should probably look at replacing blueman btw, it seems very poorly maintained, we are lucky that cyphermox took time to fix the issue, it was on top of the errors report for months without anyone caring
[20:23] <micahg> seb128: well, gnome-bluetooth fell out of sorts for Xubuntu since it started requiring heavier integration wtih GNOME
[20:24] <micahg> seb128: as I mentioned to cyphermox, I"ll all for a better replacement :)
[20:24] <xnox> infinity: are you respining cd, or will we just wait for tomorrows daily?
[20:24] <seb128> micahg, gnome-bluetooth is maintained at least...
[20:25] <stgraber> xnox: I don't see any respin in progress for quantal. What needs respinning?
[20:25] <xnox> stgraber: server+amd64
[20:25] <xnox> stgraber: if the seed/d-i upload landed
[20:26] <xnox> stgraber: that is quantal
[20:26] <stgraber> xnox: not published yet
[20:26] <xnox> kk
[20:33] <infinity> xnox: I didn't see much point in a manual respin, but I can if you're waiting on the image to test something.
[20:34] <xnox> infinity: well... i am not sure about uploading newer lvm2, if the image & jenkins are borked on the lvm test cases.
[20:35] <xnox> infinity: can wait till tomorrow, i'll do something more fun instead =)
[20:38] <infinity> xnox: Good plan.  I was pondering a bit of fun this evening myself.
[20:40] <xnox> infinity: i have numbers to crunch ;-)
[20:40] <slangasek> seb128: what do you mean, "replacing" blueman?  It's not part of the Ubuntu desktop stack at all
[20:41] <slangasek> people are either hitting this on one of the other community flavors, or they're going out of their way to install it
[20:41] <seb128> slangasek, well it was on the top 5 errors.ubuntu.com reports for some weeks
[20:41] <slangasek> yes, it was
[20:41] <slangasek> but I don't know what you think it would mean to replace it
[20:41] <slangasek> because Ubuntu already isn't using ti
[20:41] <slangasek> it
[20:41] <seb128> so it seems somewhat buggy software is pushed to users
[20:41] <micahg> xubuntu and lubuntu switched to it to avoid pulling in gnome-control-center
[20:42] <micahg> the upstream was active when we switched, then they disappeared :)
[20:42] <infinity> seb128: All software is buggy.  The bug is fixed now, I'm failing to see the issue.
[20:42] <seb128> it's fixed because somebody from our team went out of his way to fix the bug
[20:42] <seb128> which is my issue
[20:42] <slangasek> seb128: not pushed by Ubuntu.  If you want to take it up with the xubuntu and lubuntu teams, feel free
[20:42] <seb128> we shouldn't have to spend desktop resources to fix stuff we don't ship
[20:42] <slangasek> seb128: er, *why* did somebody from your team go out of the way to fix it?
[20:42] <infinity> seb128: It's fixed because... A software developer... Fixed the bug... Is an issue?
[20:42] <slangasek> you're right, you shouldn't have to
[20:42] <micahg> seb128: and I thanked him for it :)
[20:43] <slangasek> and as far as I see you shouldn't have done so
[20:43] <infinity> seb128: Did he do it on "work time"?
[20:43] <seb128> slangasek, I guess because it was on top of the report and nobody else was doing it
[20:43] <infinity> seb128: Cause there's nothing wrong with paid folks doing other things in their spare time.
[20:43] <seb128> infinity, right, well it just seemed like a buggy unmaintained piece of software
[20:44] <seb128> so I was wondering if there was a way xubuntu could use the same bluetooth stack than Ubuntu
[20:44] <seb128> but it's a low priority issue,question
[20:44] <seb128> probably the wrong channel to discuss it as well ;-)
[20:45] <seb128> slangasek, btw while you are around, what's the deal with whoopsie and 12.04.1
[20:45] <slangasek> seb128: ev's report is still running and we should have some real numbers by tomorrow
[20:46] <seb128> slangasek, I'm concerned we are getting no news on why the bug report curves dropped to some 10% of their value on 05/17/12
[20:46] <seb128> slangasek, does it mean our stats are off by a 10 times factor?
[20:47] <seb128> slangasek, and if not what's the other explanation?
[20:47] <seb128> did we loose 90% of our users on that day?
[20:47] <slangasek> I don't know the answer to that
[20:47] <seb128> that's an important question though :-(
[20:47] <seb128> how do we get an answer to it?
[20:47] <slangasek> yes, it is; but I'm not going to rush to judgement here
[20:48] <seb128> I'm not for rushing
[20:48] <seb128> but 12.04.1 hard freeze is getting close and we need to decide what to do
[20:48] <slangasek> I don't think we're going to know the answer for that dip in time for the 12.04.1 hard freeze
[20:48] <slangasek> ev is working on it but hasn't found the answer yet
[20:48] <seb128> :-(
[20:49] <seb128> so what's the process at this point that makes us decide what to do with whoopsie for 12.04.1?
[20:49] <seb128> it seems like we might need to take a decision without a complete picture
[20:49] <seb128> does it mean we will likely go for the status-quo and do nothing?
[20:50] <slangasek> well, I think we want to still get the best information we can about how often users are getting prompted
[20:50] <slangasek> and make sure that we're below the agreed threshold, one way or the other
[20:50] <seb128> ok
[20:50] <slangasek> understanding that this "best information" won't account for the anomalous drop in May
[20:51] <seb128> so we still count on getting the infos (out of the drop reason) this week?
[20:51] <slangasek> yes
[20:51] <slangasek> the necessary update is running
[20:51] <seb128> who will decide and when then? release meeting on friday?
[20:52] <seb128> .1 meeting on thursday might be better?
[20:52] <slangasek> I think the .1 meeting makes sense
[20:52] <seb128> ok, great
[20:53] <seb128> slangasek, thanks!
[22:28] <chrisccoulson> could someone please accept the firefox packages in to *-proposed? :)
[22:28] <slangasek> hmm, why should there be a sharp uptick in update-manager -related crash reports today? (https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fupdate-manager%3AAttributeError%3A_on_config_file_conflict%3Arun%3Ashow_diff, https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fupdate-manager%3Alibnspr4%3A_inline_callbacks%3Acommit%3A_inline_callbacks%3A_run_in_dialog)
[22:30] <slangasek> chrisccoulson: looking
[22:30] <chrisccoulson> thanks
[22:31] <slangasek> chrisccoulson: can you fill out the SRU template for the bug description?
[22:31] <slangasek> (test case, regression potential)
[22:34] <chrisccoulson> slangasek, sure, i'll do that in a moment
[22:38] <slangasek> oh, sigh
[22:38] <slangasek> stgraber: the 'libnspr4' in this one refers to the package name; this is somehow related to the SRU we just did. https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fupdate-manager%3Alibnspr4%3A_inline_callbacks%3Acommit%3A_inline_callbacks%3A_run_in_dialog
[22:39] <infinity> Unmet deps?  What did we break?
[22:39] <slangasek> I don't know
[22:40] <slangasek> but the error appeared the day the SRU went into -proposed
[22:40] <slangasek> and has spiked now that it's published to -updates
[22:40] <stgraber> oh, there's actually one change
[22:40] <stgraber> stgraber@castiana:~$ apt-cache show libnspr4 | grep ^Depends
[22:40] <stgraber> Depends: libc6 (>= 2.15)
[22:40] <stgraber> Depends: libc6 (>= 2.4)
[22:40] <stgraber> caused by the rebuild
[22:41] <slangasek> which ... should not be a problem at all
[22:41] <infinity> Though curious that it started using new symbols.
[22:41] <stgraber> well, it might change the upgrade ordering a bit I guess, but yeah, it shouldn't cause any problem
[22:41] <infinity> But yeah, given that libc6 is kinda crucial to almost all system upgrades, that seems odd.
[22:42] <infinity> And the Breaks doesn't look particularly harmful.
[22:42] <slangasek> infinity: implies that the previous build of the package was before 2.15 was in precise
[22:42] <infinity> slangasek: Sure, but 2.4 to 2.15 is quite a jump, if it really was only using fairly old symbols before.
[22:43] <infinity> Anyhow, that *should* be a non issue, and working as advertised.
[22:43] <infinity> So, still a big WTF here.
[22:45] <slangasek> and we don't have anyone turning this into a bug report yet, so we apparently don't get logs
[22:46] <slangasek> 00000000      DF *UND*  00000000  GLIBC_2.15  __fdelt_chk
[22:46] <slangasek> FYI
[22:46] <slangasek> so it's a hardening symbol
[22:51] <infinity> slangasek: Ahh, that makes some sense.
[22:52] <infinity> I suppose it could be the combination of both the breaks and the new libc dep, but really, I can't see how either would cause a problem alone or together.
[22:52] <infinity> A chroot that could reproduce it and some apt pkgProblemResolver output would be stellar.
[22:53] <infinity> Or whatever that option is that I always have to look up EVERY TIME.
[22:53] <infinity> Debug::pkgProblemResolver ... I was close, for once.
[23:07] <slangasek> infinity: so, we have some data on the aptdaemon SRU; I'm not sure if I think it's convincing enough to publish
[23:09] <slangasek> infinity: https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fsbin%2Faptd%3AUnicodeDecodeError%3A_simulate%3A_set_error is pretty convincing that bug #926340 is fixed; but https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fsbin%2Faptd%3AUnicodeDecodeError%3Afail%3A_emit_acquire_item , which is for the SRU regression, is still accumulating hits
[23:10] <ubot2`> Launchpad bug 926340 in aptdaemon "aptd crashed with UnicodeDecodeError in _set_error(): 'ascii' codec can't decode byte 0xc3 in position 9: ordinal not in range(128)" [High,Fix committed] https://launchpad.net/bugs/926340
[23:10] <slangasek> (bug #1034806, for that regression)
[23:10] <ubot2`> Launchpad bug 1034806 in aptdaemon "aptd crashed with UnicodeDecodeError in _emit_acquire_item(): 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)" [Critical,Fix committed] https://launchpad.net/bugs/1034806
[23:11] <infinity> slangasek: And it's definitely still being hit by the new version?
[23:11] <slangasek> no
[23:11] <infinity> Oh, see, that would be handy to know. :P
[23:11] <slangasek> it's not definite at all, I think there's a bug in stuff being misreported to errors.u.c when the version on disk doesn't match the running version
[23:16] <infinity> slangasek: Does it pass your manual testcase?
[23:16] <slangasek> yes
[23:16] <infinity> slangasek: If so, I'd be willing to call it an improvement, even if it might still be broken.
[23:17] <slangasek> infinity: if it passes my manual test case for the -proposed regression, but the -proposed regression is still there in some way we can't yet discern?
[23:17] <infinity> That, of course, is a big if.  I'm willing to assume errors.u.c is wrong here.  But that would be nice to hunt down.
[23:18] <infinity> Was this a regression introduced in -0ubuntu3, then, or something already published to -updates in -0ubuntu2?
[23:19] <infinity> I guess if it was confined to -proposed, then yeah, letting it cook a tiny bit longer while we sort out if the bug's still there or the infrastructure is broken seems sane.
[23:19] <slangasek> introduced in -0ubuntu3 as a direct consequence of the change
[23:19] <slangasek> (unicode-colored bubbles in the wallpaper)
[23:20] <slangasek> so, found a reference to our libnspr4 issue on the interwebs. http://askubuntu.com/questions/175722/unmet-dependencies-for-libnspr4/175920
[23:21] <infinity> slangasek: Oh, huzzah.  Hopefully we can get something useful from that.
[23:21] <slangasek> hope so :)
[23:23] <marrusl> so RAOF, on bug 993694, I'm going to email the fix author... well if I can figure out who made the change
[23:23] <ubot2`> Launchpad bug 993694 in d-conf "unity-2d does not start if user has logged in on unity" [High,Fix committed] https://launchpad.net/bugs/993694
[23:24] <marrusl> SpamapS sponsored it, but I don't think it was his patch.
[23:24] <marrusl> in any case, I'll find out and ask if they think it's a low risk patch.
[23:24] <infinity> slangasek: Oh, did you want to have a quick eyeball of the 37 tzdata SRUs?
[23:25] <slangasek> infinity: not terribly
[23:25] <infinity> Excellent.  Then don't!
[23:25] <RAOF> marrusl: Thanks.
[23:26] <infinity> Oh, I guess it's technically RAOF's day.  Except that it's Wenesday for him, because he lives in the future.
[23:26] <infinity> RAOF: Get a sane timezone.
[23:26] <marrusl> SpamapS, do you know who actually made the fix in bug 993694?
[23:26] <ubot2`> Launchpad bug 993694 in d-conf "unity-2d does not start if user has logged in on unity" [High,Fix committed] https://launchpad.net/bugs/993694
[23:26] <RAOF> infinity: Damn straight!
[23:27] <RAOF> marrusl: https://launchpad.net/ubuntu/+source/d-conf/0.12.0-0ubuntu1.1 makes it look like seb128 uploaded it, and it's a patch from upstream git.
[23:27] <infinity> RAOF: Actually, how do you work that?  Do we just end up doubling-up on the same (ish) day, or do you do your "Tuesday" on Australia's Wednesday, so the rest of us don't get confused? :P
[23:28] <RAOF> infinity: I think I might start doing my Tuesday on my Wednesday.
[23:28] <marrusl> RAOF, thanks
[23:28] <RAOF> infinity: Because I have, in the past, been somewhat confused by you doing stuff on my day :)
[23:29] <slangasek> heh
[23:30] <marrusl> RAOF, I should CC which list?
[23:31] <RAOF> I don't think we actually have a list.
[23:31] <marrusl> ok, you and...?  :)
[23:32] <RAOF> Probably just me is fine. Although you might also want to CC whoever is SRU-point-man for tomorrow, too.
[23:32] <marrusl> RAOF, sounds good.  will do.
[23:33] <RAOF> marrusl: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[23:34] <marrusl> well then, you and clint it is.  thanks!
[23:55] <slangasek> chrisccoulson: oh, your firefox SRU needs to be built with -v$last_version_in_updates, too.  The diff looks fine, but it needs an update for this
[23:55] <slangasek> chrisccoulson: (rejecting for now)