[00:54] <jiffe> if I have a drive mounted which has ubuntu server installed on it, is there a way to see what packages were installed on it?
[00:56] <sarnold> if there's enough of it there, the easy way is to chroot to it and then use dpkg -l
[00:58] <jiffe> no there's not enough
[00:58] <jiffe> dpkg: error while loading shared libraries: libpcre.so.3: cannot open shared object file: No such file or directory
[00:59] <sarnold> dang
[00:59] <sarnold> jiffe: I think all the data is in /var/lib/dpkg/status
[01:00] <sarnold> Package: libasan0
[01:00] <sarnold> Status: install ok installed
[01:00] <sarnold> etc
[01:00] <jiffe> gotcha
[01:00] <sarnold> hm. maybe you could move your desktop's copy aside, drop that one in place, and try dpkg -l? :) see if that works out.
[01:04] <jiffe> nah status file is good enough, thanks
[03:29] <tomreyn> see also the files in /var/backups/
[04:30] <jamespage> mdeslaur: the xenial ceph update regresssion tested ok as well
[05:03] <jamespage> coreycb: ftr autopkgtest-pkg-python does not work with the oslo.* packages
[05:03] <jamespage> it can't deal with the switch from oslo.X to oslo_X inside the package
[05:03] <jamespage> I have submitted bugs with patches
[05:37] <jamespage> mdeslaur: thanks for those ceph security updates btw
[05:41] <blackflow> cephcurity updates! ;)
[06:25] <jamespage> coreycb: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884181
[08:03] <sahid> jamespage, coreycb, I have version bump for python-ddt and python-os-traits ready
[08:04] <jamespage> sahid: lp:~ubuntu-server-dev/ubuntu/+source/python-falcon
[08:06] <sahid> oh sorry i was sure have checked for python-falcon
[08:27] <st4rf0x64> Good morning, I am looking for a simple way to bring a number of Ubuntu Servers into a Windows Active Directory for the sake of using accounts in said AD for verification with the Ubuntu Servers.
[09:41] <odc> st4rf0x64: you are probably looking for this: https://help.ubuntu.com/lts/serverguide/sssd-ad.html
[11:07] <mdeslaur> jamespage: awesome, thanks for testing them! :) I'll release them on tuesday (mon is a holiday for me)
[11:37] <Walex> st4rf0x64: what "odc" says is probably the simplest method. If your requirements are straighforward.
[11:38] <Walex> st4rf0x64: that that the AD needs to have the POSIX or UNIX account schemas merged in.
[11:38] <Walex> st4rf0x64: for things like home directory path; there are several howtos.
[11:47] <st4rf0x64> Well ideally we would like to use the same administration identification that we use elsewhere, on the ubuntu machines. currently we are doing it all through root.
[12:38] <jamespage> mdeslaur: fair nuff - I've uploaded the 13.2.6 releases for cosmic and disco ready for when they roll out
[12:38] <jamespage> sahid: no you where right - I just created that repo
[12:57] <coreycb> jamespage: thanks for submitting those patches! that should clear up some of the failures in proposed.
[12:58] <jamespage> coreycb: yeah but not anytime soon with the autodep8 stuff
[12:58] <jamespage> coreycb: the problem is we've move from a in -tree import test that passes to the autodep8 one which is unhappy
[12:58] <coreycb> jamespage: ok i can restore the old tests and add a note with link to the bug
[12:58] <jamespage> so we're blocked - we might want to switch back to in-tree to unblock
[12:58] <jamespage> coreycb: +1
[13:01] <coreycb> jamespage: seems like an XS- field would be a reasonable general solution
[13:02] <coreycb> jamespage: anyway i'll cycle through the oslo's right now and restore them and then look at proposed failures in my afternoon
[13:02] <jamespage> coreycb: thankyou
[13:54] <jamespage> cpaelzer: ok so what's the right way to set the vhost-user and vhost-perm with DPDK 18.11 via OVS?
[14:01] <teward> rbasak: sarnold: do we want to consider going to NGINX Mainline for Eoan?  There's only been one 1.17.x release thus far.  Or do we want to stick with Stable branch?
[14:14] <rbasak> teward: I don't know. What do you think? :)
[14:15] <rbasak> teward: F will be an LTS, so will we definitely be on nginx stable again by then?
[14:15] <teward> rbasak: that remains the 'dilemma'
[14:15] <rbasak> :)
[14:15] <teward> because they release **around the same time we do**
[14:16] <teward> so unless we get a total release bump exception for LTS to jump from 1.16.x stable to 1.18.x stable post-release (which includes ALL the features)...
[14:16] <rbasak> Do they do that deliberately?
[14:16] <teward> rbasak: no, it's coincidental that their 'new stable branch' release cycle happens to land on/around our release time
[14:16] <teward> been that way since ever
[14:17] <teward> rbasak: in other news though, starting in Eoan, we won't have to worry about the 1CPU SystemD PIDFile race conditions
[14:17] <teward> you can thank TJ- for that patch when they show up next
[14:17] <teward> (i just uploaded that to Eoan)
[14:17] <rbasak> Nice. Thanks!
[14:51] <lopta> Can Ubuntu Server provide desktops to RDP terminals or would I need X terminals?
[15:21] <lordcirth> lopta, you mean clients logging in to an Ubuntu server over RDP, and getting desktops?
[15:22] <lopta> lordcirth: Hopefully. :-)
[15:23] <lordcirth> lopta, "sudo apt install ubuntu-desktop xrdp; systemctl enable xrdp". Then give it a try. I don't know if you can have multiple users simultaneously, though.
[15:24] <lopta> lordcirth: Thanks!  I will test that!
[16:38] <kinghat> if you have a backup drive, do you keep it powered on all the time or do you power it up when you want to make the backup and then back off?
[16:59] <sarnold> teward: let me guess, nginx's plans include releasing their next stable release about two weeks after we release ours?
[17:03] <teward> sarnold: as they *typically* do every year
[17:03] <teward> or same-week when we're in absolute final freeze
[17:16] <lordcirth> kinghat, You should probably unplug it, and preferably store it a distance away
[17:17] <kinghat> this is just another option for my 3x1TB setup i have now. figuring out what to do with my extra 1TB drive
[17:18] <kinghat> unplugging/off site is not in the cards. something automated and attached to the same puter.
[17:48] <ahasenack> rafaeldtinoco: that import commit you got, that is what you have to "split"
[17:48] <rafaeldtinoco> yep, i did, missing changelog only
[17:48] <rafaeldtinoco> now im doing last commit before --continue
[17:49] <ahasenack> k
[17:49] <rafaeldtinoco> i saw in git diff changelog is good to go
[17:49] <rafaeldtinoco> i thought it would be ugly (Import....) but its not
[17:52] <ahasenack> what do you mean?
[17:53] <rafaeldtinoco> ahasenack: i thought the changelog would have import patches-unapplied version XXXX
[17:53] <rafaeldtinoco> but saw that the changelog was actually good already (for the single commit I had to split)
[17:54] <rafaeldtinoco> so I committed changelog as "changelog" and continued the rebase
[17:54] <rafaeldtinoco> now im tagging split
[17:54] <ahasenack> no, that was just the commit message
[17:54] <ahasenack> yep
[17:57] <lordcirth> kinghat, you could use systemd automounting to take care of cleaning up / spinning it down after
[17:58] <kinghat> well i mean maybe thats not even worth it? which is what i was wondering? if using it to backup a mirror, would it be better to power up/down daily for a backup, if thats my frequency, or to just leave it on and perform a backup daily?
[17:59] <lordcirth> kinghat, I don't think it's very important to make sure it spins down.
[17:59] <kinghat> for some reason i thought that it might be worse for the drive to power it on/off than to just leave it running.
[18:02] <rafaeldtinoco> ahasenack: should I drop all merge-changelogs, update-maintainer commits or just the last one ? (i got 2 from a previous ubuntu merge)
[18:02] <rafaeldtinoco> (after the tag split phase)
[18:02] <rafaeldtinoco> im doing the "logical" delta iirc
[18:06] <ahasenack> rafaeldtinoco: logical must not have changelog/update-metadata commits
[18:06] <rafaeldtinoco> cool i dropped it all
[18:06] <rafaeldtinoco> it worked :o)
[18:06] <ahasenack> the split phase must remain identical to what was there before
[18:06] <ahasenack> in terms of git diff old/ubuntu
[18:06] <rafaeldtinoco> it does a update-maintainer and reconstruct-changelog at the end
[18:08] <ahasenack> merge finish does that, yes
[18:08] <rafaeldtinoco> yep, its perfect i suppose
[18:08] <rafaeldtinoco> nice, will verify and propose it again
[18:08] <rafaeldtinoco> try to build, etc etc
[18:08] <rafaeldtinoco> it was good to re-do, now with a split need
[18:08] <rafaeldtinoco> i could understand better =)
[18:15] <rafaeldtinoco> argh
[18:15] <rafaeldtinoco> +Signed-off-by: Rafael David Tinoco <rafaeldtinoco@ubuntu.com>
[18:16] <rafaeldtinoco> reconstruct-changelog brought by signed-off
[18:16] <rafaeldtinoco> let me rebase this
[19:07] <ahasenack> rafaeldtinoco: this is a great command to check merges
[19:07] <ahasenack> git range-diff rafaeldtinoco/old/debian..rafaeldtinoco/logical/1%9.11.5.P4+dfsg-4ubuntu2  rafaeldtinoco/new/debian..rafaeldtinoco/eoan-bind9-merge
[19:07] <ahasenack> that will show if there have been changes between old delta and new delta
[19:07] <rafaeldtinoco> humm
[19:08] <rafaeldtinoco> yep, ive used it before, but i have to get used to the tag names and meaning
[19:08] <rafaeldtinoco> having "ubuntu" was a wrapper makes git to have some "black holes" in what we're doing, so i have to recap from time to time
[19:09] <ahasenack> old/debian..logical is the old delta (logical, no changelog)
[19:09] <ahasenack> new/debian..HEAD is what you are proposing on top of the new debian package, aka, the new delta
[19:09] <ahasenack> but this one has changelog in the last few commits
[19:10] <rafaeldtinoco> yep got it
[19:11] <rafaeldtinoco> ahasenack: so it says basically the difference is the metadata itself
[19:11] <rafaeldtinoco> merge-changelogs, reconstruct-changelog, update-maintainer