| === mundus2018 is now known as mundus | ||
| === mundus is now known as Mundus | ||
| === Mundus is now known as mundus | ||
| lordievader | Good morning | 07:12 |
|---|---|---|
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:39 |
| 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:40 |
| hateball | Seems this exists https://github.com/jfurrow/flood | 10:41 |
| 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 | 10:42 |
| roaksoax | ~/win 8 | 13:16 |
| dpawlik | coreycb: I check your package | 13:34 |
| dpawlik | python-oslo.middleware | 13:34 |
| 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 :) ? | 13:35 |
| danpawlik | coreycb: pls let me know if you receive messages :) | 14:00 |
| === Guest72992 is now known as karstensrage | ||
| === karstensrage is now known as Guest14297 | ||
| === Guest14297 is now known as karstensrage | ||
| coreycb | danpawlik: hi, i just poked in #ubuntu-devel to ask for sru review | 14:23 |
| danpawlik | BTW good that puppet integration tests doesn't test nova policy.json :P | 14:29 |
| danpawlik | coreycb: ^^ | 14:30 |
| danpawlik | coreycb: because if it test, it should raise an error :) | 14:30 |
| coreycb | danpawlik: is there a bug? | 14:31 |
| 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:33 |
| coreycb | Ok if there's a bug in the package please let me know | 14:34 |
| danpawlik | coreycb: sure :) | 14:34 |
| danpawlik | coreycb: If puppet community will not accept my PS | 14:35 |
| danpawlik | I will come to you :) | 14:35 |
| coreycb | danpawlik: why can't it apply new rules to the policy.json? is this something to-do with in-code policy defaults? | 14:38 |
| 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:41 |
| 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:42 |
| 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:43 |
| coreycb | danpawlik: i thought the point was to not require the file unless overriding defaults | 14:44 |
| 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:46 |
| danpawlik | and puppet-integration tests | 14:47 |
| coreycb | danpawlik: ah ok, good luck :) | 14:47 |
| === chmurifree is now known as chmuri | ||
| === Epx998- is now known as Epx998 | ||
| 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:08 |
| 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:09 |
| 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:10 |
| nacc | rbasak: pocket copies that establish a new pocket? | 16:12 |
| 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:13 |
| 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:14 |
| rbasak | Hmm. | 16:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| nacc | rbasak: +1 | 16:19 |
| nacc | rbasak: tbh, I *think* we did what you are suggesting originally. But there were some corner cases that simply didnn't work | 16:20 |
| 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:21 |
| 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:22 |
| nacc | yeah, it's possible also as we've solidified the rest of the algorithm, it's doable now | 16:23 |
| Epx998 | is there a different log aside from syslog to see why a system is read only? | 16:29 |
| sarnold | dmesg? | 16:30 |
| sarnold | journalctl? | 16:30 |
| sarnold | serial console? early printk? | 16:30 |
| Epx998- | hmm | 16:33 |
| RoyK | Epx998-: which filesystem is it that's read only? | 17:00 |
| nacc | cpaelzer: rbasak: are people using git-{merge,reconstruct}-changelog from the snap? | 17:26 |
| 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:28 |
| 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:29 |
| nacc | i think i am going to drop them from the snap (for now), so I can focus on getting git-ubunntu working | 17:30 |
| rbasak | nacc: +1 | 17:36 |
| 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:45 |
| 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:49 |
| rbasak | I'm not sure I know what these hooks are :-/ | 17:57 |
| rbasak | Is this a setuptools thing? | 17:58 |
| 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:01 |
| nacc | testing it now | 18:02 |
| nacc | rbasak: w00t, hooks are now a resource and ship with setup.py properly (as do our txt files) | 18:40 |
| rbasak | Ah | 18:44 |
| rbasak | Nice. Thanks! | 18:44 |
| rbasak | nacc: are you provisionally available for a HO at 2000 UTC (~45 minutes I think)? | 19:16 |
| nacc | rbasak: yes | 19:18 |
| nacc | rbasak: i'm here whenever you are ready | 20:03 |
| rbasak | nacc: omw | 20:04 |
| nacc | rbasak: standup HO? | 20:04 |
| rbasak | ack | 20:04 |
| === Guest76567 is now known as karstensrage | ||
| Epx998 | nub question - is there a single line command for adding users to sudo? without going into an editor? | 21:17 |
| sdeziel | Epx998: adduser foo sudo | 21:18 |
| Epx998 | easy enough, there a NOPASSWD option that can be passed too? | 21:20 |
| 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:22 |
| Epx998 | yeah thats good nuff for me | 21:23 |
| Epx998 | team getting these servers can fix their own sudoers file after the fact | 21:23 |
| Epx998 | ill just make sudo "work" | 21:24 |
| qman__ | Epx998: you can craft specific sudoers files and put them in /etc/sudoers.d/ | 21:32 |
| 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:33 |
| RoyK | Epx998: ansible's lineinfile will do it easily, or use groups as mentioned above | 21:34 |
| 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 | 21:37 |
| RoyK | Epx998: for two users, merely editing a sudoers file manually can't be too hard | 22:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!