[01:25] <GridCube> stgraber, :) hello
[01:26] <stgraber> hi GridCube
[01:26] <GridCube> I wonder, we should start doing test already, pre-alpha1 tests, so we need to report them, can we use the current tracker? or is it not ready yet?
[01:27] <stgraber> it should be ready in 5 minutes or so, loading the last export of the DB now
[01:27] <GridCube> :o
[01:27] <stgraber> I'll send an e-mail to ubuntu-devel, ubuntu-qa, ubuntu-testing and ubuntu-release when it's ready
[01:27] <GridCube> :P im not part of any of those
[01:27] <GridCube> add an x to a few and sure XD
[01:31] <GridCube> one question if you can, whats XMLRPC?
[01:31] <cjwatson> stgraber: that build seems to have succeeded, BTW, as did the cronned one
[01:31] <cjwatson> http://en.wikipedia.org/wiki/XML-RPC
[01:32] <cjwatson> specifically http://docs.python.org/library/xmlrpclib.html
[01:33] <stgraber> cjwatson: yep, I did some testing on it, found a bug, fixed it and the fix maybe even made it for the cronned one :)
[01:33] <GridCube> cjwatson, yes i read that already, its data transference protocol, but what for?
[01:34] <cjwatson> the ISO tracker's API
[01:34] <cjwatson> e.g. getting the list of products, posting a new build, etc.
[01:35] <GridCube> oh, so its not for users?
[01:36]  * cjwatson is not in a position to say whether that's true or not :-)
[01:37] <stgraber> Eventually yes, when the API is stable and documented
[01:37] <stgraber> currently users can only list milestones and products, so not that useful
[01:37] <stgraber> for alpha-2 I expect users to be able to push new results using it and be able to query quite a bit more (list of results, list of builds, ...)
[01:38] <GridCube> mmhmm i see
[01:38] <stgraber> at the moment we mostly use it to post new builds to the tracker (and that's a pretty restricted call ;))
[01:38] <GridCube> it was weird to me because it was under "user profile"
[01:39] <stgraber> ok, so http://91.189.93.73 is running with the latest import, I re-imported the daily testing results and my sanity check of the DB looks good. Guess it's time to e-mail the lists.
[01:39] <GridCube> another question, when i click on my nick where it says "hello GridCube" it sends me to "Access Denied"
[01:39] <stgraber> GridCube: right, everyone can set an API key, what you can actually access is then based on your rights
[01:40] <stgraber> GridCube: oh, I guess I should fix that (remove the link probably). On a regular Drupal that'd send you to some settings page, but as we use Ubuntu SSO, that page is disabled.
[01:41] <GridCube> oh, ok
[01:41] <GridCube> so where do i store the specs under the test was done? on a comment of the results? (like we use to do anyway?
[01:41] <GridCube> XD
[01:42] <GridCube> also its not possible to report test results that are "not" current? if i download an image and test it and when i go to report it it has changed, i cant report it?
[01:53] <stgraber> GridCube: at the moment, I'd recommend storing the specs in the comment as the hardware specs is one of the feature that's disabled for alpha-1
[01:54] <stgraber> GridCube: the tracker doesn't allow users to report results for superseded ISOs. If you're sure it'll affect the new version too, just report it against it and mention it in the comment field
[02:05] <GridCube> stgraber, :) thanks
[02:05] <GridCube> that sounds rasonable
[02:13] <GridCube> sorry for being such a bother
[02:13] <GridCube> :)
[08:56] <pitti> Daviey, jibel: do you know whether the i386 server failure on https://jenkins.qa.ubuntu.com/view/Precise%20Daily%20ISOs/job/precise-server/lastFailedBuild/#showFailuresLink is a bug in the tests or an actual problem with the ISO?
[08:58] <jibel> pitti, this is a bug with the test
[08:58] <jibel> error: Failed to define domain from /var/lib/ubuntu-server-iso-testing/tests/b9fce8d5-8542-451f-94c0-8212bc3138b6/libvirt.xml
[08:58] <jibel> the iso is good
[08:59] <jibel> first time I see this error
[09:00] <pitti> jibel: for example, the mysql one had some new unexpected default databases, presumably due to the migration to 5.5; but it's curious that this doesn't affect amd64, too?
[09:02] <pitti> jibel: also, how far do the desktop/alternate tests go? do they just end at successful termination of the installer, or do they also check that the installed system boots into a desktop?
[09:08] <jibel> pitti, the system is rebooted, then it runs some post installation tests, like checking that FS is RW, permissions of the encrypted home, if it's an LVM install that LVM is mounted properly.
[09:08] <pitti> jibel: nice!
[09:08] <jibel> one of the objective of this cycle is to extend the number of tests run post install.
[09:09] <pitti> jibel: https://jenkins.qa.ubuntu.com/view/Precise%20Daily%20ISOs/ is indeed quite fast
[09:09] <pitti> I mean with running and reporting the tests after new ISOs appear
[09:10] <pitti> o_O I was going to ask you why i386 OEM was shown as failed, but I can't find info in the details; reloading https://jenkins.qa.ubuntu.com/view/Precise%20Daily%20ISOs/ now shows it as passed
[09:11] <pitti> anyway, so much the better :)
[09:11] <jibel> indeed, it could be improved if we used unsafe-io and tmpfs. The current bottleneck is disk and we can run only 8 to 10 tests at the same time.
[09:12] <jibel> desktop installed failed because of the bug we talk about last friday.
[09:12] <pitti> ah, so it was re-run and then succeeded?
[09:13] <jibel> yes
[09:13] <jibel> I did a test over the week and ran a desktop installation in a loop 20 times. 50% of the tests failed with an 'Invalid argument' error
[09:14] <jibel> I did the same with an Oneiric image, and there was no failure.
[09:14] <jibel> *week end
[09:15] <pitti> ah, same host platform, I assume?
[09:15] <pitti> so supposedly some kernel change
[09:15] <jibel> same environment, same image and nothing else was running on the test env.
[09:16] <jibel> right, I'll move it there and ask the kernel team to have a look.
[09:17] <jibel> pitti, another user reported the same failure but with vbox on a mac.
[09:17] <jibel> I have no report of this error on hardware yet.
[09:18] <pitti> I just finished a successful install in kvm, but I might just have been lucky
[09:18] <pitti> jibel: was this ever reproduced on a host running the precise kernel?
[09:19] <jibel> pitti, not tested.
[09:19] <pitti> (that's what I tested just now)
[09:20] <pitti> jibel: I suppose you use virtio?
[09:20] <jibel> pitti, yes
[09:22] <pitti> I just did a 10000 times loop of copying /bin/bash to the mounted /dev/vda1, and it works fine
[09:23] <pitti> I'll try installing the lucid kernel and booting the image in kvm when running that
[09:48] <cjwatson> jibel: d-i uses unsafe-io for itself; maybe ubiquity should too ...
[09:49] <cjwatson> at least if it just created the filesystem for itself and isn't working on an existing one
[10:04] <pitti> jibel: just commented on the bug, seems I can't reproduce this :( having luck when not asking for it, I guess
[10:05] <pitti> jibel: it could be worth a try if it also happens when using -hda instead of virtio, that should have fewer requirements for the involved kenrels
[10:05] <pitti> that might be a good enough workaround for now
[11:01]  * cjwatson moves *-mismatches generation to lillypilly
[11:02] <cjwatson> Daviey: if you'd like to work on integrating component-mismatches-mir-track into component-mismatches proper, it's in lp:ubuntu-archive-tools now
[11:03] <cjwatson> it's still not very nice code but I've cleaned it up quite extensively
[11:07] <Daviey> cjwatson: oooo!
[11:07] <Daviey> cjwatson: I'll do that.
[11:08] <Daviey> cjwatson: I didn't realise you were looking at, component-mismatches-mir-track .. but the code that produces that is not suitable for open sourcing :)
[11:08] <cjwatson> I wasn't, but you mentioned it a while back and I remember you wanting to get access to the underlying c-m code
[11:09] <cjwatson> and I'd generally like to encourage efforts to improve those reports
[11:12] <Daviey> ah, right
[11:14] <cjwatson> jibel: hm, what's https://jenkins.qa.ubuntu.com/view/Precise/job/precise-desktop-i386_encryptedhome/lastFailedBuild/ about?  the d-i syslog is empty
[11:18] <jibel> cjwatson, the failure is the 'Invalid argument' error. syslog is empty because there's a bug in the framework and the output is not redirected to the log file on the host as it should be. I'll fix that.
[11:20] <Daviey> cjwatson: lillypilly only has i386 and amd64 archive, right?  How is powerpc, armel and armf being checked?
[11:20] <cjwatson> jibel: where is that error displayed?
[11:21] <cjwatson> Daviey: lillypilly:~ubuntu-archive/mirror/ has dists/ for all architectures
[11:21] <Daviey> ah, sneaky
[11:21] <Daviey> thanks
[11:21] <cjwatson> I got IS to poke some rsync holes for me
[11:21] <Daviey> heh
[11:21] <jibel> cjwatson, in the VM's syslog.
[11:22] <cjwatson> I can't see that in the build artifacts?
[11:22] <cjwatson> oh, "the output is not redirected to the log file on the host as it should be"
[11:22] <cjwatson> ok
[11:36] <knome> cjwatson, does example-content still ship *buntu* logos?
[11:41] <cjwatson> knome: no idea
[11:41] <cjwatson> I only ever do drive-by work on example-content
[11:42] <knome> okay, who should i contact?
[11:42] <cjwatson> I don't know - desktop team maybe? </flails>
[11:42] <knome> mhmm
[14:02] <stgraber> good morning
[14:04] <infinity> Can't prove it.
[14:06] <ogra_> mine was good ...
[14:07] <ogra_> (for the statistics)
[16:52] <infinity> So, who feels good about me uploading a new eglibc 3 days before A1?
[16:52] <ogra_> o/
[16:53] <ogra_> wouldnt be exciting without such uploads
[16:53]  * infinity smirks.
[16:53] <ogra_> well, we just found that our omap3 images arent working without a new kernel upload
[16:54] <infinity> Good, then I'll get my armhf omap kernel too!
[16:54]  * ogra_ loves the pre-milestone excitements and surprises
[16:54] <infinity> Since apw committed the fix for that.
[16:55] <apw> ogra_, whats up with -omap3, if leann aware?
[16:55] <infinity> apw: Broken display driver, just came up.
[16:55] <ogra_> apw, not sure, ppisati just discovered it ... seems there is a completely new display driver on omap
[16:56] <ogra_> which is in our source but not enabled in the config
[16:56] <ogra_> so its a simple config change =m to =y i think
[16:56] <apw> god we should just throw arm out of the kernel :)
[16:56] <ogra_> haha
[16:56] <infinity> apw: *glare*
[16:57] <infinity> apw: We're kinda trying to head in the other direction. :P
[16:57] <apw> don't i know it
[16:58] <apw> ogra_, is this omap4 ?
[16:58] <ogra_> apw, sadly not
[16:58] <ogra_> omap3
[16:59] <apw> bah
[17:02] <ogasawara> skaet: ^^ there's a patch to resolve the above omap issue but it will require a new kernel upload
[17:02] <ogasawara> skaet: want to get your ack before uploading
[17:04] <skaet> ogasawara, would be nice to have omap3 working for alpha1 for a change,  any other side effects?
[17:04]  * skaet just reading the comments from oneiric's alpha1 about omap3...
[17:04] <ogasawara> skaet: it's only a config change and only affecting arm, so shouldn't have other side affects
[17:04] <ogra_> uuuh, dont !
[17:04] <ogra_> :)
[17:05] <skaet> ogra_, ...?    seriously??
[17:05] <ogra_> i mean dont read the 11.10 comments :)
[17:05] <skaet> *whew*
[17:05] <ogra_> thats just depressing
[17:05] <skaet> thanks for the head's up ogasawara,  go ahead then.
[17:05] <ogasawara> skaet: the patch has been tested too -> https://lists.ubuntu.com/archives/kernel-team/2011-November/018002.html
[17:06] <skaet> pitti ^^ fyi.
[17:06] <ogasawara> skaet: thanks
[17:06] <ogra_> skaet, thanks :)
[17:06] <pitti> skaet: thanks for the ping
[17:06]  * pitti will be gone now, Taekwondo time
[17:09] <skaet> bye pitti,  have fun.
[17:19] <infinity> skaet: FWIW, I'll be making an eglibc upload later today with similar "only affects ARM" properties.
[17:20] <infinity> skaet: In fact, should be "only affects armhf", which is clearly not even part of Alpha 1. :P
[17:21] <skaet> infinity,  if it only affects armhf,  what's the impact of it waiting until after alpha 1 is out?   eglibc does tend to have a fairly wide impact...
[17:22] <cjwatson> it'd slow down the armhf bootstrap
[17:22] <cjwatson> AIUI it's critical-path for it
[17:27] <infinity> ^
[17:27] <skaet> infinity,  if it only affect armhf, ack then.   Thanks for the head's up.
[17:28] <skaet> infinity,  will it be able to land before 2100 UTC?  (soft freeze)
[17:37] <infinity> skaet: In 4 hours?  Maybe, but I wouldn't hold my breath.  Still running through some test build mojo to make sure it's sane.
[17:38] <infinity> skaet: More likely to land tonight my time, so several hours past freeze.
[17:39] <cjwatson> eglibc isn't one of the packages that causes trouble if it's out of sync across architectures, at least
[17:40] <infinity> Nope.
[17:45] <skaet> infinity,  having troubles interpreting that Nope...  are you agreeing with cjwatson?
[17:49] <infinity> skaet: Yeah.
[17:49] <infinity> Sorry, I've been awake for $way_too_long, not very verbose.
[17:54] <skaet> infinity,  please see if you can avoid the autobuilding,   or coordinate it with pitti if it gets that late.   Would like to make sure we get a clean set of initial images if possible.
[17:55] <skaet> since we'll be testing out using the new iso tracker, and would like to try to keep the churn factors down.
[17:58] <cjwatson> last armel build time was 5h35, other arches well under that
[17:59] <infinity> Yeah, there's not much hope of squeezing in before the next armel builds.
[18:01] <skaet> infinity, ping me or pitti then when its ready, and we'll see what best options are then.
[18:03] <stgraber> skaet, pitti: btw, I mentioned during the release meeting that you can now leave notes on a per-build basis, that feature is fairly well hidden in the admin UI. If you want to do so, you'll need to go in Administration, then Builds and click on the version number in the right most column.
[18:03] <infinity> skaet: Mmkay.
[18:03] <skaet> thanks stgraber
[18:03] <stgraber> skaet, pitti: if the build you want to change isn't in that column, you'll have to manually tweak the URL to include the right build ID
[18:04] <stgraber> I guess I'll need to get myself a work item on making the admin UI a bit more consistent and potentially move all of the admin stuff in the admin UI instead of having admin actions in the user UI too
[18:05]  * skaet likes consistency
[19:20] <micahg> is alpha 1 freeze at 2100?
[19:21] <stgraber> skaet: CCed you on a RT ticket (upgrades using update-manager being broken because of extras.ubuntu.com not containing precise). Not sure what our expectations are for upgrades from Oneiric to Precise for alpha-1
[19:22] <stgraber> if you think it's critical that it works, you may want to poke IS about it (deej is having a look at it now) :)
[19:22] <skaet> stgraber, thanks.
[19:23] <skaet> micahg, yes 2100 is alpha1 softfreeze.   One known exception.
[19:23] <stgraber> skaet: RT #49544
[19:23]  * micahg rushes to upload chromium before the freeze
[20:51] <pitti> skaet, infinity: so I guess I'll kick off a complete set of images tomorrow, after checking that the kernel and eglibc have built (although we don't really need to wait for eglibc, I guess)
[20:52] <pitti> skaet, infinity: FTR, cron jobs disabled, will use the optimized pipeline tomorrow
[20:53] <micahg> skaet: can I have 10 or so extra minutes to get chromium in, just waiting for a test build to complete?
[20:53] <skaet> pitti,  ok.    If I kick off a set with just the kernel in it,  I'll let you know.
[20:53] <skaet> micahg, yes,  would rather you get it in tested.
[20:58] <micahg> skaet: oops, looks like this isn't going to happen, build failed, so I guess this update won't be in alpha 1, was for a minor regression + minor security issue, so no biggie
[20:58] <pitti> skaet: ah, so you reached mvo
[20:59] <skaet> micahg,  ok.   Thanks for letting know.  :)
[20:59] <skaet> pitti,  yup.
[21:47] <cjwatson> skaet: #ubuntu-devel conversation with hallyn - we're going to need a qemu-kvm upload in the freeze, since it's uninstallable on non-i386
[21:50] <skaet> cjwatson,  thanks.   understood.
[21:53] <tumbleweed> skaet: can we clarify that announcement, saying that non-seeded packages in universe aren't affected?
[21:53] <skaet> tumbleweed,  good point,  I'll clean up the wording next time, and post a follow up now.
[21:53] <tumbleweed> thanks
[22:09] <micahg> technically, unseeded main packages also shouldn't be affected
[22:09] <micahg> err, I meant non-image based main packages...
[22:10] <stgraber> micahg: right, skaet's follow up e-mail reflected that
[22:10] <stgraber> micahg: "Just to be clear - this soft freeze is only for seeded packages in main
[22:10] <stgraber> and universe."
[22:10] <stgraber> ah, you mean, seeded but not on media packages?
[22:10] <micahg> right, i.e. in the "supported" seed :)
[22:11] <micahg> but that's just me splitting hairs :), I don't expect it to impact anyone
[22:11] <stgraber> "This soft freeze is only for seeded packages in main and universe that are shipped on one of our media (sorry, we don't really have a list of these)"
[22:12] <stgraber> would have been more accurate, but the, we don't really have a list is a bit annoying :) (you can get it from the manifests but that's quite a bit of parsing to do)
[22:13] <micahg> stgraber: well, not precisely (pun intended), build-deps for those packages would be included, just not stuff that's officially "supported", but not on media or related to building media based packages
[22:13] <stgraber> oh, right, build-deps ;)
[22:16]  * skaet will work on the wording to be a little clearer for alpha 2,  but doesn't think folk want to check lists of packages.  ;)
[22:17] <stgraber> skaet: hehe, maybe Launchpad should just be aware of soft-freezes though we'd still have to maintain a package list... don't think it's worth the time at this point
[22:17] <tumbleweed> skaet's wording was definitly better than mine :) But I'm mainly concerned about newish people working on universe who don't know how these things work yet. We expect core-devs to understand freezes :)
[22:17] <Daviey> Can we paint it green please?
[22:17] <micahg> skaet: no, what you put is fine, I'm just splitting hairs (it's only probably about 10 or so packages that would be included in the difference, I'm just causing trouble :))
[22:18] <skaet> Daviey,  lol.   Am working on colors for the ReleaseSchedule right now - that's enough coloring for me.
[22:18] <skaet> micahg, :)
[22:19] <Daviey> skaet: You might need to setup a colour council to evaulate our options.
[22:19] <stgraber> Daviey: :)
[22:19] <skaet> Daviey, LOL.
[22:21] <skaet> Daviey,  I did consider getting some of the usability team to evaluate my selections, but figured the only criteria I got from the UDS meeting was it had to be readable,  so figured there was a bit of freedom to JFDI.
[22:22] <stgraber> skaet: readable from 30ft on a projector screen seems to be the criteria
[22:23] <skaet> stgraber,  thank you for the clarification.  :)
[22:23] <stgraber> I'm pretty sure Aubergine on Ubuntu Orange doesn't qualify so I'd just skip the ubuntu colors for that one :)
[22:24] <skaet> :)
[22:24] <skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseInterlock
[22:25] <stgraber> should be readable, the yellow-ish background may appear as white on some projectors but at least the text will be readable
[22:26] <skaet> goodness.   criteria met!
[22:27] <skaet> ...or at least until I find a projector and test it properly.  ;)