Re: [aur-general] TU Application - Felix Yan - results

2012-11-02 Thread Tom Gundersen
On Fri, Nov 2, 2012 at 12:20 PM, Ronald van Haren  wrote:
> On Fri, Nov 2, 2012 at 8:13 AM, Laurent Carlier  wrote:
>> Le vendredi 2 novembre 2012 09:10:47 Bartłomiej Piotrowski a écrit :
>>> The vote for Felix' application is over.
>>>
>>> Yes: 10
>>> No:   4
>>> Abstain:  7
>>> Total:   21
>>> Active TUs:  32
>>>
>>> Ioni states that conditions are met, so congratulations Felix!
>
> I don't want to stop the addition of Felix as a TU, but the quorum has
> not been reached...
>
> SVP( addition_of_TU, 5, 0.66, 7 );
>
> 21/32 = 0.656

Sorry to be pedantic with your pedantry, but 0.656 is 0.66 to two
decimal points, so if the rule is given to two decimal points (as
opposed to 0.660, 0.666, or 2/3, or something else), then it looks
strictly speaking correct to me.

-t


[aur-general] removal request

2012-10-29 Thread Tom Gundersen
Hi guys,

Could someone please delete the bootchart2 [0] package from AUR?

Cheers,

Tom

[0]: 


Re: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

2012-10-20 Thread Tom Gundersen
On Sat, Oct 20, 2012 at 3:02 AM, Kyle  wrote:
> According to Tom Gundersen:
> # Could you post your service file to the list (maybe inline if the list
> # does not accept attachments)? As Chris is no longer active, I'll push
> # a new espeakup with the service files. However, I don't use it myself,
> # so would be great if I could have something that was already tested
>
> No problem. It's tested here and works without any issues. Cut between the
> lines and edit as needed.

Thanks!

I put this (with minor modifications) in community-testing. Could
anyone confirm that it works as intended?

Cheers,

Tom


Re: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

2012-10-19 Thread Tom Gundersen
Hi Kyle,

On Fri, Oct 5, 2012 at 10:30 PM, Kyle  wrote:
> I have a working unit for espeakup, which I saw listed in this thread, but I
> seem to recall Chris mentioning that he already had one. Let me know if it's
> needed, and if so, where I should post it.

Could you post your service file to the list (maybe inline if the list
does not accept attachments)? As Chris is no longer active, I'll push
a new espeakup with the service files. However, I don't use it myself,
so would be great if I could have something that was already tested
:-)

Cheers,

Tom


Re: [aur-general] TU resignation: Chris Brannon

2012-10-07 Thread Tom Gundersen
Hi Chris,

On Sun, Oct 7, 2012 at 5:30 PM, Chris Brannon  wrote:
> I regret that it has come time for me to resign from Arch Linux, at
> least for now.

That's a real shame! I hope you'll be back with us in not too long. In
the meantime best of luck with your new job!

Cheers,

Tom


Re: [aur-general] [REMINDER] systemd conversion

2012-10-07 Thread Tom Gundersen
On Oct 7, 2012 9:10 AM, "Tobias Powalowski" <
tobias.powalow...@googlemail.com> wrote:
> - hpoj I don't have the hardware anymore

Maybe this should be dropped then?

T


Re: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

2012-10-06 Thread Tom Gundersen
On Thu, Oct 4, 2012 at 8:57 PM, Daniel Isenmann  wrote:
> feel free to do the above packages. I'm totally busy with my real life
> right now and don't have time to do it at the moment.

Put them both (mono+xsp) in testing. Could you (or anyone else who use
them) let me know if they are ok to go to extra?

Cheers,

Tom


Re: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

2012-10-04 Thread Tom Gundersen
On Thu, Oct 4, 2012 at 9:12 PM, David J. Haines  wrote:
> Is there now any equivalent to .pacnew files for what would have been
> configuration files in /etc/conf.d? That is to say, if before a user
> edited /etc/conf.d/ and that file received a newer version in
> its package, a .pacnew file would be left behind, indicating that the
> user should set about merging his/her custom configuration into the
> newer "stock" configuration. Very useful, that. Now, however, it would
> seem that the user will never see such a message (even though
> potentially critical changes have been made to the unit file) because
> the custom unit file in /etc/systemd/... won't be tracked by pacman.
>
> Is there a good solution for detecting such changes, so that users can
> once again merge their necessary changes into the systemd equivalents of
> /etc/conf.d files?

Using Includes rather than copying the full service file reduces this
problem somewhat. Moreover, there is the systemd-delta tool which is
quite useful (it shows you the "diff" between the shipped service file
and the actual one that you are using).

-t


Re: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

