Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Kaiting Chen
On Fri, Apr 8, 2011 at 11:32 AM, David C. Rankin 
drankina...@suddenlinkmail.com wrote:

 On 04/06/2011 10:34 PM, Heiko Baums wrote:

 Upstream stability makes sense. If redhat is behind cronie, then that
   seems like the logical choice.

 Why is this logical? Is it the developer what makes a software good or
 is it the features and the stability? If Redhat's cronie has less
 features than fcron then fcron is the logical choice, of course.


  You are correct. The long term stability was just my thought. Like I said
 earlier in my message -- It doesn't matter to me which cron we have -- as
 long as we have one that works :)  I have no say in the matter, so I will,
 of course, defer to whatever decision you guys reach. I just want to make
 sure we have a cron by default :)


So what's the status here? I pulled cronie into [community-testing] a couple
of days ago and will probably merge it into [community] soon. So that's the
one I vote.

But regardless of which one we choose in my opinion the sooner we get rid of
dcron the better. --Kaiting.

-- 
Kiwis and Limes: http://kaitocracy.blogspot.com/


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Sven-Hendrik Haase
On 21.04.2011 08:32, Kaiting Chen wrote:
 On Fri, Apr 8, 2011 at 11:32 AM, David C. Rankin 
 drankina...@suddenlinkmail.com wrote:

 On 04/06/2011 10:34 PM, Heiko Baums wrote:

 Upstream stability makes sense. If redhat is behind cronie, then that
  seems like the logical choice.
 Why is this logical? Is it the developer what makes a software good or
 is it the features and the stability? If Redhat's cronie has less
 features than fcron then fcron is the logical choice, of course.

  You are correct. The long term stability was just my thought. Like I said
 earlier in my message -- It doesn't matter to me which cron we have -- as
 long as we have one that works :)  I have no say in the matter, so I will,
 of course, defer to whatever decision you guys reach. I just want to make
 sure we have a cron by default :)

 So what's the status here? I pulled cronie into [community-testing] a couple
 of days ago and will probably merge it into [community] soon. So that's the
 one I vote.

 But regardless of which one we choose in my opinion the sooner we get rid of
 dcron the better. --Kaiting.

I second this suggestion. cronie upstream isn't dead at all. cronie is a
drop-in unlike fcron which was favored earlier. Kaiting said he would
even be willing to become a developer to maintain this in [core] himself
in case no other developer was  interested.

Is there anything that would keep us from making it default and also
replace dcron?

-- Sven-Hendrik


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Grigorios Bouzakis
Kaiting Chen wrote:

 So what's the status here? I pulled cronie into [community-testing] a couple
 of days ago and will probably merge it into [community] soon. So that's the
 one I vote.

 But regardless of which one we choose in my opinion the sooner we get rid of
 dcron the better. --Kaiting.

You forgot to remove it from the AUR though:
https://aur.archlinux.org/packages.php?ID=37260

No matter which cron implemention replaces dcron that means that most
likely dcron will be dropped to the AUR, so it would be nice having 2
implementions in binary form, despite the fact that cronie only has 4
votes.

Has anyone actually tested it as a dcron replacement on Arch, now that
its built with anacron support?


Greg


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Lukas Fleischer
On Thu, Apr 21, 2011 at 02:32:42AM -0400, Kaiting Chen wrote:
 On Fri, Apr 8, 2011 at 11:32 AM, David C. Rankin 
 drankina...@suddenlinkmail.com wrote:
 
  On 04/06/2011 10:34 PM, Heiko Baums wrote:
 
  Upstream stability makes sense. If redhat is behind cronie, then that
seems like the logical choice.
 
  Why is this logical? Is it the developer what makes a software good or
  is it the features and the stability? If Redhat's cronie has less
  features than fcron then fcron is the logical choice, of course.
 
 
   You are correct. The long term stability was just my thought. Like I said
  earlier in my message -- It doesn't matter to me which cron we have -- as
  long as we have one that works :)  I have no say in the matter, so I will,
  of course, defer to whatever decision you guys reach. I just want to make
  sure we have a cron by default :)
 
 
 So what's the status here? I pulled cronie into [community-testing] a couple
 of days ago and will probably merge it into [community] soon. So that's the
 one I vote.
 
 But regardless of which one we choose in my opinion the sooner we get rid of
 dcron the better. --Kaiting.

