[00:00] <sarnold> right :)
[00:00] <sarnold> sshd doesn't care about the details of the group
[00:00] <sarnold> all it cares about it 755 not 775.
[00:02] <ProCycle> it has the same perms as my other account which can log in
[00:02] <ProCycle> So I don't know what it's complaining about
[00:03] <sarnold> your other account was 775 as well and it *could* log in? o_O
[00:04] <ProCycle> yes
[00:04] <ProCycle> They've always been that way, for years
[00:04] <ProCycle> I do -rw------- for the actual authorized_keys file
[00:07] <ProCycle> wow it worked
[00:08] <ProCycle> changed to 755 and can login now
[00:10] <ProCycle> Thanks for the help!
[00:10] <sarnold> \o
[00:10] <sarnold> \o.
[00:10] <sarnold> GAH.
[00:10] <sarnold> yay.
[00:10] <sarnold> there we go. :)
[00:11] <ProCycle> So strange it would take exception to only that account
[00:13] <ProCycle> Oh it's closing time, gotta run. Thanks again!
=== Aztec03 is now known as SmokinGrunts
=== SmokinGrunts is now known as Aztec03
[06:35] <lordievader> Good morning
[12:38] <ahasenack> rbasak: hi, good morning/afternoon. Could you please import ubuntu-advantage-tools into git? Latest version is 16, uploaded on march 21st, but in git we still have v15 from March 20th
[12:40] <rbasak> It's in the whitelist.
[12:41] <rbasak> nacc: ^ so I assume it's OK to just run the importer against this. The only risk is a collision, but that seems unlikely for this package.
[12:41] <rbasak> Running
[12:42] <ahasenack> thx
[12:42] <rbasak> ahasenack: it ran but didn't seem to do anything
[12:43] <rbasak> ahasenack: I see version 16 here.
[12:43] <ahasenack> hm, I see it now too
[12:43] <ahasenack> oh geez, I just did a fetch, not a pull or merge
[12:43] <ahasenack> sorry
[12:44] <ahasenack> my mistake
[13:16] <samba35> is there a bug in 16.04.4 with openvswitch ?
[13:16] <samba35> too many logs are been genrated with openvswitch
[13:17] <samba35> in GB s
[14:44] <ahasenack> rbasak: ohh, something changed in lp regarding our git repo for packages
[14:44] <ahasenack> rbasak: I'm making a new MP, and lp by default selected this target for me:  lp:ubuntu/+source/ubuntu-advantage-tools (repository details)– default repository
[14:44] <rbasak> ahasenack: that's intentional.
[14:44] <ahasenack> the UI is also slightly different now
[14:44] <rbasak> It's easier/better now, no?
[14:44] <ahasenack> yep
[14:44] <ahasenack> that wa the "ohh" part :)
[14:44] <rbasak> Ah :)
[14:45] <ahasenack> rbasak: who will be the default reviewer?
[14:47] <rbasak> ahasenack: we don't really have an answer for that yet, sorry
[14:47] <rbasak> Mapping reviewers to people who can upload doesn't really work currently
[14:47] <ahasenack> ah, it defaulted to the usual import team
[14:47] <rbasak> (there is no such map)
[15:05] <teward> rbasak: can you stab the Canonical Landscape team for me about bug 1685885?  I'm not the only one affected by it, and it makes using Landscape impossible.
[15:05] <ubottu> bug 1685885 in landscape-client (Ubuntu) "Extreme RAM and SWAP usage" [High,Confirmed] https://launchpad.net/bugs/1685885
[15:07] <RoyK> is there an exception for sigterm? I have one for kbkdinterrupt, but that doesn't work when systemd takes down the service
[15:10] <rbasak> teward: done
[15:14] <nacc> rbasak: ack, np
[15:25] <teward> rbasak: thank you kindly.  That's been biting me for some time, and though it's confirmed and High priority, nobody's touched it.  One guy said on the bug it ate all the ram on their mail server, so if *someone* could consider that an urgent issue, that'd be great.  I've not been using Landscape for centralized management because of what I consider a massive memleak
[15:25] <teward> *returns to the shadows*
[17:17] <jamespage> frickler: fwiw the ceph-volume and missing dep for ceph-mgr are now in bionic and the Queens UCA; working updates for artful and Pike UCA now
[17:32] <nacc> rbasak: around? had a quick Q re: git-ubuntu tests
[17:35] <rbasak> nacc: o/
[17:36] <nacc> rbasak: ok, so i've got a quick implementation of repo_comparator.equals, and i was assuming it'd take two pygit2.Repository objects to compare; however, if we pass in expected_result, that's a repo_builder.Repo object (and not yet written anywhere). Should I create a second temporary pygit2.Repo fixture?
[17:40] <rbasak> nacc: could go either way I guess. I think that it probably makes sense for repo_comparator.equals to take a pygit2.Repository and a repo_builder.Repository perhaps, and handle writing the latter to a pygit2.Repository in a temporary directory itself. So no fixture.
[17:41] <rbasak> nacc: my reasoning is that it'll make the tests simpler, and that's what we'll be writing in bulk.
[17:41] <nacc> rbasak: hrm, a good point
[17:42] <rbasak> I can't think of a case where we'd need an equals method with two pygit2.Repositories. But if we ever do need that, we could always supply two methods; one being a wrapper of the other.
[17:42] <nacc> rbasak: yep, good point
[17:42] <nacc> ok, i'll switch to that
[17:58] <nacc> rbasak: nice, test passes (case #1)
[17:58] <nacc> rbasak: i need to clean up this pile of commits significantly, of course :)
[17:58] <nacc> and found a few bugs in my branch, i'll get them squashed and send you a few MPs to review
=== FalconMillennium is now known as Tardigradum
=== Tardigradum is now known as FalconMillennium
[18:32] <smoser> can someone takek a quick review for me
[18:32] <smoser>  https://code.launchpad.net/~smoser/ubuntu/+source/ssh-import-id/+git/ssh-import-id/+merge/342231
[18:37] <sarnold> with open(output_file, "r") as f:
[18:37] <sarnold> is it kosher to open an output file with read permissions, not write?
[18:37] <sarnold> oh, nevermind, that's pre-existing code
[18:38] <rbasak> smoser: what if HOME is set but empty?
[18:39] <rbasak> I see the code is upstream.
[18:39] <smoser> if os.environ.get("HOME")
[18:39] <rbasak> It seems the code doesn't really define the behaviour in that edge case.
[18:39] <smoser> if truly empty would still take the 'else'
[18:39] <rbasak> Whatever behaviour it has feels like an accident.
[18:40] <smoser> but HOME=" "
[18:40] <smoser> then i'm not sure.
[18:40] <rbasak> Shouldn't else have a : at the end?
[18:40] <sarnold> I'd wager "empty HOME" falls under "don't do that"
[18:40] <smoser> rbasak: yes. and the code does. i was just typing here.
[18:40] <rbasak> Not in the patch I'm looking at.
[18:41] <rbasak> Line 50 in the MP
[18:45] <smoser> rbasak: http://paste.ubuntu.com/p/MBMXFmfSKt/
[18:45] <smoser> thank you
[18:45] <smoser> we'd have found that anyway in a test of proposed, but that was quicker.
[18:59] <frickler> jamespage: thx for the notification, for me that means that I must update my local builds in order to stay ahead of you ;-)
[19:20] <ahasenack> rbasak: hi, when you have a moment, since you reviewed some of the previous uploads: https://code.launchpad.net/~ahasenack/ubuntu/+source/ubuntu-advantage-tools/+git/ubuntu-advantage-tools/+merge/342208 (I'm not expecting anything for today)
[19:37] <rbasak> ack
[20:27] <ahasenack> nacc: I think I'm done with the nvdimm packages, would you like to take a look?
[20:28] <ahasenack> otherwise, or in addition to, I'm about to follow the remaining steps of https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[20:28] <ahasenack> via motu
[20:29] <ahasenack> (assuming it was always meant to go to universe first)
[20:49] <nacc> ahasenack: universe +1
[20:49] <nacc> ahasenack: i can look, where should I?
[20:49] <ahasenack> nacc: ppa: https://launchpad.net/~canonical-server/+archive/ubuntu/nvdimm/
[20:49] <ahasenack> nacc: git:
[20:49] <ahasenack> (jsut a sec)
[20:50] <ahasenack> ndctl: https://code.launchpad.net/~ahasenack/ubuntu/+source/ndctl/+git/ndctl
[20:50] <ahasenack> nvml: https://code.launchpad.net/~ahasenack/ubuntu/+source/nvml/+git/nvml
[20:50] <nacc> ahasenack: ok
[20:50] <nacc> ahasenack: do you have any response re: testing?
[20:50] <nacc> actual functional testing, i mean
[20:51] <ahasenack> nacc: I have responses about the packaging
[20:51] <ahasenack> let me link to the first
[20:51] <ahasenack> I never got an explicit "yes, it's working with our hardware"
[20:51] <nacc> ahasenack: yeah that's what i'm most concerned with at this point
[20:51] <ahasenack> nacc: since I took over: https://bugs.launchpad.net/ubuntu/+bug/1752378/comments/13 (comment #13 and later)
[20:51] <ubottu> Launchpad bug 1752378 in Ubuntu "Please add Userspace Packages for NVDIMM support" [Medium,In progress]
[20:52] <ahasenack> I can ask point blank now
[20:53] <nacc> yeah that's what i'd recommend
[20:54] <ahasenack> nacc: done
[20:54] <nacc> ahasenack: +1
[20:55] <ahasenack> thx
[20:56] <nacc> ahasenack: on first glance, code looks good -- i think it'll really need an AA review, though, as I've never done a new package like this
[20:56] <ahasenack> nacc: sure, and I added some lintian overrides to the nvml package
[20:56] <ahasenack> about the *_dbg/ directories
[20:56] <ahasenack> hopefully with enough comments on why they are needed, and for how long
[20:56] <nacc> ahasenack: yep, was reading about that in the bug
[20:58] <ahasenack> I understand why an AA review would be welcomed first, I just want to get rid of any potential low hanging fruit in the packaging before it's shown to an AA
[20:58] <ahasenack> or, s/low hanging fruit/embarrasing mistake/
[20:59] <ahasenack> and, of course, it needs to work, hence the question in the bug for a comment stating that it does work with their hardware
[21:00] <ahasenack> I didn't get a reply yet in that other bug you pointed me at yesterday
[21:00] <nacc> ahasenack: ack
[22:19] <hashwagon> Is there a common reason why a statically set ip address set via /etc/network/interfaces would revert back to DHCP?
[22:20] <hashwagon> ^ in ubuntu 16.04
[22:24] <nacc> hashwagon: revert when?
[22:28] <nacc> rbasak: fyi, 4 branches pushed up for review, the first 3 are i believe ready to land (i coudl use some help coming up with tests for the repo_comparator, i think
[22:33] <hashwagon> I have  many servers all configured through SaltStack and about 1% of them are changing to DHCP. The last example was ~4:30PM ET today. It's been reverting about every 24 hours now on this particular system.
[22:33] <hashwagon> nacc, ^
[22:34] <hashwagon> Are there any other logs other than journalctl I should be going through?
[22:35] <sarnold> if you don't need dhcp on these machines maybe just purge the package that supplies the daemon it winds up using?
[22:54] <hashwagon> Good thought. That might complicate things as there are maintenances we go through where dhcp comes in handy.
[22:55] <sarnold> oh. then that'd require more thought and nuance :)
[23:04] <nacc> hashwagon: strange, i'd check syslog, journalctl