apwjibel, looks like autopkgtst broke for linux during setup ?09:46
apwjibel, specifically working for amd6409:47
jibelapw, 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
jibelmaybe we can drop this copy_timeout completely from autopkgtest09:49
=== doko_ is now known as doko
apwjibel, it is 5GB or so, perhaps we can improve the test some, as it makes no sense to run when uploading the kernel09:50
apwjibel, /me asks pitti about it on #ubuntu-devel09:51
Laneyhere comes the alpha freeze09:55
=== 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
Riddellsuperm1: ping, no reply on https://wiki.ubuntu.com/TrustyTahr/Alpha209:59
Riddellutlemming: likewise ↑09:59
LaneyI've only been taking action for those flavours marked as 'yes'10:00
Riddellzequence: ↑10:01
Riddellyes safe to assume they're not in if it's not marked but worth a poke :)10:01
zequenceRiddell: That's correct :)10:03
Riddellzequence: shall I take Howard Chan off as a contact for Studio?10:06
* Riddell does so10:07
zequenceRiddell: Thanks. Can't login there atm10:08
Laneykicked iso rebuilds10:08
Laneyself service after these ones appear10:09
darkxstLaney, why are there no alpha 2 targets on the qa tracker?10:14
LaneyI just made it10:14
Laneythe new images will go in there10:14
Laneyassuming I got it right10:14
didrocksat-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:28
didrocksRiddell: ^11:29
apwthe kernel we uploaded last night (to fix the random oddness with tmpfs as reported by cjwatson) is ready in -proposed11:51
Riddelldidrocks: will it need a respin?11:56
Riddellapw: oh cool11:56
cjwatsonWe should respin for the kernel in any case; the percpu counter problems make it unreleaseable IMO11:56
didrocksRiddell: we are going to respin ubuntu-touch, I don't think it's impacting other flavors as they don't use qt511:56
didrocks(but ubuntu touch isn't in the alpha2 set, so we handle ourself the respin)11:57
Riddelldidrocks: is ubuntu touch part of the alpha? (does it even get releases?)11:57
Riddellok groovy11:57
didrockspre-emptive answer ;)11:57
Laneyfeel free to do the unblocks & handle the respin once the kernel is in11:57
Riddellhow does the kernel get in? dose it just need an unblock on linux?11:59
xnoxRiddell: 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:05
didrocksRiddell: are you handling the unblokcing of at-spi2-core as well? (was still blocked on latest update_excuses.output generation)12:10
Riddelldidrocks: yeah can do12:11
* apw would recommend updating the kernel in any images you are releasing, the -4 seems to be a bit of a lemon12:19
Laneywe'll respin12:19
Laneythe branch says it is unblocked12:23
Riddelldidrocks: at-spi2 in12:54
didrocksRiddell: excellent, thanks!12:54
RiddellLaney: new linux in too, will you do the respins?12:55
LaneyRiddell: you can12:55
Riddelllucky me :)12:55
Laneytick them on the alpha 2 page on the tracker, click request rebuild at the bottom12:55
Laneyassuming you checked that rmadison shows everything12:55
RiddellLaney: rmadison?12:56
Laneyrmadison -S -s trusty linux12:57
cjwatsonmore accurate than LP for the purpose of image builds, indeed12:59
cjwatsonrmadison => "actually visible in published archive"12:59
Riddellmm, still on the old image using my cache from archive.ubuntu.com, so I guess I should wait a bit13:00
=== rtg is now known as Guest18552
cjwatsonRiddell: rmadison is also quicker than waiting for archive.ubuntu.com to update13:05
cjwatson(because the rmadison backend works off ftpmaster.internal, which is also what image builds work off, but archive.ubuntu.com is a mirror)13:05
Riddellbut if i run it on my local computer does that use ftpmaster.internal?13:06
cjwatsonyes, rmadison talks to a CGI script on snakefruit.c.c13:07
Laneyit hits a remote web service13:07
cjwatsonmlankhorst: is glamor-egl-lts-saucy OK to promote to precise-updates?  (no bug)13:33
mlankhorstshould be13:34
mlankhorsttjaalton: ?13:34
cjwatsonthat's what I thought but just wanted to double-check13:34
tjaaltonI've no objections13:35
mlankhorstlet me test on precise real quick13:35
mlankhorstcjwatson: oh right that was just the shlibdeps override, if you can make the cd's now that's fine13:41
mlankhorstyeah did some testing, glamor works13:44
* cjwatson tries to remember how to check13:44
mlankhorstDepends: libc6 (>= 2.14), libgl1-mesa-glx-lts-saucy | libgl113:45
mlankhorstand Xorg starts with my radeon 5570hd glamor, so it's fine13:45
cjwatsonhttp://ci.ubuntu.com/smokeng/precise/alternate/ started passing at around the time we pushed glamor-egl to -proposed13:46
cjwatsonso LGTM13:46
mlankhorstship it13:47
* ogra_ scratches head ... 13:47
ogra_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 it13:48
ogra_oops, that was supposed to land in -devel13:48
mlankhorst       A mere - implies -i.  If no COMMAND, print the resulting environment.13:48
ogra_well, mere means nothing after it, no ?13:49
cjwatsonI think it means as opposed to -optionname13:49
ogra_with something like: chroot "/usr/bin/env - FOO=bar /usr/bin/env"13:50
cjwatsonthe info docs simply list "-" as a synonym for "-i"13:50
ogra_i would expect the FOO var to be added13:50
ogra_(and printed)13:50
ogra_hmm, k13:50
cjwatsonit is, outside a chroot13:50
cjwatson$ env - FOO=bar env | grep FOO13:50
cjwatsonbut the above is an invalid use of chroot13:51
cjwatson$ sudo chroot /var/lib/schroot/chroots/sid-i386 "/usr/bin/env - FOO=bar /usr/bin/env" | grep FOO13:51
cjwatsonchroot: failed to run command β€˜/usr/bin/env - FOO=bar /usr/bin/env’: No such file or directory13:51
cjwatsonbad quoting13:51
cjwatsonif you remove the quotes it works fine13:51
ogra_err, yes13:52
cjwatsonand you can also lose the unnecessary hardcoded paths13:52
cjwatson$ sudo chroot /var/lib/schroot/chroots/sid-i386 env - FOO=bar env | grep FOO13:52
cjwatsonanyway, it'll still behave the same way as -i in terms of not inheriting the environment13:52
ogra_sudo chroot  env - "$(env)" FOO=bar14:00
ogra_that one works14:00
cjwatsonthat looks pretty perilous if any environment variables might contain spaces14:01
cjwatsonwhy are you doing this strange thing?14:02
ogra_i want to keep a valid PATH etc when setting a bunch of env vars in a script14:02
cjwatsonI mean, why not just say   env FOO=bar command?14:02
ogra_and dont want to have to set it every time the scrit chroots14:02
cjwatsonbut chroot passes through the environment14:03
ogra_why does env not show it to me then ?14:03
cjwatson$ diff -u <(sudo env | grep -v ^SUDO_COMMAND=) <(sudo chroot /var/lib/schroot/chroots14:03
cjwatsoner, sorry14:03
cjwatson$ diff -u <(sudo env | grep -v ^SUDO_COMMAND=) <(sudo chroot /var/lib/schroot/chroots/sid-i386 env | grep -v ^SUDO_COMMAND=)14:03
cjwatsonit shows it to me.  you must be doing something wrong ...14:04
ogra_using your "sudo chroot /var/lib/schroot/chroots/sid-i386 env - FOO=bar env " from above only returns FOO=bar14:04
cjwatsonthat's because - wipes the environment, as I told you14:04
cjwatsonthis is why I'm hoping you can tell me what you're actually doing, rather than a constructed example14:04
ogra_i'm trying to write a wrapper around an armhf live-build on an x86 machine ...14:05
cjwatsonright, so live-build's Chroot (as opposed to chroot) function explicitly clears the environment14:05
ogra_exporting PROJECT, ARCH etc before calling the lb commands14:05
ogra_but the testing i do isnt in live build14:06
cjwatsonbut that may not matter here, since if you're just talking about PROJECT/ARCH/etc., those don't need to be passed through Chroot14:06
cjwatsonwhy don't you just export the environment and call lb?  you shouldn't need to do anything special for what you just described14:06
ogra_i call lb inside an armhf chroot14:06
cjwatsondoesn't matter14:06
ogra_and the env doesnt have the vars if i exported them outside14:06
cjwatsonshow me real code that doesn't work14:07
cjwatsonwithout any of this env madnes14:07
cjwatsonbecause in general this *does* work14:08
cjwatsonhave you tried sudo -E?14:10
ogra_uh, heh, no, not yet14:10
cjwatsonor maybe it's worth simply running this whole script as root14:11
cjwatsonit doesn't really seem worth having something that runs as a user but runs sudo around basically everything it does14:11
cjwatsonI'd just ditch the sudos and have a uid check at the top14:11
ogra_hmm, well, let me try the -E ... didnt strike me that it could be sudo14:12
cjwatsonor else have a single uid check that does   exec sudo "$0" "$@"   or similar14:12
ogra_if that doesnt work i'll ditch sudo14:12
cjwatsonsudo -E is configuration-dependent, so it's probably a worse option14:12
cjwatsonit's possible to have sudo set up such that that won't work14:12
cjwatsonbest just to arrange things so that you don't need to pass the environment through sudo14:13
ogra_well, then the self exec via sudo wouldnt work either14:13
ogra_(if sudo was set up like that)14:13
cjwatsonogra_: I believe it always preserves PATH14:16
* ogra_ waits for the result ... 14:17
cjwatsonogra_: 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 environment14:18
ogra_right, i dont care so much about keeping the actual env, but i want a properly working one *and* my vars that i exported14:19
cjwatsonright, so just doing the whole thing inside a single <pick your root escalation method> is best14:19
ogra_yeah, -E definitely works14:20
ogra_thanks !14:20
cjwatsonok, I still think -E isn't the right answer though14:20
* ogra_ will think about the re-exec 14:21
cjwatsonjust a way to confirm that you're on the right track14:21
* ogra_ drops the exit ... lets see if i end up with a tarball :)14:22
ogra_hmm, i should probably have set LB_MIRROR in the environment ...14:32
ogra_lb doesnt like its env14:42
ogra_W: Failure trying to run: chroot //chroot mount -t proc proc /proc14:42
ogra_/usr/sbin/chroot: failed to run command '/usr/bin/env': No such file or directory14:42
ogra_to sad, lb clean and lb config did work fine14:50
ogra_/tmp/chroot/chroot/debootstrap/debootstrap.log has "/usr/sbin/chroot: failed to run command 'mount': No such file or directory"14:50
ogra_which is weird14:51
cjwatsonI expect the key is figuring out where the "//chroot" comes from14:51
cjwatsonthat's probably /$SOMETHING_UNSET/chroot14:52
cjwatsonstick set -x everywhere14:52
ogra_well, thats inside live-build itself ...14:52
ogra_given that the deboootstrap pahse already worked i can only imagine that live-build misses some config in our default setup14:55
cjwatsonI think you should pick a different candidate theory than "live-build is broken"14:56
cjwatsonsince it works fine for e.g. building all our imaegs14:56
ogra_i dont say live-build is broken, i say our livecd-rootfs setup is broken when run standalone :)14:56
cjwatsonI've used it standalone not that long ago14:57
cjwatsonand the BuildLiveCD script is not that complex a wrapper14:57
cjwatsonyou could compare it with what you're doing14:57
=== barry` is now known as barry_
=== barry_ is now known as barry
xnoxcjwatson: 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:10
cjwatsonyou know as much as I do :)15:14
xnoxok =)15:14
cjwatsonlooks fine in chdist ...15:15
xnoxrunning finish.sh with set -x to see which command fails.15:15
LaneyRiddell: AFAICS you can do the respins15:15
xnox(of the click chroot portions) as yeah, normal things look fine.15:15
* Riddell rebuilds alpha 2 flavours15:16
Laneyah we have explicit answers for everything other than cloud15:17
xnoxcjwatson: 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
xnoxdoko: should version numbers match across all of them in http://paste.ubuntu.com/6792203/ ?15:38
dokoxnox, no, built from different sources15:39
dokowhy the "unmet dependencies"?15:40
xnoxdoko: 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
xnoxyet succeeds when "gcc g++ cpp cpp-4.8 g++-4.8 gcc-4.8" is added15:41
xnoxi wonder if gcc-defaults-armhf-cross simply needs a rebuild in saucy.15:42
=== rcj` is now known as rcj
xnoxdo cloud images also need a respin for new kernel?16:25
apwif they have a kernel in then i would16:26
xnoxsmoser: ^ ? i see strange errors when trying to prepare testbeds for adt.16:26
* xnox ENOCLUE how / where cloud images are respun16:26
utlemmingxnox: I can respin16:27
xnoxutlemming: yes, please! =)16:27
smoserk. yeah, please re-spin16:27
* utlemming respins16:27
utlemmingxnox: eta is roughly three or four hours16:27
xnoxutlemming: thank's, i'll look for something else to do in the mean time then.16:28
utlemmingxnox: which kernel should this image have?16:29
utlemmingxnox: thanks16:29
jibelxnox, with 3.13.0-4 in adt VMs, df reports rootfs is full while it is only 15% full and everything fails with ENOSPC16:46
xnoxjibel: ack. So once cloud images respun, all should be well.16:47
jibelfinger crossed16:47
cjwatsonjibel: right, same failure mode as d-i.16:55
utlemmingxnox, 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 look17:01
bdmurrayslangasek or somebody else - could you please review whoopsie in saucy -proposed fixing bug 124552417:01
ubot2`Launchpad bug 1245524 in whoopsie (Ubuntu Saucy) "whoopsie fails to notice/process .upload files on trusty" [High,In progress] https://launchpad.net/bugs/124552417:01
xnoxutlemming: well, i mostly after generic cloud-image.ubuntu.com which ADT uses.17:11
xnoxhttp://cloud-images.ubuntu.com/$RELEASE/$BUILDID ...17:11
=== Ursinha is now known as Ursinha-afk
=== rbasak_ is now known as rbasak
=== Ursinha-afk is now known as Ursinha
slangasekbdmurray: why does this include changes to the debugging CFLAGS in ./Makefile? (CFLAGS=-g3)17:43
slangasekjodh: 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 it17:44
bdmurrayslangasek: hmm, it shouldn't - go ahead and reject it17:44
jodhslangasek: 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
slangasekjodh: you have the power to ask the release team to let it through :)17:45
dokoif you respin packages, please unblock libffi, or unblock it anyway. armhf only fix17:45
slangasekLaney: ^^ I think upstart 1.11-0ubuntu2 should be let through immediately; what do you think?17:46
jodhslangasek: ok, please can someone release it after maybe doing a boot test?17:46
slangasekjodh: I'm assuming you've done a boot test already?17:46
jodhslangasek: I have done one, yes (not tested on all arches as the fix is so generic).17:47
* slangasek nods17:47
LaneyIs it that random reboot fix?17:47
slangasekso I don't intend to retread ground you've already covered17:47
Laneywell, not random, YKWIM17:47
dokoafk now, please consider libffi, see lp #127081617:47
ubot2`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/127081617:47
slangasekLaney: it's the kernel-panic-on-telinit-u fix17:47
jodhLaney: yes, if you want to try it :)17:47
Laneycan't right now17:48
jodhLaney: 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
Laneybut it's fine to unblock it IMO17:48
Laneymaybe someone else could verify and then do thatr17:49
slangasekLaney: ok.  If we're unblocking upstart, should we also unblock the libffi doko asked for, at the same time?17:49
bdmurrayslangasek: reuploaded17:49
Laneyslangasek: fine from an alpha pov - armhf only which we aren't releasing any of17:51
* slangasek nods17:51
Laneyjodh: I just get "ERROR: Another instance of this program is already running" a lot17:52
jodhLaney: yes, there's a fix for that upstream that will end up in the release I hope to do this/next week.17:58
jodhLaney: 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.17:59
Laneyjodh: Nah, it always does it18:01
cjwatsonmlankhorst: another precise-updates question for you: is xserver-xorg-video-nouveau-lts-saucy OK?18:01
mlankhorst~$ grep -i blank /var/log/Xorg.0.log18:05
mlankhorst[    21.213] (==) NOUVEAU(0): GLX sync to VBlank enabled.18:05
mlankhorstseems to be :)18:06
cjwatsonOK, releasing18:06
jodhLaney: 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 fixed18:06
jodhupstream). 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:06
LaneyMaybe I'll wait until I reboot tomorrow :P18:07
jodhLaney: good plan18:07
jodhLaney: 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.sh18:09
Laneyjodh: aha, that works18:15
Laneythere's a few that it cries about18:15
Laneyoh no, it's just racy - that's what you said before I guess18:16
infinityrtg: 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
infinityrtg: 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:24
jodhLaney: ace :)18:28
jodhLaney: so, any invalid jobs?18:28
jodhLaney: hmm, no the new version shouldn't be racy :(18:29
Laneyrunning on old upstart?18:29
jodhLaney: 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:30
Laneyokay, but that'll be a tomorrow job18:31
rtginfinity, I don't think there is any file overlap between the 2 versions, is there ?18:54
rtginfinity, at any rate, I think the previous version has been sufficiently verified.18:58
stgraberif 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)20:47

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!