I don't want to be pedantic, but what's the point of that? Moving
arbitrary cron daemons that no one uses to [community] is nonsense
(according to the TU guidelines, you shouldn't even have moved it
without prior discussion and consensus on aur-general at all - but as I
said before, I don't want to be pedantic here...)

Adding yet another cron daemon to our repositories makes sense as soon
as there's a clear decision to switch default daemons. Just moving low
usage stuff to [community] because you're able to do so definitely
doesn't...


[arch-general] [arch-dev-public] [signoff] mkinitcpio 0.6.11

2011-04-21 Thread Thomas Bächler
Version 0.6.10 was busted, this time everything should be fine (finally).

Thomas Bächler (2):
  Rewrite parse_cmdline (again)
  Release version 0.6.11

There is a problem: The new filesystem package was moved to core and
creates /run, but /run is not usable as it is not a world-writable
tmpfs. We need this and the new initscripts (which should be released
soon) in core quickly. Moving mkinitcpio only should suffice for now.

Please sign off quickly.

This is a copy of the last announcement:

Fixes:
- FS#23467
- FS#22080
- FS#13900
- FS#23622
It also introduces /run.

Please sign off. Shortlog:

Thomas Bächler (6):
  Fix broken command line parsing due to insufficient quoting
introduced in 42e8dba5dce4879e4a372c5c2fb5446b4e8bb16c.
  init: Unify/improve mount --move handling
  Introduce /run
  Allow initramfs to be completely silent:
  Fix problems in parsing the kernel command line
  Release mkinitcpio 0.6.10





signature.asc
Description: OpenPGP digital signature


Re: [arch-general] [arch-dev-public] [signoff] kernel26-2.6.38.3-1

2011-04-21 Thread dave reisner
On Apr 21, 2011 6:17 AM, Tom Gundersen t...@jklm.no wrote:

 On Thu, Apr 21, 2011 at 7:16 AM, Andreas Radke a.ra...@arcor.de wrote:
  Am Mon, 18 Apr 2011 07:29:20 +0200
  schrieb Tobias Powalowski t.p...@gmx.de:
  yes, i think this is because i enabled printk_time option.
 
  Once again somebody request something and we don't think about it
  and enable it without any need...
 
  The configuration item CONFIG_EARLY_PRINTK:

 CONFIG_PRINTK_TIME is not the same as CONFIG_EARLY_PRINTK. The former
 is very useful to make sense of dmesg (otherwise you dont know what
 messages belong together) and it should not have any negative side
 effects (I have been using it for years). The latter might be, as you
 say, annoying and should perhaps be removed, it is not new in this
 release though (it is from before the start of the packages repo)...

 Cheers,

 Tom

the kconfig for PRINTK_TIME doesn't mention that its only setting a default
behavior. The cmdline accepts printk.time= which can be set to 1/0 to
appropriately disable or enable.

Plus one to removing this as its really only good for debugging and making a
mess of your logs.

Dave


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Heiko Baums
Am Thu, 21 Apr 2011 08:48:04 +0200
schrieb Sven-Hendrik Haase s...@lutzhaase.com:

 I second this suggestion. cronie upstream isn't dead at all. cronie
 is a drop-in unlike fcron which was favored earlier.

Is it such a drop-in like the new dcron when dcron upstream was adopted
by this Arch user?

Better look at the features and the use cases (don't only think of some
24/7 servers, but also think of the desktop users) and not at some small
differences in the crontab syntax. It's definitely not such a big work
to re-adjust a few crontab entries if this is necessary at all. And this
work has to be done only once and can probably be done with sed.

And cronie still has only 4 votes in AUR after one year! Why? Could have
a reason as packages which are useful and/or necessary for several
people are usually getting a lot more votes in much less time.

I can be wrong, but I really have the feeling that switching the
default cron daemon to cronie will be a big mistake. And wasn't there
someone who wanted to test both daemons and write a feature comparison?
Nothing heard about it anymore.

Heiko


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Heiko Baums
Am Thu, 21 Apr 2011 13:18:33 +0200
schrieb Heiko Baums li...@baums-on-web.de:

 I can be wrong, but I really have the feeling that switching the
 default cron daemon to cronie will be a big mistake.

And, btw., what's about the licenses? fcron is GPL, cronie has a custom
license called ISC. I don't know this ISC but this should be checked
before.

Heiko


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Sebastian Köhler

On Thu, 21 Apr 2011 13:27:07 +0200, Heiko Baums wrote:
Am Thu, 21 Apr 2011 13:18:33 +0200 schrieb Heiko Baums 
li...@baums-on-web.de:
And, btw., what's about the licenses? fcron is GPL, cronie has a 
custom

license called ISC. I don't know this ISC but this should be checked
before.


http://en.wikipedia.org/wiki/ISC_license

I don't think these 3 lines need much checking.

--
The best thing about a boolean is even if you are wrong, you are only
off by a bit.


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Yaro Kasear
On Thursday, April 21, 2011 01:48:04 Sven-Hendrik Haase wrote:
 On 21.04.2011 08:32, Kaiting Chen wrote:
  On Fri, Apr 8, 2011 at 11:32 AM, David C. Rankin 
  
  drankina...@suddenlinkmail.com wrote:
  On 04/06/2011 10:34 PM, Heiko Baums wrote:
  Upstream stability makes sense. If redhat is behind cronie, then that
  
   seems like the logical choice.
  
  Why is this logical? Is it the developer what makes a software good or
  is it the features and the stability? If Redhat's cronie has less
  features than fcron then fcron is the logical choice, of course.
  
   You are correct. The long term stability was just my thought. Like I
   said
  
  earlier in my message -- It doesn't matter to me which cron we have --
  as long as we have one that works :)  I have no say in the matter, so I
  will, of course, defer to whatever decision you guys reach. I just want
  to make sure we have a cron by default :)
  
  So what's the status here? I pulled cronie into [community-testing] a
  couple of days ago and will probably merge it into [community] soon. So
  that's the one I vote.
  
  But regardless of which one we choose in my opinion the sooner we get rid
  of dcron the better. --Kaiting.
 
 I second this suggestion. cronie upstream isn't dead at all. cronie is a
 drop-in unlike fcron which was favored earlier. Kaiting said he would
 even be willing to become a developer to maintain this in [core] himself
 in case no other developer was  interested.
 
 Is there anything that would keep us from making it default and also
 replace dcron?
 
 -- Sven-Hendrik

