| slangasek | utlemming: ohai | 00:52 |
|---|---|---|
| slangasek | utlemming: so I just looked at this change of yours... and it can't possibly fix the cause of whatever damage you were seeing | 00:52 |
| slangasek | the only line that's changed now has 6 args instead of 5 | 00:53 |
| slangasek | utlemming: can you point me at a build log, so I can see what was happening? | 00:57 |
| slangasek | https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc is conspicuously lacking in build attempts | 00:57 |
| slangasek | utlemming: as an aside while I'm thinking of it, passing a --modules list to grub-install when you're also passing --uefi-secure-boot is a complete no-op... | 02:03 |
| slangasek | at least, any modules getting installed are unused by the signed uefi bootloader | 02:04 |
| utlemming | slangasek: ack...well, its broken now because of a problem with lxc not installing | 02:04 |
| slangasek | hmm | 02:04 |
| utlemming | slangasek: let me pull the build log.... | 02:05 |
| utlemming | slangasek: https://paste.ubuntu.com/14999303/ | 02:06 |
| slangasek | utlemming: thanks, will dig | 02:07 |
| slangasek | we definitely don't want to just add another argument to the end of that call | 02:07 |
| utlemming | slangasek: right...I was going for the smallest change | 02:07 |
| utlemming | slangasek: but we're blocked right now on https://bugs.launchpad.net/bugs/1543170 | 02:08 |
| ubot5` | Launchpad bug 1543170 in lxc (Ubuntu) "lxc fails to install" [Critical,Triaged] | 02:08 |
| utlemming | slangasek: which looks like invoke-rc.d is needing to detect if its in a chroot w/ systemd | 02:09 |
| slangasek | utlemming: ok so I think you had a race condition, where your failed build used a version earlier than commit 1293 where I fixed this particular problem | 02:10 |
| slangasek | can't say for sure, your build log doesn't show the upstream bzr revision | 02:10 |
| slangasek | but I am pretty sure we both were fixing the same bug :) | 02:11 |
| slangasek | anyway, after fixing that, I have some subsequent failures in my test builds that I'm working through: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/cpc | 02:11 |
| slangasek | once I've resolved these I can have a look at invoke-rc.d if someone else doesn't get to it first | 02:11 |
| xnox | slangasek, btw, i had to create https://launchpad.net/~canonical-foundations/+livefs/ubuntu/xenial/cpc as i cannot trigger ~ubuntu-cdimage builds in upstart-daily ppa, because launchpad ACL. | 02:13 |
| slangasek | xnox: ok :) | 02:13 |
| slangasek | xnox: that's fine, I had to create https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/cpc because I couldn't trigger the cloud one ;P | 02:14 |
| utlemming | slangasek: interesting...haven't see that problem | 02:17 |
| yofel | cjwatson: could you please remove ScottK from the recipient list for the kubuntu image health checks? He doens't want to get those anymore. | 09:14 |
| tjaalton | cyphermox: hmm, there's another d-i upload still unverified which would need to be released first I guess | 09:26 |
| cjwatson | yofel: done | 09:32 |
| yofel | thanks! | 09:32 |
| michi | sil2100: It looks like there is still a problem with s-jenkins. The generic landing jobs are hanging: http://s-jenkins.ubuntu-ci:8080/job/generic-update_mp/ | 10:55 |
| sil2100 | eh | 10:57 |
| sil2100 | hm | 10:57 |
| michi | sil2100: hm? :) | 10:59 |
| davmor2 | michi: It's Polish for pass me the hammer..../me hands sil2100 a hammer | 11:00 |
| sil2100 | Problem is that s-jenkins currently is not really maintained right now | 11:00 |
| michi | davmor2: \o/ Perfect! | 11:00 |
| sil2100 | Not sure who to poke | 11:00 |
| michi | sil2100: Yes, agree that this is a problem… | 11:00 |
| michi | Evan? | 11:01 |
| michi | fginther? | 11:01 |
| michi | It’s not good to just walk away from infrastructure we critically depend on. | 11:01 |
| michi | “Here, you go and do it all yourself from now on. It’ll be much easier.” That just doesn’t quite cut it, I’m afraid. | 11:02 |
| sil2100 | I saw an e-mail from Evan that you can poke them to get operational access to s-jenkins itself, so I wonder if there's anyone doing any maintenance of it right now | 11:04 |
| michi | sil2100: Sorry, me.issed your messag | 11:48 |
| michi | missed your message… | 11:48 |
| michi | I have no idea. | 11:48 |
| michi | but, even with access, I wouldn’t have a clue what to do | 11:48 |
| tjaalton | xserver-xorg-video-amdgpu needs to move to main | 14:08 |
| tjaalton | it's the default driver on newer amd gpu's | 14:08 |
| tjaalton | I added it to xserver-xorg-video-all depends, but didn't realize it wasn't in main yet | 14:09 |
| tjaalton | so now the dailies don't have -video-all or any of the drivers | 14:10 |
| tjaalton | could I save the paperwork and not file a MIR? | 14:10 |
| tjaalton | doko, cyphermox, didrocks: ^ | 14:12 |
| jamespage | if there is a sru team member around ^^ is the original SRU + a fix to limit the memory consumption during the compilation process for arm64, fixing the current ftbfs | 14:29 |
| === barry` is now known as barry_ | ||
| === barry_ is now known as barry | ||
| davmor2 | tjaalton: do we know what is happening in regard to the d-i upload for 14.04.4? We would like to know when we are likely to have a final image to start testing? | 15:00 |
| tjaalton | davmor2: there's a pending SRU | 15:01 |
| tjaalton | so either drop that and upload a new one with just the new diff | 15:01 |
| tjaalton | or add on top of it, but the current SRU is unverified | 15:01 |
| tjaalton | i guess the first option needs to happen ASAP | 15:05 |
| tjaalton | wait, the previous SRU was a no-change rebuild as well.. bah | 15:07 |
| tjaalton | davmor2: I've released the old SRU | 15:09 |
| tjaalton | so now a rebuild.. | 15:09 |
| tjaalton | done | 15:10 |
| jibel | tjaalton, is it the only remaining SRU for 14.04? I see ubiquity 2.18.8.12, doesn't it need to go into this image too? | 15:11 |
| jibel | it's verified | 15:12 |
| tjaalton | jibel: no idea | 15:14 |
| tjaalton | I can have a look | 15:14 |
| tjaalton | infinity: trusty daily image has the right X bits in it and it works (live) | 15:19 |
| tjaalton | so ship it | 15:19 |
| tjaalton | them | 15:20 |
| apw | initramfs-tools is blocked for a test failure in linux (ppc64el). this issue is a known intermittent failure which is kernel not initramfs-tools related | 15:24 |
| apw | i have asked for it to retry but the queue is really long, and the two fixes in this are blocking image generation and | 15:26 |
| apw | is preventing maas images from workgin, which is bleeding through to testing, preventing testing for the kernel | 15:27 |
| apw | i am therefore requesting we hint that test for initramfs-tools | 15:27 |
| smoser | +1. i trust apw to speak for the transient failure. i know that i need the change. | 15:30 |
| tjaalton | jibel: released | 15:33 |
| jibel | tjaalton, thanks | 15:41 |
| Laney | tjaalton: did someone reply about the drivers? | 16:33 |
| * Laney wants fixed images! | 16:33 | |
| tjaalton | Laney: no | 16:33 |
| tjaalton | I'm filing the MIR now | 16:33 |
| tjaalton | just in case | 16:33 |
| Laney | bloop | 16:34 |
| coreycb | hello, can an archive admin please promote python3-novaclient to main? this will help get some of our openstack packages out of dependency waits. | 16:34 |
| slangasek | utlemming: I see that we're past the lxc failure now in cloud-image builds, hurray; now I'm back to the previous failure of 'ln' saying 'livecd.ubuntu-cpc.squashfs': File exists... and I can't see how this worked before or how my code changes would have impacted this | 17:05 |
| utlemming | slangasek: I'm not sure why your hitting this, because my builds based on the fork I just took work | 17:06 |
| slangasek | utlemming: because 032-root-squashfs.binary clearly says it's creating the squashfs in $PWD, not in binary/boot | 17:07 |
| slangasek | hmm so actually, what I don't see is why anything creates binary/boot/livecd.ubuntu-cpc.squashfs | 17:07 |
| slangasek | fun | 17:07 |
| wxl | when we getting 14.04.4 to test? shouldn't today be the day? | 17:52 |
| wxl | i guess i'm pining you about that one according to ReleaseTaskSignup, infinity | 17:53 |
| wxl | also no luck on alternates again cjwatson apw so is it the same problem? http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/xenial/daily-20160209.log | 17:54 |
| cjwatson | wxl: apw fixed it, but only an hour ago so after your build. | 17:55 |
| cjwatson | https://launchpad.net/ubuntu/+source/initramfs-tools/0.122ubuntu3 | 17:55 |
| wxl | okie dokie thanks :) | 17:55 |
| apw | wxl, yeah initramfs-tools got uploaded last night, but held up on test failures | 17:55 |
| wxl | apw: i'll check it out. thanks for your hard work :) | 17:55 |
| infinity | wxl: I'm sending out an announce today about .4 being delayed until next week, but please do test dailies and make sure nothing needs urgent fixing. | 17:56 |
| wxl | infinity: so we'll have images next tuesday the 16th? | 17:56 |
| cjwatson | ah yes, I should have noticed the upload date. should be in place now anyway | 17:56 |
| cjwatson | you probably *just* missed it. | 17:56 |
| wxl | i could have looked at the changelog, too, so sorry for bugging you guys | 17:56 |
| infinity | wxl: I'll probably freeze trusty and flip over to building RCs over the weekend. | 17:57 |
| wxl | infinity: ok, well i'll announce to the ubuntu team to expect something by tuesday or sooner and to start testing now to make sure we don't have any fires | 17:58 |
| slangasek | utlemming: so I think the reason you're not seeing this failure with squashfs is because you're passing some other configuration options to your build. This is suboptimal, as it makes it difficult to have a clean baseline cloud image build in livecd-rootfs for amd64 | 18:21 |
| slangasek | utlemming: but you pass --chroot-filesystem ext4 to your build, overriding the default squashfs; I'm not sure why? | 18:22 |
| slangasek | (except maybe to work around this bug ;) | 18:22 |
| wxl | infinity: permission to edit ReleaseSchedule/ReleaseTaskSignup to match the fact that we'll be releasing 14.04.4 on the 18th? | 18:59 |
| infinity | wxl: Go to town. | 19:00 |
| wxl | infinity: on it. should we expect Beta1 to be kicked out two since it will be the week after? | 19:00 |
| infinity | wxl: Nope, we'll do them back-to-back. | 19:01 |
| wxl | infinity: k cool. thx boss. :) | 19:01 |
| davmor2 | infinity: hey dude how we standing for testing 14.04.4, tjaalton and jibel were talking a d-i and ubiquity landing still to go is the correct as we really need isos to test for tomorrow am or it won't be covered in time | 19:36 |
| davmor2 | jibel: might of hit an issue with the mini.iso no mouse it's only a small issue though right who uses a mouse now anyway right :D I'm double checking it now though | 19:37 |
| davmor2 | but I seem to have a mouse in the live cd so it is boding well, but might be the wily hwe stack at fault from the mini iso | 19:38 |
| davmor2 | jibel: so install from the livecd has mouse working will try the mini.iso again in the morning might be something missing in the archive that is there now or something :) | 19:46 |
| tjaalton | davmor2: yesterdays daily worked fine for me, though i didn't try installing just the live session | 20:07 |
| davmor2 | tjaalton: yeah this is on the mini.iso that installs straight from the archive so that might well be the issue with additional bit landing and using d-i instead of livecd too :) | 20:08 |
| davmor2 | tjaalton: http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/wily-netboot/ | 20:09 |
| tjaalton | ok | 20:09 |
| tjaalton | i was mostly interested that the lts-wily bits were there :) | 20:10 |
| slangasek | utlemming: commit #1302 should fix the problem I'm seeing when doing an ubuntu-cpc build via the public branch, without causing any regressions for you; but you may want to double check this | 21:18 |
| === Noskcaj_ is now known as Noskcaj | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!