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