I'm still trying to understand WHY we suddenly feel the need to replace dcron 
when its not even broken. Replacing packages with other packages purely 
because they're new is something Fedora and Ubuntu would do, I though Arch 
wasn't about arbitrarily replacing its defaults but using what was simple and 
what works.

Can someone explain to me why we think we need a new crond?


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Thomas S Hatch
On Thu, Apr 21, 2011 at 9:37 AM, Yaro Kasear y...@marupa.net wrote:

 On Thursday, April 21, 2011 01:48:04 Sven-Hendrik Haase wrote:
  On 21.04.2011 08:32, Kaiting Chen wrote:
   On Fri, Apr 8, 2011 at 11:32 AM, David C. Rankin 
  
   drankina...@suddenlinkmail.com wrote:
   On 04/06/2011 10:34 PM, Heiko Baums wrote:
   Upstream stability makes sense. If redhat is behind cronie, then that
  
seems like the logical choice.
  
   Why is this logical? Is it the developer what makes a software good
 or
   is it the features and the stability? If Redhat's cronie has less
   features than fcron then fcron is the logical choice, of course.
  
You are correct. The long term stability was just my thought. Like I
said
  
   earlier in my message -- It doesn't matter to me which cron we have --
   as long as we have one that works :)  I have no say in the matter, so
 I
   will, of course, defer to whatever decision you guys reach. I just
 want
   to make sure we have a cron by default :)
  
   So what's the status here? I pulled cronie into [community-testing] a
   couple of days ago and will probably merge it into [community] soon. So
   that's the one I vote.
  
   But regardless of which one we choose in my opinion the sooner we get
 rid
   of dcron the better. --Kaiting.
 
  I second this suggestion. cronie upstream isn't dead at all. cronie is a
  drop-in unlike fcron which was favored earlier. Kaiting said he would
  even be willing to become a developer to maintain this in [core] himself
  in case no other developer was  interested.
 
  Is there anything that would keep us from making it default and also
  replace dcron?
 
  -- Sven-Hendrik

 I'm still trying to understand WHY we suddenly feel the need to replace
 dcron
 when its not even broken. Replacing packages with other packages purely
 because they're new is something Fedora and Ubuntu would do, I though Arch
 wasn't about arbitrarily replacing its defaults but using what was simple
 and
 what works.

 Can someone explain to me why we think we need a new crond?


The discussion is based on upstream not responding to bugs in dcron and the
overall lack of upstream development/responsiveness.


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Grigorios Bouzakis
Yaro Kasear wrote:

 I'm still trying to understand WHY we suddenly feel the need to replace dcron 
 when its not even broken. Replacing packages with other packages purely 
 because they're new is something Fedora and Ubuntu would do, I though Arch 
 wasn't about arbitrarily replacing its defaults but using what was simple and 
 what works.

 Can someone explain to me why we think we need a new crond?


