[07:12] <lordievader> Good morning
[10:34] <albech> good morning. Looking for a bittorrent client with a webui front that can be run on my server.
[10:34] <hateball> albech: Transmission
[10:34] <hateball> You can also connect with the desktop app if you like
[10:35] <albech> hateball: interesting always thought transmission was only a desktop app
[10:35] <albech> was looking at deluge, but it seems a bit bloated for what we need
[10:35] <hateball> Nope, you can run transmission-daemon
[10:36] <albech> need to sync large data sets via torrent between 8 sites
[10:36] <hateball> I was going to suggest Deluge also, but I personally left it due to being too fat
[10:36] <hateball> (I run torrents on RPi)
[10:36] <albech> hateball: nice
[10:37] <hateball> Transmission even has an ncurses interface iirc
[10:37] <oerheks> deluge a bit bloated ??
[10:37] <albech> oerheks: i have only looked at their website..
[10:39] <albech> hateball: would be nice with some daemon as you said so the process can be automated. We are looking at ~200tb data in smaller chunks.
[10:40] <albech> and the number of locations will go up to 16+ over the next year.
[10:40] <hateball> albech: there is of course rtorrent
[10:40] <hateball> but I dunno if that has a webgui
[10:41] <hateball> Seems this exists https://github.com/jfurrow/flood
[10:42] <albech> interesting.. id hate to bloat something which really isnt needed.. will have a look at that too.. Cheers and thanks a ton
[10:42] <hateball> albech: https://help.ubuntu.com/community/TransmissionHowTo
[13:16] <roaksoax> ~/win 8
[13:34] <dpawlik> coreycb: I check your package
[13:34] <dpawlik> python-oslo.middleware
[13:35] <dpawlik> from pike repo on Openstck ocata release
[13:35] <dpawlik> and I can say: it works and all basic comands also
[13:35] <dpawlik> like nova list, neutron net-list etc
[13:35] <dpawlik> coreycb: Is possible to move from pike to ocata staging pliz :) ?
[14:00] <danpawlik> coreycb: pls let me know if you receive messages :)
[14:23] <coreycb> danpawlik: hi, i just poked in #ubuntu-devel to ask for sru review
[14:29] <danpawlik> BTW good that puppet integration tests doesn't test nova policy.json :P
[14:30] <danpawlik> coreycb: ^^
[14:30] <danpawlik> coreycb: because if it test, it should raise an error :)
[14:31] <coreycb> danpawlik: is there a bug?
[14:33] <danpawlik> coreycb: yup. Puppet is crying that it can not apply new rules on policy.json because.. File is available
[14:33] <danpawlik> but I think this bug should be resolved by puppet side
[14:34] <coreycb> Ok if there's a bug in the package please let me know
[14:34] <danpawlik> coreycb: sure :)
[14:35] <danpawlik> coreycb: If puppet community will not accept my PS
[14:35] <danpawlik> I will come to you :)
[14:38] <coreycb> danpawlik: why can't it apply new rules to the policy.json? is this something to-do with in-code policy defaults?
[14:41] <coreycb> danpawlik: it looks like we dropped the policy.json in ocata since default policy is registered in code.
[14:41] <danpawlik> coreycb: Not in-code policy defaults, but... in puppet. Puppet want to save new policy rules in policy.json but it can not find the file so it raise an error. Normall touch /etc/nova/policy.json is resolving the problem
[14:42] <danpawlik> so I will do that in puppet module
[14:42] <danpawlik> if patch set will be not accepted by puppet community, we should consider create the file
[14:43] <danpawlik> it can be empty
[14:43] <danpawlik> coreycb: but for now I try to do that in puppet module
[14:43] <coreycb> danpawlik: if a file is required then i think that would be a bug upstream for nova
[14:44] <coreycb> danpawlik: i thought the point was to not require the file unless overriding defaults
[14:46] <danpawlik> coreycb: I think most of puppet cores/reviewers did not know that such problem is
[14:46] <danpawlik> coreycb: I can say, you found a bug in puppet-nova module :)
[14:47] <danpawlik> and puppet-integration tests
[14:47] <coreycb> danpawlik: ah ok, good luck :)
[16:08] <rbasak> nacc: chatted with Colin and he suggested a commit graph change for pocket copies (will cause hash-abi-break). I need to think it through since I previously didn't think we could do what he suggests, but probably worth a sync with you (HO?) so you can think about it too.
[16:09] <rbasak> In short: he doesn't think that pocket copies necessarily need their own commits and we should just be able to move forward the branch pointer in most cases.
[16:09] <rbasak> I can't remember my logic for not doing that.
[16:10] <rbasak> It might be that it may then appear that the pocket previously had something that never got published.
[16:10] <rbasak> But Colin pointed out that it would appear like that anyway because of eg. changelog parents.
[16:12] <nacc> rbasak: pocket copies that establish a new pocket?
[16:13] <rbasak> Couldn't we just create a branch pointer at the import tag in that case?
[16:13] <nacc> rbasak: i'm asking what pocket copy you are referring to?
[16:13] <rbasak> Oh
[16:14] <rbasak> Any time the importer processes a Launchpad publication that already has an import atg.
[16:14] <nacc> rbasak: sorry. Yes, I understand what a pocket copy is. "necessarily need their own commit" implies the parenting is the same.
[16:14] <nacc> rbasak: and that would oly be true for a pocket copy where this is no publishing parent
[16:14] <rbasak> Ah
[16:14] <rbasak> Yes, that's it. We need to add a publishing parent.
[16:14] <rbasak> Thanks. I'll explain to Colin and see what he thinks.
[16:15] <rbasak> Hmm.
[16:16] <rbasak> What if we didn't add a publishing parent, and just move the branch pointer up assuming it's fast-forwarding?
[16:16] <rbasak> That'd lose the reflection of publishing history in the commit graph I suppose.
[16:16] <rbasak> Though that reflection is only available manually, since we don't have a good way of identifying the different types of parent except in the commit message.
[16:17] <rbasak> If we did this, would fast forwarding be possible most of the time?
[16:17] <nacc> rbasak: sorry, i'm deep in snapping right now
[16:17] <rbasak> np
[16:17] <nacc> do you want to put a HO on the cal for an hour from ow?
[16:17] <nacc> *now
[16:17] <nacc> so i can context switch
[16:18] <nacc> rbasak: or whenever later today
[16:18] <rbasak> I'm not sure I can get away right now. Later is fine - no need for you to context switch. I just wanted to make you aware of the discussion.
[16:19] <nacc> rbasak: +1
[16:20] <nacc> rbasak: tbh, I *think* we did what you are suggesting originally. But there were some corner cases that simply didnn't work
[16:21] <rbasak> That's the impression I got. I'd like to figure out what they were again and run them past Colin :)
[16:21] <nacc> yep
[16:22] <rbasak> In our discussion it was one of the first suggestions we made. Then as our discussion continued there were a few scenarios that came up where it would clearly be better if the commit graph appeared that way for those use cases.
[16:22] <rbasak> s/we/he/
[16:23] <nacc> yeah, it's possible also as we've solidified the rest of the algorithm, it's doable now
[16:29] <Epx998> is there a different log aside from syslog to see why a system is read only?
[16:30] <sarnold> dmesg?
[16:30] <sarnold> journalctl?
[16:30] <sarnold> serial console? early printk?
[16:33] <Epx998-> hmm
[17:00] <RoyK> Epx998-: which filesystem is it that's read only?
[17:26] <nacc> cpaelzer: rbasak: are people using git-{merge,reconstruct}-changelog from the snap?
[17:28] <cpaelzer> nacc: people = ?
[17:28] <cpaelzer> nacc: I do
[17:28] <cpaelzer> well OTOH no merges for a while now
[17:28] <nacc> cpaelzer: you use those tools and not `git ubuntu merge` ?
[17:29] <cpaelzer> nacc: no
[17:29] <cpaelzer> nacc: I use git ubuntu X and thought that is using the things from the snap for me as needed
[17:29] <cpaelzer> I'm not like calling into the snap's binaries if that was the queston
[17:29] <nacc> cpaelzer: no, I believe someoe (you? :) asked they be there while merge was in-progress
[17:29] <nacc> yeah
[17:30] <nacc> i think i am going to drop them from the snap (for now), so I can focus on getting git-ubunntu working
[17:36] <rbasak> nacc: +1
[17:45] <nacc> rbasak: thanks, urgent questionn for you: what is the setuptools way to isntall our hooks? :)
[17:45] <nacc> rbasak: the snap is now using the python3 plugin, which is working great (and fixes a bunch of other issues), but now git-ubuntu won't find hooks (as it's looking in /snap/git-ubuntu/x1/lib/python3.5/site-packages/gitubuntu/../hooks)
[17:49] <nacc> rbasak: oh i see i can 'organize' it into our snap
[17:49] <nacc> but i don't think we want it at lib/python3.5/site-packages/hooks ?
[17:57] <rbasak> I'm not sure I know what these hooks are :-/
[17:58] <rbasak> Is this a setuptools thing?
[18:01] <nacc> rbasak: they are your hooks for empty directories
[18:01] <nacc> that get isntalled on every clone
[18:01] <nacc> rbasak: i think if i mv them to gitubuntu/ and make them a pkg_resource, then it will dtrt
[18:02] <nacc> testing it now
[18:40] <nacc> rbasak: w00t, hooks are now a resource and ship with setup.py properly (as do our txt files)
[18:44] <rbasak> Ah
[18:44] <rbasak> Nice. Thanks!
[19:16] <rbasak> nacc: are you provisionally available for a HO at 2000 UTC (~45 minutes I think)?
[19:18] <nacc> rbasak: yes
[20:03] <nacc> rbasak: i'm here whenever you are ready
[20:04] <rbasak> nacc: omw
[20:04] <nacc> rbasak: standup HO?
[20:04] <rbasak> ack
[21:17] <Epx998> nub question - is there a single line command for adding users to sudo?  without going into an editor?
[21:18] <sdeziel> Epx998: adduser foo sudo
[21:20] <Epx998> easy enough, there a NOPASSWD option that can be passed too?
[21:22] <sdeziel> Epx998: no as the above simply joins the foo user to the sudo group and this group is by default prompted for password when elevating privileges
[21:23] <Epx998> yeah thats good nuff for me
[21:23] <Epx998> team getting these servers can fix their own sudoers file after the fact
[21:24] <Epx998> ill just make sudo "work"
[21:32] <qman__> Epx998: you can craft specific sudoers files and put them in /etc/sudoers.d/
[21:33] <qman__> so you don't have to modify the system file
[21:33] <RoyK> Epx998: just edit sudoers or script it
[21:33] <RoyK> Epx998: shouldn't be that hard
[21:34] <RoyK> Epx998: ansible's lineinfile will do it easily, or use groups as mentioned above
[21:37] <Epx998> im adding as much as i can to the preseed, i dont want to touch anything after the fact
[21:37] <Epx998> they want 2 users, so i added a late command to add the 2nd account, with sudo i hope
[22:08] <RoyK> Epx998: for two users, merely editing a sudoers file manually can't be too hard