Package Details: dcron 4.5-8

Git Clone URL: https://aur.archlinux.org/dcron.git (read-only, click to copy)
Package Base: dcron
Description: dillon's lightweight cron daemon
Upstream URL: http://www.jimpryor.net/linux/dcron.html
Licenses: GPL
Conflicts: cron
Provides: cron
Submitter: xyproto
Maintainer: ptchinster
Last Packager: andy5995
Votes: 36
Popularity: 0.001325
First Submitted: 2013-01-24 14:33 (UTC)
Last Updated: 2021-07-09 18:35 (UTC)

Dependencies (2)

Required by (18)

Sources (2)

Latest Comments

lamarpavel commented on 2021-06-24 07:43 (UTC) (edited on 2021-06-24 07:44 (UTC) by lamarpavel)

From the manpage:

Only users who belong to the same group as the crontab binary will be able to install or edit crontabs.

The PKGBUILD suggests that the group users is used, but that group is no longer used by default archlinux, so all users will have to be manually added to the group in order to use crontab. At the same time, the binary is installed with a GID of 985 (on my systems), which differs from the default GID of users (100 on all my systems).

I suggest that the PKGBUILD should create the group cron and install the binary with that GID.

giddie commented on 2018-05-22 07:46 (UTC)

Great! I think the issues / pull requests can be made here:

https://github.com/dubiousjim/dcron

The website for dcron is at: http://www.jimpryor.net/linux/dcron.html

ashkan commented on 2018-05-22 00:55 (UTC)

I noticed a mistake in the crontab manpage but I can't seem to figure out where the proper place to submit a bug or PR would be since this package is quite old and it's hosted on the archlinux git repository. (Specifically the location of the timestamp files is not /var/spool/cron/cron-stamps/user.jobname but /var/spool/cronstamps/user.jobname)

x33a commented on 2016-02-15 06:44 (UTC)

@mnovick1988, done.

EndlessEden commented on 2016-02-14 04:35 (UTC)

please add armv7h, as well. (RPI-2)

x33a commented on 2015-06-17 11:06 (UTC)

Updated PKGBUILD. Now it explicitly mentions armv6h instead of any. Thanks all.

giddie commented on 2015-06-17 10:58 (UTC)

Oh yeah, sorry: I think I misunderstood your question. Yeah, it shouldn't be a problem to do this on the AUR, as the AUR isn't officially supported anyway, so I'd say we're free to put whatever we like in arch. I've done this for a couple of my packages.

x33a commented on 2015-06-17 10:58 (UTC)

Yes, I know about the syntax. But I was thinking about the guidelines. But apparently, it is fine to include other architectures in AUR packages since AUR is unsupported as a whole. Reference: https://bbs.archlinux.org/viewtopic.php?id=160737

giddie commented on 2015-06-17 10:56 (UTC)

It should be an array, like this: arch=('i686' 'x86_64' 'armv6h')

x33a commented on 2015-06-17 10:54 (UTC)

Thanks guys for the explanation. So, would it be fine if I put armv6h in the PKGBUILD, since Arch doesn't officially support anything other than i686 and x86_64?

giddie commented on 2015-06-17 10:52 (UTC)

The arch field doesn't describe the code; it describes the *package*. Once the package is built, it will declare "arch=any", but that's not the case: it contains a compiled binary, which ties it to a specific architecture. If I understand correctly, makepkg will choose the build arch from the list in the PKGBUILD, and that arch will be used for the package metadata. Using "any" in the PKGBUILD means that the package will be marked as suitable for "any", which is misleading.

JonnyJD commented on 2015-06-17 10:52 (UTC)

@x33a: running namcap on the any.pkg.tar.xz gives: dcron E: ELF file ('usr/sbin/crond') found in an 'any' package. dcron E: ELF file ('usr/bin/crontab') found in an 'any' package.

JonnyJD commented on 2015-06-17 10:50 (UTC)

@x33a: This is not about archicture specific _code_. The resulting binary package contains an ELF executable and is different for different architectures. So the binary package is not architecture independent, which is exactly what "any" in the PKGBUILD would mean.

x33a commented on 2015-06-17 10:47 (UTC)