Because of these:
https://bugs.archlinux.org/index.php?string=dcronproject=1
Mostly https://bugs.archlinux.org/task/18681


Greg


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Lukáš Jirkovský
 I'm still trying to understand WHY we suddenly feel the need to replace dcron
 when its not even broken.

Actually dcron is broken quite badly. Sometimes the cron job is run
several times in a row, sometimes it's not run at all. The dcron
developer said he will fix it soon, but it was about a year ago and
still nothing.

Lukas


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Ionut Biru

On 04/21/2011 02:18 PM, Heiko Baums wrote:

Am Thu, 21 Apr 2011 08:48:04 +0200
schrieb Sven-Hendrik Haases...@lutzhaase.com:


I second this suggestion. cronie upstream isn't dead at all. cronie
is a drop-in unlike fcron which was favored earlier.


Is it such a drop-in like the new dcron when dcron upstream was adopted
by this Arch user?

Better look at the features and the use cases (don't only think of some
24/7 servers, but also think of the desktop users) and not at some small
differences in the crontab syntax. It's definitely not such a big work
to re-adjust a few crontab entries if this is necessary at all. And this
work has to be done only once and can probably be done with sed.



i think you are not understanding the process.

if cronie is moved in core, it won't have a replaces=dcron. Only new 
installations will get cronie by default instead of dcron.


--
Ionuț


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread C Anthony Risinger
On Thu, Apr 21, 2011 at 2:33 PM, Ionut Biru ib...@archlinux.org wrote:
 On 04/21/2011 02:18 PM, Heiko Baums wrote:

 Am Thu, 21 Apr 2011 08:48:04 +0200
 schrieb Sven-Hendrik Haases...@lutzhaase.com:

 I second this suggestion. cronie upstream isn't dead at all. cronie
 is a drop-in unlike fcron which was favored earlier.

 Is it such a drop-in like the new dcron when dcron upstream was adopted
 by this Arch user?

 Better look at the features and the use cases (don't only think of some
 24/7 servers, but also think of the desktop users) and not at some small
 differences in the crontab syntax. It's definitely not such a big work
 to re-adjust a few crontab entries if this is necessary at all. And this
 work has to be done only once and can probably be done with sed.


 i think you are not understanding the process.

 if cronie is moved in core, it won't have a replaces=dcron. Only new
 installations will get cronie by default instead of dcron.

personally i can't stand crons at all; IME they are usually used for
hack job workarounds to other problems, and i avoid them at all costs,
preferring boundary triggers or other event-based activation points.
crons tend to end up forgotten and separated from other application
logic.

while i totally agree that a new one is needed if the current one has
such fundamental problems, i'm with the guy that says systemd will
obsolete it anyways.  as far as i'm concerned, `cron` and `init` are
the same program, differing only by _when_ they run stuff.  the power
and flexibility of systemd and it's configuration provide for
unprecedented precision and control over your timed executions.  let's
make a smarter Arch ... init/cron are not smart.

