[01:19] 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] nacc: the libvirt import is good now, I assume you removed it from the blacklist so it will stay current right? [05:44] and good morning everybody [05:50] nacc: s/remove from blacklist/added to whitelist/ but you know what I meant anyway [09:14] Hi All [09:15] 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] 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] that is - only looked for ssh auth with AD, but should be the same, more or less [09:51] I guess it's a PAM thing after all [09:54] RoyK: yeap, I think also it should be done by /etc/pam.s/xrdp-sesman [09:55] but I didn't found any example or solution that works 100% [09:57] not sure - sorry - never tried myself [09:57] sure, thx [10:07] hey all [10:15] Hi all. Will pinning look for dependencies of a certain package i wish to upgrade or simply forcefully upgrade that one package? [10:41] i have a quick question I am setting up a server with a particular user which will be SFTP access only. [10:41] 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] when I try to connect via filezilla its giving me an EOF message and its unable to connect [10:42] does the user need to have a bash shell [10:42] to be able to sftp [10:44] try rssh [10:45] it's made for just that sort of stuff [10:54] RoyK: hey i remember your name hehe. i managed it seems like a line needs to be changed in the ssh config [10:54] 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] eagles0513875: that requires chrooting, which is a longer story [10:59] 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] I know it was just released, but any plans to bump neutron ocata to 10.0.3? [14:00] jamespage: do you know the history behind running db sync commands in our packages when there's no connection string? [14:00] jamespage: for example: https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/nova/tree/debian/nova-common.postinst#n50 [14:00] i'd like to limit that check to the 2nd sqlite check ^ [14:00] coreycb: gah we duped on https://bugs.launchpad.net/ubuntu/+source/python-pyperclip/+bug/1713617 [14:00] Launchpad bug 1713617 in xclip (Ubuntu) "[MIR] python-pyperclip, xclip" [High,New] [14:00] jamespage: ah shoot, i should've pinged you [14:01] coreycb: no worries - xclip looks rusty fwiw xsel might be better [14:01] coreycb: re running db syncs; I'll all up for disabling those completely in the packaging - they create nothing but woes [14:01] I'd hoped to have spent time of those earlier in cycle [14:01] but tbh I think we could drop them now anyway [14:02] coreycb: what do you think? [14:02] coreycb: the maintainer script execution should be limited to the default sqlite based connection value only [14:02] jamespage: i think that's a good idea. i can take a pass today. [14:02] coreycb: pls [14:07] coreycb: I've switched the branch builds to use stable/pike branches where possible.... [14:08] 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] jamespage: ok thanks [14:08] coreycb: yeah - just drop the sync calls would be my recommendation [14:08] ok [15:05] cpaelzer: ack [15:12] or if I should spend time doing a single bugfix for neutron (https://bugs.launchpad.net/neutron/+bug/1696889) [15:12] Launchpad bug 1696889 in neutron "external_dns_driver causes floating ip association to fail" [Undecided,Fix released] [15:12] (it is included in 10.0.3) [17:34] todays task, make a 360 character regex readable for my lower level admins [17:37] guess i cannot break this up into lines [18:11] ahasenack: as to raphael, is it actually a bug we have the file in the name we do? [18:11] ahasenack: cpaelzer implied it was delta, without explanation? [18:11] 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] nacc: you mean reverse the symlink? [18:13] nacc: do deb upgrades work "just fine" when a file becomes a symlink? No extra treatment? [18:16] ahasenack: you'll need a maintscript [18:16] I smelled something like that :) [18:17] I *think* [19:25] guys [19:25] is mysql_secure_installation required after a fresh install? [19:48] nacc, [19:48] git fetch --all [19:48] git pull [19:48] the second is redundant [19:48] is there a simple way to do that ? [20:28] smoser: to do which? :) [20:28] smoser: git-fetch doesn't manipulate the branch pointed to by HEAD [20:28] smoser: git-pull does [20:28] right [20:28] git reset --hard [20:29] or git merge [20:29] smoser: right, the notion would be the latter [20:29] smoser: becuase pull will only pull if it ffs [20:29] *FFs [20:29] or maybe it was, I'm trying to recall [20:29] there is pull --no-ff and pull --ff-only [20:30] smoser: so you want to do that easily, without using pull? [20:32] nacc, well, i'll go into a git dir and type: [20:32] git fetch --all [20:32] which makes sense to me. [20:32] but say my 'master' is tracking origin/master [20:32] to update that i have to 'git pull' [20:32] smoser: ah right [20:32] which goes and does (i think) git fetch origin [20:33] smoser: so if you "know" it was origin/master [20:33] smoser: you should be able to do a `git merge origin/master` after `git fetch --all` from master [20:33] and it will FF master to origin/master [20:33] right. i just was wondering if there as anything even that would fast forward only all my branches [20:34] i can script somethign for sure, but it seems like it is a common use case. [20:34] smoser: sorry, ENOPARSE -- you want to ff all possible branches that were identical to remote-branches when the remote-branches move? [20:34] especially for the case of 'master' tracking 'origin/master' [20:34] smoser: is that right? [20:36] often i use 'git fetch --all'. that takes quite a while as i have lots of remotes. [20:36] yep [20:37] after doing so, i then basically want 'master' branch to move to 'origin/master' [20:37] unless i've got changes locally. [20:37] that can be done with: [20:37] but only master? [20:37] git checkout master [20:37] git pull [20:37] yep [20:37] but git pull is a network operation [20:37] which is again slow. [20:38] and it's already done in theory because you just did fetch? [20:38] yeah. the network portion is already done. [20:38] so i want to fetch all the data [20:38] and then any branch locally that is tracking a remote branch, i'd like to fast forward it [20:39] (fast forward only, in case i have local changes) [20:39] (to be clear `git pull = git fetch; git merge FETCH_HEAD`) [20:40] smoser: ok, but why do you have a local branch that's identical to a remote-tracking branch? [20:40] smoser: just checkout the remote-tracking branch and be in a detached HEAD state [20:41] when you do need it [20:41] 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] git checkout master; git merge ; git push origin HEAD [20:42] but yeah, you're right. if i have tracking only branches that is kind of pointless. [20:42] yeah, I tend to only use local branches only when they differ from remote branches [20:42] and then delete them when they don't :) [20:43] 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] I am thinking you might be able to get `git pull` to do it on a per-remote basis (it uses remote..fetch), but i'm not 100% [20:46] 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] right. i guess its really just 'master' that typically is set up to track a remote and generally expected not to [20:48] er... generally expected not to differ [20:48] yeah [20:48] and that's why people use `git pull` for master [22:15] 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] rbasak: basically, the difference between using a 'local' distribution pristine-tar branch and a remote-tracking one [22:24] rbasak: http://paste.ubuntu.com/25428010/ === Epx998- is now known as Epx998