Re: The trouble with torrents
So, I was reading the other day that aria2 also has control over xmlrpc, and a web ui (iirc it is no packaged with aria, but another bit o the project.). So that could be an option as well. aria is my go to when I torrent, and has always seemed solid. Am So, 30. Sep, 2018 um 1:27 A. M. schrieb Mikolaj Izdebski : On 09/29/2018 01:24 AM, Kevin Fenzi wrote: On 09/26/2018 10:59 PM, Pablo Iranzo Gómez wrote: Hi Kevin, What about using transmission-daemon which is available in Fedora? (also console with optional Web UI) Yeah, we looked at it the last time, but it there were issues... I think the daemon version still pulled in the entire gtk stack or you couldn't manage it via config files. Looks like it might be better now... I've been successfully using transmission-daemon since January. It can definitely be managed via config files, but it expects to own config files - it overwrites them when the process terminates. This can be worked around easily, eg. by updating config files when the deamon is not running: - name: Create transmission config directory file: dest=/var/lib/transmission/.config/transmission-daemon/ state=directory owner=transmission group=transmission - name: Copy transmission config file template: src=settings.json.j2 dest=/var/lib/transmission/.config/transmission-daemon/settings.json register: settings_j2 - name: Stop transmission-daemon service: name=transmission-daemon state=stopped when: settings_j2.changed - name: Copy transmission config file again template: src=settings.json.j2 dest=/var/lib/transmission/.config/transmission-daemon/settings.json when: settings_j2.changed - name: Start and enable transmission-daemon service: name=transmission-daemon state=started enabled=true -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The trouble with torrents
On 09/29/2018 01:24 AM, Kevin Fenzi wrote: > On 09/26/2018 10:59 PM, Pablo Iranzo Gómez wrote: >> Hi Kevin, >> >> What about using transmission-daemon which is available in Fedora? >> >> (also console with optional Web UI) > > Yeah, we looked at it the last time, but it there were issues... > > I think the daemon version still pulled in the entire gtk stack or you > couldn't > manage it via config files. Looks like it might be better now... I've been successfully using transmission-daemon since January. It can definitely be managed via config files, but it expects to own config files - it overwrites them when the process terminates. This can be worked around easily, eg. by updating config files when the deamon is not running: - name: Create transmission config directory file: dest=/var/lib/transmission/.config/transmission-daemon/ state=directory owner=transmission group=transmission - name: Copy transmission config file template: src=settings.json.j2 dest=/var/lib/transmission/.config/transmission-daemon/settings.json register: settings_j2 - name: Stop transmission-daemon service: name=transmission-daemon state=stopped when: settings_j2.changed - name: Copy transmission config file again template: src=settings.json.j2 dest=/var/lib/transmission/.config/transmission-daemon/settings.json when: settings_j2.changed - name: Start and enable transmission-daemon service: name=transmission-daemon state=started enabled=true -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: epel7-infra and epel7 conflicts wrt pagure updates (or, can we have an epel7-infra DistTag?)
On 09/29/2018 01:16 AM, Kevin Fenzi wrote:
> On 09/27/2018 01:50 PM, Mikolaj Izdebski wrote:
>> On 09/27/2018 10:39 PM, Neal Gompa wrote:
>>> I'd like to propose that we change epel7-infra so that the DistTag
>>> defined in %dist is ".el7.infra" instead of ".el7". This will prevent
>>> the conflict and have the advantage that the infra tag is higher by
>>> default.
>>
>> +1 to use custom dist tags for infra builds. But I would like to see
>> this implemented for all infra repos, not only epel7-infra.
>
> Is there an easy way to do this?
I think that currently the easiest way would be creating a package (like
fedora-infra-srpm-macros) that would override %dist macro in a generic
way, eg:
%dist .%{?fedora:fc%{fedora}}%{?rhel:el%{rhel}}.infra
Then add this package to all infra tags, and to build and srpm-build
groups for these tags.
I can implement a PoC in staging.
>
> I'm ok with it, but perhaps we could do 'fedora-infra' or 'fi' since we
> aren't the only infrastructure out there. :)
>
> kevin
>
>
>
>
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: [PATCH] Add a RabbitMQ vhost for pubsub (fedmsg) and configure an HA policy
On 09/28/2018 07:15 PM, Kevin Fenzi wrote: > +1, but should we name that queue something like 'fedora-messaging' to > be more descriptive? Or does that matter much? A virtual host in RabbitMQ is like a namespace for AMQP that you can apply permissions to. The "pubsub" virtual host will contain all the exchanges and queues we use to replace general fedmsg usage. There could be others for individual applications that want to use AMQP for, say, Celery tasks. My thinking was that "pubsub" was more descriptive for a newcomer than "fedmsg" or something since it's general publishing and subscribing for apps and services. That being said, names are hard and I welcome alternatives, so if people think something else is more descriptive now's the best time to voice your opinion. -- Jeremy Cline XMPP: jer...@jcline.org IRC: jcline ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
