[02:25] <DarthFrog> Hi folks.  I was wondering, is there an info to be had about installing & booting Ubuntu Server from ZFS?
[02:26] <sarnold> DarthFrog: give this a look https://github.com/zfsonlinux/zfs/wiki/Ubuntu-16.04-Root-on-ZFS
[02:26] <DarthFrog> Thanks!
[03:25] <smoser> bdmurray, shoot. i realized i never responded to you.
[03:25] <smoser> i can upload to yakkety
[03:32] <smoser> should be uploaded as soon as local sbuild finishes
[03:35] <smoser> done.
[05:09] <stgraber> barry: just uploaded a fixed autopkgtest to the archive (adds support for LXD storage API). If that resolves the failure with LXD 2.9, it'd be great if you could push that fix to Debian so we can sync again.
[09:17] <tjaalton> Laney: I've kicked several dogtag-pki autopkgtests, but looks like freeipa test on dogtag-pki/i386 is somehow in limbo and just shows "in progress" while it clearly is not
[09:18] <tjaalton> oh sorry
[09:18] <tjaalton> now it's running :P
[09:18] <tjaalton> damn. the queue was empty though
[09:22] <Laney> hehe
[09:23] <tjaalton> I'll kick the rest
[09:23] <Laney> if you wait for dogtag-pki itself to migrate you'll have an easier time getting the new ones to pick that version up
[09:24] <Laney> good work on the tests btw
[09:24] <tjaalton> yeah
[09:25] <tjaalton> I'll wait for that.. then work on freeipa which seems to have some issues still :/
[09:44] <caribou> rbasak: nut's ftbs, looking at it
[10:02] <rbasak> caribou: thanks!
[10:02] <Laney> tough nut to crack
[10:03] <caribou> rbasak: looks like it's a dh_makeshlibs issue : http://pastebin.ubuntu.com/24012671/
[10:06] <rbasak> caribou: yeah it seems to end up with extra symbols on ppc64el which aren't part of the ABI
[10:07] <rbasak> I'm not sure I understand why.
[10:08] <caribou> rbasak: dunno where that cruft comes from indeed
[10:08] <rbasak> I've seen it in other packages.
[10:08] <rbasak> It seems wrong to just stuff those lines in libnutclient0.symbols.
[10:08] <rbasak> doko: ^ any advice please?
[10:08] <caribou> rbasak: I get the same error in a PPA
[10:08] <caribou> rbasak: doko is out today afaik
[10:13] <caribou> rbasak: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831725
[10:19] <caribou> rbasak: fix is in though
[10:26] <cult-> xnox: Boris hasn't yet responded on the ticket. I could only verify the base odb package. is there anything i can do?
[11:10] <tsdgeos> oh man our zesty libreoffice still crashes because the version mismatch between apps and l10n is still there
[11:10] <tsdgeos> are we going to fix that or should i just go the snap way that seems to have the newer version anyway?
[12:19] <caribou> Is there a reason why dpkg-gensymbols would behave differently on ppc64el ?
[12:20] <caribou> it appends the full version string (with the ubuntu1 suffix) on ppc64el and does not on amd64
[12:21] <caribou> here is the diff of the debian/libnutclient0/DEBIAN/symbols files b/w amd64 & ppc64el builds : http://paste.ubuntu.com/24013220/
[12:22] <caribou> rbasak: I suspect that this is why nut build is failing on ppc64el
[12:24] <infinity> caribou: That just means the symbols files in the package are wrong.
[12:24] <infinity> caribou: And don't list ppc64el where they should.
[12:31] <caribou> well, it's in the debian buildlog as well, so might not be why it fails
[12:32] <infinity> It is why it fails.
[12:33] <infinity> At least one of the symbols is obviously jumping out.  Lemme dig a bit.
[12:34] <caribou> infinity: here is the debian buildlog : https://buildd.debian.org/status/fetch.php?pkg=nut&arch=ppc64el&ver=2.7.4-5&stamp=1485336450&raw=0
[12:39] <infinity> caribou: Not sure why our toolchains differ to make that not fatal in Debian, but our behaviour is more correct. :P
[12:40] <caribou> infinity: good to know
[12:40] <infinity> caribou: Tossing a build at ppa:adconrad/staging to see if I got all the bits.
[12:41] <ginggs> infinity, caribou: new symbols aren't fatal, dropping symbols is
[12:42] <ginggs> ppc64el defaults to -O3 in Ubuntu
[12:42] <ginggs> some symbols might be being optimized away
[12:42] <infinity> Oh, indeed, I missed the MISSING line.
[12:43] <caribou> infinity: could come from here : http://paste.ubuntu.com/24013303/
[12:43] <caribou> that's the bug I mentionned earlier
[12:58] <infinity> caribou: https://launchpad.net/ubuntu/+source/nut/2.7.4-5ubuntu2
[12:58] <caribou> infinity: yep, got it but it faiild
[12:58] <caribou> failed
[12:59] <caribou> infinity: looking at your diff atm
[12:59] <infinity> The part where nut is leaking half of stdlib through its ABI is ridiculous.
[13:00] <infinity> So, yes, -O3 generates slightly different stdlib grossness, and ppc64el becomes a unique snowflake on Ubuntu.
[13:00] <infinity> The other option would be to drop optimisation to -O2.
[13:00] <infinity> The best option would be to fix libnutclient0 to stop leaking stdlib.
[13:01] <infinity> Anyhow, this works for now.
[13:02] <fossfreedom_> seb128: sorry to keep bothering... - beta 1 is next week.  Any chance that our gnome-menus patch (bug 1631745) could be pushed before the beta build on Tuesday? TIA
[13:03] <infinity> caribou: So, all the lines where I added ppc64el to some amd64 bits, those can be upstreamed to Debian.
[13:03] <caribou> infinity: k
[13:03] <infinity> caribou: Where we're unique is that top line with the mangled ppc64el-only stdlib thing, and near the end, with the !ppc64el added to a demangled stdlib thing. :P
[13:04]  * infinity ponders a nap.
[13:05]  * caribou ponders a meal
[13:05] <seb128> fossfreedom, not today, I've too much to do and need to call it day early but I'm not the only sponsor around
[13:05] <seb128> fossfreedom, I can have a look on monday otherwise
[13:06] <fossfreedom_> seb128: thanks - ask on motu?
[13:06] <seb128> they probably don't have upload rights for main?
[13:07] <seb128> no, the channel we are on is good
[13:07] <seb128> but it's not easy to find people wanted to do sponsoring nowadays :-/
[13:11] <fossfreedom_> thanks.  Anyone around who is able to upload to main and is willing to sponsor a very import fix for Ubuntu Budgie please? bug 1631745
[13:11] <jamespage> ratliff, hello
[13:12] <jamespage> ratliff, the python-crypto security update to 2.6.1-6ubuntu0.16.04.1 in xenial has a bit of a knockon into paramiko
[13:13] <ratliff> jamespage: ask working on it, I will release a regression fix asap
[13:14] <ratliff> jamespage: thanks for letting me know
[13:14] <jamespage> ratliff, just found the bug report for paramiko !
[13:14] <jamespage> ratliff, CTR mode needs counter parameter, not IV
[13:14] <jamespage> ratliff, no not that on
[13:14] <jamespage> ratliff, https://bugs.launchpad.net/ubuntu/+source/paramiko/+bug/1665565
[13:14] <jamespage> beisner, ^^
[13:15] <beisner> ack thx jamespage
[13:43] <popey> hello! apparently http://gb.archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/vmlinuz doesn't boot under Xen anymore, but the trusty and xenial ones do. Where should this be reported?
[13:55] <Odd_Bloke> popey: That file hasn't changed in ~5 years, so I'd be surprised if that specific path was the issue.
[14:18] <smb> popey, the question might be under what version of Xen. I could imagine hypervisor changes happening which might result in old kernels failing with newer hypervisor versions. tbh with precise I would be tempted to hide somewhere until April
[14:26] <popey> Odd_Bloke: smb I'm told in Xen 4.4 (which is in debian stable) is breaks.
[14:28] <popey> hm, it's possibly it's always been broken, friend said he only just discovered it.
[14:30] <smb> That I could believe. Not sure why there is a special image anyway. At least for Precise onwards I believe the normal kernel should just work
[14:33] <popey> Ok. Thanks.
[14:44] <barry> stgraber: 4.3ubuntu1?
[14:46] <Henning__> Is there any way to get this into zesty: https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1655782 ?
[16:40] <teward> arges: cyphermox: either of you know whether there was any progress on https://bugs.launchpad.net/bugs/1600452 ?  Someone on Ask Ubuntu is asking if/when this fix will be available to backport into older releases.
[16:40] <teward> and I haven't seen any progress on that since Sept. in the comments.
[18:33] <cyphermox> teward: it always takes a while, this requires a new shim to be signed.
[19:10] <smoser> hey. open-iscsi at http://autopkgtest.ubuntu.com/running#pkg-open-iscsi
[19:10] <smoser> is there a way to get the full log of that ?
[19:11] <smoser> or do i just have to wait till it fails (neither of those are going to finish, the hang has occurred)
[19:17] <nacc> slangasek: infinity: re perl and libembperl-perl, it's a testcase regression (I think) where if PERL_DL_NONLAZY=1 is set, we get a redefinition warning from the DynaLoader module. Is it normal for DynaLoader.pm to be in both /usr/lib/x86_64-linux-gnu/perl/5.24.1/ and /usr/lib/x86_64-linux-gnu/perl-base/ ?
[19:18] <nacc> I guess so, nm, it's that way in yakkety (allowing for version difference) too
[19:26] <nacc> slangasek: infinity: ok, so I ran the libembperl-perl testcase against the release pocket and it also fails
[19:29] <fossfreedom> Hi all - I asked this earlier - but just in-case someone who didnt see ...  Anyone around who is able to upload to main and is willing to sponsor a very import fix for Ubuntu Budgie please? bug 1631745
[19:32] <nacc> fossfreedom: i can look
[19:32] <fossfreedom> much appreciated!
[19:35] <nacc> fossfreedom: the patch from Feb. 10, I assume
[19:36] <fossfreedom> yes - comment 19
[19:45] <nacc> fossfreedom: sponsored
[19:45] <nacc> fossfreedom: note that i think there is no actul task for budgie-desktop itself?
[19:45] <fossfreedom> nacc: \o/
[19:46] <fossfreedom> correct - nothing specifically for budgie-desktop - but its budgie-desktop that crashes due to this bug in gnome-menus
[19:46] <nacc> fossfreedom: ack, i'll mark it as fix committed there too then
[19:46] <nacc> fossfreedom: it'll need to be manually updated to fix-released when gnome-menus migrates
[19:46] <fossfreedom> no worries - I'll handle.
[19:47] <nacc> fossfreedom: thanks!
[19:48] <nacc> xnox: i saw your rebuild for liblog4ada -- I don't understand how/why it's still out of date. Do you know ada? :)
[21:09] <kyrofa> Where might I find the manifest for ubuntu server (amd64)?
[21:09] <kyrofa> Xenial, specifically
[21:09] <kyrofa> I see the ones for the desktop on http://releases.ubuntu.com/xenial/, but no server
[21:10] <dobey> kyrofa: the manifest of the ISO, or do you mean the bits that genrate the ubuntu-server meta-package?
[21:10] <ogra_> kyrofa, http://cdimage.ubuntu.com/ubuntu-server/xenial/daily/current/
[21:10] <ogra_> they seem to not go to releases.u.c for some reason
[21:10] <dobey> yeah and desktop iso isn't on cdimage for some reason
[21:10] <dobey> no idea why
[21:11] <kyrofa> dobey, ogra_ haha, perfect, thanks guys
[21:12] <ogra_> dobey, just a bit hidden http://cdimage.ubuntu.com/xenial/daily-live/
[21:12] <ogra_> or s/xenial// for zesty
[21:14] <dobey> ogra_: i mean, the release ISOs aren't in the like 16.04.1 release directory on cdimage, but the server ISOs are
[21:14] <ogra_> ah, yeah
[22:19] <infinity> dobey: Eh?
[22:20] <infinity> dobey: "the release ISOs aren't in the like 16.04.1 release directory"?
[22:20] <infinity> dobey: x86 goes to releases, ports go to cdimage.
[22:21] <infinity> dobey: The "server ISOs are on cdimage" bit you're seeing are !x86.
[22:26] <dobey> oh
[22:27] <dobey> well when looking for *desktop* i wasn't even paying attention to what archs were there, only that desktop wasn't
[22:29] <infinity> cdimage could probably do with a top-level index header with wordy explainy things, like releases but backwards.
[22:29] <dobey> or *gasp* cdimage could have all the images ;)
[22:29] <dobey> but meh
[22:29] <infinity> "Here's where we host ports arches, unsupported images, and daily builds, for Canonical-supported x86 images, go -> here"
[22:30] <infinity> It perhaps could do.  But then people might start using it as their primary download source.
[22:30] <infinity> Which would be expensive.
[22:31] <infinity> The point of releases/archive versus cdimage/ports is that the former is what 95% (99%?) of our users use, so it's a small set of bits, widely-mirrored.
[22:32] <dobey> well, could have redirects to releases. the "physical" location of the ISOs i don't care much about. just want one listing of everything :)
[22:33] <dobey> yeah, i get that. i'm not complaining (much). just confused whenever i go there and don't remember the split
[22:33] <dobey> so meh
[22:35] <dobey> anyway, time for me to fly, as it were. later :)
[23:01] <nacc> so puppet is failing in z-p (has been for some time) because (I think) `puppet cert print $(hostname --fqdn)` complains about no certificates. I'm not sure how this is supposed to work if there's no guarantee that certificates are installed/configured somewhere in the tests themselves and I can reproduce this in a Sid lxd (although ci.debian says it did pass there before)
[23:02] <nacc> I'm not entirely sure what is recommended here
[23:26] <nacc> are quote exceeded messages in autopkgtest logs a concern? e.g. the linux autopkgtest for pciutils (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/l/linux/20170217_124537_d30e3@/log.gz)
[23:26] <nacc> ogasawara: --^ or is the RTC timeout a known issue for the kernel test?