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