[00:01] <tumbleweed> esp when the queues are empty
[00:02] <infinity> tumbleweed: Yes, I should have said "matters today".
[00:46] <micahg> infinity: in quantal I've had quite a few i386 builds fail when amd64 passed and I've started doing some double testing as well
[01:24] <NCommander> infinity: I do it as a matter of habit (though I never did have an urgency=critical in Debian :-)).
[01:25] <NCommander> (nor would that d-i upload be criticla in Debian-terms)
[02:01]  * skaet back from dinner
[03:07] <skaet> infinity,  was that last set you? ^  linux [armhf] ?
[03:07] <infinity> skaet: Yes.
[03:07] <infinity> skaet: Same ABI bump that was already done on x86, the armhf build was still in progress at the time.
[03:08] <skaet> ah,  gotcha.   thanks.
[03:08] <skaet> NCommander,  anything left to pick up before the rebuilds get kicked off?
[03:09] <NCommander> skaet: d-i armhf needs a retry as the kernel just poofed into existance
[03:09] <infinity> I just did a mythbuntu-meta upload that affects only PPC.
[03:09] <infinity> And d-i can't retry for about ~30m.
[03:09] <infinity> (I'm waiting on the publisher)
[03:09]  * NCommander loves waiting for the publisher :-/
[03:10] <infinity> Oh, make that ~60m, the publisher didn't run at :03.
[03:10] <NCommander> *grumble*
[03:10] <infinity> *shrug*
[03:11] <infinity> You're outside of work hours anyway, grumble less and go have a beer.
[03:11] <infinity> ftpmaster and cdimage will both still be here in the morning. :P
[03:12] <skaet> infinity, yeah, but we'll miss a day of Europeans testing the images...  and finding all sorts of nice interesting bugs.
[03:12] <skaet> NCommander,  you ok to kick off the rebuilds tonight?
[03:13] <NCommander> skaet: yeah, I'll set an alarm for an hour to kick d-i, another to kic the images and check channel backscroll at that tie
[03:13] <infinity> NCommander: I'm watching d-i don't worry about that.
[03:13] <infinity> NCommander: So, just give yourself ~2h for image respin time.
[03:13] <NCommander> Great
[03:13] <skaet> Thanks NCommander, infinity.  :)
[03:15]  * skaet --> zzz
[04:47] <infinity> NCommander: publisher ran over itself again, d-i won't be published for another hour or so from now.
[04:47] <infinity> (Well, ~45m, if all goes smoothly)
[04:50] <infinity> NCommander: Though, current linux-meta doesn't actually match the current ABI anyway, so we may be held up until the kernel team is happy with the state of things anyway.
[07:35] <jibel> skaet, balloons I removed the test case for migration-assistant from Ubuntu Desktop
[09:40] <jibel> Quantal Desktop doesn't install on Mac. I can reproduce bug 1008905 repeatedly
[09:40] <ubot2`> Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [Undecided,Confirmed] https://launchpad.net/bugs/1008905
[09:53] <jibel> I reproduced bug 1008898, I think it's A1 critical (can't install desktop over wifi)
[09:53] <ubot2`> Launchpad bug 1008898 in ubiquity "crash after inserting wireless password" [High,Triaged] https://launchpad.net/bugs/1008898
[09:53] <ogra_> hmpf, someone should fix d-i to not attempt armel omap builds
[10:16] <ogra_> stgraber, just build ac100 too, if it works we'll indeed release it for A1
[10:16] <ogra_> (its not much extra work for me to test)
[13:21] <skaet> good morning
[13:22] <Laney> howdy
[13:25] <skaet> :)
[13:26]  * iulian waves.
[13:30] <skaet> jibel,  thanks for flagging bug 1008905.
[13:30] <ubot2`> Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [High,Confirmed] https://launchpad.net/bugs/1008905
[13:32] <stgraber> skaet: good morning
[13:32] <skaet> stgraber,  good morning :)
[13:33] <jibel> good morning
[13:33] <skaet> stgraber,  so looks like kernel drops continued last night,  am just trying to figure out if it makes sense to do the respins now, or if anything else is about to land.
[13:33] <skaet> jibel,  you want a fresh set of images with the latest kernel and d-i changes from yesterday?
[13:34] <jibel> skaet, this one and 1008898 are the only really important defects found for a1
[13:34]  * skaet goes to look at bug 1008898
[13:34] <ubot2`> Launchpad bug 1008898 in ubiquity "crash after inserting wireless password" [High,Triaged] https://launchpad.net/bugs/1008898
[13:37] <stgraber> skaet: a quick look at bug 1008898 shows that NetworkManager is the likely problem
[13:37] <ubot2`> Launchpad bug 1008898 in ubiquity "crash after inserting wireless password" [High,Triaged] https://launchpad.net/bugs/1008898
[13:37] <stgraber> skaet: which also explains all the other bugs where networking stops working completely
[13:37] <stgraber> cyphermox_: ^
[13:38] <skaet> jibel,  that one would be good to fix,  but its release notable for A1 if we must.
[13:38] <stgraber> skaet: basically NetworkManager looks like it just vanishes from dbus (or at least isn't listening in that case)
[13:38]  * skaet nods
[13:38] <stgraber> I believe ubiquity does the right call, unless the API changed on NM's side without telling us :)
[13:39] <skaet> stgraber,  you able to take a pass at seeing if you can fix it?
[13:39] <stgraber> skaet: I can certainly make ubiquity ignore the missing dbus function but that won't help a whole lot as it'll likely just crash later...
[13:40] <stgraber> skaet: I poked cyphermox_ a few lines earlier, hopefully he'll have a clue about what's going on with NM
[13:40] <jibel> skaet, it's release notable sure but a major annoyance. It crashes the installer
[13:40] <skaet> Thanks.
[13:40] <jibel> by crash I mean the installer closes when the user clicks on continue
[13:41] <skaet> jibel,  yup, will prioritize seeing we can get a fix figured out.
[13:41] <stgraber> jibel: an easy trick would be to turn off the wireless step completely but I'm really more worried about NM being broken than about ubiquity crashing
[13:41] <stgraber> because nothing tells me yet that networking will work properly post-install
[13:49] <dobey> can i *please* get someone to accept my ubuntuone-client and ubuntuone-control-panel uploads for precise-proposed?
[13:49] <jibel> stgraber, post-install network is working. The workaround during installation is to setup wireless with network manager instead of letting Ubiquity doing it (although my test machine just hang :( )
[13:51] <seb128> dobey, try maybe pinging bdmurray slangasek or SpamapS (or RAOF tomorrow)
[13:52] <stgraber> jibel: I'm actually quite surprised that the applet works... as far as I know it's supposed to use the same API as ubiquity and so I'd think would fail just as badly
[13:52] <dobey> SpamapS: ^^ please? :)
[13:52] <dobey> oh
[13:53] <dobey> i guess SpamapS might be a bit preoccupied at the moment though
[13:54] <jibel> skaet, ok for a fresh set of images to get latest kernel and d-i changes :)
[13:54] <skaet> thanks jibel.  :)
[13:56] <jibel> stgraber, I confirm that the workaround actually works
[13:56] <stgraber> jibel: ok, that's weird, but still a good news :)
[13:56] <skaet> stgraber,  ^  can you kick the full set of rebuilds off?
[13:56] <stgraber> skaet: yep
[13:56] <skaet> thanks stgraber,  :)
[13:56]  * skaet goes to update the pad
[14:01] <stgraber> skaet: do we actually have a kernel in core? I thought we didn't
[14:03] <skaet> stgraber, you're right,  oversight.
[14:03] <cyphermox_> stgraber: I wonder if the signature for AddAndActivateConnection might have changed; but NM is running when the crash happens
[14:05] <jibel> stgraber, will you respin wubi ?
[14:05] <stgraber> cyphermox_: can you check what are the valid signatures for AddAndActivateConnection? if it just slightly changed recently, it should be easy enough to fix on my side
[14:05] <stgraber> jibel: yes
[14:06] <cyphermox_> yes, that's what I'm doing; but it would surprise me if it had changed
[14:06] <stgraber> I'm refreshing my ubiquity branch to see if something broke with the python3 port
[14:06] <jibel> skaet, do we add upgrades to the tracker for a1 ?
[14:07] <skaet> jibel,  since it should now be working based on yesterday's fixes from mvo,  yes please.
[14:08] <cyphermox_> stgraber: actually, scratch that, it didn't change; we're still at the same version as in precise
[14:08] <jibel> skaet, and automated tests passed :)
[14:08] <skaet> jibel,  :)  that's good news.
[14:11] <stgraber> jibel: will you be around for a potential test fix?
[14:11] <stgraber> cyphermox_: looking at the ubiquity code we actually have an handler for the dbus exception, but I believe the exception name might have changed with the switch to python3
[14:11] <stgraber> barry: ping
[14:12] <barry> stgraber: pong
[14:12] <barry> stgraber: hmm, which exception?
[14:12] <stgraber> barry: is it possible that "except dbus.DBusException as e:" doesn't match with python3 and I instead need "except dbus.exceptions.DBusException as e:"?
[14:12] <jibel> stgraber, I won't move from my chair
[14:12] <barry> stgraber: that doesn't sound right, but let me consult the code
[14:12] <stgraber> barry: we basically get that crash in ubiquity: https://launchpadlibrarian.net/106902328/UbiquityDebug.txt
[14:13] <stgraber> barry: and on the ubiquity side we didn't change a whole lot, just ported to python3: http://paste.ubuntu.com/1025088/
[14:13] <stgraber> barry: full nm.py is: http://paste.ubuntu.com/1025089/
[14:14] <stgraber> barry: AFAICT the dbus exception should be caught by that except...
[14:15] <barry> stgraber: that could just be its printed name.  exceptions in python are caught by inheritance and reference, not by name, so if dbus.DBusException doesn't catch dbus.exceptions.DBusException then they are different exception hierarchies, which doesn't sound right
[14:15] <barry> stgraber: unless you're importing it from some place you're not aware of
[14:18] <stgraber> barry: hmm, and actually, reading the code again, the bit that fails isn't in one of these excepts to start with...
[14:20] <cyphermox_> looks weird to me that the error is with a signature a{sa{sv}}ss; when it should be a{sa{sv}}oo. stgraber; your code looks like it should be doing the right thing there
[14:20] <barry> stgraber: this is on quantal right?
[14:20] <stgraber> barry: yeah
[14:21] <stgraber> jibel: can you try: python /usr/lib/ubiquity/ubiquity/nm.py and then python3 /usr/lib/ubiquity/ubiquity/nm.py
[14:21] <stgraber> jibel: and confirm that the first works and the second fails
[14:23] <barry> stgraber:
[14:23] <barry> Python 3.2.3 (default, May  3 2012, 15:51:42)
[14:23] <barry> [GCC 4.6.3] on linux2
[14:23] <barry> Type "help", "copyright", "credits" or "license" for more information.
[14:23] <barry> >>> import dbus
[14:23] <barry> >>> import dbus.exceptions
[14:23] <jibel> stgraber, both work
[14:23] <barry> >>> dbus.DBusException is dbus.exceptions.DBusException
[14:23] <barry> True
[14:23] <barry>  
[14:24] <stgraber> jibel: even when connecting?
[14:24] <jibel> stgraber, ah, sorry
[14:25] <stgraber> jibel: apparently all the dbus calls works except for the final AddAndActivateConnection, so it should be failing after you press enter
[14:25] <jibel> stgraber, you're right, 2.7 pass, 3 fails
[14:27] <stgraber> barry: hey, I heard somewhere that you know a bit about python and dbus :) any clue as to what's going on here (type related problem apparently)?
[14:28] <barry> stgraber: i think at this point i need something i can reproduce locally
[14:29] <jibel> barry, you can reproduce from a live session of the latest desktop image
[14:30] <stgraber> jibel: can you try that one? http://paste.ubuntu.com/1025108/
[14:30] <stgraber> jibel: it should crash just as much but will print the type of all the parameters
[14:30] <barry> jibel: let me fire up a vm.
[14:31] <stgraber> barry: you'll need something with a wireless card. I can reprouce the bug on my laptop by running the python code I just gave to jibel, the problem is, I kind of depend on my wifi at the moment :)
[14:32] <barry> stgraber: ah.  i *might* be able to get that working on my old mbp, but probably have to burn a cd - which is fine, happy to do that if necessary, but maybe we can debug it a different way
[14:33]  * stgraber tries to find a wire :)
[14:34] <barry> stgraber: so, my first question is about what exactly the problem is ;).  are you getting an exception you don't expect, or are you not catching an exception you do expect?
[14:34] <barry> (or something else? ;)
[14:35] <stgraber> barry: getting an exception when we shouldn't
[14:35] <barry> stgraber: so you think that AddAndActivateConnection with the given signature should exist on the server, right?
[14:36] <stgraber> barry: it exists with a{sa{sv}}oo not with a{sa{sv}}ss
[14:36] <stgraber> barry: with the same python code, python2-dbus uses the right signature but python3 doesn't
[14:36] <barry> stgraber: interesting.  where's the server code?
[14:37] <stgraber> barry: that'd be NetworkManager in C. So we know the server side is identical
[14:37] <stgraber> barry: http://paste.ubuntu.com/1025120/
[14:38] <cyphermox_> indeed, that's an issue in dbus
[14:38] <barry> stgraber: i can hear bells ringing, so give me a moment to look at some code
[14:38] <cyphermox_> stgraber: if I break it on purpose, with python2: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "AdAndActivateConnection" with signature "a{sa{sv}}oo" on interface "(null)" doesn't exist
[14:38] <jibel> stgraber, with which version of python ?
[14:39] <stgraber> jibel: no longer needed, I found a wire here and ran it myself :) wanted to see the different in output between python2 and python3 but that's what I just pasted to barry
[14:40] <barry> stgraber: still looking...
[14:45] <barry> stgraber: i have a bit of an incomplete view of what's happening atm, but here's what i think's going on.  hopefully talking it out loud will clarify it.
[14:46] <barry> jibel: ^^
[14:46] <barry> to dbus 's' means utf-8 string
[14:47] <barry> in python 2, there is a UTF8String type which inherits from StrBase, which is an 8-bit string type
[14:47] <barry> 'o' is ObjectPath, which in both 2 and 3 inherit from strbase
[14:49] <barry> in py2 strbase inherits from NATIVESTR_TYPE, which in py2 is PyBytes_Type (i.e. 8-bit str), but in py3 is PyUnicode_Type
[14:50] <barry> so essentially, an ObjectPath is a str (a.k.a. bytes) in py2 but a unicode in py3
[14:51] <barry> stgraber, jibel what's tripping you up is that in py2, you'll get auto-downcasted from 'o' to 's' and you'll match the signature, but i believe that auto-downcasting is not happening because the type of ObjectPath doesn't match 's'
[14:51] <barry> (it's not in the inheritance tree)
[14:52] <barry> still, that doesn't look exactly right, but it smells like the path we're on
[14:52] <stgraber> barry: except that it's the other way around, the signature on NM's side is a{sa{sv}}oo
[14:52] <stgraber> so the auto-downcasting is what's breaking it
[14:53] <barry> hmm.....
[14:53]  * barry wonders, why would it try to autodowncast when the signature is 'o'?
[14:55] <stgraber> barry: is there a way to bypass the autodowncast?
[14:56] <barry> stgraber: not sure this will work, but in the AddAndActivateConnection() call try adding a trailing keyword argument, e.g.:
[14:57] <barry> signature='a{sa{sv}}oo'
[14:57] <stgraber> barry: it works
[14:58] <stgraber> jibel: can you confirm that http://paste.ubuntu.com/1025156/ works for you?
[14:58] <jibel> stgraber, let me try
[14:59] <cyphermox_> stgraber: wise
[14:59] <barry> stgraber: cool.  i think you should file a bug at freedesktop.org.  istm that the automatic signature calculation is not doing the right thing.  simon will probably have deeper insight though
[15:00] <barry> stgraber: it's been a while since i traced through that code and it's tricky
[15:01] <jibel> stgraber, all good, with python 2 and 3
[15:01] <cyphermox_> stgraber: confirming
[15:01] <barry> yay!
[15:02] <stgraber> skaet: once jibel confirms that it works, I'll be uploading a new ubiquity to -proposed. Also uploading a new isc-dhcp to -proposed to fix a pretty serious bug where the dhclient config file is ignored. Once both are built I'll pocket copy and start a respin.
[15:02] <stgraber> skaet: in theory we should respin desktop+alternate for it as oem-setup also uses ubi-wireless
[15:02] <barry> stgraber, jibel, cyphermox_ please do file the bug at https://bugs.freedesktop.org/ and if you paste me the url, i'll subscribe to it
[15:03] <barry> if it's a real bug then i'll work with simon to get it fixed upstream
[15:03] <skaet> stgraber,  sounds good.   There's some kernel fixes for arm in progress as well.  once everything lands/builds/publishes we'll respin for these.
[15:03] <skaet> do you have a bug number for isc-dhcp
[15:04] <stgraber> skaet: cool, can you add the arm stuff on the pad?
[15:04] <skaet> stgraber,  will do,  as soon as I get a bug number from them ;)
[15:04] <skaet> ogra_ ^ do you have a bug number for the latest issues?
[15:05] <stgraber> skaet: added isc-dhcp to pad
[15:05] <skaet> stgraber, Thanks!
[15:06] <ogra_> skaet, still collecting, i havent managed a successfull install yet
[15:06] <skaet> ogra_,  ack.  ok, post it here when one is created please.
[15:06] <ogra_> or what arm stuff are you referring to ?
[15:07] <ogra_> (did i miss anything (i had my laptop closed the last hours during testing and debugging)
[15:07] <ogra_> )
[15:07] <skaet> kernel config changes for omap to boot
[15:07] <skaet> bug number associated with it?
[15:07] <ogra_> ah, well, havent gotten to omap at all yet :)
[15:10] <ogra_> i'll happily add it if ogasawara or paolo  have a bug # for it
[15:14] <balloons> anyone try CJK install yet?  I got a hard failure during install  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1009052
[15:14] <ubot2`> Launchpad bug 1009052 in ubiquity "CJK Installation fails with error" [Undecided,New]
[15:15] <jibel> balloons, let me try
[15:15] <jibel> balloons, did you get it in a VM ?
[15:15] <balloons> jibel, yes, hence my asking for real hw confirmation :-)
[15:15] <balloons> trying the amd64 iso now.. it happened on i386
[15:16] <stgraber> ubiquity and isc-dhcp uploaded to -proposed, will monitor and pocket copy when they're done
[15:17] <skaet> ack
[15:18] <bdmurray> slangasek: I approve of the ubuntuone-client upload for precise-proposed
[15:18] <jibel> balloons, looks like a dependency issue with langpacks
[15:19] <balloons> jibel, I was also concerned about ubiquity not seeing my active connection..
[15:22] <jibel> stgraber, skaet can you disable alternate and desktop on the tracker if new images are being rebuilt soon-ish
[15:23] <stgraber> jibel: yeah, I can disable everything we'll rebuild for sure
[15:24] <stgraber> done, everything disabled
[15:24] <jibel> I think we don't need to waste tester time on downloading and testing images that have an hour lifetime.
[15:25] <stgraber> oh, and I suppose I should be adding the upgrade entries to the tracker now that update-manager is supposedly working :)
[15:25] <balloons> jibel, amd64 build just failed also in the VM; tried a different language still failed
[15:26] <jibel> balloons, I confirm the crash with Chinese, it passed with French. Which language did you selected ?
[15:26] <balloons> I tried chinese just now, and simplified chinese in my bug report
[15:27] <skaet> jibel,  agreed
[15:27] <balloons> it's interesting we're missing some string translation coverage in apport
[15:33] <stgraber> isc-dhcp built and pocket copied to quantal-release
[15:41] <slangasek> bdmurray, dobey: ubuntuone-client accepted
[15:41] <slangasek> bdmurray: I don't suppose you have any insight into why that one stalled in the unapproved queue so long?
[15:46] <bdmurray> slangasek: I believe it was missing test cases for a bit
[15:47] <slangasek> aha, ok
[15:53] <ogra_> hmpf, so it seems that omap4 is very very fragile wrt displays ...
[15:54] <ogra_> might need a release note to boot with no screen attached (to make it fall back to a hardcoded 1024x786 mode)
[15:55] <balloons> stgraber, skaet can I get details on the rebuilds? I'd like to send something out to everyone.. the build notes on the tracker should contain the reason yes?
[15:56] <skaet> balloons,  see: http://pad.ubuntu.com/ubuntu-release
[15:56] <skaet> at the bottom,  is history of what's already been included in the rebuilds so far.
[15:56] <skaet> status on what's about to go into rebuilds is at the top.
[15:56] <skaet> (for the next set)
[15:56] <balloons> right -- so [6] is current?
[15:57] <balloons> OHH!
[15:57] <skaet> yes.
[15:57] <balloons> haha, right on top
[15:57]  * balloons never saw those
[15:57] <skaet> however we're about to respin for those triggers - so, ....  timing of when you send the email out will influence content.
[15:57] <skaet> probably wait until stgraber kicks off the next set of respins, and then summarize what's landing.
[15:57] <skaet> ?
[15:59] <balloons> skaet, yes I wanted to summarize yesterday and since I'm at it.. all the respin bugs
[15:59] <balloons> including stuff that is about to land.. which was driving my question, what's about to land
[16:00] <skaet> ok, let me know if what's on the pad is not sufficent and we'll add it to there for now.
[16:00] <skaet> want to have one place to keep history going. ;)
[16:00] <skaet> so experimenting with format/info.
[16:02] <stgraber> ubiquity is done building too, waiting for publisher, then pocket copy, then waiting for publisher, then mass rebuild
[16:02] <balloons> I think i was just confused.. stuff up top is about to land.. stuff on the bottom is history
[16:02] <balloons> yes?
[16:02] <stgraber> and using all that waiting for publisher time to get some lunch :)
[16:02] <stgraber> balloons: correct
[16:04] <skaet> balloons, yes,  when the rebuild is triggered, I'm moving the info down to history part.
[16:05] <balloons> skaet, yep makes sense.. :-)
[16:05] <skaet> numbers are monitonically increasing, so we can keep track over time and refer to triggers explcitly (some aren't bugs and packages)
[16:07] <stgraber> slangasek: once I'm done with the pocket copying and it's published in the release pocket, should I poke you/another AA to cleanup -proposed or do we already have some process in place to regularly remove the duplicates from -proposed?
[16:07] <slangasek> stgraber: http://people.canonical.com/~ubuntu-archive/pending-sru.html tracks stale packages in -proposed
[16:09]  * skaet notes that at bottom is -proposed cleanup"  commands to be run.   ;)
[16:11] <stgraber> slangasek: oh right, forgot about that part of pending-sru
[16:22] <bdmurray> slangasek: I approve of ubuntuone-control-panel for precise
[16:34] <skaet> stgraber,  looks like kernel team has fixes for  bugs 1008905 and 1009061.   linux-meta fix will be uploaded.
[16:34] <ubot2`> Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [High,In progress] https://launchpad.net/bugs/1008905
[16:34] <ubot2`> Launchpad bug 1009061 in linux "Beagleboard doesn't boot" [High,Confirmed] https://launchpad.net/bugs/1009061
[16:35] <skaet> how close are you to starting off the respins?
[16:36] <skaet> NCommander,  can you handle getting the d-i updates done for these?
[16:36] <stgraber> skaet: I should have isc-dhcp published soon which will unblock a good set of respins, then ubiquity will be published around 30min later unblocking the rest
[16:37] <stgraber> skaet: do we want to wait for the kernels? because it sounds like they'll affect pretty much everything too...
[16:38] <ogra_> does anyone else get scrollbars in the slideshow or is that just caused by my 1024x768 screen ?
[16:38] <stgraber> ogra_: I remember seeing a report of that on the tracker
[16:38] <ogra_> great
[16:38] <skaet> jibel,  would like to get some data on the fixes already queued up,  and then when all the other pieces for the kernel land later today respin (so fresh images for tomorrow),  that work for you?
[16:38] <stgraber> ogra_: minimum supported resolution is 1024x600, if you get scrollbars with anything >=, it's a bug
[16:38] <ogra_> yep, i thought so
[16:38] <jibel> ogra_, bug 1008717
[16:38] <ubot2`> Launchpad bug 1008717 in ubiquity "Ubiquity displays scrollbars inside of slideshow" [Medium,Triaged] https://launchpad.net/bugs/1008717
[16:39] <infinity> skaet: I'll fix d-i for the new kernels.
[16:39] <ogra_> jibel, thanks, will add it to my isotracker report
[16:39] <skaet> Thanks infinity.
[16:39] <jibel> skaet, works for me
[16:39] <skaet> Thanks jibel.
[16:40] <skaet> stgraber,  ok,  go ahead and spin up the kernels, and we'll collect data on them.   Then pick up the new kernel later today.
[16:40] <skaet> oops
[16:41] <skaet> stgraber,  ok,  go ahead and spin up the "images", and we'll collect data on them.   Then pick up the new kernel later today in fresh images.
[16:41] <slangasek> bdmurray: ubuntuone-control-panel accepted
[16:41] <stgraber> skaet: right, ETA is 30min for images that don't ship ubiquity and an hour for the hours (ETA to build start that's)
[16:56] <NCommander> skaet: once the kernel and kernel meta package lands, I'll kick d-i
[16:59] <skaet> NCommander,  infinity has said he'll help out with d-i,  so may have that covered.   Can you handle the rebuilds tonight?
[17:00] <NCommander> skaet: I can cover that
[17:01] <skaet> Thanks NCommander.  :)
[17:09] <stgraber> isc-dhcp looks published, starting some builds now
[17:10] <dobey> hi skaet
[17:11] <dobey> skaet: uploads for things in universe can go straight to quantal still for soft freeze, right? (making sure i understand correctly)
[17:13] <skaet> Thanks jibel
[17:13] <stgraber> dobey: depends what packages in universe
[17:13] <stgraber> dobey: if it's seeded, no
[17:14] <dobey> stgraber: how do i tell if it's seeded?
[17:15] <stgraber> dobey: seeded-in-ubuntu <package>
[17:16] <stgraber> where <package> is the source package
[17:16] <dobey> right
[17:16] <dobey> ok
[17:25] <stgraber> barry: https://bugs.freedesktop.org/show_bug.cgi?id=50740
[17:25] <ubot2`> Freedesktop bug 50740 in python "py3dbus is downcasting the ObjectPaths to signature 's' when the server is advertising 'o'" [Major,New: ]
[17:26] <stgraber> barry: feel free to correct my explanation if I missed something ;) I quickly typed that one after Fabio reported the bug to make it a bit more readable for upstream :)
[17:59] <skaet_> infinity,  NBS list looks like its got a fair bit of cruft in it,  http://people.canonical.com/~ubuntu-archive/nbs.html,  can you sort it?
[17:59] <stgraber> ok, ubiquity just finished publishing, will start the rebuilds
[17:59] <infinity> skaet_: Yeah, I'm dealing with that today.  Getting my beer on quantal-probs was my first concern. ;)
[18:01] <skaet_> lol,  why am I not surprised.  ;)
[18:04] <infinity> Also, fixing the archive reporting cronjob...
[18:04] <infinity> And maybe eating breakfast.
[18:05] <infinity> ^-- Beer.
[18:05] <infinity> That should be the last uninstallable in !ports.
[18:06] <infinity> Sadly, mono on armel makes ports look a bit worse. :P
[18:07] <Daviey> stgraber: bug 1006937 is fix released, re-spin server?  Or should i do it?
[18:07] <ubot2`> Launchpad bug 1006937 in isc-dhcp "dhclient does not send hostname to dhcp-server" [Undecided,Fix released] https://launchpad.net/bugs/1006937
[18:07] <stgraber> Daviey: I was told not to respin server
[18:07] <stgraber> skaet_: ^
[18:07] <infinity> Daviey: There are new kernels coming anyway, but if you want an interim respin to test things, you can.  *shrug*
[18:08] <Daviey> infinity: nah, can wait
[18:08] <Daviey> stgraber: Yep, please continue to build server.
[18:08] <Daviey> stgraber: I asked QA to make server less of a priority as i was expecting changes, but didn't communicate that to you.. as i wanted them built regardless :)
[18:09] <skaet_> stgraber,   Daviey had some discusions with others, and its back in for the A1 manifest.
[18:09] <stgraber> Daviey, skaet_: ok
[18:09] <barry> stgraber: thanks.  i'll follow up to the upstream bug
[18:12] <bdmurray> slangasek: +1 for retext in precise-proposed
[18:12]  * ogra_ hands infinity an eyepatch that hides armel from his view 
[18:14]  * infinity goes to scramble some eggs for "breakfast".
[18:16] <ogra_> didnt you just have beer ?
[18:16] <ogra_> that should be enough for breakfast
[18:16] <ogra_> :)
[18:16] <infinity> I don't get beer until the end of this publisher run.
[18:16] <infinity> Sadness.
[18:17] <ogra_> ah, and you are bridging with eggs ... understood now :)
[18:20] <stgraber> skaet_: updated the pad to reflect that we're currently rebuilding the desktop/alternate images to get the new ubiquity+isc-dhcp and will respin the world later for the kernel
[18:21] <skaet_> thanks stgraber.  :)
[18:21] <Daviey> why is there a new alternate if a kernel is being waited on?
[18:23] <Daviey> Is the kernel an ABI bump?
[18:23] <ogra_> someone said so above
[18:23] <stgraber> Daviey: ubiquity was quite broken in the previous build, so we want to still get some results
[18:23] <stgraber> (and ubiquity is on alternate because of the OEM install mode)
[18:24] <Daviey> stgraber: If it's a kernel ABI bump, will d-i be rebuilt ?
[18:24] <stgraber> yes
[18:24] <ogra_> stgraber, well, oem-config just worked fine on preinstalled for me
[18:24] <Daviey> super
[18:24] <stgraber> ogra_: not connecting to a wifi I suspect?
[18:24] <ogra_> ah, no, wired on the panda
[18:24] <stgraber> right, wifi is what crashes ubiquity
[18:24] <Daviey> I imagine all OEM's provision their hardware using wifi :)
[18:24] <ogra_> i dont test such exotic setups for A1 :P
[18:25] <stgraber> Daviey: it's not the provisioning that's the problem, it's the first-boot configuration screen
[18:25] <stgraber> Daviey: which on most laptops is going to happen over wifi
[18:25] <Daviey> ah yeah
[18:26] <stgraber> ogra_: so based on the changelog, the same kernel that'll fix amd64+mac will fix omap3 right?
[18:27] <ogra_> yes
[18:27] <stgraber> ogra_: cool. Do you want to wait for it or do you want an ubuntu desktop preinstalled build now? the ARM builders aren't doing anything :)
[18:28] <bdmurray> slangasek: I approve of ntp for precise-proposed too
[18:29] <ogra_> stgraber, well, i tested omp4 already and have my collection of bugs for it ... omap3 wont boot, and ac100 will likely have flash-kernel issues so just leave them for now
[18:29] <stgraber> ogra_: ok
[18:29] <ogra_> stgraber, unless infinity wants an mx5 build for testing
[18:30]  * ogra_ will do a smoketest for ac100 tomorrow but i dont expect it to work OOTB without some default changes to f-k
[18:31] <stgraber> I believe yesterday's mx5 build failed, was that fixed?
[18:32] <ogra_> http://cdimage.ubuntu.com/daily-preinstalled/current/ seems to have a recent build
[18:32] <ogra_> ac100 not though :/
[18:33] <ogra_> intrestingly the failed ac100 builds dont generate failure mails ... at least i didnt get any
[18:36] <stgraber> skaet_: so I'll be building the following for now: ubuntu desktop, wubi, edubuntu desktop, kubuntu desktop, lubuntu desktop
[18:36] <stgraber> skaet_: by the time these are done, we'll probably have the next batch of rebuilds for the kernel
[18:36] <skaet_> stgraber,  ok.
[18:36] <stgraber> skaet_: but that should at least leave some time for testing the rest of the system
[18:36] <NCommander> stgraber: does it make sense to do a rebuild to only do another rebuild for another kernel?
[18:37] <NCommander> As it stands, test results get hidden against old builds.
[18:37] <skaet_> NCommander,  earlier discussion indicated it would be good to get some testing cycles on these fixes.
[18:37] <stgraber> NCommander: I'd kind of like to have smoke testing on some of these images that haven't received any testing for alpha1 yet
[18:37] <skaet_> NCommander,  we can see via /history prior results, so not lost
[18:37] <NCommander> stgraber: skaet_: good points, just making sure we're not making more work for ourselves
[18:38] <stgraber> I've prioritized by images with the least testing done so far (well, except for ubuntu desktop), so hopefully we can catch any critical bug before we respin for the kernel
[18:39] <skaet_> thanks stgraber,  that makes sense.  :)
[18:41]  * NCommander goes AFK for lunch
[18:55] <barry> stgraber, jibel: looks like upstream already fixed it :)  i'll back port the patch for ubuntu while waiting for a new upstream release
[18:58] <stgraber> barry: that was fast :)
[18:58] <barry> yep :)
[19:30] <barry> stgraber: i'v backported the patch, but i'd like you to try it without the nm.py hack (i.e. setting the signature).  would you like to try a ppa or should i just go ahead and upload it?
[19:33] <stgraber> barry: at this point I'd prefer not to have it uploaded to the archive until post alpha-1 as we already have the workaround in ubiquity
[19:33] <stgraber> barry: I'm happy to test with a PPA though
[19:33] <barry> stgraber: perfect, i'll upload it momentarily
[19:33] <barry> (to my ppa)
[20:08] <slangasek> bdmurray: retext, ntp accepted
[22:09] <RAOF> So where's this SRU hangout thingy?
[22:09] <skaet> RAOF,  didn't get quorum
[22:09] <skaet> moved it next week.
[22:10] <bdmurray> SRU hangout?
[22:10] <RAOF> Ah, ok. I'll go about my regular morning business then :)
[22:17] <slangasek> skaet: ^^ should bdmurray also be invited, now that he's on the SRU team?
[22:18] <skaet> slangasek,  yup,  he's going to care about the topic.  ;)  will add.
[22:19] <bdmurray> slangasek: I approve policycoreutils for precise-proposed
[22:19] <slangasek> bdmurray: accepted
[22:19] <slangasek> and hmm, what happened with the discussion about adding you to ubuntu-archive for this :)
[22:20] <slangasek> RAOF: what archive admin training did we subject you to before adding you to the group?
[22:20] <bdmurray> indeed
[22:20] <RAOF> slangasek: None specifically for archive admin; for SRU it was use of the tools, and prodding of launchpad.
[22:21] <RAOF> slangasek: And a pinky swear to not do the things that I have access to that I'm not authorised to.
[22:22] <slangasek> RAOF: where "not authorized to" is anything except pocket-copies to -updates, managing the unapproved queue, and deleting packages from -proposed?
[22:22] <RAOF> slangasek: Yes.
[22:23] <ScottK> skaet and slangasek: As a reminder, I've volunteered for SRU as well, but it seems to be hard to make progress on it.
[22:24] <slangasek> bdmurray, cjwatson: ^^ that seems to me like a pretty straightforward policy for non-AA SRU members to follow - should we add bdmurray to ubuntu-archive?
[22:24] <slangasek> ScottK: oh, indeed - I think we'll want to get you paired up with someone to help train you up
[22:24] <ScottK> OK.
[22:26] <ScottK> Since I'm already in ubuntu-archive and was once a motu-sru member, I think the needed training will be minimal (I already know how to drive sru-accept.py since I've done accepts on behalf of non-ubuntu-archive SRU members before).
[22:27] <slangasek> ah, ok
[22:28] <slangasek> I think it's still a good idea to give you a refresher on the current tools/policies just in case things have changed (i.e., I'd prefer one of the people dealing with the day-to-day stuff do the training, not me, since my own understanding is potentially bit-rotted :P)
[22:28] <ScottK> Certainly.
[22:28] <slangasek> RAOF: would you be willing to train ScottK for current SRU team practices?  That might work well as far as your respective time-of-day availabilities
[22:29] <RAOF> Yeah, certainly.
[22:29] <ScottK> I'm kind of booked until my Friday at this point.  Let's try and do it then.
[22:29] <RAOF> ScottK: When's good for you?
[22:32] <infinity> skaet: SRU hangout?
[22:32] <infinity> skaet: Did I miss an invite to something?
[22:33] <bdmurray> slangasek: yes that policy seems easy to follow
[22:54]  * micahg sees infinity finally got his beer
[22:55] <infinity> \o/
[23:19] <skaet_> infinity, ETA on d-i changes?
[23:19] <infinity> skaet_: Kernel's still building.
[23:19] <infinity> skaet_: So... After that. :P
[23:19] <skaet_> bleh.  thought it would be through by now.
[23:19] <skaet_> thanks.
[23:19] <infinity> (I have it all ready to upload when the kernel's done and copied)
[23:20] <skaet_> Thanks.  :)
[23:28]  * skaet --> dinner
[23:29]  * infinity does a bunch of NEW processing while waiting on the last kernel build.