@lilydjwg, can you point out any architecture specific code in dcron?

lilydjwg commented on 2015-06-17 07:34 (UTC)

I don't think "arch" should be "any". From man 5 PKGBUILD: arch (array) Defines on which architectures the given package is available (e.g., arch=('i686' 'x86_64')). Packages that contain no architecture specific files should use arch=('any'). But the dcron package contains architecture-specific binaries. It will harm anyone who tries to distribute built packages to different architectures, e.g. unofficial repositories and package cache for multiple systems.

x33a commented on 2015-06-17 06:08 (UTC)

@respiranto, I have changed the "arch" field to any.

x33a commented on 2015-06-14 04:51 (UTC)

@respiranto, will do that shortly. First I need to find some time to port the package to AUR4.

respiranto commented on 2015-06-13 18:40 (UTC)

Works fine on my raspberry-pi (armv6h). Could you add armv6h to the PKGBUILD? Or maybe even 'any'?

unnamed11 commented on 2014-02-05 18:16 (UTC)

nice, thank you

commented on 2013-07-20 14:36 (UTC)

x33a commented on 2013-07-06 08:39 (UTC)

Adopted Package. Updated for the /usr move. Removed rc.d script. For anyone still using initscripts, you can get the rc.d script from this package. https://aur.archlinux.org/packages/rcdscripts-aic/

JonnyJD commented on 2013-06-10 13:49 (UTC)

I added the complete source package files to my repository: https://github.com/JonnyJD/PKGBUILDs/tree/master/dcron These are the changes by x33a and ponsfoot. @giddie: root's cron is changed with x33a's change, but installed normally as /var/spool/cron/root.pacnew Hopefully the AUR package gets updated soon.

ToLo commented on 2013-06-05 16:27 (UTC)

@ponsfoot & @giddie, thanks for pointing me in the right direction

giddie commented on 2013-06-05 09:38 (UTC)

You also might want to consider altering the crontab for root, which currently runs /usr/sbin/run-cron for each interval.

ponsfoot commented on 2013-06-05 04:08 (UTC)

@ToLo: Yes. The following is a patch for service and x33a's PKGBUILD: http://pastebin.com/jcfMqbp0

ToLo commented on 2013-06-04 20:41 (UTC)

I think dcron.service (service) must be modified too, or am I wrong? The best thing is to stop the daemon before updating the package an than to restart the service? greetings

giddie commented on 2013-06-04 09:00 (UTC)

I found it easier to add the following after "make install": mv "$pkgdir"/usr/sbin/* "$pkgdir"/usr/bin/ rmdir "$pkgdir"/usr/sbin That way, you're sure you don't miss anything :) The run-cron install line had to be tweaked from sbin to bin as well, of course.

x33a commented on 2013-06-03 16:22 (UTC)

Well, spoke too soon. The root crontab shipped with the upstream package had run-cron under /usr/sbin, which led to job failure. Also changed sendmail to /usr/bin. Here's the final (hopefully) updated PKGBUILD. https://gist.github.com/anonymous/5699296

x33a commented on 2013-06-03 14:44 (UTC)

@ lilydjwg, your PKGBUILD gave this error. ==> ERROR: PKGBUILD contains CRLF characters and cannot be sourced. You created this on windows (Notepad)? Anyway, changing it to unix (LF) fixed it. It works fine, thanks. Here's the fixed PKGBUILD: https://gist.github.com/anonymous/5698637

lilydjwg commented on 2013-06-03 13:42 (UTC)

Hi, here's an updated PKGBUILD moving all /usr/sbin files to /usr/bin: http://pastebin.com/5Q7UYybu

kachelaqa commented on 2013-05-31 22:58 (UTC)

This package currently installs some files in /usr/sbin, and so will be affected by the changes to /usr which are coming soon: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-May/025003.html To avoid problems, it would be a good idea to fix the pkgbuild now so that the affected files are installed in /usr/bin instead.

xyproto commented on 2013-01-24 14:37 (UTC)

Moved from [community] in connection with the Winter Cleanup. http://www.mail-archive.com/arch-dev-public@archlinux.org/msg20678.html