[00:13] <IShavedForThis_> shit. I disconnected. did anybody respond?
[00:15] <ChmEarl> IShavedForThis_, use the single ubuntu-server iso and install it with preseed. Works in Xen and kvm
[00:16] <ChmEarl> 5-6 minutes max. Nobody else responded while you were out
[00:16] <oerheks> some ideas of security https://www.thefanclub.co.za/how-to/how-secure-ubuntu-1604-lts-server-part-1-basics
[00:17] <IShavedForThis_> thanks man. I already have ubuntu server installed and it is used for plex, and other home things, what I want to do is just take maybe 5gb's from one of my drives and place a virtual instance on that
[00:17] <IShavedForThis_> to make a game server. and since I will have mods/admins I don't want anybody to be able to somehow get around the virtual instance and into my actual machine
[00:19] <oodani> Hi! I'm having some trouble upgrading my ejabberd installation, and I think it's caused by AppArmor? I'm running 16.04.2 LTS and just tried to install the ejabberd 17.04 package from https://jabber.at/p/apt-repository/  and now it won't launch - it's vague about what's wrong in systemctl status, but in journalctl, I'm seeing warnings like apparmor="DENIED" operation="open" profile="/usr/sbin/ejabberdctl" name="/usr/lib/". Any idea why this would be
[00:19] <oodani>  happening? The new ejabberd package does still contain an AppArmor profile, so it should be one that works.
[00:19] <IShavedForThis_> i'm on 16.04.2lts server by the way.
[00:43] <oodani> Huh. I managed to fix that by adding "/usr/lib/ r," to my local include for that AppArmor profile. Not totally sure why that's necessary to make ejabberd and AppArmor play nicely, but there you go. (It still didn't wanna launch, but that was my fault for getting ejabberd.yml wrong. :P )
[00:43] <IShavedForThis_> nice! I would've helped if I knew anything about it lol
[00:44] <oodani> :)
[01:37] <nergar> Hello, I have some general docker questions, anyone minds if I ask here? #docker is kinda dead
[01:40] <teward> nergar: not sure we're the best place for docker questions, a ton of those questions exist in FAQs on the Internet already
[01:40] <teward> and unless your question is related to docker on ubuntu server, this is probably not the place to ask
[04:41] <cpaelzer> good morning
[04:53] <lordievader> Good morning
[05:26] <cpaelzer> rbasak: hiho, please ping me once you are around
[05:26] <cpaelzer> rbasak: After the last update I'm more lost than ever on the ubuntu-virt package bug you had :-)
[10:00] <rbasak> cpaelzer: ping
[10:19] <cpaelzer> rbasak: hiho, are you avail for a HO?
[10:21] <cpaelzer> now I finished my current item, context switch ready :-)
[10:22] <cpaelzer> rbasak: I'll send you a link and invite
[10:22] <rbasak> ack
[11:40] <zioproto> coreycb: hello, I am looking at this repo: https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/python-cinderclient
[11:41] <zioproto> coreycb: why there is only stable/ocata ? I can find any older stable branch
[11:41] <zioproto> my goal is to refresh the package to include https://review.openstack.org/#/c/462204/ in stable/newton
[11:43] <zioproto> what would be the right repo to patch for  python-cinderclient                  1:1.9.0-0ubuntu1~cloud0 ??
[11:43] <zioproto> jamespage: maybe you also know the answer to this
[11:44] <jamespage> zioproto: good question
[11:45] <jamespage> zioproto: I would suspect that @newton we where sufficiently aligned with debian that alot of deps for openstack where just syncs from Debian unstable
[11:45] <zioproto> later bazaar repo is liberty
[11:45] <zioproto> Mitaka and Newton are missing
[11:46] <zioproto> but the version is 1:1.9.0-0ubuntu1~cloud0
[11:46] <zioproto> that ~cloud0 means it was built from the cloud archive, no ?
[11:48] <zioproto> I try to explain my self better
[11:48] <jamespage> zioproto: pushed a stable/newton branch with 1:1.9.0-0ubuntu1
[11:48] <zioproto> oh great !
[11:48] <jamespage> zioproto: you won't normally find a ~cloudX version in a git repo - that's a auto-backport version
[11:48] <jamespage> zioproto: remember that all openstack pkgs come from Ubuntu initially - newton sources from yakkety
[11:49] <zioproto> ok
[11:50] <zioproto> perfect, looks like everything is there now
[11:50] <zioproto> also the new tarballs in pristine-tar
[11:50] <zioproto> I will try to compile
[11:50] <zioproto> the new package
[12:05] <cpaelzer> thanks rbasak I experimentally created my own ubunut-meta content generated via germinate now
[12:05] <cpaelzer> more puzzles fall into place - thanks for the right hints where to start
[12:16] <rbasak> cpaelzer: you're welcome. Sorry my comment was misleading.
[12:18] <ahasenack> which team would triage this bug, kernel? https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1685528
[12:18] <ahasenack> it's a userland zfs issue
[12:19] <ahasenack> or foundations, since it's initramfs related?
[12:22] <zioproto> jamespage: https://code.launchpad.net/~zioproto/ubuntu/+source/python-cinderclient/+git/python-cinderclient/+merge/326291
[12:24] <cpaelzer> ahasenack: kernel IMHO
[12:25] <cpaelzer> ahasenack: being a "FS thing"
[12:25] <ahasenack> ok
[12:25] <cpaelzer> ahasenack: also looking at the PPU permissions I see cking
[12:25] <cpaelzer> ahasenack: you might ask him for more experience around it
[12:26] <cpaelzer> ahasenack: that is https://launchpad.net/~colin-king, but I don't see him aroung atm
[12:49] <jamespage> zioproto: is there a 1.9.x point release that includes that fix?
[12:57] <zioproto> jamespage: no is only in stable/newton
[12:58] <zioproto> you can check looking here: https://review.openstack.org/#/c/462204/ there is a "Included in" button. It shows only stable/newton
[13:16] <frickler> mdeslaur: I'm currently getting errors from LP when trying to update https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1700079, here is the dpkg.log output http://paste.ubuntu.com/24956199/
[13:16] <mdeslaur> frickler: thanks, I'll add it
[15:39] <cncr04s> how would you find out if 14.04 supports any particular 10gig nic
[16:13] <RoyK> cncr04s: which 10gig nic?
[16:13] <RoyK> cncr04s: the support lies in the kernel, not in the distro
[16:35] <cncr04s> any 10gig nic
[16:35] <cncr04s> which ones should I look for
[16:35] <cncr04s> preferably ones under 100$
[16:38] <genii> The cheapest you're going to find will be 3-4 times that
[16:39] <genii> Unless it's been pulled from a working server and being sold used for maybe $150-200
[16:40] <genii> Anyway... look for Intel and QLogic chipsets
[16:55] <ahasenack> nacc: hi, around?
[17:22] <ahasenack> rbasak: still around?
[17:32] <dpb1> ahasenack: what do you need?
[17:32] <ahasenack> just merge workflow questions
[17:32] <dpb1> k
[17:49] <hehehe_off> hello
[17:52] <ahasenack> the hardest part so far has been the changelog
[17:52] <ahasenack> how do I record that this delta in particular was dropped, for example:
[17:52] <ahasenack>     - d/control: add libcephfs-dev as b-d to build vfs_ceph
[17:52] <ahasenack> it's not a debian/patch/
[17:52] <ahasenack> and it's not like the adding of libcephfs-dev was dropped
[17:53] <ahasenack> it was used by debian, so it's no longer a delta
[17:53] <ahasenack> I can't say "no longer adding libcephfs-dev"
[17:54] <nacc> ahasenack: simply http://paste.ubuntu.com/24957516/
[17:55] <ahasenack> doesn't that mean that we no longer carry libcephfs-dev as a b-d?
[17:55] <ahasenack> it's what I would think if I read that
[17:55] <nacc> ahasenack: no, it means we've dropped it as delta relative to the new/debian version
[17:56] <ahasenack> ok
[17:56] <ahasenack> nacc: are you back fully? I have one more question :)
[17:56] <nacc> ahasenack: http://paste.ubuntu.com/24957528/ maybe is more clear
[17:57] <ahasenack> that's better
[18:14] <hashwagon> Anyone know if it's possible to have a samba shared printer automatically setup on a freshly installed ubuntu server? Is it as simple as copying over /etc/cups directory from a pre-existing system and starting the cups services?
[18:15] <ahasenack> probably not
[18:16] <ahasenack> but if your ubuntu server is configured to use the printer already, samba should just pick it up I think
[18:16] <ahasenack> there is a default [print$] share
[18:16] <ahasenack> and [printers]
[18:18] <hashwagon> Okay thanks, I wasn't sure where to start as my search engine results weren't helping much.
[18:19] <ahasenack> get it working with ubuntu first, then install and worry about samba
[18:57] <ahasenack> hm, that empty commit is showing up commented in the rebase -i now
[18:57] <ahasenack> # pick 9ced15d621657d576cc17417d8230ecb157dad44 * Drop:     - d/control: add libcephfs-dev as b-d to build vfs_ceph       [ Fixed in Debian 2:4.6.5+dfsg-2 ]
[18:58] <ahasenack> and now showing up at all in d/changelog after I reconstruct-changelog
[18:58] <ahasenack> yep, changelogs are hard
[19:07] <ahasenack> and now that disappeared
[19:08] <nacc> ahasenack: right, so you have to keep it in the rebase log each time
[19:08] <nacc> ahasenack: or pass --keep-empty
[19:08] <nacc> ahasenack: 'keep it in the rebase log' --> uncomment it
[19:08] <ahasenack> I didn't, now it's gone
[19:09] <ahasenack> I'm starting this is too much work just to keep a commit message that will be later used to reconstruct the d/changelog
[19:09] <nacc> ahasenack: so you have the line above, you can easily do another rebase and put it back in
[19:09] <ahasenack> I might as well make a note on paper
[19:09] <nacc> ahasenack: once you get the hang of it, it's easy
[19:09] <nacc> ahasenack: git doesn't really like empty commits by default
[19:09] <ahasenack> nor empty directories
[19:09] <nacc> ahasenack: you *can* of course also do what you're saying -- make notes, etc.
[19:11] <ahasenack> http://pastebin.ubuntu.com/24957999/ both of these are drops
[19:11] <ahasenack> but the topmost one has no "Drop:" header, because I expect it to be put below the second one when the changelog is reconstructed
[19:11] <nacc> ahasenack: yep, seems right
[19:11] <ahasenack> if that's correct, it leads to a bad commit message in 8547bbbdfa4f2e259ebc6c81c1c5216274049c11
[19:11] <nacc> ahasenack: you can also have Drop: in each, and then you'd need to do some editing
[19:12] <ahasenack> just looking at that commit message doesn't dell you what happened to that file
[19:12] <nacc> ahasenack: 'bad commit message'?
[19:12] <nacc> ahasenack: well, that's semantically up to you :)
[19:12] <ahasenack> the commit message for 8547bbbdfa4f2e259ebc6c81c1c5216274049c11 in itself doesn't say it was dropped
[19:12] <nacc> ahasenack: IMO, I see that it's a nested changelog entry and it's nested below something prior to it
[19:12] <ahasenack> the only reason it is what it is is because I'm thinking ahead about debian/changelog
[19:12] <nacc> ahasenack: it's all just convention
[19:13] <ahasenack> I'm spending way too much time thinking about how the future d/changelog will be rendered, instead of focusing on the actual important changes
[19:15] <ahasenack> nacc: here is a conundrum: http://pastebin.ubuntu.com/24957369/ I can't really remove those two changes
[19:15] <ahasenack> on paper, they cancel each other out
[19:15] <ahasenack> but in real life, one of them had a mistake and didn't completely undo what the former one did: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1700527
[19:15] <nacc> ahasenack: right, so it'd be a partial drop?
[19:15] <ahasenack> so I kept both picks
[19:15] <ahasenack> and will see what happens
[19:19] <nacc> ahasenack: since the last upload (aiui) of that removal fix was in artful, you can just finish it in this merge
[19:20] <ahasenack> nacc: I made an MP already for that, it's in the bug mentioned above
[19:20] <ahasenack> I also updated the SRU MP
[19:20] <nacc> ahasenack: right, but it's racy now -- e.g., either your merge or the above fix needs to go in first, which will change the other
[19:21] <ahasenack> I'd say the above goes in first
[19:21] <ahasenack> the bug fix
[19:22] <ahasenack> I never know what will happen first, since I have to wait for sponsorship, so I just do it all and adapt when one or the other happens :)
[19:25] <nacc> ahasenack: true -- i think you can also make one MP depend on another
[20:02] <ahasenack> nacc: there is no bug requesting the merge, how do people usually proceed? File a bug? Or just the MP and ping for sponsorship?
[20:22] <nacc> ahasenack: right, file the bug (not explicitly required but good practice, since you need sponsorship)
[20:23] <ahasenack> ok
[20:23] <nacc> ahasenack: andthe update the changelog of your MP to close the bug (e.g., Merge from Debian unstable (LP: #...). Remaining changes:
[20:23] <nacc> ahasenack: that's waht the --bug parameter to `git ubuntu merge` inserts
[20:23] <ahasenack> nacc: and indent everything to the right?
[20:24] <ahasenack> ah, no, it will say the bug number in the "Remaining changes" line, ok
[20:24] <nacc> ahasenack: right
[20:32] <ahasenack> nacc: I cannot use the --bug parameter when finishing the merge?
[20:32] <ahasenack> if I didn't use it when starting?
[21:47] <nacc> ahasenack: right, because it uses that for tagging and references
[21:47] <nacc> ahasenack: it's sort of an oversight (the --bug thing is newer)
[21:47] <nacc> ahasenack: feel free to file a bug (ironically)
[21:48] <nacc> ahasenack: really, eventually, I want `git ubuntu merge finish` to not take any parameters, just wahtever start was given
[21:52] <nacc> ahasenack: i *think* could work around by manually creating the tags (basically, the bug acts like a namespace for the merge workflow). If we can't find the bug tags, though, we should fall back to the non-bug ones, if we can find them, and they make sense (that's the bug you can file, if you like)