2012-10-04 Thread Tom Gundersen
On Thu, Oct 4, 2012 at 8:58 PM, Matthew Monaco  wrote:
> This will do what rc.d/webfsd does with conf.d/webfsd:
> webfsd.service -
> [Unit]
> Description=webfsd
> Documentation=man:webfsd(1)
> After=network.target
>
> [Service]
> ExecStart=/usr/bin/webfsd -p 8080 -u nobody -R /srv/http -f index.html -F
>
> [Install]
> WantedBy=multi-user.target
>
>
> But I think an EnvironmentFile is useful for this service as it only takes
> config on the command line.
> webfsd@.service 
> [Unit]
> Description=webfsd
> Documentation=man:webfsd(1)
> After=network.target
>
> [Service]
> EnvironmentFile=/etc/webfs/%i.conf
> ExecStart=/usr/bin/webfsd $WEBFSD_ARGS -F
>
> [Install]
> WantedBy=multi-user.target

It depends on the service/daemon of course, so there might be a case
for doing this. I would say to keep it simple in general (the first
file you pasted), but if it turns out that there is no way to make it
generic enough (e.g., in the case of domainname literally every admin
would need to tweak the file), then using EnvFile might make sense.

I would, however, really resist using instances of config files as you
did here, unless that is really a common scenario (I don't know this
software at all, so might be). Let's keep it simple :-)

-t


Re: [aur-general] [arch-dev-public] [REMINDER] systemd conversion

2012-10-04 Thread Tom Gundersen
On Thu, Oct 4, 2012 at 8:31 PM, Matthew Monaco  wrote:
> Is there a general strategy as far as reusing /etc/conf.d/? A lot of units can
> use those as environment files to work as drop-in replacements for the rc.d
> scripts, but there's probably more systemd-ish ways of configuring most units.

The general strategy is "don't do that". The reason being that such a
service file would never be acceptable upstream, as /etc/conf.d/ is
arch-specific. This means that we will likely have to change it again
in the future and it seems more natural to have the break now rather
than at random times later.

The ideal way to set things up is: don't use EnvironmentFile unless
you must. If you can, set up the service file so that it can give a
reasonable default out-of-the-box without further configuration.
Moreover, prefer configurations to happen in the native config files
of the service if they exist, rather than on the commandline. Lastly,
the expectation should be that in case the user/admin needs to tweak
the service file, this can be done by copying it to /etc/systemd/ and
editing it there, rather than editing a config file.

To be a bit less abstract:

 * An example of where I could see no way but use EnvironmentFile is
for domainname.service in yp-tools.
 * An example of where one might argue that an EnvironmentFile would
be useful, but where I think I found a reasonable way to avoid it is
transmission-cli.

Cheers,

Tom


Re: [aur-general] [REMINDER] systemd conversion

2012-10-04 Thread Tom Gundersen
On Thu, Oct 4, 2012 at 8:27 PM, Tom Gundersen  wrote:
> On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen  wrote:
>> Hi guys,
>>
>> Thanks to everyone who converted their packages to use native systemd
>> service files since my last email.
>>
>> There are stil 66 packages remaining in our TODO however (10 from
>> extra and the rest from community):
>> https://www.archlinux.org/todo/178/.
>
> I got a request from a user eager to help to post the full list (our
> TODO lists are password protected, mostly by accident I think):

And then Dave points out that there is indeed a public version:
<https://www.archlinux.org/todolists/#178>.

I'll shut up now,

Tom


Re: [aur-general] [REMINDER] systemd conversion

2012-10-04 Thread Tom Gundersen
On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen  wrote:
> Hi guys,
>
> Thanks to everyone who converted their packages to use native systemd
> service files since my last email.
>
> There are stil 66 packages remaining in our TODO however (10 from
> extra and the rest from community):
> https://www.archlinux.org/todo/178/.

I got a request from a user eager to help to post the full list (our
TODO lists are password protected, mostly by accident I think):

