[00:16] <powersj> nacc: sorry for the failure emails; I eventually realized I was using the wrong type of quotes *sigh*
[00:17] <powersj> I need to get the VM to recognize lp: git addresses now and should be set
[00:17] <nacc> powersj: cool
[00:42] <powersj> nacc: ok.. that took longer than expected :\ https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/326/console
[00:42] <powersj> I'll check on it later tonight, but it is running now
[06:25] <cpaelzer> smoser: thanks for the cross check, very interesting that you can not reproduce this
[06:25] <cpaelzer> smoser: that lures me deeper into this rabbit hole
[06:26] <cpaelzer> save me if I don't get out :-)
[06:26] <cpaelzer> nacc: "more context" is a vast exaggeration, I just made it migrate back then with the changes :-)
[06:27] <cpaelzer> nacc: but I surely can take a look and hopefully propose something that you can check when you are back online
[06:28] <cpaelzer> good morning server chan btw
[06:34] <cpaelzer> smoser: I'm further throu my mails - so you finally could reproduce
[06:39] <cpaelzer> I'll do the open-vm-tools portion and we can leave bug 1750780 for a thought by xnox (for systemd on xenial) then
[07:04] <lordievader> Good morning
[07:05] <cpaelzer> hi lordievader, how are you?
[07:05] <lordievader> Doing allright here, how are you?
[07:07] <cpaelzer> fine as well today
[07:12] <lordievader> 👍
[11:08] <tobasco> jamespage: thanks for the help with gnocchi, i'm working on it now, but i noticed another issue when fixing this the panko-common package in queens no longer supplies /usr/share/panko-common/app.wsgi i can only find /usr/lib/python2.7/dist-packages/panko/api/app.wsgi is this intentional?
[11:08] <tobasco> i.e apache2 won't start because /usr/share/panko-common/app.wsgi is not present anymore
[11:31] <cpaelzer> nacc: is https://code.launchpad.net/~nacc/ubuntu/+source/kopanocore/+git/kopanocore/+merge/337021 to be considered dead then?
[13:33] <cpaelzer> nacc: I have two different approaches to the kopanocore merge in build atm
[13:33] <cpaelzer> once that works I'll go on to some tests
[13:33] <cpaelzer> at least later today you should have a MP if not showstoppers come along
[13:35] <cpaelzer> I'm iterating on some minor cleanups while build/test goes on
[13:35] <cpaelzer> so don't take the ppa content as final
[14:04] <smoser> cpaelzer: maybe i didnt respond. I *did* reproduce it.
[14:04] <smoser> it was just really really wierd to me that I didn't see any output from the shell "can't open file" or something.
[14:06] <cpaelzer> smoser: all fine
[14:06] <cpaelzer> smoser: I later found your latter update in the bug
[14:07] <smoser> good deal.
[14:07] <smoser> it seems to me that in bionic systemd is a bit overzealous
[14:07] <smoser> in PrivateTmp then means local-fs.target
[14:07] <cpaelzer> at least it adds some dependencies
[14:07] <smoser> when, clearly having /tmp and /var/tmp is much different than all filesystems.
[14:07] <cpaelzer> instead of failing on it's own features
[14:07] <smoser> yes
[14:07] <smoser> better
[14:08] <cpaelzer> I don't even think it adds full local-fs.target btw
[14:08] <cpaelzer> not tested, but what I saw in the dep chain was no full local-fs
[14:08] <smoser> oh. i thought it did. your critical-chain i thoguht showed them.
[14:08] <smoser> ah.
[14:08] <cpaelzer> some -tmp target
[14:08] <smoser> ok.
[14:08] <cpaelzer> smoser: systemd-tmpfiles-setup.service
[14:08] <cpaelzer> not sure if that is better, but it is different :-)
[14:09] <smoser> right. systemd-tmpfiles-setup.service
[14:09] <smoser> but *that* does wait for local-fs.target
[14:09] <smoser>  http://paste.ubuntu.com/p/Gz2rnyqNxT/
[14:09] <cpaelzer> hehe
[14:09] <cpaelzer> well
[14:09] <cpaelzer> that is how it is
[14:09] <cpaelzer> for now
[14:10] <cpaelzer> I don't see a much better thing to wait on for it
[14:10] <smoser> cpaelzer: thanks for working on this.
[14:10] <cpaelzer> and I like the waiting more than the racy fail
[14:10] <smoser> for sure.
[14:10] <cpaelzer> smoser: I thank you for check/comments having helped to understand it way better
[15:43] <cpaelzer> nacc: I need to bsiect on kopano
[15:43] <cpaelzer> nacc: it is not a clean sync
[15:43] <cpaelzer> I have 5 changes Debian didn't pick and I confirmed we need some of them
[15:43] <cpaelzer> I need to iterate on the tests which ones we could drop and which we need as a hard requirement
[16:13] <cpaelzer> nacc: people run into "fun" with the default depends being mariadb-client | default-mysql-client | virtual-mysql-client
[16:13] <cpaelzer> nacc: do you think we should change the order so that by default mysql is installed by the dependency
[16:13] <cpaelzer> ?
[16:14] <cpaelzer> actually, this isn't seeded/main right
[16:48] <rbasak> nacc: one issue with my most recent fixes is that they need the Bionic version of gnupg2 (the Artful version won't do). Will this affect the snap at all? Eg. do we need to add a gnupg part?
[17:35] <GoopAway> So, at my school, they have Windows 7 (and probably some Microsoft server somewhere), and they've allowed me to log in to 1 computer with special credentials, and log into another computer in the area with the same credentials. I know none of these are zero clients, and its weird (IIRC) they have physical accounts and accounts that only work if the server and computer connect. How would I do the same thing for Ubuntu?
[17:38] <dpb1> GoopAway: sounds like roaming profiles in Microsoft.  I'd start here: https://askubuntu.com/questions/198158/how-do-i-set-up-a-roaming-profile -- warning, it's not a checkbox or anything.  It takes pretty good sysadmin knowledge to get going.
[17:42] <GoopAway> Is it possible to have Windows machines connect to a network that spoofs the LDAP server they're looking for?
[17:42] <TJ-> GoopAway: no; Windows Active Directory uses Kerberos and authenticates in both directions
[17:43] <jdr> you would have to forge kerberos tickets
[18:02] <rbasak> nacc: my MP CI failure: looks like the snap isn't bundling the test files?
[19:07] <arunpyasi> Hi everyone, how fine is it to upgrade the distro from 14.04 to 16.04 ?
[19:07] <arunpyasi> sory
[19:07] <arunpyasi> 10.10 to 16.04
[19:07] <arunpyasi> *10.04 to 16.04
[19:09] <Ussat> thats a big jump
[19:09] <Ussat> I would not personally
[19:11] <sarnold> arunpyasi: the supported upgrade path is through 12.04 LTS, 14.04 LTS, then 16.04 LTS. A fresh install might be more reliable
[19:11] <jdr> thats a huge jump.
[19:11] <dpb1> arunpyasi: https://help.ubuntu.com/community/EOLUpgrades
[19:12] <sarnold> hopefully there's enough 12.04 LTS left on the mirror network due to the 12.04 ESM support offering still live
[19:13] <TJ-> it's all on old-releases
[19:13] <dpb1> sarnold: and it's still in the real archive
[19:14] <dpb1> fwiw
[19:14] <sarnold> yay
[19:14] <sarnold> then this path stands a chance of working ;)
[19:14] <dpb1> ya, would be a fun experiment. :)
[19:21] <arunpyasi> :)
[19:22] <arunpyasi> Thanks for your support. I guess I shall go with the fresh and migration
[19:30] <jdr> Anyone run a ubuntu server distro on digital ocean, and can run a user compiled kernel?
[19:31] <dpb1> jdr: 1) yes, 2) never done it
[19:32] <jdr> I can get it to compile, modules installed, go to reboot and kernel panic.
[19:33] <jdr> I have reached out to DO, and have read a few articles saying you cant install, and a few that say you can
[19:39] <TJ-> jdr: in the config have you choosen the "DigitalOcean GrubLoader" ?
[19:48] <jdr> no i did not
[19:57] <nacc> rbasak: you didn't add them to the MANIFEST.in
[20:11] <pmatulis> why is there no 16.04.4 download here: https://www.ubuntu.com/download/server ?
[20:14] <sarnold> pmatulis: I don't think we've released one yet, no one's amended https://wiki.ubuntu.com/Releases to show one
[20:14] <Ussat> pmatulis, I would not be concerned, get .3, use that, update as needed
[20:18] <sbeattie> pmatulis, sarnold: indeed, 16.04.4 iso testing is underway, it's not been released yet.
[20:19] <sarnold> cool :)
[20:24] <rbasak> nacc: I thought you said I didn't need to? I'll do that :)
[20:24] <nacc> rbasak: sorry, I thought I said you *did* need to :)
[20:25] <rbasak> nacc: I went away with the impression that everything in gitubuntu got included by virtue of it already being picked up as a Python package. Anyway no big deal :)
[20:25] <nacc> rbasak: right, all *.py does
[20:25] <nacc> rbasak: but not non-python files
[20:26] <nacc> rbasak: you have to expliclitly make them package data via either package_data in setuptools or the MANIFEST.in
[20:26] <rbasak> Ah, OK.
[20:26] <rbasak> I've added it to MANIFEST.in and pushed
[20:27] <rbasak> We can squash that before merging if it passes perhaps?
[20:27] <rbasak> I don't mind either way.
[20:27] <nacc> rbasak: yeah i can do that if it passes
[20:27] <nacc> rbasak: if it does, i'll land it, feel free to eod
[20:27] <rbasak> Thanks
[21:08] <pmatulis> sarnold, sbeattie: thanks for the info
[21:10] <nacc> rbasak: err, are you depending on gpgv behavior from the bionic version?
[21:11] <nacc> rbasak: http://manpages.ubuntu.com/manpages/xenial/man1/gpgv.1.html no such option in xenial :)
[22:48] <rbasak> nacc: yeah, that's what I meant
[22:48] <rbasak> nacc: Bionic only
[22:49] <nacc> rbasak: well, we are on xenial
[22:49] <nacc> rbasak: and i was advised to *not* build gpg from source
[22:50] <rbasak> Oh
[22:50] <rbasak> What do you think we should do about this?
[22:50] <nacc> rbasak: (that is, we call to the system gpg for stuff)
[22:50] <rbasak> gpgv didn't gain --output until Bionic.
[22:50] <nacc> rbasak: i don't know
[22:50] <nacc> rbasak: we could *just* build gpgv in our snap
[22:50] <rbasak> However, bare gpg does have --output defined in the manpage. It just doesn't work until Bionic.
[22:50] <nacc> and then make sure to call the snapped binary via run
[22:51] <rbasak> In terms of making sure, it's fine if we just rely on PATH I think. If the wrong one is called, the code is designed to fail safe (fail verification), and that's tested.
[22:52] <rbasak> nacc: what was the basis of the advice not to build gpg from source?
[22:52] <nacc> rbasak: because e.g., gpg vs. gpg2
[22:52] <nacc> and we'd end upa ffecting the user's ~/.gnupg directory
[22:53] <rbasak> I see
[22:54] <nacc> rbasak: (iirc)
[22:55] <nacc> rbasak: 3294bc6d6c93c8c76f953266f9665ede78c5937d
[22:55] <nacc> rbasak: so we could build just gpgv into the snap (it will require some carefully snapping)
[22:56] <rbasak> OK
[22:56] <rbasak> Another way (not sure it's the least worst) might be to mark the tests that need a newer gppv, skip them from the self test, but do run then in some other manner in CI.
[22:57] <nacc> rbasak: so we don't call gpgv in the actual code? only in the tests?
[23:04] <rbasak> Oh. Good point.
[23:04] <rbasak> So that won't work. We do call gpgv in the actual code.
[23:04] <rbasak> --output is needed in the case of cleartext (InRelease) signatures, which is the common case for us.
[23:07] <nacc> rbasak: right
[23:08] <nacc> so i think we do need gpgv in the snap no matter what
[23:08] <nacc> so it's good the self-test caught it :)