[01:19] <nacc> rbasak: fyi, i'm starting the refactor for main/cli_main. build was really easy, so was clone. importer is going to be a bit ugly, because of how much state we have, but i should have it done tmrw AM. Hopefully the rest by the EOD tmrw.
[05:36] <cpaelzer> nacc: the libvirt import is good now, I assume you removed it from the blacklist so it will stay current right?
[05:44] <cpaelzer> and good morning everybody
[05:50] <cpaelzer> nacc: s/remove from blacklist/added to whitelist/ but you know what I meant anyway
[09:14] <krzyzaq> Hi All
[09:15] <krzyzaq> I have an issue finding in internet an answear for my problem - how to allow AD group users to login to the xrdp on ubuntu
[09:50] <RoyK> krzyzaq: I've looked around for solutions for that, and they exist, with winbind or other stuff - never setup anything like that myself, though
[09:50] <RoyK> that is - only looked for ssh auth with AD, but should be the same, more or less
[09:51] <RoyK> I guess it's a PAM thing after all
[09:54] <krzyzaq> RoyK: yeap, I think also it should be done by /etc/pam.s/xrdp-sesman
[09:55] <krzyzaq> but I didn't found any example or solution that works 100%
[09:57] <RoyK> not sure - sorry - never tried myself
[09:57] <krzyzaq> sure, thx
[10:07] <eagles0513875> hey all
[10:15] <albech> Hi all. Will pinning look for dependencies of a certain package i wish to upgrade or simply forcefully upgrade that one package?
[10:41] <eagles0513875> i have a quick question I am setting up a server with a particular user which will be SFTP access only.
[10:41] <eagles0513875> i setup up the user with out a shell so /bin/false in this case and added the user to the ssh group
[10:42] <eagles0513875> when I try to connect via filezilla its giving me an EOF message and its unable to connect
[10:42] <eagles0513875> does the user need to have a bash shell
[10:42] <eagles0513875> to be able to sftp
[10:44] <RoyK> try rssh
[10:45] <RoyK> it's made for just that sort of stuff
[10:54] <eagles0513875> RoyK: hey i remember your name hehe. i managed it seems like a line needs to be changed in the ssh config
[10:54] <eagles0513875> now the next issue I need to figure out RoyK  is how to restrict a particular user to a particular directory to upload files to
[10:58] <RoyK> eagles0513875: that requires chrooting, which is a longer story
[10:59] <RoyK> seems it's easier now than what I remember https://unix.stackexchange.com/questions/9853/restricting-an-ssh-scp-sftp-user-to-a-directory
[13:52] <gQuigs> I know it was just released, but any plans to bump neutron ocata to 10.0.3?
[14:00] <coreycb> jamespage: do you know the history behind running db sync commands in our packages when there's no connection string?
[14:00] <coreycb> jamespage: for example: https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/nova/tree/debian/nova-common.postinst#n50
[14:00] <coreycb> i'd like to limit that check to the 2nd sqlite check ^
[14:00] <jamespage> coreycb: gah we duped on https://bugs.launchpad.net/ubuntu/+source/python-pyperclip/+bug/1713617
[14:00] <coreycb> jamespage: ah shoot, i should've pinged you
[14:01] <jamespage> coreycb: no worries - xclip looks rusty fwiw xsel might be better
[14:01] <jamespage> coreycb: re running db syncs; I'll all up for disabling those completely in the packaging - they create nothing but woes
[14:01] <jamespage> I'd hoped to have spent time of those earlier in cycle
[14:01] <jamespage> but tbh I think we could drop them now anyway
[14:02] <jamespage> coreycb: what do you think?
[14:02] <jamespage> coreycb: the maintainer script execution should be limited to the default sqlite based connection value only
[14:02] <coreycb> jamespage: i think that's a good idea. i can take a pass today.
[14:02] <jamespage> coreycb: pls
[14:07] <jamespage> coreycb: I've switched the branch builds to use stable/pike branches where possible....
[14:08] <coreycb> jamespage: there's a lot more in that postinst script that is general setup (non-sqlite) so i think i'll just drop the db migrations
[14:08] <coreycb> jamespage: ok thanks
[14:08] <jamespage> coreycb: yeah - just drop the sync calls would be my recommendation
[14:08] <coreycb> ok
[15:05] <nacc> cpaelzer: ack
[15:12] <gQuigs> or if I should spend time doing a single bugfix for neutron (https://bugs.launchpad.net/neutron/+bug/1696889)
[15:12] <gQuigs> (it is included in 10.0.3)
[17:34] <Epx998> todays task, make a 360 character regex readable for my lower level admins
[17:37] <Epx998> guess i cannot break this up into lines
[18:11] <nacc> ahasenack: as to raphael, is it actually a bug we have the file in the name we do?
[18:11] <nacc> ahasenack: cpaelzer implied it was delta, without explanation?
[18:11] <nacc> ahasenack: rather than adding yet-another symlink, is it better to drop the delta, and symlink to the 'correct' (Debian) location for b-c until 18.04 is out
[18:12] <ahasenack> nacc: you mean reverse the symlink?
[18:13] <ahasenack> nacc: do deb upgrades work "just fine" when a file becomes a symlink? No extra treatment?
[18:16] <nacc> ahasenack: you'll need a maintscript
[18:16] <ahasenack> I smelled something like that :)
[18:17] <nacc> I *think*
[19:25] <gunix> guys
[19:25] <gunix> is mysql_secure_installation required after a fresh install?
[19:48] <smoser> nacc,
[19:48] <smoser> git fetch --all
[19:48] <smoser> git pull
[19:48] <smoser> the second is redundant
[19:48] <smoser> is there a simple way to do that ?
[20:28] <nacc> smoser: to do which? :)
[20:28] <nacc> smoser: git-fetch doesn't manipulate the branch pointed to by HEAD
[20:28] <nacc> smoser: git-pull does
[20:28] <smoser> right
[20:28] <smoser> git reset --hard <branch that this one tracked>
[20:29] <smoser> or git merge <branch that this branch tracked>
[20:29] <nacc> smoser: right, the notion would be the latter
[20:29] <nacc> smoser: becuase pull will only pull if it ffs
[20:29] <nacc> *FFs
[20:29] <nacc> or maybe it was, I'm trying to recall
[20:29] <nacc> there is pull --no-ff and pull --ff-only
[20:30] <nacc> smoser: so you want to do that easily, without using pull?
[20:32] <smoser> nacc, well, i'll go into a git dir and type:
[20:32] <smoser>  git fetch --all
[20:32] <smoser> which makes sense to me.
[20:32] <smoser> but say my 'master' is tracking origin/master
[20:32] <smoser> to update that  i have to 'git pull'
[20:32] <nacc> smoser: ah right
[20:32] <smoser> which goes and does (i think) git fetch origin
[20:33] <nacc> smoser: so if you "know" it was origin/master
[20:33] <nacc> smoser: you should be able to do a `git merge origin/master` after `git fetch --all` from master
[20:33] <nacc> and it will FF master to origin/master
[20:33] <smoser> right. i just was wondering if there as anything even that would fast forward only all my branches
[20:34] <smoser> i can script somethign for sure, but it seems like it is a common use case.
[20:34] <nacc> smoser: sorry, ENOPARSE -- you want to ff all possible branches that were identical to remote-branches when the remote-branches move?
[20:34] <smoser> especially for the case of 'master' tracking 'origin/master'
[20:34] <nacc> smoser: is that right?
[20:36] <smoser> often i use 'git fetch --all'. that takes quite a while as i have lots of remotes.
[20:36] <nacc> yep
[20:37] <smoser> after doing so, i then basically want 'master' branch to move to 'origin/master'
[20:37] <smoser> unless i've got changes locally.
[20:37] <smoser> that can be done with:
[20:37] <nacc> but only master?
[20:37] <smoser>   git checkout master
[20:37] <smoser>  git pull
[20:37] <nacc> yep
[20:37] <smoser> but git pull is a network operation
[20:37] <smoser> which is again slow.
[20:38] <nacc> and it's already done in theory because you just did fetch?
[20:38] <smoser> yeah. the network portion is already done.
[20:38] <smoser> so i want to fetch all the data
[20:38] <smoser> and then any branch locally that is tracking a remote branch, i'd like to fast forward it
[20:39] <smoser> (fast forward only, in case i have local changes)
[20:39] <nacc> (to be clear `git pull = git fetch; git merge FETCH_HEAD`)
[20:40] <nacc> smoser: ok, but why do you have a local branch that's identical to a remote-tracking branch?
[20:40] <nacc> smoser: just checkout the remote-tracking branch and be in a detached HEAD state
[20:41] <nacc> when you do need it
[20:41] <smoser> well, yeah. thats an option. i have master generally track origin/master. as then i checkout the thing, do a merge and push
[20:41] <smoser> git checkout master; git merge <something>; git push origin HEAD
[20:42] <smoser> but yeah, you're right. if i have tracking only branches that is kind of pointless.
[20:42] <nacc> yeah, I tend to only use local branches only when they differ from remote branches
[20:42] <nacc> and then delete them when they don't :)
[20:43] <nacc> but yeah, in general, I don't think there is a 'fetch and FF all my local branches that used to be identical to remote-tracking branches which have moved due to the fetch'
[20:43] <nacc> I am thinking you might be able to get `git pull` to do it on a per-remote basis (it uses remote.<repository>.fetch), but i'm not 100%
[20:46] <nacc> smoser: i think it points to what i said just now, though, the idea of local branches is they store state that's not present somewhere else. For branches from the remote, they are stored in the remote-tracking branches. There's not really any benefit to having a local branch that is identical to a remote branch (IMO). At least, once you get used to not having it :)
[20:47] <smoser> right. i guess its really just 'master' that typically is set up to track a remote and generally expected not to
[20:48] <smoser> er... generally expected not to differ
[20:48] <nacc> yeah
[20:48] <nacc> and that's why people use `git pull` for master
[22:15] <nacc> rbasak: i recalled why we have move now -- and i'm working on replacing it anyways. But it has to do with when we need to make changes to the pristine-tar contents (e.g. the importer). In that case, it's not sufficient to just start a new branch named pristine-tar at the same spot, we need to change the distribution's pristine-tar branch's contents
[22:17] <nacc> rbasak: basically, the difference between using a 'local' distribution pristine-tar branch and a remote-tracking one
[22:24] <nacc> rbasak: http://paste.ubuntu.com/25428010/