x86_64  Community   esekeyd 1.2.7-2 cbrannonIncomplete
x86_64  Community   espeakup0.71-4  cbrannonIncomplete
x86_64  Community   mldonkey3.1.3-1 cbrannonIncomplete
x86_64  Community   webfs   1.21-7  cbrannonIncomplete
x86_64  Community   gkrellm 2.3.5-2 daenyth Incomplete
any Community   lastfmsubmitd   1.0.6-5 daenyth Incomplete
x86_64  Community   noip2.1.9-3 daenyth Incomplete
x86_64  Extra   mono2.10.8-1daniel  Incomplete
x86_64  Extra   xsp 2.10.2-3daniel  Incomplete
x86_64  Extra   pdns2.9.22.6-1  jgc Incomplete
x86_64  Extra   pdns-recursor   3.3-2   jgc Incomplete
x86_64  Extra   xorg-xfs1.1.2-1 jgc, andyrtrIncomplete
x86_64  Community   boinc   7.0.25-1jlichtblau  Incomplete
x86_64  Community   boinc-nox   7.0.25-1jlichtblau  
Incomplete
x86_64  Community   monit   5.5-1   jlichtblau  Incomplete
x86_64  Community   quassel 0.8.0-1 jlichtblau, vesaIncomplete
x86_64  Community   partimage   0.6.9-2 lfleischer  Incomplete
x86_64  Community   snort   2.9.3.1-1   lfleischer  Incomplete
x86_64  Extra   at  3.1.13-1romashkaIncomplete
x86_64  Extra   net-snmp5.7.1-3 romashkaIncomplete
any Community   ajaxterm0.11-5  spupykinIncomplete
x86_64  Community   bind-geodns 9.4.1-6 spupykinIncomplete
x86_64  Community   couchdb 1.2.0-4 spupykinIncomplete
x86_64  Community   dante   1.3.2-1 spupykinIncomplete
x86_64  Community   darkstat3.0.715-2   spupykin
Incomplete
x86_64  Community   dbmail  3.0.2-4 spupykinIncomplete
x86_64  Community   dictd   1.12.0-4spupykinIncomplete
any Community   dkfilter0.11-8  spupykinIncomplete
x86_64  Community   dspam   3.10.2-1spupykinIncomplete
x86_64  Community   ejabberd2.1.11-3spupykin
Incomplete
x86_64  Community   freeradius  2.2.0-2 spupykinIncomplete
any Community   gnump3d 3.0-6   spupykinIncomplete
x86_64  Community   gnunet  0.9.3-1 spupykinIncomplete
x86_64  Community   inputattach 1.24-5  spupykinIncomplete
x86_64  Community   ipsec-tools 0.8.0-3 spupykinIncomplete
x86_64  Community   ircservices 5.1.24-2spupykin
Incomplete
any Community   jmc 0.2.3-5 spupykinIncomplete
x86_64  Community   mcelog  1.0pre3-3   spupykinIncomplete
x86_64  Community   mediaproxy  2.5.2-2 spupykinIncomplete
x86_64  Community   opendkim2.6.7-1 spupykinIncomplete
x86_64  Community   opensips1.8.1-1 spupykinIncomplete
x86_64  Community   osiris  4.2.3-4 spupykinIncomplete
x86_64  Community   p3scan  2.3.2-6 spupykinIncomplete
any Community   postgrey1.34-5  spupykinIncomplete
x86_64  Community   pound   2.6-2   spupykinIncomplete
x86_64  Community   pptpd   1.3.4-10spupykinIncomplete
any Community   pyaimt  0.8.0.1-4   spupykinIncomplete
any Community   pyicqt  0.8.1.5-4   spupykinIncomplete
any Community   pymsnt  0.11.3-6spupykinIncomplete
any Community   pyrss   0.9.9.1-9   spupykinIncomplete
x86_64  Community   ser2net 2.7-2   spupykinIncomplete
x86_64  Community   sysstat 10.1.1-1spupykinIncomplete
any Community   trac1.0-1   spupykinIncomplete
x86_64  Community   ultimate-ircd   3.0.2-5 spupykinIncomplete
x86_64  Community   unrealircd  3.2.9-2 spupykinIncomplete
x86_64  Community   xl2tpd  1.3.0-2 spupykinIncomplete
x86_64  Community   xmms2   0.8DrO_o-7  spupykinIncomplete
any Community   yahoo-t 0.4-4   spupykinIncomplete
x86_64  Extra   hpoj0.91-17 tpowa   Incomplete
x86_64  Extra   kexec-tools 2.0.3-1 tpowa   Incomplete
x86_64  Extra   usermin 1.520-1 tpowa   Incomplete
x86_64  Extra   vde22.3.2-1 tpowa   Incomplete
x86_64  Community   tinc1.0.19-2tredaelli   Incomplete
x86_64  Community   courier-authlib 0.64.0-2Incomplete
x86_64  Community   

[aur-general] [REMINDER] systemd conversion

2012-10-04 Thread Tom Gundersen
Hi guys,

Thanks to everyone who converted their packages to use native systemd
service files since my last email.

There are stil 66 packages remaining in our TODO however (10 from
extra and the rest from community):
https://www.archlinux.org/todo/178/.

It would be great if we can get the last few packages sorted so
nothing is left out when systemd moves to base. It might be that some
packages are pseudo-orphans (i.e., officially maintained, but not in
practice), so those packages we should probably drop if no one adopts
them.

If you (for whatever reason) don't think you will be converting your
packages in the near future, please let us know so we know which
packages to focus on when we help out with the conversion. In
particular those of you who have not converted any (or only a small
percentage) of your packages [0], it would be helpful to know your
intentions.

Cheers,

Tom

[0]:

cbrannon
daenyth
daniel
jlichtblau
romashka
spupykin
tpowa
tredaelli