[00:54] <smoser> lutostag, this is the installing packages ?
[00:55] <smoser> we will need new daily and released images to get that all the way though
[00:55] <smoser> generally speaking the current images should mostly work, just can't install packages with cloud-init.
[02:47] <Dragon_Buidler> Can i use this to ask questions regarding building a virtual machine?
[03:02] <nacc> Dragon_Buidler: sure (although it's late in teh .us and i'm off ;)
[03:17] <Dragon_Buidler> I can check back in when time is better. Thanks.
[05:44] <[gnubie]> anyone can help me check http://paste.ubuntu.com/23185024/ and identify what causes debootstrap to fail? line 27 is the debootstrap command and it ended right after line 42
[05:49] <PryMar56> [gnubie] show the permissions on /data/build/xenial
[05:49] <PryMar56> ls -al /data/build/xenial
[06:25] <[gnubie]> the /data/build/xenial directory is being created by debootstrap..
[06:25] <cpaelzer> [gnubie]: line 13 ?
[06:26] <cpaelzer> isn't that pre creating the dir
[06:30] <[gnubie]> cpaelzer: it’s 755
[06:31] <[gnubie]> i will add chmod 1777 to /data/build/xenial for testing in my script..
[06:34] <cpaelzer> [gnubie]: I just ran the debootstrap with the dir not existing before and it worked fine
[06:34] <cpaelzer> [gnubie]: you could try that first if it works for you and only then try to resolve any difference in the setup
[06:34] <[gnubie]> directly from cli or via inside a shell script?
[06:34] <cpaelzer> cli
[06:35] <cpaelzer> I just copied your command and it made my /data/build/xenial look good
[06:35] <[gnubie]> yes, that’s what i was having a problem.. if i execute the debootstrap command directly from the cli, it works.. but not if it’s inside my bash script..
[06:36] <cpaelzer> [gnubie]: and that could be your pre-creation of that dir
[06:36] <cpaelzer> [gnubie]: does it fail also if you just run the deboostrap from your script?
[06:37] <[gnubie]> yes, it only fails when executed via script
[06:37] <[gnubie]> i am running my script again but this time, i already added a line with chmod 1777 /data/build/xenial
[06:38] <[gnubie]> same thing..
[06:39] <[gnubie]> it failed on the same line after the “I: Extracting zlib1g...”
[06:39] <cpaelzer> [gnubie]: in script working
[06:39] <cpaelzer> [gnubie]: sudo rm -rf /data/build/xenial; echo '#!/bin/bash' > /tmp/test.sh; echo "debootstrap --verbose --arch amd64 --variant=minbase xenial /data/build/xenial http://archive.ubuntu.com/ubuntu/" >> /tmp/test.sh; chmod +x /tmp/test.sh; sudo /tmp/test.sh
[06:39] <cpaelzer> [gnubie]: drop the mkdir and anything else that pre-creates the dir - debootstrap will do that for you
[06:40] <[gnubie]> hhhmmmm.. ok, for testing..
[06:41] <[gnubie]> please hold on.. i will remove a lot of lines in my script..
[06:43] <[gnubie]> re-running my script again without those lines that pre-creates the directories
[09:39] <rbasak> cpaelzer: good job documenting https://wiki.ubuntu.com/QemuKVMMigration, thank you!
[09:40] <rbasak> cpaelzer: note that I wouldn't call non-LTS releases "development releases". That's confusing because we already use the term for the development release (eg. Yakkety right now)
[09:40] <rbasak> cpaelzer: I'd say stable release, or interim release in an LTS context, or non-LTS release, etc.
[09:41] <rbasak> cpaelzer: does the new scheme mean that an action needs to be taken in qemu every release to add the new machine type?
[10:32] <cpaelzer> rbasak: thanks I'll fix up the names - interim release is better since I need a short abbreviation
[10:33] <cpaelzer> rbasak: and yes it means that every release an action has to be taken (and always was since trusty)
[10:33] <cpaelzer> rbasak: just not as documented as now
[10:33] <cpaelzer> rbasak: which IMHO was why it decayed
[10:33] <rbasak> cpaelzer: I wonder if we can do something to make sure we notice and do it, or do it automatically or something (use lsb_release in a pre-build script to patch in the correct name).
[10:34] <rbasak> It would presumably mean that during the development cycle the machine definition will change, so that might break live migration. But that might be reasonable.
[10:35] <cpaelzer> rbasak: one of the tests I developed can maybe become a autopkgtest to prevent uploads without making a new type
[10:35] <cpaelzer> rbasak: and yes the "in-type" defnition while a devel release cycle is ongoing might change, but that is ok
[10:35] <cpaelzer> yet it would catch completely forgetting to update
[10:36] <cpaelzer> rbasak: I also added quite some doc and a dep3 header to the patch, so that anybody touching it sees it
[11:42] <frickler> what kernel do I need to install on trusty in order to be able to mount an xfs created on xenial? will 3.19 be new enough?
[11:44] <frickler> ah, nevermind, there is linux-image-virtual-lts-xenial now, that should be fine I guess
[12:09] <cpaelzer> rbasak: I now also fixed the "dev" naming in the drawing that was linked - thanks
[12:34] <frickler> so can someone look at https://bugs.launchpad.net/nova/+bug/1621257 and try to decide whether qemu, libvirt or novnc might be the culprit?
[12:35] <frickler> I can reproduce this with a simple devstack instance
[13:32] <coreycb> jamespage, ddellav: rc1's are uploaded for aodh, cinder, glance, horizon, manila, and nova
[13:45] <jamespage> coreycb, awesome
[13:45] <jamespage> coreycb, hows horizon looking?
[13:45] <jamespage> do we need design team time for a refersh?
[13:46] <coreycb> jamespage, I'll take a look
[13:46] <coreycb> jamespage, it was looking ok recently
[13:55] <jgrimm> smb, would you be able to sponsor 1541902?
[13:56] <smb> jgrimm, maybe but I know cpaelzer and/or xnox have been working on qemu updates
[13:56] <jgrimm> smb,  indeed xnox's has landed, cpaelzer is basing his off of mine
[13:58] <MelRay> Hi everyone...I haver never used the network installer and plan on installing iredmail which requires many things not to be installed like maria-db/mysql postfix etc. Does the network installer allow a more customized install so I can avoid some of these packages and let the iredmail script pull them all in for the repos? Or is there a better way to do it with the ubuntu-server .iso?
[13:58] <smb> jgrimm, and he is currently building an ubuntu3 version even
[13:58] <jgrimm> smb, bah.. i hadn't noticed that yet
[14:00] <jgrimm> smb, ok, let me sort out what's going on there first
[14:02] <smb> jgrimm, right... what I also see is that ubuntu1 has not yet cleared proposed. Ok, not preventing another upload but needs special changes handling. Still when there is further stuff in the pipe already its probably worth just to wait and then upload once
[14:02] <xnox> smb, jgrimm, note my qemu is stuck in proposed at the moment...
[14:03] <smb> xnox, I did note :)
[14:04] <jgrimm> indeed. thanks guys. i'll go into holding pattern
[14:44] <dusty225> administering apparmor or selinux? which one will cause you to slam your monitor into the wall first?
[14:50] <patdk-wk> selinux
[14:50] <patdk-wk> apparmor is simple
[14:50] <patdk-wk> if you like acl's, use selinux
[14:50] <patdk-wk> if you want config files, use apparmor
[14:51] <dusty225> thank you
[14:51] <dusty225> would you consider apparmor a required security measure for a server and that your an idiot if you dont use it?
[14:52] <patdk-wk> depends on many things
[14:52] <patdk-wk> it is an extra layer
[14:57] <joelio> profiles for selinux on ubuntu are sketchy
[14:57] <joelio> apparmor is a "1st class citizen"
[14:58] <joelio> then there's grsec too with it's rbac ;)
[14:59]  * joelio installs a fresh 4.7.4 grsec kernel
[15:11] <Smurphy> Anyone can explain me, or provide me a link on how to limit the number of ttys to 2 ? Seems that it is handled dynamically upon request.
[15:11] <Smurphy> And it also seem to prevent rsyslog to write data to tty4.
[15:27] <patdk-wk> just disable them in systemd
[15:28] <Smurphy> Hmmm. I thought I already tried. Didn't work.
[15:29] <Smurphy> You have a link to it? I am rather one of the old school guys using sysVinit ...
[15:29] <Smurphy> I think I got it.
[16:01] <rbasak> lamont: I spent some time on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744304. It's legit, and the suggested "RemainAfterExit=yes" line fixes the problem completely. Can we get that pushed to git and uploaded, and I can sync to Yakkety?
[16:02] <rbasak> lamont: looks like I can upload, but I can't push to git. Do you want me to send you git-format-patch output or something?
[16:14] <lamont> rbasak: git-format-patch would be awesome, I should be able to do the whacky-thump in pauses in my day today
[16:17] <rbasak> ack, thanks
[17:03] <rbasak> cpaelzer: is bug 1577596 one of the ntpdate ones you were tracking?
[17:12] <rbasak> lamont: you have mail. Also, did you forget to push your tags for P4-9 and P4-10? And there's a P4-10.1 NMU that needs acknowledging, importing to git and pushing.
[17:13] <lamont> rbasak: sigh.  I'll get things cleaned up there
[17:13] <lamont> thanks for the reminders
[17:13] <rbasak> No problem. Let me know if I can do anything more to help.
[17:13] <lamont> it'll be later today though, possibly tomorrow worst case.
[17:14] <lamont> will highlight you when done
[17:14] <rbasak> ack, thanks
[18:42] <cpaelzer> rbasak: no 1577596 was not on my list yet
[18:42] <cpaelzer> rbasak: it is another case of dump ntpdate and use timesync as intended :-/
[18:42] <cpaelzer> IMHO
[18:45] <SpudDogg> hello all, i am trying to set up a deb mirror.  however, this page does not show what key(s) i would need for xenial https://help.ubuntu.com/community/Debmirror
[18:45] <SpudDogg> any ideas?
[19:28] <powersj> SpudDogg, is your question coming from the where it tells you to import the keyrings?
[19:34] <SpudDogg> powersj: yes, but i think im just going to use apt-mirror instead
[19:35] <powersj> ok :)
[19:35] <powersj> What I believe you were looking for is that the keys are kept in ubuntu-archive-keyring.gpg
[19:35] <SpudDogg> ya that was what i needed
[19:36] <SpudDogg> thanks powersj
[19:40] <rbasak> cpaelzer: agreed, we should link to the ML thread, etc.
[20:40] <jgrimm> hallyn, would you have time for a qemu upload sponsorship?
[20:42] <jgrimm> hallyn, 1541902 if so, else I'll poke others next week
[20:57] <hallyn> jgrimm: i'll find time before next week - thanks
[21:03] <jgrimm> hallyn, you rock. thank you sir!
[21:11] <hallyn> urg, someone uploaded 1:2.6.1+dfsg-0ubuntu1 without updating the debian tree :)
[21:11] <hallyn> will sort that out later
[21:11] <hallyn> jgrimm: this has been tested right?  is it the same one i tested before?
[21:12] <jgrimm> exactly the same patches, but rebased on 2.6.1 (which happens to be the version that IBM originally tested the patches on)
[21:12] <jgrimm> and yes
[21:12] <hallyn> kthx - \o
[21:12] <jgrimm> thank you!
[22:07] <nacc> hallyn: ack on the debian git tree, i have it on my backburner action item to document that process