just the other day i had to tweak a debian sqeeze system (which uses
upstart btw) and the LSB scripts + half-baked dependency system was
rather painful IMO, and it made me appreciate the systemd readability
even more ... Arch may end up being the only distro that cares about
sysvinit :-(

not trying to derail the conversation, i just think it's relevant ... when i:

# tree /etc/systemd

i get a nice neat view of what my system will do at boot time, or any
other time.  i haven't had a chance to try it yet, but i believe each
user could potentially have their own ~/unit directory, and systemd
could run stuff from there too.

C Anthony


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Jan Steffens
On Thu, Apr 21, 2011 at 9:33 PM, Ionut Biru ib...@archlinux.org wrote:
 Only new installations will get cronie by default instead of dcron.

+1 from me for replacing dcron like this, but with fcron, not cronie.


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Grigorios Bouzakis
Ionut Biru wrote:
 On 04/21/2011 02:18 PM, Heiko Baums wrote:
 Am Thu, 21 Apr 2011 08:48:04 +0200
 schrieb Sven-Hendrik Haases...@lutzhaase.com:

 I second this suggestion. cronie upstream isn't dead at all. cronie
 is a drop-in unlike fcron which was favored earlier.

 Is it such a drop-in like the new dcron when dcron upstream was adopted
 by this Arch user?

 Better look at the features and the use cases (don't only think of some
 24/7 servers, but also think of the desktop users) and not at some small
 differences in the crontab syntax. It's definitely not such a big work
 to re-adjust a few crontab entries if this is necessary at all. And this
 work has to be done only once and can probably be done with sed.


 i think you are not understanding the process.

 if cronie is moved in core, it won't have a replaces=dcron. Only new 
 installations will get cronie by default instead of dcron.


How is that possible? Are you saying that the broken dcron will stay in
core and there will two packages for cron?
Otherwise i dont understand how it wont be replaced (for all users).


Greg


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Ionut Biru

On 04/22/2011 12:11 AM, Grigorios Bouzakis wrote:

Ionut Biru wrote:

On 04/21/2011 02:18 PM, Heiko Baums wrote:

Am Thu, 21 Apr 2011 08:48:04 +0200
schrieb Sven-Hendrik Haases...@lutzhaase.com:


I second this suggestion. cronie upstream isn't dead at all. cronie
is a drop-in unlike fcron which was favored earlier.


Is it such a drop-in like the new dcron when dcron upstream was adopted
by this Arch user?

Better look at the features and the use cases (don't only think of some
24/7 servers, but also think of the desktop users) and not at some small
differences in the crontab syntax. It's definitely not such a big work
to re-adjust a few crontab entries if this is necessary at all. And this
work has to be done only once and can probably be done with sed.



i think you are not understanding the process.

if cronie is moved in core, it won't have a replaces=dcron. Only new
installations will get cronie by default instead of dcron.



How is that possible? Are you saying that the broken dcron will stay in
core and there will two packages for cron?
Otherwise i dont understand how it wont be replaced (for all users).




if this will happen, the steps are very simple
1) remove dcron from core
2) add cronie/fcron to core in base group and depending on the package, 
it might have conflicts=dcron but not replaces


this way the existent systems will still have a working cron and new 
installations will have the new cron



--
Ionuț


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Grigorios Bouzakis
Ionut Biru wrote:
 On 04/22/2011 12:11 AM, Grigorios Bouzakis wrote:
 Ionut Biru wrote:
 On 04/21/2011 02:18 PM, Heiko Baums wrote:
 Am Thu, 21 Apr 2011 08:48:04 +0200
 schrieb Sven-Hendrik Haases...@lutzhaase.com:

 I second this suggestion. cronie upstream isn't dead at all. cronie
 is a drop-in unlike fcron which was favored earlier.

 Is it such a drop-in like the new dcron when dcron upstream was adopted
 by this Arch user?

 Better look at the features and the use cases (don't only think of some
 24/7 servers, but also think of the desktop users) and not at some small
 differences in the crontab syntax. It's definitely not such a big work
 to re-adjust a few crontab entries if this is necessary at all. And this
 work has to be done only once and can probably be done with sed.


 i think you are not understanding the process.

 if cronie is moved in core, it won't have a replaces=dcron. Only new
 installations will get cronie by default instead of dcron.


 How is that possible? Are you saying that the broken dcron will stay in
 core and there will two packages for cron?
 Otherwise i dont understand how it wont be replaced (for all users).



 if this will happen, the steps are very simple
 1) remove dcron from core
 2) add cronie/fcron to core in base group and depending on the package, 
 it might have conflicts=dcron but not replaces

 this way the existent systems will still have a working cron and new 
 installations will have the new cron


Has that ever happened before?
That means the existing systems will have a package from base thats not
supported by the Arch developers.
But since its not replaced, it would make it an infinite part of Arch so
it should also be supported.
Plus, the 2010.05 ISOs will still (try to) install it, but it wont be
there, and there wont be an upgrade path either.
Anyway, first time i've heard about such a plan. It makes absolutely no
sense to me. I seriously doubt its gonna work. But good luck.


Greg


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Dimitrios Apostolou

On Thu, 21 Apr 2011, Grigorios Bouzakis wrote:

Because of these:
https://bugs.archlinux.org/index.php?string=dcronproject=1
Mostly https://bugs.archlinux.org/task/18681


The run many times per day bug hasn't bitten me since months ago. And I 
used to see it really often. Maybe it is fixed?



