| * xnox ponders if fsharp is what i think it is | 01:55 | |
| Mirv | ok click is published to xenial which should make ubuntu-app-launch installable on s390x which should fix xenial finally for good | 14:08 |
|---|---|---|
| Mirv | xnox: ^ | 14:08 |
| slangasek | cjwatson, infinity: what am I missing that pushing to lp:~ubuntu-cdimage/debian-cd/ubuntu fails for me with a 'readonly transport' error? | 16:48 |
| ogra_ | slangasek, did you follow https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup ? | 16:52 |
| slangasek | ogra_: ...no, why would I push to nusakan before pushing to LP and why would anything described there prevent me from pushing to LP? | 16:55 |
| ogra_ | well, thats a cjwatson question then :) | 16:55 |
| ogra_ | there is some binding magic going on | 16:56 |
| xnox | slangasek, lp is a mirror from people.canonical.com =) | 17:02 |
| xnox | This branch is an import of the Bazaar branch at http://people.canonical.com/~cjwatson/bzr/debian-cd/ubuntu. | 17:02 |
| slangasek | xnox: hmm ok | 17:03 |
| slangasek | in that case it sounds like I do need to push straight to nusakan | 17:03 |
| xnox | please remove mono/powerpc binaries from xenial-release | 18:09 |
| xnox | slangasek, ^ | 18:09 |
| doko | xnox, doesn't it build anymore? | 18:11 |
| xnox | doko, debian maintainer remove powerpc architecture... | 18:27 |
| doko | xnox, debian *never* had powerpc binaries | 18:27 |
| xnox | also, please build 4.2.1.102+dfsg2-4ubuntu1 on z13-008 builder with a fixed kernel. | 18:27 |
| xnox | doko, i believe it was enabled in experimental for a while for 4.x series | 18:27 |
| xnox | slangasek, wgrant, cjwatson - mono 4.2.1.102+dfsg2-4ubuntu1 did build correctly on a "good" kernel, could you please retry it on z13-008? | 18:29 |
| * xnox ponders if -no-pie is not needed at all, just a fixed kernel needed. | 18:29 | |
| * xnox rebuilds | 18:30 | |
| slangasek | xnox: surely all of the lp builders have "good" kernels at this point, don't they? | 18:33 |
| xnox | slangasek, nope. | 18:33 |
| slangasek | what's the difference between them? | 18:34 |
| xnox | Kernel version: Linux z13-009 4.3.0-0-generic #9 SMP Tue Dec 1 18:12:15 CET 2015 s390x | 18:34 |
| xnox | bad | 18:34 |
| slangasek | they must all have the basic PIE fixes | 18:34 |
| xnox | Kernel version: Linux z13-008 4.3.0-1-generic #10+wgrant+s390x.1-Ubuntu SMP Thu Dec 3 23:39:27 UTC 2015 s390x | 18:34 |
| xnox | good | 18:34 |
| xnox | slangasek, https://launchpad.net/ubuntu/+source/linux/4.3.0-2.11 is the first good one or better. wgrant prebuilt the cherrypick and deployed it to z13-008. | 18:37 |
| slangasek | xnox: non-trivial arch-dep reverse-dependencies of mono on powerpc; please iterate through these for a clean removal before we drop mono itself: | 18:39 |
| slangasek | $ reverse-depends -a powerpc src:mono | awk '{ print $2 }' | sort -u | xargs apt-cache show | grep-dctrl -FArchitecture amd64 -sPackage | wc -l | 18:39 |
| slangasek | 44 | 18:39 |
| * xnox hands over `--list' to slangasek, and takes away | awk '{ print $2 }' | 18:40 | |
| slangasek | useful, thanks ;) | 18:42 |
| slangasek | (also makes the sort -u go away) | 18:42 |
| xnox | right so -fno-pie upload is not needed at all. as building on a good kernel is sufficient. | 18:44 |
| xnox | oh | 19:32 |
| xnox | my build on ibm vpn was done noopt, rather than just on a fixed kernel. | 19:32 |
| xnox | sigh. | 19:32 |
| xnox | mono is crazy and kernel has nothing to do with it. | 19:59 |
| infinity | doko: Eh? Debian definitely used to have powerpc mono with 3.x, it was dropped with 4.x | 20:20 |
| doko | infinity, hmm, I thought we were patching that ... | 20:21 |
| infinity | doko: No, we patched for ppc64el. | 20:21 |
| doko | right, I remember, the suse patches ... | 20:26 |
| infinity | doko: Speaking of compilers, have you managed to hunt down why arm64 suddenly hates the kernel source? | 20:30 |
| doko | infinity, yes it succeeds with an assembler test testing ARMv8.1 instructions and succeeds, while the compiler doesn't yet support them | 20:31 |
| infinity | Ahh, so it was actually the new binutils that upset it slightly? | 20:32 |
| doko | that's what will appear with the Linaro branch in Jan/Feb | 20:32 |
| infinity | Okay, we can't wait until January to have a buildable kernel. So, where do you proposed we fix this for now? | 20:32 |
| doko | told apw to disable these checks for now | 20:32 |
| infinity | Kay. | 20:32 |
| infinity | (Normally wouldn't care, but we still have linux/meta skew issues on s390x until this is all resolved, and we need to have sane s390x kernels for the upcoming milestone) | 20:33 |
| doko | and ubuntu-toolchain-r/test now has the first gcc-6 packages ... | 20:34 |
| infinity | I saw that, yeah. | 20:34 |
| infinity | I assume that's for xenial+1? | 20:34 |
| doko | yes, and for test rebuilds over the holidays | 20:34 |
| doko | infinity, can you prepare gibc 2.22 for the end of next for the test rebuilds? or is it to busy? | 20:35 |
| doko | infinity, how many cpu's have the s390x buildds? | 20:36 |
| infinity | doko: It's the top of my list to get done before holidays. Should be there before the 17th. | 20:36 |
| infinity | @z13-001:~$ nproc | 20:37 |
| infinity | 4 | 20:37 |
| infinity | doko: 4 cores, 8G, 2G/core. | 20:37 |
| doko | 1h 10 is not bad for the gcc-6 build on s390x | 20:37 |
| doko | (with tests) | 20:37 |
| doko | out | 20:37 |
| infinity | s390x is pretty speedy. | 20:38 |
| infinity | It better be for the price. :P | 20:38 |
| infinity | And it screams at pure integer stuff, since the clock speeds are insanely high. | 20:38 |
| doko | I thought it would scream at decimal stuff ... | 20:40 |
| infinity | Float performance is good too, don't get me wrong, but float insns imply pipe bubbles, generally, so you don't see the same pure linear increase from clock speeds going up. | 20:41 |
| infinity | Pure integer == full pipes == "whoah, dude". | 20:41 |
| slangasek | xnox: s390x debian-cd branch merged and deployed on nusakan | 20:46 |
| slangasek | kicking off an extra ubuntu-server daily build to see what explodes | 20:47 |
| infinity | It'll be less than ideal while the kernel/meta situation is still borked. | 20:48 |
| infinity | But it still might build, just won't install. | 20:48 |
| slangasek | last time it failed at "can I make it bootable" | 20:48 |
| slangasek | let's see if we cleanly get past that now | 20:49 |
| slangasek | if we do, we can always kick off an s390x-only build with -proposed enabled | 20:49 |
| infinity | We can, yeah. But I intend to get with the kernel team to sort the kernels ASAP. | 20:50 |
| slangasek | genisoimage: No such file or directory. cannot read from MD5 list file '/srv/cdimage.ubuntu.com/scratch/ubuntu-server/xenial/daily/tmp/xenial-s390x/md5-check' | 21:27 |
| slangasek | also, /srv/cdimage.ubuntu.com/debian-cd/tools/boot/xenial/common.sh: line 88: MANIFEST.udebs: No such file or directory | 21:27 |
| slangasek | infinity: any idea about bug #1525393? xnox was mentioning a similar thing this morning | 21:34 |
| ubot5 | bug 1525393 in Ubuntu CD Images "xenial secureboot images not signed" [Undecided,New] https://launchpad.net/bugs/1525393 | 21:34 |
| slangasek | not sure at what point this may have regressed | 21:34 |
| infinity | slangasek: No idea. I guess we'd need to trace where that comes from. | 21:35 |
| * infinity hunts a bit. | 21:35 | |
| slangasek | I would have assumed debian-cd was to blame, but no recent changes there | 21:35 |
| slangasek | ah... one thing that changed was that cjwatson un-stuck the ftp mirror, I wonder if that would be related | 21:37 |
| slangasek | 20151209 image was grub +2.02~beta2-31, which dated from 19Nov. 20151210 image is grub +2.02~beta2-32ubuntu1 | 21:40 |
| infinity | I'm not entirely convinced I understand where efi.img comes from in the first place... | 21:43 |
| slangasek | yeah | 21:43 |
| slangasek | also, old logs: touch /srv/cdimage.ubuntu.com/scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64/CD1/.disk/base_installable | 21:43 |
| slangasek | new logs: Linking /srv/cdimage.ubuntu.com/scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64/CD1/./.disk/base_installable to /srv/cdimage.ubuntu.com/scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64/CD1/./EFI/BOOT/grubx64.efi | 21:43 |
| infinity | Yeah, grubx64.efi being 0 length doesn't inspire confidence. | 21:46 |
| infinity | I suspect this is one of those things Colin would give us on answer on in 2 minutes. :P | 21:47 |
| slangasek | right the 'Linking' is because they're both empty files and so their md5sums match; not the root cause | 21:49 |
| infinity | *nod* | 21:50 |
| slangasek | efi.img isn't the issue, either; it's wherever it's getting bootx64.efi and grubx64.efi | 21:50 |
| infinity | So, bootx64.efi comes from d-i. | 21:57 |
| slangasek | ah. who broke d-i? | 22:08 |
| infinity | Nobody... | 22:08 |
| slangasek | infinity: ok. where does it copy it out of d-i? | 22:09 |
| infinity | Trying to figure that out. | 22:10 |
| slangasek | (and how do you know it's from d-i? I don't see this in the build log) | 22:10 |
| infinity | Oh. Maybe it doesn't come from d-i. That might just be for mini.iso | 22:10 |
| slangasek | right, the bootx64.efi file is supposed to be a copy of what's in the shim-signed package | 22:11 |
| slangasek | and grubx64.efi from grub-efi-amd64-signed | 22:11 |
| slangasek | it's the how-they-get-there that's opaque | 22:11 |
| slangasek | what happens if we nuke scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64 and rebuild... | 22:12 |
| infinity | Nuking it should happen before every build anyway. | 22:13 |
| xnox | slangasek, i suspect that i didn't git something right. MANIFEST.udebs should have been retrievied among the d-i kernel/initramfs/paramfile not sure what md5-check is. Thanks for this, will toy with it. I wonder if I can run debian-cd stage locally myself... | 22:14 |
| slangasek | tools/boot/xenial/boot-amd64: | 22:14 |
| slangasek | mcopy -i boot$N/isolinux/grub/efi.img ::EFI/BOOT/BOOTx64.EFI $CDDIR/EFI/BOOT/BOOTx64.EFI | 22:14 |
| slangasek | mcopy -i boot$N/isolinux/grub/efi.img ::EFI/BOOT/grubx64.efi $CDDIR/EFI/BOOT/grubx64.efi | 22:14 |
| slangasek | so that is actually coming from grub/efi.img | 22:14 |
| xnox | boot-* scripts usually do the "find latest d-i and download/copy things from it" | 22:15 |
| slangasek | infinity: so that file is scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64/CD1/boot/grub/efi.img, which is extracted from scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64/cdrom/debian-cd_info.tar.gz | 22:19 |
| infinity | Yeahp, found it. | 22:19 |
| infinity | http://paste.ubuntu.com/13944778/ | 22:20 |
| infinity | Certainly seems a bit suspect. :P | 22:20 |
| slangasek | what are "new" and "old" here? | 22:20 |
| infinity | 404 and 402 | 22:21 |
| infinity | new/grub/mount/efi/boot: | 22:23 |
| infinity | total 384 | 22:23 |
| infinity | -rwxr-xr-x 1 root root 391680 Dec 5 00:51 bootx64.efi | 22:23 |
| infinity | -rwxr-xr-x 1 root root 0 Dec 5 00:51 grubx64.efi | 22:23 |
| infinity | old/grub/mount/efi/boot: | 22:23 |
| infinity | total 2230 | 22:23 |
| infinity | -rwxr-xr-x 1 root root 1289424 Nov 24 07:00 bootx64.efi | 22:23 |
| infinity | -rwxr-xr-x 1 root root 991608 Nov 24 07:00 grubx64.efi | 22:23 |
| xnox | make[1]: Leaving directory `/srv/cdimage.ubuntu.com/debian-cd' | 22:23 |
| xnox | ... checking your mirror | 22:23 |
| xnox | rm -f /srv/cdimage.ubuntu.com/scratch/ubuntu-server/xenial/daily/tmp/xenial-s390x/md5-check | 22:23 |
| xnox | Unknown arch/source s390x! | 22:23 |
| xnox | make: *** [mirrorcheck-binary] Error 1 | 22:23 |
| xnox | hm. | 22:24 |
| infinity | slangasek: It's possible a rebuild of d-i would "fix" it, but I'd kinda like to know why it exploded... | 22:24 |
| slangasek | yep | 22:26 |
| xnox | slangasek, https://code.launchpad.net/~xnox/debian-cd/s390x/+merge/280369 | 22:26 |
| slangasek | xnox: looking. btw, did you catch the fix-up commits I did to make bzr-builddeb plugin not fall over on dpkg-parsechangelog? | 22:27 |
| infinity | Oh, bah. | 22:28 |
| xnox | slangasek, hm? | 22:28 |
| slangasek | xnox: looks like the answer to this is 'no' ;) please merge from trunk | 22:28 |
| slangasek | xnox: the branch has debian packaging in it, the debian/changelog has garbage at the top that makes it unparseable; if bzr-builddeb is installed you can't merge | 22:28 |
| slangasek | infinity: ? | 22:29 |
| xnox | slangasek, done. | 22:29 |
| * xnox goes back to adult size LEGO, IKEA series... | 22:30 | |
| infinity | slangasek: The code in d-i kinda relies on wget actually working. A network blip would have caused this mess. | 22:30 |
| infinity | slangasek: So, yeah, a rebuild will fix it. | 22:30 |
| slangasek | sigh | 22:30 |
| slangasek | ok | 22:30 |
| infinity | I'll just release cyphermox's findutils fix for now, and build against the old kernel ABI so it doesn't get stuck. | 22:31 |
| slangasek | xnox: merged, pushed, retrying build | 22:33 |
| infinity | slangasek: Hah, you added that d-i task half a second before I tried. :P | 22:34 |
| slangasek | :-) | 22:34 |
| infinity | slangasek: Alright, tiny brain dump done in the bug. | 22:38 |
| slangasek | excellent, thanks | 22:38 |
| infinity | FFS. | 22:42 |
| infinity | That build also broke. | 22:43 |
| * infinity investigates harder. | 22:43 | |
| infinity | And, of course, it works from home. Grr. | 22:49 |
| infinity | slangasek: Okay, no, there's a real bug here. Sorting it out now. | 23:08 |
| xnox | oh. | 23:17 |
| xnox | stgraber, we need Ubuntu Server s390x product in the iso tracker? | 23:17 |
| stgraber | probably | 23:18 |
| xnox | stgraber, can you create s390x server image there and mark me as the "manager for it" i guess i will be doing qa for it, at least for the initial few milestones | 23:19 |
| xnox | raise KeyError("Product '%s' not found" % product) | 23:19 |
| xnox | KeyError: "Product 'Ubuntu Server s390x' not found" | 23:19 |
| xnox | http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/xenial/daily-20151211.2.log | 23:19 |
| stgraber | xnox: done | 23:22 |
| xnox | stgraber, merci beaucoup | 23:22 |
| xnox | later we will add testcase specific to that image, but the defaults look good for now. | 23:24 |
| cyphermox | how do the sections work in our archive? would it be very complicated to add a Section: tasks ? | 23:49 |
| infinity | cyphermox: Err, why? | 23:50 |
| cyphermox | looking at tasksel merge, seems like the source in there in Debian | 23:51 |
| infinity | cyphermox: We don't do tasks as metapackages. | 23:52 |
| cyphermox | so you think I should just revert that section change for us? | 23:53 |
| infinity | I think there's probably more to it than that. | 23:53 |
| infinity | And it's entirely possible we don't want to merge at all. | 23:53 |
| infinity | tasksel 3.00 is when metapackage tasks happened, which is why we're forked from 2.88 | 23:54 |
| cyphermox | I'd be tempted to think it just happens that the timing fits, other things haven't been merged in a while. | 23:55 |
| infinity | That one's quite deliberate. | 23:55 |
| infinity | Tasks in Ubuntu come from the Task: header in Packages, which comes from seeds. | 23:56 |
| cyphermox | oh, I know | 23:56 |
| infinity | Which is entirely different from what tasksel >= 3.0 expects. | 23:56 |
| cyphermox | we have delta to handle this | 23:56 |
| cyphermox | I'm not saying you're wrong, just trying to get a clear picture of things | 23:56 |
| cyphermox | and I feel like it probably wouldn't hurt to merge anyway, provided it's done correctly | 23:57 |
| infinity | It's possibly mergable, by dropping all the debian metapackages, keeping our update magic, etc. | 23:58 |
| infinity | And yes, keeping our Sections. | 23:59 |
| cyphermox | yeah | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!