[01:55]  * xnox ponders if fsharp is what i think it is
[14:08] <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: ^
[16:48] <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:52] <ogra_> slangasek, did you follow https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup ?
[16:55] <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:56] <ogra_> there is some binding magic going on
[17:02] <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:03] <slangasek> xnox: hmm ok
[17:03] <slangasek> in that case it sounds like I do need to push straight to nusakan
[18:09] <xnox> please remove mono/powerpc binaries from xenial-release
[18:09] <xnox> slangasek, ^
[18:11] <doko> xnox, doesn't it build anymore?
[18:27] <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:29] <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:30]  * xnox rebuilds
[18:33] <slangasek> xnox: surely all of the lp builders have "good" kernels at this point, don't they?
[18:33] <xnox> slangasek, nope.
[18:34] <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:37] <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:39] <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:40]  * xnox hands over `--list' to slangasek, and takes away | awk '{ print $2 }'
[18:42] <slangasek> useful, thanks ;)
[18:42] <slangasek> (also makes the sort -u go away)
[18:44] <xnox> right so -fno-pie upload is not needed at all. as building on a good kernel is sufficient.
[19:32] <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:59] <xnox> mono is crazy and kernel has nothing to do with it.
[20:20] <infinity> doko: Eh?  Debian definitely used to have powerpc mono with 3.x, it was dropped with 4.x
[20:21] <doko> infinity, hmm, I thought we were patching that ...
[20:21] <infinity> doko: No, we patched for ppc64el.
[20:26] <doko> right, I remember, the suse patches ...
[20:30] <infinity> doko: Speaking of compilers, have you managed to hunt down why arm64 suddenly hates the kernel source?
[20:31] <doko> infinity, yes it succeeds with an assembler test testing ARMv8.1 instructions and succeeds, while the compiler doesn't yet support them
[20:32] <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:33] <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:34] <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:35] <doko> infinity, can you prepare gibc 2.22 for the end of next for the test rebuilds? or is it to busy?
[20:36] <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:37] <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:38] <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:40] <doko> I thought it would scream at decimal stuff ...
[20:41] <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:46] <slangasek> xnox: s390x debian-cd branch merged and deployed on nusakan
[20:47] <slangasek> kicking off an extra ubuntu-server daily build to see what explodes
[20:48] <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:49] <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:50] <infinity> We can, yeah.  But I intend to get with the kernel team to sort the kernels ASAP.
[21:27] <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:34] <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:35] <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:37] <slangasek> ah... one thing that changed was that cjwatson un-stuck the ftp mirror, I wonder if that would be related
[21:40] <slangasek> 20151209 image was grub +2.02~beta2-31, which dated from 19Nov.  20151210 image is grub +2.02~beta2-32ubuntu1
[21:43] <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:46] <infinity> Yeah, grubx64.efi being 0 length doesn't inspire confidence.
[21:47] <infinity> I suspect this is one of those things Colin would give us on answer on in 2 minutes. :P
[21:49] <slangasek> right the 'Linking' is because they're both empty files and so their md5sums match; not the root cause
[21:50] <infinity> *nod*
[21:50] <slangasek> efi.img isn't the issue, either; it's wherever it's getting bootx64.efi and grubx64.efi
[21:57] <infinity> So, bootx64.efi comes from d-i.
[22:08] <slangasek> ah. who broke d-i?
[22:08] <infinity> Nobody...
[22:09] <slangasek> infinity: ok.  where does it copy it out of d-i?
[22:10] <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:11] <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:12] <slangasek> what happens if we nuke scratch/ubuntu/xenial/daily-live/tmp/xenial-amd64 and rebuild...
[22:13] <infinity> Nuking it should happen before every build anyway.
[22:14] <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:15] <xnox> boot-* scripts usually do the "find latest d-i and download/copy things from it"
[22:19] <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:20] <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:21] <infinity> 404 and 402
[22:23] <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:24] <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:26] <slangasek> yep
[22:26] <xnox> slangasek, https://code.launchpad.net/~xnox/debian-cd/s390x/+merge/280369
[22:27] <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:28] <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:29] <slangasek> infinity: ?
[22:29] <xnox> slangasek, done.
[22:30]  * 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:31] <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:33] <slangasek> xnox: merged, pushed, retrying build
[22:34] <infinity> slangasek: Hah, you added that d-i task half a second before I tried. :P
[22:34] <slangasek> :-)
[22:38] <infinity> slangasek: Alright, tiny brain dump done in the bug.
[22:38] <slangasek> excellent, thanks
[22:42] <infinity> FFS.
[22:43] <infinity> That build also broke.
[22:43]  * infinity investigates harder.
[22:49] <infinity> And, of course, it works from home.  Grr.
[23:08] <infinity> slangasek: Okay, no, there's a real bug here.  Sorting it out now.
[23:17] <xnox> oh.
[23:17] <xnox> stgraber, we need Ubuntu Server s390x product in the iso tracker?
[23:18] <stgraber> probably
[23:19] <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:22] <stgraber> xnox: done
[23:22] <xnox> stgraber, merci beaucoup
[23:24] <xnox> later we will add testcase specific to that image, but the defaults look good for now.
[23:49] <cyphermox> how do the sections work in our archive? would it be very complicated to add a Section: tasks ?
[23:50] <infinity> cyphermox: Err, why?
[23:51] <cyphermox> looking at tasksel merge, seems like the source in there in Debian
[23:52] <infinity> cyphermox: We don't do tasks as metapackages.
[23:53] <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:54] <infinity> tasksel 3.00 is when metapackage tasks happened, which is why we're forked from 2.88
[23:55] <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:56] <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:57] <cyphermox> and I feel like it probably wouldn't hurt to merge anyway, provided it's done correctly
[23:58] <infinity> It's possibly mergable, by dropping all the debian metapackages, keeping our update magic, etc.
[23:59] <infinity> And yes, keeping our Sections.
[23:59] <cyphermox> yeah