Dimitris



Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Kaiting Chen
On Apr 21, 2011, at 17:30, Grigorios Bouzakis grb...@xsmail.com wrote:

 Ionut Biru wrote:
 On 04/22/2011 12:11 AM, Grigorios Bouzakis wrote:
 Ionut Biru wrote:
 On 04/21/2011 02:18 PM, Heiko Baums wrote:
 Am Thu, 21 Apr 2011 08:48:04 +0200
 schrieb Sven-Hendrik Haases...@lutzhaase.com:
 
 I second this suggestion. cronie upstream isn't dead at all. cronie
 is a drop-in unlike fcron which was favored earlier.
 
 Is it such a drop-in like the new dcron when dcron upstream was adopted
 by this Arch user?
 
 Better look at the features and the use cases (don't only think of some
 24/7 servers, but also think of the desktop users) and not at some small
 differences in the crontab syntax. It's definitely not such a big work
 to re-adjust a few crontab entries if this is necessary at all. And this
 work has to be done only once and can probably be done with sed.
 
 
 i think you are not understanding the process.
 
 if cronie is moved in core, it won't have a replaces=dcron. Only new
 installations will get cronie by default instead of dcron.
 
 
 How is that possible? Are you saying that the broken dcron will stay in
 core and there will two packages for cron?
 Otherwise i dont understand how it wont be replaced (for all users).
 
 
 
 if this will happen, the steps are very simple
 1) remove dcron from core
 2) add cronie/fcron to core in base group and depending on the package, 
 it might have conflicts=dcron but not replaces
 
 this way the existent systems will still have a working cron and new 
 installations will have the new cron
 
 
 Has that ever happened before?
 That means the existing systems will have a package from base thats not
 supported by the Arch developers.
 But since its not replaced, it would make it an infinite part of Arch so
 it should also be supported.
 Plus, the 2010.05 ISOs will still (try to) install it, but it wont be
 there, and there wont be an upgrade path either.
 Anyway, first time i've heard about such a plan. It makes absolutely no
 sense to me. I seriously doubt its gonna work. But good luck.
 
 
 Greg

Things have got to be deprecated eventually. Why can't we keep dcron in [core] 
for a while longer? And remove it when any install media that requires it 
becomes unsupported?

Kiwis and Limes: http://kaitocracy.blogspot.com/

Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Evangelos Foutras
On 22/04/11 00:30, Grigorios Bouzakis wrote:
 Ionut Biru wrote:
 if this will happen, the steps are very simple
 1) remove dcron from core
 2) add cronie/fcron to core in base group and depending on the package, 
 it might have conflicts=dcron but not replaces

 this way the existent systems will still have a working cron and new 
 installations will have the new cron

 
 Has that ever happened before?
 That means the existing systems will have a package from base thats not
 supported by the Arch developers.

