[09:46] jibel, looks like autopkgtst broke for linux during setup ? [09:47] jibel, specifically working for amd64 [09:49] apw, again :( I'll increase the copy timeout a bit more, but more than half an hour to copy the build tree becomes ridiculous. [09:49] maybe we can drop this copy_timeout completely from autopkgtest === doko_ is now known as doko [09:50] jibel, it is 5GB or so, perhaps we can improve the test some, as it makes no sense to run when uploading the kernel [09:51] jibel, /me asks pitti about it on #ubuntu-devel [09:55] here comes the alpha freeze === Laney changed the topic of #ubuntu-release to: Released: Trusty Alpha 1 | Archive: alpha 2 freeze | Trusty Tahr Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis [09:59] brr [09:59] superm1: ping, no reply on https://wiki.ubuntu.com/TrustyTahr/Alpha2 [09:59] utlemming: likewise ↑ [10:00] I've only been taking action for those flavours marked as 'yes' [10:01] zequence: ↑ [10:01] yes safe to assume they're not in if it's not marked but worth a poke :) [10:03] Riddell: That's correct :) [10:06] zequence: shall I take Howard Chan off as a contact for Studio? [10:07] * Riddell does so [10:08] Riddell: Thanks. Can't login there atm [10:08] kicked iso rebuilds [10:09] self service after these ones appear [10:11] thanks [10:14] Laney, why are there no alpha 2 targets on the qa tracker? [10:14] I just made it [10:14] the new images will go in there [10:14] assuming I got it right [11:28] at-spi2-core is blocked by the alpha2 freeze. it's a revert to yesterday's version as it created crashes with qmlscene in qt5 for touch, can we get it unblocked please? [11:29] Riddell: ^ [11:51] the kernel we uploaded last night (to fix the random oddness with tmpfs as reported by cjwatson) is ready in -proposed [11:56] didrocks: will it need a respin? [11:56] apw: oh cool [11:56] We should respin for the kernel in any case; the percpu counter problems make it unreleaseable IMO [11:56] Riddell: we are going to respin ubuntu-touch, I don't think it's impacting other flavors as they don't use qt5 [11:57] (but ubuntu touch isn't in the alpha2 set, so we handle ourself the respin) [11:57] didrocks: is ubuntu touch part of the alpha? (does it even get releases?) [11:57] ok groovy [11:57] ;) [11:57] pre-emptive answer ;) [11:57] feel free to do the unblocks & handle the respin once the kernel is in [11:59] how does the kernel get in? dose it just need an unblock on linux? [12:05] Riddell: as per http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux yes, linux linux-meta linux-signed debian-installer need unblocking. [12:10] Riddell: are you handling the unblokcing of at-spi2-core as well? (was still blocked on latest update_excuses.output generation) [12:10] unblocking* [12:11] didrocks: yeah can do [12:11] thanks! [12:19] * apw would recommend updating the kernel in any images you are releasing, the -4 seems to be a bit of a lemon [12:19] we'll respin [12:23] the branch says it is unblocked [12:23] oops [12:54] didrocks: at-spi2 in [12:54] Riddell: excellent, thanks! [12:55] Laney: new linux in too, will you do the respins? [12:55] Riddell: you can [12:55] lucky me :) [12:55] tick them on the alpha 2 page on the tracker, click request rebuild at the bottom [12:55] assuming you checked that rmadison shows everything [12:56] Laney: rmadison? [12:57] rmadison -S -s trusty linux [12:59] more accurate than LP for the purpose of image builds, indeed [12:59] rmadison => "actually visible in published archive" [13:00] mm, still on the old image using my cache from archive.ubuntu.com, so I guess I should wait a bit === rtg is now known as Guest18552 [13:05] Riddell: rmadison is also quicker than waiting for archive.ubuntu.com to update [13:05] (because the rmadison backend works off ftpmaster.internal, which is also what image builds work off, but archive.ubuntu.com is a mirror) [13:06] but if i run it on my local computer does that use ftpmaster.internal? [13:07] yes, rmadison talks to a CGI script on snakefruit.c.c [13:07] it hits a remote web service [13:33] mlankhorst: is glamor-egl-lts-saucy OK to promote to precise-updates? (no bug) [13:34] should be [13:34] tjaalton: ? [13:34] that's what I thought but just wanted to double-check [13:35] I've no objections [13:35] let me test on precise real quick [13:41] cjwatson: oh right that was just the shlibdeps override, if you can make the cd's now that's fine [13:44] yeah did some testing, glamor works [13:44] * cjwatson tries to remember how to check [13:45] Depends: libc6 (>= 2.14), libgl1-mesa-glx-lts-saucy | libgl1 [13:45] and Xorg starts with my radeon 5570hd glamor, so it's fine [13:46] http://ci.ubuntu.com/smokeng/precise/alternate/ started passing at around the time we pushed glamor-egl to -proposed [13:46] so LGTM [13:47] ship it [13:47] hmm [13:47] * ogra_ scratches head ... [13:48] why does env - behave the same as env -i in a chroot call ? i thought - keeps the environment (and adds to it) while -i wipes it [13:48] oops, that was supposed to land in -devel [13:48] A mere - implies -i. If no COMMAND, print the resulting environment. [13:49] well, mere means nothing after it, no ? [13:49] I think it means as opposed to -optionname [13:50] with something like: chroot "/usr/bin/env - FOO=bar /usr/bin/env" [13:50] the info docs simply list "-" as a synonym for "-i" [13:50] i would expect the FOO var to be added [13:50] (and printed) [13:50] hmm, k [13:50] it is, outside a chroot [13:50] $ env - FOO=bar env | grep FOO [13:50] FOO=bar [13:51] yeah [13:51] but the above is an invalid use of chroot [13:51] $ sudo chroot /var/lib/schroot/chroots/sid-i386 "/usr/bin/env - FOO=bar /usr/bin/env" | grep FOO [13:51] chroot: failed to run command ‘/usr/bin/env - FOO=bar /usr/bin/env’: No such file or directory [13:51] bad quoting [13:51] if you remove the quotes it works fine [13:52] err, yes [13:52] and you can also lose the unnecessary hardcoded paths [13:52] $ sudo chroot /var/lib/schroot/chroots/sid-i386 env - FOO=bar env | grep FOO [13:52] FOO=bar [13:52] anyway, it'll still behave the same way as -i in terms of not inheriting the environment [13:53] right [14:00] aha [14:00] sudo chroot env - "$(env)" FOO=bar [14:00] that one works [14:01] um [14:01] that looks pretty perilous if any environment variables might contain spaces [14:02] why are you doing this strange thing? [14:02] i want to keep a valid PATH etc when setting a bunch of env vars in a script [14:02] I mean, why not just say env FOO=bar command? [14:02] and dont want to have to set it every time the scrit chroots [14:02] *script [14:03] but chroot passes through the environment [14:03] why does env not show it to me then ? [14:03] $ diff -u <(sudo env | grep -v ^SUDO_COMMAND=) <(sudo chroot /var/lib/schroot/chroots [14:03] $ [14:03] er, sorry [14:03] $ diff -u <(sudo env | grep -v ^SUDO_COMMAND=) <(sudo chroot /var/lib/schroot/chroots/sid-i386 env | grep -v ^SUDO_COMMAND=) [14:03] $ [14:04] it shows it to me. you must be doing something wrong ... [14:04] using your "sudo chroot /var/lib/schroot/chroots/sid-i386 env - FOO=bar env " from above only returns FOO=bar [14:04] that's because - wipes the environment, as I told you [14:04] this is why I'm hoping you can tell me what you're actually doing, rather than a constructed example [14:05] i'm trying to write a wrapper around an armhf live-build on an x86 machine ... [14:05] right, so live-build's Chroot (as opposed to chroot) function explicitly clears the environment [14:05] exporting PROJECT, ARCH etc before calling the lb commands [14:06] but the testing i do isnt in live build [14:06] but that may not matter here, since if you're just talking about PROJECT/ARCH/etc., those don't need to be passed through Chroot [14:06] why don't you just export the environment and call lb? you shouldn't need to do anything special for what you just described [14:06] i call lb inside an armhf chroot [14:06] doesn't matter [14:06] and the env doesnt have the vars if i exported them outside [14:07] show me real code that doesn't work [14:07] without any of this env madnes [14:07] s [14:08] because in general this *does* work [14:10] http://paste.ubuntu.com/6791775/ [14:10] have you tried sudo -E? [14:10] uh, heh, no, not yet [14:11] or maybe it's worth simply running this whole script as root [14:11] it doesn't really seem worth having something that runs as a user but runs sudo around basically everything it does [14:11] I'd just ditch the sudos and have a uid check at the top [14:12] hmm, well, let me try the -E ... didnt strike me that it could be sudo [14:12] or else have a single uid check that does exec sudo "$0" "$@" or similar [14:12] if that doesnt work i'll ditch sudo [14:12] sudo -E is configuration-dependent, so it's probably a worse option [14:12] it's possible to have sudo set up such that that won't work [14:13] best just to arrange things so that you don't need to pass the environment through sudo [14:13] well, then the self exec via sudo wouldnt work either [14:13] (if sudo was set up like that) [14:16] ogra_: I believe it always preserves PATH [14:17] k [14:17] * ogra_ waits for the result ... [14:18] ogra_: and in any case I would expect it to resolve the command using the caller's PATH; nothing to say that that has to be the same PATH as is set in the callee's environment [14:19] right, i dont care so much about keeping the actual env, but i want a properly working one *and* my vars that i exported [14:19] right, so just doing the whole thing inside a single is best [14:20] yeah, -E definitely works [14:20] thanks ! [14:20] ok, I still think -E isn't the right answer though [14:21] * ogra_ will think about the re-exec [14:21] just a way to confirm that you're on the right track [14:21] yep [14:22] * ogra_ drops the exit ... lets see if i end up with a tarball :) [14:32] hmm, i should probably have set LB_MIRROR in the environment ... [14:42] bah [14:42] lb doesnt like its env [14:42] W: Failure trying to run: chroot //chroot mount -t proc proc /proc [14:42] ... [14:42] /usr/sbin/chroot: failed to run command '/usr/bin/env': No such file or directory [14:50] to sad, lb clean and lb config did work fine [14:50] /tmp/chroot/chroot/debootstrap/debootstrap.log has "/usr/sbin/chroot: failed to run command 'mount': No such file or directory" [14:51] which is weird [14:51] I expect the key is figuring out where the "//chroot" comes from [14:52] that's probably /$SOMETHING_UNSET/chroot [14:52] stick set -x everywhere [14:52] well, thats inside live-build itself ... [14:55] sure [14:55] given that the deboootstrap pahse already worked i can only imagine that live-build misses some config in our default setup [14:56] I think you should pick a different candidate theory than "live-build is broken" [14:56] since it works fine for e.g. building all our imaegs [14:56] *images [14:56] i dont say live-build is broken, i say our livecd-rootfs setup is broken when run standalone :) [14:57] I've used it standalone not that long ago [14:57] hmm [14:57] and the BuildLiveCD script is not that complex a wrapper [14:57] you could compare it with what you're doing [14:57] right === barry` is now known as barry_ === barry_ is now known as barry [15:10] cjwatson: is there some uninstallability in Saucy atm? #sdk folks are spotting that click chroot create is failing against saucy http://paste.ubuntu.com/6792074/ [15:14] you know as much as I do :) [15:14] ok =) [15:15] looks fine in chdist ... [15:15] running finish.sh with set -x to see which command fails. [15:15] Riddell: AFAICS you can do the respins [15:15] now [15:15] (of the click chroot portions) as yeah, normal things look fine. [15:16] * Riddell rebuilds alpha 2 flavours [15:17] ah we have explicit answers for everything other than cloud [15:38] cjwatson: adding " gcc g++ cpp cpp-4.8 g++-4.8 gcc-4.8" to the list of packages to install, succeeds. Yet intermediate steps, look like have mismatched version numbers. [15:38] http://paste.ubuntu.com/6792203/ [15:38] doko: should version numbers match across all of them in http://paste.ubuntu.com/6792203/ ? [15:39] xnox, no, built from different sources [15:40] why the "unmet dependencies"? [15:41] doko: it's quite strange. In a saucy-amd64 chroot, with armhf added as foreign arch, apt-get -y --force-yes install build-essential g++-arm-linux-gnueabihf pkg-config-arm-linux-gnueabihf dpkg-cross libc-dev:armhf fails with unmet dependencies. [15:41] yet succeeds when "gcc g++ cpp cpp-4.8 g++-4.8 gcc-4.8" is added [15:42] i wonder if gcc-defaults-armhf-cross simply needs a rebuild in saucy. === rcj` is now known as rcj [16:25] do cloud images also need a respin for new kernel? [16:26] if they have a kernel in then i would [16:26] smoser: ^ ? i see strange errors when trying to prepare testbeds for adt. [16:26] * xnox ENOCLUE how / where cloud images are respun [16:27] xnox: I can respin [16:27] utlemming: yes, please! =) [16:27] k. yeah, please re-spin [16:27] * utlemming respins [16:27] xnox: eta is roughly three or four hours [16:28] utlemming: thank's, i'll look for something else to do in the mean time then. [16:29] xnox: which kernel should this image have? [16:29] 3.13.0-5 [16:29] xnox: thanks [16:46] xnox, with 3.13.0-4 in adt VMs, df reports rootfs is full while it is only 15% full and everything fails with ENOSPC [16:47] jibel: ack. So once cloud images respun, all should be well. [16:47] finger crossed [16:55] jibel: right, same failure mode as d-i. [17:01] xnox, jibel: correct kernel is in the respin. I uploaded the amd64 on Canonistack as utlemming/testing/ubuntu-trusty-amd64-20131213-1390322199 if you want to take a look [17:01] slangasek or somebody else - could you please review whoopsie in saucy -proposed fixing bug 1245524 [17:01] Launchpad bug 1245524 in whoopsie (Ubuntu Saucy) "whoopsie fails to notice/process .upload files on trusty" [High,In progress] https://launchpad.net/bugs/1245524 [17:11] utlemming: well, i mostly after generic cloud-image.ubuntu.com which ADT uses. [17:11] http://cloud-images.ubuntu.com/$RELEASE/$BUILDID ... === Ursinha is now known as Ursinha-afk === rbasak_ is now known as rbasak === Ursinha-afk is now known as Ursinha [17:43] bdmurray: why does this include changes to the debugging CFLAGS in ./Makefile? (CFLAGS=-g3) [17:44] jodh: why are we waiting for the alpha freeze to be over before pushing out upstart 1.11-0ubuntu2? It's a critical bug fix, I think we should just land it [17:44] slangasek: hmm, it shouldn't - go ahead and reject it [17:44] ok [17:45] slangasek: yes, shame it was only reviewed today. I only put that comment on the bug as I do not have the power to progress it personally. [17:45] jodh: you have the power to ask the release team to let it through :) [17:45] if you respin packages, please unblock libffi, or unblock it anyway. armhf only fix [17:46] Laney: ^^ I think upstart 1.11-0ubuntu2 should be let through immediately; what do you think? [17:46] slangasek: ok, please can someone release it after maybe doing a boot test? [17:46] jodh: I'm assuming you've done a boot test already? [17:47] slangasek: I have done one, yes (not tested on all arches as the fix is so generic). [17:47] * slangasek nods [17:47] Is it that random reboot fix? [17:47] so I don't intend to retread ground you've already covered [17:47] well, not random, YKWIM [17:47] afk now, please consider libffi, see lp #1270816 [17:47] Launchpad bug 1270816 in python-cffi (Ubuntu Trusty) "python-cffi tests fail on arm-linux-gnueabihf with glibc-2.18" [High,Confirmed] https://launchpad.net/bugs/1270816 [17:47] Laney: it's the kernel-panic-on-telinit-u fix [17:47] Laney: yes, if you want to try it :) [17:48] can't right now [17:48] Laney: if you are still seeing the problem, either you have an old alsa-utils still, or you have another invalid job. You could try "for i in /etc/init/*; do init-checkconf $i;done" to see which job(s) are invalid. [17:48] but it's fine to unblock it IMO [17:49] maybe someone else could verify and then do thatr [17:49] Laney: ok. If we're unblocking upstart, should we also unblock the libffi doko asked for, at the same time? [17:49] slangasek: reuploaded [17:51] slangasek: fine from an alpha pov - armhf only which we aren't releasing any of [17:51] * slangasek nods [17:52] jodh: I just get "ERROR: Another instance of this program is already running" a lot [17:58] Laney: yes, there's a fix for that upstream that will end up in the release I hope to do this/next week. [17:59] Laney: I think the problem you're seeing is a timing one so if you put a small pause (sleep - shudder) between each call, it should work. [18:01] jodh: Nah, it always does it [18:01] mlankhorst: another precise-updates question for you: is xserver-xorg-video-nouveau-lts-saucy OK? [18:05] ~$ grep -i blank /var/log/Xorg.0.log [18:05] [ 21.213] (==) NOUVEAU(0): GLX sync to VBlank enabled. [18:06] seems to be :) [18:06] OK, releasing [18:06] Laney: just checked the code - the problem with init-checkconf is that you need the new upstream version that runs a session init to test the files. The version you are running is using upstart running against the session bus (an old test facility). However, that no longer works because the current Session Init also connects to the session bus. Although it drops the connection when re-exec'ed due to a bug (that I've also fixed [18:06] upstream). So, you *could* make init-checkconf work for you by running 'telinit u' to make the Session Init disconnect from the session bus. Oh the irony... [18:07] Maybe I'll wait until I reboot tomorrow :P [18:07] Laney: good plan [18:09] Laney: but if you're keen, you could just pull the latest version of init-checkconf from here: http://bazaar.launchpad.net/~jamesodhunt/upstart/use-session-init-for-init-checkconf/view/head:/scripts/init-checkconf.sh [18:15] jodh: aha, that works [18:15] there's a few that it cries about [18:16] oh no, it's just racy - that's what you said before I guess [18:24] rtg: Did we want to consider the previous linux-firmware SRU verified and push it out before I review this one, or did you want this one to supersede the current proposed version? [18:24] rtg: The current one seems as verified as it's going to get, but maybe you intentionally wanted to replace some bits with this upload? [18:28] Laney: ace :) [18:28] Laney: so, any invalid jobs? [18:29] Laney: hmm, no the new version shouldn't be racy :( [18:29] running on old upstart? [18:30] Laney: the new version of that script using the existing upstart _should_ be fine, yeah. If not, feel free to raise a bug on init-checkconf. [18:31] okay, but that'll be a tomorrow job [18:54] infinity, I don't think there is any file overlap between the 2 versions, is there ? [18:58] infinity, at any rate, I think the previous version has been sufficiently verified. [20:47] if anyone was wondering, I'll take care of Newing cgmanager (I already did a pre-upload NEW review, just checking that everything is still in order in the current one)