[00:22] <tmartins> Hey guys, jamespage, I'm trying to start "systemctl start gnocchi-api" (Ocata Cloud Archive), and I'm seeing the following error:
[00:23] <tmartins> gnocchi-api[10900]: gnocchi-api: error: unrecognized arguments: --config-file=/etc/gnocchi/gnocchi.conf --log-file=/var/log/gnocchi/gnocchi-api.log
[00:23] <tmartins> Any clue?
[00:23] <tmartins> I manage to run "gnocchi-update" as expected, gnocchi-statsd and gnocchi-metricd are running, gnocchi.conf looks good...
[00:23] <tmartins> But gnocchi-api doesn't run...
[00:24] <tmartins> I think that the "/lib/systemd/system/gnocchi-api.service" that comes wth Ubuntu is wrong...
[00:27] <tmartins> I'm not sure but, looks like that gnocchi-api is a Web App, that runs under Apache2.4, don't know why its package includes systemd files, but no apache confs...   =/
[03:33] <tarpman> nacc: so the deal with tomcat-pki seems to be that 'systemctl start pki-tomcatd' does nothing because systemd thinks it was already started - but it's not running because that was before it was configured
[08:05] <jamespage> tmartins, hey - which Ubuntu release?  I think coreycb and zul have worked on the apache2/mod_wsgi transitions this cycle so it might be fixed for ocata
[08:05] <tmartins> Ubuntu 16.04 + Ocata Cloud Archive
[08:05] <tmartins> staging...
[08:05] <jamespage> tmartins, a load of changes landed very late in newton which did cause some pain - gnocchi is not covered by the automated testing we do for openstack deploys so it might have got missed
[08:06] <tmartins> I see...
[08:06] <tmartins> I really need AutoScaling in OpenStack...
[08:06] <tmartins> Looking forward to use those tools on Ubuntu, like Senlin, Ceilometer, Aodh, Gnocchi...
[08:07] <tmartins> Working to put those things together
[08:07] <tmartins> I'm trying rift.io but, looks very complex.
[08:07] <tmartins> I'll prefer to give a try first, with OpenStack projects.
[08:08] <tmartins> Thanks for your reply!
[08:24] <tmartins> jamespage, I think that I got gnocchi-api to work under apache. It is definitely not a daemon to run via systemd. I used the nova-placement-api as an example...    ;-)
[08:58] <jamespage> tmartins, that's a good guide - keystone, aodh and others work the same way
[08:59] <jamespage> tmartins, projects are in a bit of a transitionary state atm
[09:11] <cking> happyaron, hey, what's the situation with the zfs sync from debian to ubuntu?
[09:56] <tjaalton> doko: mesa in proposed now wants llvm-4.0, can you handle the switch to main and demote 3.9?
[09:58] <doko> tjaalton: no, not now. next week would be better (Thu & Fri afk). Did you check that everything else builds using 4.0?
[09:58] <tjaalton> doko: new libclc does
[09:58] <doko> tjaalton: I don't want to know the success stories ;p
[09:59] <doko> tjaalton: fyi https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/rust/+packages  ... so newer llvm versions for trusty will be fun ...
[09:59] <tjaalton> trusty is not an issue for me at least
[10:22] <ginggs> cjwatson_: hi, are you still interested in #708123 by any chance?  I have an affected machine
[11:28] <cult-> xnox: cool! :)
[11:50] <Odd_Bloke> xnox: Is https://bugs.launchpad.net/cloud-images/+bug/1664367 something that you'd be able to look at?  I know you did the original livecd-rootfs work for s390x.
[11:53] <xnox> Odd_Bloke, yes i can look into that. All of that makes sense, as long as squashfs is not used as the basis for any container-like images.
[11:53] <Odd_Bloke> xnox: *sad trombone* It's used by lxd.
[11:54] <xnox> Odd_Bloke, since s390-tools is a bootloader and makes sense only on things that are booted (e.g. VMs and bare metal)
[11:54] <Odd_Bloke> xnox: Well, MAAS uses the squashfs as well.
[11:54] <xnox> Odd_Bloke, does amd64 squashfs has UEFI grub and grub2?
[11:55] <Odd_Bloke> xnox: http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64.squashfs.manifest is what it has.  (i.e. no)
[11:55] <Odd_Bloke> So it sounds like maybe my diagnosis of the issue is incorrect.
[11:56] <Odd_Bloke> And really curtin/MAAS needs to understand that s390-tools should be installed in to s390x images?
[11:58] <xnox> Odd_Bloke, i did the curtin work too.
[11:59] <xnox> and it totally should install s390-tools before calling zipl (previously it was important and seeded everywhere)
[12:00] <xnox> Odd_Bloke, added a comment to the bug report.
[12:00] <xnox> cpaelzer, ^^^^ squashfs is a base for container images too, hence should not have a bootloader (pointlessly)
[12:00] <xnox> powersj, ^^^^
[12:06] <GunnarHj> chrisccoulson: Hi Chris, pepperflashplugin-nonfree has been fixed in Debian and synced to zesty. Is there any reason to backport that fix and keep update the package in Ubuntu, considering that we have adobe-flashplugin? (Discussion today at bug #1632870.)
[12:06] <Odd_Bloke> xnox: My guess would be that grub ends up in there when the kernel is installed.
[12:06] <Odd_Bloke> xnox: Because the kernel Recommends grub.
[12:08] <Unit193> GunnarHj: adobe-flashplugin is in a repo that by default is disabled, whereas this is in the primary repositories.
[12:10] <GunnarHj> Unit193: True, but why is that significant? This is what we currently say in the desktop guide: https://help.ubuntu.com/stable/ubuntu-help/net-install-flash.html
[12:12] <xnox> Odd_Bloke, kernel cannot know if one needs grub-efi; grub-pc; or grub-legacy
[12:13] <xnox> on s390x it's only s390-tools ever, but we may or may not have /etc/zipl.conf written out for us, before kernel is installed =/
[12:13] <Odd_Bloke> xnox: There's some logic around EFI in curtin.
[12:13] <xnox> apw, should kernel, on s390x, recommend a bootloader? (s390-tools)
[12:13] <xnox> Odd_Bloke, i shall look at curtin.
[12:36] <mdeslaur> Could someone from the SRU team please process the php7.0 packages in the xenial and yakkety queues, please? We are waiting on them as security updates...
[12:42] <mdeslaur> apw, bdmurray, rbasak, stgraber ^
[13:10] <xnox> smoser, is there work started to support curtin for bare-metal support? e.g. for subiquity or not at all yet?
[13:11] <xnox> cause curin will need to learn which network interfaces and hard drives (zfcp and dasd) are requested to be used; and run `chzdev -e` for all of those ids to activate them and make that activation persistent (by generating udev rules)
[13:11] <rbasak> pho7.0> looking
[13:11] <rbasak> php7.0>
[13:11] <xnox> smoser, not sure if this belongs in curtin or subiquity
[13:14] <mdeslaur> rbasak: thanks!
[13:25] <rbasak> mdeslaur, nacc: please see https://bugs.launchpad.net/ubuntu/+source/php7.0/+bug/1658289/comments/4. This doesn't stop us from landing 7.0.15, but we should tweak the changelog. Do you want to handle the security update separately? Or do you still want this SRU in the proposed pockets?
[13:25] <ChrisTownsend> seb128: Hi again:)  Just wondering if you've had a chance to look at libertine in -proposed.  afaict, it's still stuck due to some other libertine packages needing to be promoted from universe to main.
[13:25] <mdeslaur> rbasak: I plan on rebuild in the -security pocket once the SRU has been successful
[13:26] <rbasak> mdeslaur: you mean after 7 days?
[13:26] <mdeslaur> yeah
[13:26] <rbasak> OK. Then I guess I can drop this entry from the changelog.
[13:26] <rbasak> (and re-upload)
[13:26] <mdeslaur> thanks
[13:26] <rbasak> Unless nacc wants to cherry-pick the fix or something?
[13:27] <seb128> ChrisTownsend, oh, sorry, got pulled into other things yesterday and then forgot, I'm going to have a look in a bit, thanks for the reminder
[13:27] <rbasak> mdeslaur: I might wait for nacc to come online if that's OK.
[13:27] <ChrisTownsend> seb128: Ah ok, no worries:)
[13:27] <mdeslaur> I plan on pointing people to -proposed when the mail starts pouring in when I release my php5 updates
[13:27] <ChrisTownsend> seb128: And thanks!
[13:27] <mdeslaur> rbasak: sure, np
[14:36] <cpaelzer> nacc: pitti: would be nice if you could take a look at the prepared stable postgres updates at bug 1664478
[14:37] <cpaelzer> nacc: pitti: especially on the "known to be flaky tests" there is experience required
[14:39] <smoser> xnox, you are the only one who has touched curtin and s390
[14:41] <smoser> perhaps cpaelzer has thought about it.
[15:44] <xnox> NM started to fail to start in adt tests
[15:44] <xnox> quite weird, and blocks a few things.
[15:45] <xnox> cyphermox, do you still touch NM?
[16:02] <nacc> tarpman: interesting... thanks for investigating that
[16:02] <nacc> rbasak: here
[16:02] <nacc> cpaelzer: will do
[16:03] <nacc> cpaelzer: approved the tasks, as well
[16:04] <cpaelzer> thank nacc
[16:55] <nacc> tjaalton: did you see that dogtag-pki failed to build on all archs (10.3.5-7)
[16:56] <tarpman> he acked bug 1664457, so I guess so
[16:56] <cyphermox> xnox: I can look
[16:57] <nacc> tarpman: ah thanks!
[17:00] <xnox> cyphermox, the symptoms are failing adt tests of networkmanager in zesty. And from the logs it "fails to start network-manager-wait-online" on installation =/ with not permitted in the logs.
[17:02] <cyphermox> for zesty?
[17:02] <cyphermox> there was a rerun which looks like it went ok: http://autopkgtest.ubuntu.com/packages/network-manager/zesty/amd64
[17:03] <cyphermox> (i'm not saying this is fixed, but more "what is this mess")
[17:03] <slangasek> kees, mdeslaur, infinity, stgraber: TB meeting?
[17:03] <mdeslaur> slangasek: ack
[17:04] <tjaalton> nacc: yes, still needs tomcat 8.0
[17:05] <tjaalton> even after fixing resteasy
[17:06] <nacc> tjaalton: rather than 8.5, you mean?
[17:06] <tjaalton> yes
[17:06] <nacc> tjaalton: ack, ok, i pinged just now in -release, will see if i can get some traction on that bug today
[19:01] <nacc> rbasak: what's up with php7.0?
[19:11] <zul> bdmurray: ping https://bugs.launchpad.net/ubuntu/+source/aodh/+bug/1645772
[19:11] <cjwatson_> ginggs: interested I guess, but largely lacking in time to deal with it - it'd be a good opportunity to work out how to debug grub!
[19:15] <ginggs> cjwatson: if you gave me some pointers where to start, i might be able to help
[19:15] <bdmurray> zul: hmm?
[19:15] <zul> bdmurray: the SRU passed
[19:16] <cjwatson> ginggs: best thing to do would be to figure out a way to replicate the same situation with a VM (at minimum) or disk image (ideally)
[19:16] <cjwatson> ginggs: grub-fstest can be useful for the latter
[19:17] <cjwatson> ginggs: then it might be possible to work on minimising the test case to a point where it can usefully be debugged
[19:18] <cjwatson> I vaguely remember trying to replicate that once and giving up ...
[19:30] <ginggs> cjwatson: thanks - i'll make a disk image (at least that will give me a backup - i might try to upgrade the mdraid superblock format on the real machine) and see if i can replicate in a VM
[19:31] <cjwatson> I seem to remember it partly being hard because fakeraid is weird
[19:31] <cjwatson> but it was years ago ...
[19:33] <ginggs> i'm not using fakeraid
[19:34] <ginggs> i have an mdraid raid 1 array - array created in 2009 - machine stopped booting after 14.04 -> 16.04 upgrade
[19:38] <ginggs> it comes up with 'error: disk 'mduuid/blahblah...' not found. Entering rescue mode...'
[19:39] <ginggs> i can get it to boot if i set root and prefix to one of the drives
[20:06] <smoser> cyphermox, looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[20:07] <smoser> and knowing you've fought open-iscsi tests... i think its probably best to remove them
[20:07] <smoser> what do you think ?
[20:07] <nacc> smoser: do you think it's worth porting the curtin stuff to open-iscsi's tests?
[20:08] <smoser> nacc, how so ?
[20:09] <cyphermox> smoser: I don't think removing the tests is going to achieve much, this has the benefit of actually testing open-iscsi at least a bit
[20:09] <smoser> i cleaned up a *lot* of the stuff that is in that package
[20:09] <smoser> but still has serious issues that i dont have solutions for
[20:09] <smoser>  https://git.launchpad.net/~smoser/ubuntu/+source/open-iscsi/tree/debian/tests/README-boot-test.md?h=diglett-master
[20:09] <smoser> see 'Caveats' there.
[20:09] <cyphermox> smoser: they could be fixed to work better though, possibly using a different kernel?
[20:09] <cyphermox> s/kernel/root-image
[20:09] <nacc> smoser: as in our tgt spawning logic, etc. or is it the image manipulation that's not working?
[20:10] <smoser> see caveats there.
[20:10] <cyphermox> this is just failing because something craps out in the maas image paths or something
[20:10] <smoser> '1' can be addressed, but takes some engineering to do it.
[20:11] <cyphermox> the download of open-iscsi isn't what broke here.
[20:11] <cyphermox> /tmp/autopkgtest.qCZ79u/build.C9k/open-iscsi-2.0.873+git0.3b4b4500/debian/tests/zesty.d/root-image: not a file
[20:12] <smoser> well, the file isnt there because the download failed.
[20:12] <smoser> becauase 404 Not found.
[20:13] <smoser> the argument of "it tests open-iscsi some" is not valid when it fails 100%  of the time for unrleated reasons.
[20:13] <smoser> i'm not suggesting that we should not test.
[20:13] <smoser> i'm suggesting that we should disable until tests that work can be added.
[20:18] <smoser> nacc, the tgt spawning isnt really a problem, as it all in a vm. we just run tgt on the default port and use it htere.
[20:20] <bdmurray> zul: What happened to ironic?
[20:20] <zul> bdmurray: hmm...good question ill find out
[20:20] <smoser> zul still sings that song all the time bdmurray
[20:21] <zul> smoser: its ironic that i was working on ironic today while listening to ironic dont you think?
[20:22] <smoser> is that actually irony or is that a coincidence. i get the two confused.
[20:33] <nacc> smoser: ok
[21:50] <smoser> pitti, you told me once, but i lost it.
[21:50] <smoser> in a test run by adt, where does one find the package that caused this run
[23:13] <teward> so, any of the packaging experts mind sharing a copy of their .quiltrc?
[23:14] <teward> I apparently lost mine in the upgrade so it's not handling patches right with quilt, so i need to 'redo' my .quiltrc
[23:14] <sarnold> QUILT_REFRESH_ARGS="--diffstat --no-timestamps --backup -p ab"
[23:15] <teward> sarnold: what about for where to put patches, QUILT_PATCHES=debian/patches?
[23:15] <nacc> teward: yeah
[23:15] <nacc> QUILT_NO_DIFF_INDEX=1
[23:15] <sarnold> teward: funny ehnough I almost never need that. I've got this alias that I almost never need:
[23:15] <nacc> QUILT_NO_DIFF_TIMESTAMPS=1
[23:15] <sarnold> alias dq='export QUILT_PATCHES=debian/patches'
[23:15] <nacc> heh
[23:16] <teward> nacc: sarnold: thank you both.  now I have a working quilt again.
[23:16] <teward> *facedesks at forgetting to back it up before nuking and reinstalling*
[23:16] <teward> sarnold: have I mentioned I have a hatred of manually recreating deltas?
[23:16] <teward> it's ***PAINFUL***
[23:17] <sarnold> teward: yup. sometimes retyping a security fix is the only way to get the stupid thing to apply..
[23:17] <teward> sarnold: well, the issue was a missing quiltrc
[23:18] <teward> because if I had that I'd save myself a headache
[23:18] <teward> 'cause the quilt patches wouldn't apply with a direct import from Debian -> MergeInProgress
[23:18] <teward> because it didn't have everything it needed to understand them :/
[23:18] <teward> sarnold: this one's more painful for nginx though
[23:19] <teward> we're at 1.10.3
[23:19] <teward> Debian's at 1.10.2
[23:19] <teward> I have to retroactively copy in Debian's changes
[23:19] <teward> and then up the packaging to 1.10.3.
[23:19] <teward> ***painful***
[23:20] <teward> sarnold: let's just hope this doesn't blow up in my face
[23:20] <teward> after all this work...
[23:24] <Unit193> sarnold: Nice spot with the new motd, that's something nasty.
[23:25] <sarnold> Unit193: what's this?
[23:26] <Unit193> /etc/update-motd.d/50-news, and the new dynamic motd.
[23:26] <sarnold> Unit193: ah! xnox found that. :)
[23:28] <Unit193> Also fun because as it stands, it's implied you can disable it in /etc/default/motd-news, but you actually can't.
[23:36] <teward> i think i fubard
[23:36] <teward> and uploaded to release  by accident :/