The package will no longer be in the 'base' group, and most likely end
up in the AUR. Therefore, it will not be a supported package, and the
output of `pacman -Qm' will reflect that.

 But since its not replaced, it would make it an infinite part of Arch so
 it should also be supported.

As I mention above, my understanding is that dcron will be moved to the AUR.

 Plus, the 2010.05 ISOs will still (try to) install it, but it wont be
 there, and there wont be an upgrade path either.

In offline installations, the package will exist on the installation
media. On netinstalls, the new cron daemon will get installed to the
target system instead.

 Anyway, first time i've heard about such a plan. It makes absolutely no
 sense to me. I seriously doubt its gonna work. But good luck.


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Grigorios Bouzakis
Kaiting Chen wrote:
 On Apr 21, 2011, at 17:30, Grigorios Bouzakis grb...@xsmail.com wrote:

 Ionut Biru wrote:
 On 04/22/2011 12:11 AM, Grigorios Bouzakis wrote:
 Ionut Biru wrote:
 On 04/21/2011 02:18 PM, Heiko Baums wrote:
 Am Thu, 21 Apr 2011 08:48:04 +0200
 schrieb Sven-Hendrik Haases...@lutzhaase.com:
 
 I second this suggestion. cronie upstream isn't dead at all. cronie
 is a drop-in unlike fcron which was favored earlier.
 
 Is it such a drop-in like the new dcron when dcron upstream was adopted
 by this Arch user?
 
 Better look at the features and the use cases (don't only think of some
 24/7 servers, but also think of the desktop users) and not at some small
 differences in the crontab syntax. It's definitely not such a big work
 to re-adjust a few crontab entries if this is necessary at all. And this
 work has to be done only once and can probably be done with sed.
 
 
 i think you are not understanding the process.
 
 if cronie is moved in core, it won't have a replaces=dcron. Only new
 installations will get cronie by default instead of dcron.
 
 
 How is that possible? Are you saying that the broken dcron will stay in
 core and there will two packages for cron?
 Otherwise i dont understand how it wont be replaced (for all users).
 
 
 
 if this will happen, the steps are very simple
 1) remove dcron from core
 2) add cronie/fcron to core in base group and depending on the package, 
 it might have conflicts=dcron but not replaces
 
 this way the existent systems will still have a working cron and new 
 installations will have the new cron
 
 
 Has that ever happened before?
 That means the existing systems will have a package from base thats not
 supported by the Arch developers.
 But since its not replaced, it would make it an infinite part of Arch so
 it should also be supported.
 Plus, the 2010.05 ISOs will still (try to) install it, but it wont be
 there, and there wont be an upgrade path either.
 Anyway, first time i've heard about such a plan. It makes absolutely no
 sense to me. I seriously doubt its gonna work. But good luck.
 
 
 Greg

 Things have got to be deprecated eventually.

If/when they cease to work, or simply don't cover people's needs,
naturally.

Why can't we keep dcron in [core] for a while longer?
And remove it when any install media that requires it becomes
unsupported?

I didn't say you can't keep it in core. This discussion keeps coming up
every few months because apparently dcron doesn't work correctly so the
question should be is there any reason to keep it? and not the
opposite. No matter how much time 'a while longer' is you'll always have
to replace it with something that provides the same functionality in
order to avoid the stuff i wrote above.
Removing a package from the repos has happened many times before and
will happen again but its very different removing eg. catalyst than
removing a package from core, let alone base.
A package from base is a package that you assume its present on every
system. A package that part of base is obviously a very important part
of the system. You can't just remove it or choose to ignore its there.

Does dcron work? Yes? Then stick to it. No? Then replace it with
something that works.

PS. If cron is deprecated in favour of systemd which is so awesome, why
is Red Hat paying someone to work on cronie?


Greg


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Grigorios Bouzakis
Evangelos Foutras wrote:
 On 22/04/11 00:30, Grigorios Bouzakis wrote:
 Ionut Biru wrote:
 if this will happen, the steps are very simple
 1) remove dcron from core
 2) add cronie/fcron to core in base group and depending on the package, 
 it might have conflicts=dcron but not replaces

 this way the existent systems will still have a working cron and new 
 installations will have the new cron

 
 Has that ever happened before?
 That means the existing systems will have a package from base thats not
 supported by the Arch developers.

 The package will no longer be in the 'base' group, and most likely end
 up in the AUR. Therefore, it will not be a supported package, and the
 output of `pacman -Qm' will reflect that.

 But since its not replaced, it would make it an infinite part of Arch so
 it should also be supported.

 As I mention above, my understanding is that dcron will be moved to the AUR.

 Plus, the 2010.05 ISOs will still (try to) install it, but it wont be
 there, and there wont be an upgrade path either.

 In offline installations, the package will exist on the installation
 media. On netinstalls, the new cron daemon will get installed to the
 target system instead.


An unsupported package installed by the official installation media.
Like i said it doesnt make sense to me. But you got a plan. So just go
with it. And hopefully there'll never be another debate about cron
around here in the future.


Greg


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Allan McRae

On 22/04/11 10:18, Grigorios Bouzakis wrote:

An unsupported package installed by the official installation media.
Like i said it doesnt make sense to me. But you got a plan. So just go
with it. And hopefully there'll never be another debate about cron
around here in the future.



There is actually a plan?  I though there was just a bunch of talk so far...




Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Heiko Baums
Am Thu, 21 Apr 2011 22:33:57 +0300
schrieb Ionut Biru ib...@archlinux.org:

 i think you are not understanding the process.
 
 if cronie is moved in core, it won't have a replaces=dcron. Only new 
 installations will get cronie by default instead of dcron.

I understand this exactly. But I still have the feeling that making
cronie as the default cron daemon could be a mistake.

I also know that the question is just about a default for new
installations and not about having just only one cron in the repos.
Nevertheless those features and use cases should be taken into
consideration because Arch Linux is not only installed on 24/7 servers
but also on desktops. So a default cron daemon should fit both needs
and not only one.

Heiko


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Norbert Zeh
Dimitrios Apostolou [2011.04.22 0126 +0300]:
 On Thu, 21 Apr 2011, Grigorios Bouzakis wrote:
 Because of these:
 https://bugs.archlinux.org/index.php?string=dcronproject=1
 Mostly https://bugs.archlinux.org/task/18681
 
 The run many times per day bug hasn't bitten me since months ago.
 And I used to see it really often. Maybe it is fixed?

Nope.  Just saw it yesterday.

