[10:19] <cub> basically the US team is 24/7 and cover all the globe?
[10:19] <cub> the US, Canada, Europe, Asia
[10:19] <smartboyhw> cub, yeah sure but I'm 6 hours ahead
[13:15] <OvenWerks> cub: A very loose 24/7... it is good to have a life too ;)
[13:16] <cub> sure, but when you sleep or live life..someone else is awake. :D
[13:16] <OvenWerks> sort of...
[13:17] <OvenWerks> we cover the globe, but are not a large bunch
[13:17] <cub> if not zequence seems to never sleep.
[13:17] <zequence> I like to sleep 8-9h, if I can :)
[13:18] <cub> according to the irc logs you seem to not do that very often. ;)
[13:18] <cub> since I got a baby I'm happy if I get 6 hours sleep.
[13:18] <zequence> my chat client is on 24/7. It's a irssi cle
[13:18] <zequence> ..client on my se3rver
[13:19] <OvenWerks> as is mine
[13:19] <zequence> I'm not using it only for chatting, but also for logging different channels
[13:20] <zequence> I have alerts for certain words, so I'm alerted if someone discusses some topics
[13:20] <cub> your own private PRISM
[13:21] <zequence> also, channels like #ubuntu-bugs-announce is good to monitor. I get alerts when there are linux-lowlatency bugs
[13:21] <OvenWerks> speaking of which, I will probably be doing a merge of the menus in the next few days.
[13:22] <OvenWerks> I think if no one finds any problems with it I will put up versions on my ppa for back to precise
[13:22] <cub> zequence, on another note, you are not leaning towards moving to Stockholm? The company I work for are looking for linux techs
[13:23] <zequence> cub: not really. I'm pretty rooted here, at least for the time being. no chance to do work from home? :)
[13:23] <cub> It should, but management like people on site
[13:25] <zequence> I'm getting some certificates for another 6 months at most, and after that, the plan is I'll try to find a job somewhere
[13:26] <OvenWerks> Managment people are odd ducks anyway...
[13:28] <smartboyhw> Hey zequence OvenWerks
[13:28]  * smartboyhw is still bundled under KDE SC packaging:P
[13:29] <OvenWerks> Whats SC?
[13:31] <smartboyhw> OvenWerks, Software Collection aka the KDE desktop
[13:32] <OvenWerks> Ah! You may want to make your own PPA for it. It is a lot easier to test.
[13:32] <smartboyhw> I have worked on 6 packages today:O
[13:32] <smartboyhw> OvenWerks, the Kubuntu team has a secret PPA;P
[13:32] <OvenWerks> That would work.
[13:33] <smartboyhw> Actually, this is the fifth one I'm working on. I do have a sixth.
[13:35]  * OvenWerks does one at a time
[13:35] <zequence> OvenWerks: I've put up a PPA for our development work here, so it would be good if you put the menu there, once you're ready to have people test it https://launchpad.net/~ubuntustudio-dev/+archive/devel
[13:35] <zequence> -default-settings is auto built once a day from source there
[13:35] <zequence> the meta needs to be built manually
[13:35] <smartboyhw> OvenWerks, I do do one at a time. I did 4 already.
[13:36] <smartboyhw> zequence, auto-built. Nice.
[13:36] <OvenWerks> That would be the place to put -menu packages for older studio versions too then
[13:37] <zequence> OvenWerks: backporting is a different issue though
[13:38] <zequence> we should set up a special ppa for backport testing
[13:38] <smartboyhw> +1
[13:38] <OvenWerks> There are not that many people who want it, but I think Luke is doing cinnamon on R
[13:38] <zequence> I assume the menu package doesn't need any changes for older releases
[13:39] <OvenWerks> No, just marked as P, Q and R
[13:39] <OvenWerks> One word difference in the changelog :P
[13:40] <zequence> I still want to separate development release work from SRU and backporting work
[13:40] <OvenWerks> OK
[13:41] <zequence> so, for backports https://launchpad.net/~ubuntustudio-dev/+archive/backport-testing
[13:41] <zequence> OvenWerks: but, if the menu is to be backported, that would mean changing -default-settings as well, right
[13:42] <zequence> so, that makes it a little bit more complicated
[13:42] <OvenWerks> No, I would not worry about that.
[13:42] <OvenWerks> This is more for those installing our metas on top of something else.
[13:43] <zequence> yet, you can install it on top of Ubuntu Studio too
[13:43] <OvenWerks> And it would work.
[13:43] <zequence> we would need to do a SRU on our -default-settings, and make it depend on the menu
[13:43] <OvenWerks> May not need to.
[13:44] <OvenWerks> unless we want to update the menu for P
[13:44] <zequence> Why do you want to test the menu for older releases then?
[13:44] <OvenWerks> I will work on -settings next for -menu integration.
[13:45] <OvenWerks> As I said only for those who want to use it on top of another DE/flavour.
[13:45] <zequence> the problem is if it conflicts with our -default-settings package
[13:46] <OvenWerks> I will test.
[13:46] <zequence> it will of course, if both are installing files with the same names that diff
[13:46] <OvenWerks> The menu itself is a different file
[13:46] <OvenWerks> in a different directory
[13:47] <OvenWerks> It does not replace the system menu
[13:47] <OvenWerks> It merges on top of it
[13:47] <zequence> Ok, well, one thing at the time then. First we make sure the development version is ok, then worry about backporting it
[13:48] <smartboyhw> R shouldn't conflict, nor should Q.
[13:49] <OvenWerks> What I will be doing (If I can) is basically reverting our system menu to stock xfce in settings and using the merge for our menu
[13:49] <smartboyhw> Not sure for R though.
[13:49] <zequence> Yeah, well, let's see when the packages are ready for testing :)
[13:49] <OvenWerks> P is the important one.
[13:50] <zequence> it's just that we are required to backport one release at the time, in sequence
[13:50] <zequence> so, beginning with R, then Q and finally P
[13:50] <OvenWerks> Ok
[13:50]  * OvenWerks has to go eat and get to work
[13:51] <OvenWerks> Bye now
[13:51] <zequence> see you OvenWerks
[16:42] <madeinkobaia> Hi fellows
[17:57] <madeinkobaia1> I am twice here ? :-/
[17:59] <madeinkobaia1> Strange, I log out/in again...


[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<EMAIL_ADDRESS>[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