N.


[arch-general] Myths and reality about cronie

2011-04-21 Thread Kaiting Chen
I've compiled a short document describing exactly what cronie is and is not;
and if it were to be the default what would and would not happen to base,
[core], and the rest of Arch. It is my hope that this will clear up some of
the misunderstanding surrounding the current discussion on arch-general.

First of all the cronie in [community-testing] is compiled with
--enable-anacron. It installs not only an /etc/crontab but also an
/etc/anacrontab. Scripts in '/etc/cron.hourly' are run directly by
`/usr/sbin/crond` while scripts in '/etc/cron.daily', '/etc/cron.weekly',
and '/etc/cron.monthly' are run by indirectly by `/usr/sbin/crond` through
`/usr/sbin/anacron`.

Therefore it will accommodate both machines that are run continuously and
machines that are not.

Second cronie will in no way `replaces=('dcron')` but will most likely
`conflicts=('dcron')`. Therefore while it will be impossible to install both
on the same system having cronie in [core] will in no way force existing
users to switch.

Third if cronie is picked up as the default it will enter the 'base' group
while 'dcron' will leave the 'base' group. In the foreseeable future there
will never be a situation in which a package that is not in [core] is in
'base'.

Next it is absolutely not the case that every package in 'base' is critical
to the operation of a machine. For example 'reiserfsprogs' is in 'base' but
unless you have a ReiserFS filesystem then you don't need it. Every package
in 'base' is however installed by default.

Please note that the following point is my opinion and does not in any way
necessarily represent anyone else's point of view: At no point in time in
the near future will 'systemd' become the default on Arch. It may certainly
enter [extra] or [core], but sorry Thomas and falconindy, I just don't see
it becoming the default for a while. Therefore waiting for 'systemd' to
become the new default to replace 'dcron' is a serious mistake as we would
be waiting a very very long time. --Kaiting.

-- 
Kiwis and Limes: http://kaitocracy.blogspot.com/


Re: [arch-general] Change Arch's default crond

2011-04-21 Thread Loui Chang
On Thu 21 Apr 2011 10:46 +0200, Lukas Fleischer wrote:
 On Thu, Apr 21, 2011 at 02:32:42AM -0400, Kaiting Chen wrote:
  So what's the status here? I pulled cronie into [community-testing]
  a couple of days ago and will probably merge it into [community]
  soon. So that's the one I vote.
  
  But regardless of which one we choose in my opinion the sooner we
  get rid of dcron the better. --Kaiting.
 
 I don't want to be pedantic, but what's the point of that? Moving
 arbitrary cron daemons that no one uses to [community] is nonsense
 (according to the TU guidelines, you shouldn't even have moved it
 without prior discussion and consensus on aur-general at all - but as I
 said before, I don't want to be pedantic here...)

This is supposed to be a rule, not just a guideline.
The rule doesn't exactly apply to [community-testing].
Perhaps it should?

https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#Rules_for_Packages_Entering_the_.5Bcommunity.5D_Repo



Re: [arch-general] Myths and reality about cronie

2011-04-21 Thread Heiko Baums
Am Thu, 21 Apr 2011 21:07:35 -0400
schrieb Kaiting Chen kaitocr...@gmail.com:

 First of all the cronie in [community-testing] is compiled with
 --enable-anacron. It installs not only an /etc/crontab but also an
 /etc/anacrontab. Scripts in '/etc/cron.hourly' are run directly by
 `/usr/sbin/crond` while scripts in '/etc/cron.daily',
 '/etc/cron.weekly', and '/etc/cron.monthly' are run by indirectly by
 `/usr/sbin/crond` through `/usr/sbin/anacron`.

And this is one of the main problems with cronie. It needs a separate
/etc/anacrontab for anacron jobs. And this makes it more complicated as
necessary. Fcron only needs one fcrontab for every job. To use the
anacron feature it just needs to be added a bootrun in front of the
line. This way tasks are run as usual cron jobs if the system is up and
as anacron jobs if the system is down. This fits all needs in one, the
needs of 24/7 servers and the needs of desktop systems.

Cronie is nothing else than two different daemons, cron and anacron, put
into one binary but with exactly the same complicated functionality
and configuration.

And the scripts in /etc/cron.{hourly,daily,weekly,monthly} are run
directly by fcron, too. And by default there is a bootrun in front of
the fcrontab lines which tell fcron when to run those scripts.

Another point: fcron is very well documented while there's no
documentation about cronie, not even a feature list and comparison.

Heiko